Skip to main content

Digital Marketing

How to Increase Page Performance When Including Multiple Social Widgets

Facebook’s Like, Google’s Plus One, or Twitter’s Tweet buttons are very easy to include on a page with their provided scripts, but they can be very resource intensive when downloading. I recently needed to include a Facebook Like button and Google Plus One button for each tip on a page, and there were pages with 20+ tips on them. On page load, while the social button widgets were rendering, the page would slow to a crawl, occasionally even crashing older browsers like Internet Explorer 7.
That is obviously unacceptable, so I needed to look for a better way. We already use a small JavaScript function to load the social widget scripts once after the page loads, rather than during the page load, as recommended by the fantastic blog post on why loading third party scripts async is not good enough. The code we use for this snippit looks like this (modified slightly from the original at the above blog to allow for a callback function for each script being loaded).
https://gist.github.com/1390496#file_async_onload3rd_party_script_loader.js
Using a script like this solves the page load time (which Google takes into account for SEO and search rankings) but this still didn’t solve the problem on the page in question, as it was the sheer number of widgets being loaded all at once that was causing the issues with the browsers. Thankfully, I saw Doug Neiner give a talk at the Fall 2011 jQuery conference where he discussed “Detecting Probable User Actions” and how you could use the mouseenter event to initialize things like social widgets when the user moves the mouse near the widget in question.
With than in mind, I needed to do two things. One, modify the above code so that it didn’t render the social buttons on page load, but rather waited for an explicit command to render them. Facebook and Google Plus where the only requirements for this, which was good because they both have a way to prevent the scripts from rendering their widgets on load. Twitter doesn’t have that command (or didn’t when I wrote this), so it would have required inserting the Twitter button HTML on each user interaction. Facebook was relatively easy, you just need to change the “#xfbml=1” to “#xfbml=0” in the script URL source (unfortunately, I couldn’t find any documentation on this “feature”). Google Plus requires you to add {“parsetags”: “explicit”} to the body of the script tag.
Once I had this, the rest was fairly simple. I was using the HTML5 format for the Facebook Like, so neither it nor the Google Plus HTML code shows anything until rendered. I made a screenshot of the default state of the Facebook Like button and Google Plus button and set that as a background image on the container div for the social buttons.
Then I setup the following script, which listens for mouseover, and renders the social buttons for both Facebook and Google Plus. I specifically used mouseover rather than mouseenter, so that if the user’s mouse was already over a div, as soon as it moved over another element in that div, it would render the buttons if they don’t already exist. Here is the updated function that sets both scripts to load, but not render on load, and the script to listen for the mouse events:
https://gist.github.com/1927926#file_social_parse.js
This technique is working in Internet Explorer 7,8,9, Firefox 3.6 and the latest versions of Firefox, Chrome, Safari, and Opera. It decreased page load time drastically, making the page responsive to scrolling and other events no matter how many social icons where placed on the page. An enhancement for the above script is that it currently checks against an iFrame being present, and if so, doesn’t fire the render function again. But it should probably have a seperate check for each network.
I would highly recommend using a script like this if you have a page with multiple widgets. There are two minor downsides: there could be a slight flicker if the social button loads slowly and the background image of that button is removed before it finishes loading, and there are no counts for the widgets until the user interacts with the section that includes them. I think both of these issues are trumped by the overall usability of the page, and the overall savings in resources downloaded.

Perficient Author

More from this Author

Categories
Follow Us