We hear it all the time:
Why do you recommend a 6 hour budget for a simple integration? Here's an embed widget right here -- if this were WordPress I could do it myself!
Well, in Drupal you can do it yourself, exactly the same way you might in WordPress. Add a block, use an input format that doesn't strip out Javascript, paste in your code, put the block where you want it on your page, and away you go.
It's pretty spectacular what you can do by mashing up a bunch of widgets on a webpage these days. There are tens of thousands of "software as a service" providers that provide embeddable widgets you can put on your site, and have all kinds of cool things: Twitter feeds, Google Ads, Facebook Likes, analytics (a.k.a spying on your visitors), maps, upcoming event widgets, data collection forms, CRM capture forms, live cam feeds, games -- the list is endless.
But... this entire approach has a dark side. Several of them, in fact!
It hurts your page load speed, and potentially loses visitors
Google takes page load speed into account when indexing your page. Very slow-to-load pages are penalized in search engines, largely because they've learned that people don't stick around waiting for pages to load.
We check the page load times for our maintenance customers each month, checking times for both an "Empty cache" (e.g. the first time a visitor loads a page from your site) and a "Primed cache" (e.g. subsequent page views). We aim to get the empty cache load time under 6 seconds, and a primed cache load time under 1 second if possible, through a combination of tuning the server, minimizing the number of requests done on the page before it renders, and other optimizations. In the page loads of this particular site, you can see we're a very long ways from those targets! 
In this case, the page is full of images, and the server could use some tuning to deliver those faster. But a big part of the primed cache problem is how many different external services are getting loaded on the page. This is a substantial e-commerce site doing a healthy business, and it has scripts from 9 external services embedded on the page. Many of these load additional pages inside the main page, which then load more scripts and images... and usually all of this needs to load before the visitor sees the page as it's designed to look!
2 minute load times? I wonder how much business has been lost simply because people don't want to wait that long.
This problem gets far worse on mobile devices, with less powerful browsers, less RAM, sometimes spottier and slower connections...
Sometimes it breaks your site completely
We've had at least 4 or 5 calls in the past few months from customers saying "My site is down! Please get us back up right away!" And it turns out their site is just fine -- but some embedded widget they've added to their page is not loading, and it's blocking the rendering of the page entirely. And these aren't even unusual services -- 3 cases in particular come to mind from big, well known services: Disqus, Google Adwords, and a mobile app vendor.
It might not even be the remote service's fault, it could just be a network issue. But the simple fact is, by using a bunch of different embedded apps on your site, you're making your site dependent on all of them! If any one of them has a problem on a particular day, it can bog down your site entirely, and affect your business!
Do you trust all the sources of these widgets?
Anytime you use code from other sources, you're putting the security of your site at risk. Even reputable, widely used services can introduce malware onto your site. For example, last September there was malware loaded by Google ads that may have been shown to millions of computers, via sites that used Ad words, and that's not the first time. And these are major services run by major companies with a strong security record -- if they can't keep their embeds secure, can you really trust all those other services that don't have those resources?
When you load any script from a server that's not yours, you're trusting that that script is not going to hijack data sent through your page. If you run an e-commerce site, this means they could potentially sniff data like your customer's credit card numbers being typed on the checkout page, or their passwords entered into a login form. Even your password!
You can download and review exactly what the script is doing, but if you don't control the source of that script, it could get changed at some point and you'll never now.
It may not "degrade gracefully"
More and more people are becoming sensitive to their online privacy, and running ad-blockers/script blockers. Have you checked out what happens if you visit your site in a browser configured to block all 3rd party scripts? If you just embed a bunch of widgets on the page, it's quite likely that the experience is very bad... so you're forcing your visitors to give up their privacy to use your service. Do you want to be sensitive to your customers' privacy, or lose that business?
Argh! Enough already! What can we do instead?
First of all, you should probably have a reason for each one of the widgets you want to use on the page. Here is how I would go through and analyze, decide upon a course of action, for each one...
Do I really need this widget?
If you don't need it, ditch it. There's enough noise out there already. Think about what the goals are for each type of user on your site -- prospective customer, prospective employee, current customer, current employee, content editor, business owner, administrator, etc. If a widget does not support the goals of any of your users, get rid of it.
Can I provide a behind-the-scenes integration, instead of using the widget?
If the service in question has a straightforward API, it's often much better to have Drupal send information through the API, rather than having the user's browser load a bunch of uncontrolled Javascript.
For many data collection forms, this kind of approach can solve all of the issues identified above -- the entire interface gets aggregated and can use Drupal's caching to load quickly, nothing visibly breaks if the service is unavailable, you control all the data flow and don't expose anything unnecessary to the 3rd party, and done right it degrades gracefully.
This is why our first response when asked to integrate something is to go check to see if we already have a Drupal module available that we can just turn on to do the integration, or whether we need a few hours to create something new or custom.
This tends to be much more "the Drupal Way", compared to pasting in an embed code!
Can I "do it in Drupal?"
One step further than doing a server-side integration, is to not use the 3rd party service at all, and simply roll your own solution in Drupal.
For really complex integrations (like SalesForce) this can cost less than doing the integration, if you only need the other service for a couple of scenarios -- Drupal is a very powerful platform that can be easily configured to do a lot of CRM-kinds of activities. And there's a huge ecosystem of sometimes pretty complete solutions for event management, mapping, e-commerce, and much more, which put you more in an "Ownership" role rather than a "Renter".
If your needs are complex, this will cost more than using another already-existing service -- but you gain the benefit of complete control over the resulting solution.
How to embed "The Drupal Way"
Sometimes it does make sense to embed scripts and code from other sites. You don't necessarily want to run your own ad server, if Google can fill all your ad slots for you, and that's a big source of your revenue. Lots of specific services for loading fonts, analytics, and more really end up necessitating 3rd party scripts.
Even in those cases, manually embedding code snippets leads to all the issues we identified. By using a Drupal module (either one publicly available on Drupal.org, or a custom one we create for you) you can at least minimize some of those:
- With many of these services, you can download the script to your server where it can be aggregated with the rest of your Javascript and not impact page load speed
- If it's on your server, it's not necessarily subject to the same outages
- If it's on your server you can detect changes to the script and trigger new audits
- If you manage where and how the script is loaded, you can make it run after the page is rendered, and degrade gracefully
These changes aren't always possible, but you can almost always at least improve the amount of control you have over the user experience if something goes awry by bundling it into a Drupal module.
So... Yes, you can just paste in an embed code, really, really quickly. But do you really want to?
Add new comment