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.

But How?

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.

Baseline Test

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.

That such a simple-looking page logged nearly three-dozen requests is a clear demonstration of the impact of those tiny little sharing buttons. Without social media, the page would have topped out at 7 requests, sourced from 1 domain. To produce one button, the building blocks of an entire web page are present, including JavaScript, CSS, HTML, and images.  (For the record, the request totals for each button were: Twitter 13; Google+ 17; Facebook 8).

Introducing Load-on-Mouseover
The idea behind this optimization technique is simple – delay the loading of JavaScript tags until the user’s attention is actually on them. That way, the user gets to interact with a fully functional page much faster, and will hardly notice when the tags do load, since they do so in small batches. In this case, we decided that the user putting the cursor over the article area would be a good trigger. Alternatives include setting a smaller trigger area, such as an image with the word “”Sharing.””

The Scripts

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.

The Tags

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.

Results

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?

The page we used for testing was devoid of heavy CSS, images, and JavaScript (aside from the social sharing buttons themselves). The average website today will have all of the above in abundance. That?s what keeps most sites from having the kind of sub 1-second load times we saw testing the page.

But average sites also have over 100 kb of JavaScript, comprising about a fifth of the total weight of the website. Some have much more. If you delay much of that JavaScript overhead you can see a proportional improvement. For instance, on a site that currently loads in six seconds on average, delaying tags can easily shave 1 second off the average load time.  A one second improvement will seriously affect metrics like conversion rate and bounce rate. 

Summary

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.