What makes this issue even worse is that some of them are only slow intermittently, making identification of the issue more difficult. In this article I’ll show you how you can identify and analyze external services on your site.
#1. What Are External Services
An external service could be considered anything that communicates with your website from outside your own servers. There are a bunch of examples, here are just some common ones:
- Social platforms like Twitter and Facebook
- Ad networks like Google Adsense, Chitika, Clicksor
- Website analytics like Google Analytics and Crazy Egg
- Comment systems like Disqus
- Backup and security like VaultPress
- CDN networks like Amazon Cloudfront, CDN77 and MaxCDN or KeyCDN
#2. How External Services Cause Problems
External services bring with them two problems. One is brought about by sheer volume, the other has to do with waiting until they load.
If you have a lot of external services, you need to load all of them and wait for information from them on each page load. The more calls you have, the more you wait, the higher the load on your own server and the higher chance you have of bumping into the second issue.
In some cases the page load will wait until the data transfer is completed between your site and the external service. If the service is called in the header and there is a service interruption your page will simply refuse to load.
#3. Identifying External Services
Identifying these services is not too difficult. The easiest way is to use the developer console in your browser. Go to your website and press alt+ctr+j to invoke the console. Switch to the network view and reload the website. You should see a list of resources that were loaded.
You can hover over a resource on the left to see its full path or click on it and view the headers tab (like in the screenshot) to see all the details. In the screenshot you can see that the minified version of jQuery was loaded from an external source (http://ajax.googleapis.com).
If you don’t know what an external service is, for example
https://js.stripe.com/v2/ try visiting the URL, going to the main domain (http://stripe.com) or searching for its name in Google. This is a good way to determine if the service is legit. In this case it turns out that Stripe is a pretty well known payment provider, so we’re probably good.
#4. Identifying Issues With External Services
If your website is always slow, you’ll need to figure out what is slowing it down – this is not that difficult. If your website has intermittent issues, that’s a bit more difficult. let’s start with continuous slowness.
Handling Continuously Slow Websites
We’re presuming here that your website is slow because of external services. While many speed issues can be caused by external services, there are a vast amount of other issues, so this may not solve your problems.
First, let’s determine if there is any one service that is taking a long time to load. You can do this in the same console we used earlier. Notice the timeline section at the end of each row. This shows the start and end loading times in the timeline.
You can hover over each bar to see how long each part of the loading process took. The bars look just fine here, you should be looking for extra long bars (compared to the rest) and places where bars only start loading after a particular bar has finished – these are your bottlenecks.
Once you’ve found a specific element that takes too long or prevents other resources from loading, you need to figure out why it is there and where it comes from. This can be a bit difficult, the call to the service could be coded within your theme, or it could come from a plugin.
If you have an issue with an ad network and you have a plugin that handles the ad network for you, chances are that disabling that plugin will get rid of the issue. If it is coded within the theme you’ll need to modify your theme files. I recommend doing both of the following if you are a developer.
Minimizing External Service Loads
If you’re working on code you should always minify and concatenate your scripts. Minification involves getting rid of everything in the code that makes it human-readable and condensing it into a machine-readable, super compact version.
Concatenation is the process of merging multiple files into one. This is useful for reducing the amount of external calls that need to be made.
Instead of grabbing the minified version of jQuery from a CDN, then using your favourite lightbox plugin from your own server and a form validation plugin from another CDN, download all of them and concatenate them into a single file. You can then serve it from your own servers, or upload it to a CDN if you’d like.
Of course un-minified and un-concatenated code is much nicer. What you can do is use a PHP constant to indicate “developer mode”, or even use the
WP_DEBUG constant. If it is set to true you can include all the unminified files one-by-one. If the constant is false you can use the single minified file.
Preventing Stalled Loading
The bigger issue is when a script prevents loading while it finished loading itself. If a script like this is included in the header it can keep your website blank indefinitely. Due to this, anything which is not absolutely necessary in the header should be placed in the footer.
This will allow your website to load fully before the problematic script even begins loading. If you use the
wp_enqueue_script() function (you should), you can use the fifth parameter to indicate that it should load in the footer.
If you notice that a plugin loads an asset in the header without reason you can use
wp_dequeue_script() to remove it from the footer and then use
wp_enqueue_script() to register it in the same way, but in the footer.
Handling Intermittent Issues
The way you solve intermittent issues is the same as the way you solve continuous issues but identifying the culprit is more difficult. Implementing the solutions above could already help, but it would still be nice to know what is causing the issue.
I like to use a tool like GTMetrix to schedule hourly speed checks on my site. After a couple of days you can check back and see the results in a nice little graph:
This tells you when your site was slower than average. I would click on the far right spike first to go into the report created at that point in time. I would then view the waterfall to see which resource created the issue.
There’s one asset in there which seemingly blocks subsequent ones, take a look at the green bar near the middle. Turns out that this is from Google Recaptcha. 632ms may seem like a blink of the eye, but in reality it is a lot. A page really should load in 3 seconds-ish. Almost a third of that is taken up just by this one asset.
The asset should either be loaded later, or it should be ditched in favour of other methods of verification.
External assets can slow a site down quite a bit, but there is a lot that can be done, especially if you involve a programmer. Ditching services, disabling unneeded plugins, concatenating and minifying files will go a long way in making your site a lot faster!