Third party tags are bad for web performance.
Tags — the on-page manifestations of web services beloved by online marketers — introduce extra work for the visitor’s browser. Whether it’s for social media integration or even a simple pixel tracker, tags introduce at least one request to a page’s download process. And while a single request might not move the needle on performance, visible/interactive elements like buttons and widgets often add 10 or more requests — each — to a page, causing a multiplicative impact on performance. Loading up a page with these tags leads to slow page loads, choppy scrolling and unresponsive interaction.
But you’re not about to abolish social media integration and tracking from your pages. You’d no sooner incite a full-scale revolt from your marketing team. Plus, the reason these third party services exist is to help your website be better, and they (mostly) accomplish that goal.
Thankfully, there’s a way to have your cake and eat it too: by optimizing the scripts and tags themselves. With optimization you can seriously minimize the performance impact of third-party tags, decreasing page load time and improving user experience. And when a user does want to share (or like, or comment, or chat) he or she will have the capability.
There are several common methods to optimize third party scripts, and in this post we’ll cover one of our favorites: setting social tags to execute on mouseover. We provide some basic tips for getting it done, and assess the technique’s effectiveness with a performance comparison. We’ll also explain how learning this technique also opens the door for using other, similar techniques.
The page we created for testing the technique is a basic WordPress format with three articles, each featuring an image and three social media sharing buttons. The buttons are common editions from Twitter, Facebook, and Google+.
For the first test we used no optimizations, other than to employ the best practice of placing scripts at the end of the load order. This ensures that the most important content, such as the articles, appear for the visitor first, and the widgets load after. While arranging the load order this way is recommended (we wrote an eBook on it, in fact) it generally doesn?t affect the overall load time.
Tested with Chrome, from a North American location, the page loaded in 2.8 seconds. The “”Time to Display”” – when the content was fully visible – was 2.4 seconds. It logged 44 requests sourced from 16 distinct domains.
The first step is to set each of the scripts is to be “”explicit”” so that it won’t load the tags (the visual elements) automatically.
Google: The easiest part of this stage is dealing with the Google+ script. Simply add the word “”explicit”” to the script, as shown below. For the sake of clarity, it’s best to place it directly after the script, as shown.
Facebook: The following is the standard script copied from Facebook social plugins configurator for the “”Like”” button we used in the baseline test.
To make this script explicit we removed ?#xfbml=1? from the js.src, so that it becomes:
There is one more step for Facebook, which is to set up initialization. Add the following code to the Facebook script:
Twitter: Twitter is a bit more complicated, since it doesn’t offer a pre-made “”explicit”” option. To get around this we wrote a script to stop Twitter’s automatic load function by hooking the “”twttr.ready”” function. To do so, add this script before Twitter script tag:
This accomplishes the same result as the””explicit”” instruction: the script will load behind the scenes but the buttons themselves won’t render.
At this point the scripts will load along with the rest of the page, but the tags themselves (the visible parts) won’t. This is a prerequisite to any technique that involves loading social tags on-demand. If you want the tags to load as soon as they become visible in the user’s viewport (known as lazy-loading) this is the first step. Same goes for if you want tags to load on-click – for instance, if you want to create a button that lets users “”opt in?”” to seeing the tags.
In this particular case, we instructed the tags to load when the user moves his or her cursor over the article area. For simplicity’s sake, we used jQuery to listen all article tags- mouseover event. As shown below, when mouseover event fires, it calls loadTag, which loads social tags by invoking functions defined in social scripts.
Now when a user moves his or her cursor on one of the articles, the only the three tags related to that article will load; the rest will not.
After applying this technique, we re-ran the test in the same browser and same location. The results are huge: the page loaded in less than 1 second, an improvement of 66%. The number of total requests went from 44 to 14, a reduction of 68%. Every millisecond counts on the web, and improvements on this scale are enormous.
But will it work on a “”real”” page?
- Social tags like widgets and buttons are costly from a performance standpoint, since they add numerous requests to the page
- Applying the “”load on mouseover”” technique delays breaks up the performance cost into smaller chunks such that they don’t affect the user’s experience when they are loaded
- Our test page loaded significantly faster (66%) after applying the technique
We hope this test demonstrates that better performance can be found even with a single, simple optimization. Combining techniques like this one with image optimization like compression and lazy-loading, minification and concatenation of scripts, and other best practices will make a significant impact on the user experience of your site.