We know how to shave those valuable seconds of your site’s load time. If you have a web site that’s terribly slow or just not fast enough and want to stop losing money as a result, we’re the team for that.

Optimize the Performance of Widgets, Buttons & More

A recent post by web site performance thought leader (and user experience expert as a result) Steve Souders reminds me of a vital nuance that’s not even clearly expressed in the popular Yahoo! performance rules; namely render the page first, THEN add JavaScript. One of the largest challenges with this objective is addressing the performance of 3rd party resources. With social media demanding more widgets, plugins, badges and buttons etc available every day and a lack of awareness on the part of developers about how to make sure that their buttons are as effective and valuable as possible, sometimes performance concerns are overlooked.

Ask yourself, what is the value of lost visitors due to a slow loading web site? There are literally page views “locked” away in those slow loading pages of your web site that can be “unlocked” with a few quick changes. Simply put, having numerous 3rd party elements in your site can ultimately be its downfall.

For example, simply adding the Facebook fan box will dramatically slow a page in many cases, slow down the browsers due to large memory usage and usually lots of additional download time making the page “not ready” until everything is downloaded. So if your goal is to optimize your site for social media and make sure that your bounce rates are low, time on site is high, page views per visit grows and Google has 1 less reason to rank your site poorly, keep reading.

So, let’s take a look at the implementations you need for your site that make sure your visitors see your content before your widgets. From an idealistic point of view the “start render time,” or when the browser actually starts to paint the page, these tips will not bring this value as close to zero as I would like, however they will definitely improve user experience. Keep in mind that there are numerous other steps to be taken or possibilities, but we’re focusing on reducing the negative impact of widgets characterized above. What follows is HTML5 code for various cases:

Digg:After working with Digg on some their latest improvements, I’m happy to share an implementation that is much more user-centric; if you have multiple buttons per page, this is especially valuable:

This implementation allows the page to render and then draws the buttons later.

StumbleUpon:SU, has recently updated their buttons, which is good, but what follows is not truly asynchronous and definitely not as optimal as the Digg button above because of the multiple JS embeddings per page, at least this implementation won’t block the page render. First position the button with a unique ID wherever you wish:

[html]
<div id="id"></div>
[/html]

Then for each button make sure that an embedding exists above </body> so the button will be rendered in the location:

Tweetmeme:I still recommend this service because it also generates a usable button for feeds you may syndicate, while the official twitter button still does not. The best way to use this widget is via <iframe> as iframes do not block the render of a page, too many though can still slow down a page render or cause other anomalies in some browsers. Anyway, here’s what that implementation looks like:

Twitter:The official twitter button works pretty well, it doesn’t have retweet data for everything ever shared on your site as they only started gathering that data when they launched the button (so use tweetmeme for those older stories if you can), but it does have a reliable sharing experience for users, just make sure that if you use the following implementation:

You can of course use a technique similar to LinkedIn or Digg, but the JS will actually create an <iframe> anyway, so this approach is more performance as it won’t block the page render and yields the same net result. For those using @anywhere to add hovercards and other twitter functionality to their sites, the technique that apples for Diff of LinkedIn can be applied.

ShareThis:
Among the most popular buttons available, their implementation has dramatically improved as the total payload for JavaScript has been reduced, although the script loads synchronously still unfortunately. On the positive side, the buttons are decoupled from the scripts that embed them. The instructions recommend adding the scripts to the <head>, but I recommend adding them before </body> or after <body> if you’re having any problems.

Google Friend Connect (AdSense & Gadgets):
It’s critical to remember that you only need to embed the Friend Connect JS library once per page. If you’re minifying the file be sure to make sure your cache is frequently updated as the code is changed quite often and an old cache may cause anomalies on your site. The reason why this tip is notable is that this implementation supports AdSense as well as all of the other Gadgets with a single embed, so if you have multiple AdSense placements in a page, this is the way to go:

Then you can obviously embed numerous other placements or gadgets all powered by a single JS embedding. Unfortunately the JS embedding is not asynchronous, but at least it’s better than having lots of AdSense JS calls throughout a page or even additional calls for your gadgets.

Facebook Share / Facebook Like / Other Facebook plugins:Use the XFBML implementation described on the various plugin pages; this implementation does interfere with page render and positioning it after the <body> tag means that each of the plugins used in a given page will load at the same time as soon as the scripts have loaded. No need for multiple scripts, which have to be downloaded repeatedly and slow down the page render etc etc.

Meebo Bar:Meebo has actually taken a number of strides (with the consult of Steve Souders as well) to improve the performance of their meebo bar; still it’s something more for users to download and more JavaScript to be run in your visitor’s browser, but I can now actually recommend this for publishers looking to increase engagement and create new monetization opportunities for their site. Their implementation is fully asynchronous and has a number of optimizations compared to earlier version. The latest implementation documentation at their site is the best reference.

OpenX:The OpenX team has promised some an asynchronous embedding code for their single page call (SPC) implementation, which basically means that multiple ads in a given page can be requested without blocking the page render and are requested at once instead of sequentially, however for the moment, this is the best implementation I can recommend. It also uses iframes to alleviate render-blocking issues as well some:

I recommend adding this 1.3K of (closure compiler optimized) code directly in the <head> of the page to power the widgets. It’s small enough that it is faster than making another HTTP transaction (DNS lookup, connect, download, execute etc) for this purpose, the original file is here:

Because of the various use cases and implementations supported I do recommend OpenX, but depending on the size and needs of your site/organization Google’s offerings are far more robust and will eventually perform better than they do now.

Google DoubleClick for Publishers (formerly Google Ad manager):If your site is monetized with AdSense as well as various types of ad formats or networks, Google DFP is a great solution, however for now, it actually creates a negative experience for users depending on the quantity and type of ads being displayed. Instead of embedding the snippet in the <head> of the page, instead embed it after <body> and make sure note that this implementation uses the single request command to make the render more responsive:

Then place your ad slots as you normally would in your page template. I’m definitely looking forward better performing implementation for Google DFP, ads are not optional for many publishers today and ironically they are actually causing publishers to lose money.

BuySellAds:
If you monetize your site using BSA, and still have not switched to their asynchronous embed code, make sure you do, your users will appreciate seeing the content they’re after without delay.

Woopra:
Woopra Analytics not only has a decent WordPress plugin, they also now have an asynchronous tracking code implementation (which is not yet available in the WordPress plugin at the time of this writing). Being that it’s actually asynchronous, I recommend embedding it in the <head> of the page manually if you want to capture partial page views:

Wrapping Up:For those buttons, widgets, services etc not covered one of the last remaining rules of thumb (within the scope of this discussion) is to put all scripts that are not essential for functionality of the site (like navigation, but hopefully that’s not the case) above </body> so that they’re not directly interfering with page render. Remember all of the CSS and JS files that exist in <head> must be downloaded and executed before the page can start to render. Note: your mileage may vary, but it’s possible to realize asynchronous performance of some scripts by adding the attribute async to the <script> tag with the value true. Keep in mind that this make break a script so test for yourself.

There are numerous other widgets, advertising networks, statistics and analytics services available, if you don’t see a tip above for the one you use, then reach out to them and find out if they have any performance tips (like asynchronous JavaScript code). Also, don’t forget that if you are able to minify scripts to reduce HTTP transactions, which will be a huge performance win for scripts that support it.

Bonus Tips for WordPress Users:jQuery is used in countless plugins and themes. It’s often out-of-date and every new release includes bug fixes and more importantly performance improvements. The following snippet is useful for your header.php file, it will make sure that your site is always using the latest version of jQuery without having to modify your theme. You’ll also benefit from Google’s content delivery network and using a hostname other than your domain name, meaning that the file will be pipelined (downloaded in parallel) with the other files in the <head> of the page which is faster:

The Wibya bar is nowhere near close to what I'd like from from a performance standpoint at this time, which is why it was deliberately omitted. It's not asynchronous and I've seen it slow down lots of sites. While it's easier to integrate than Meebo, it feels less robust as well and I'm disappointed about the back links they try to place on users sites using the "hidden" <noscript> tag.

I've heard ( on the WordPress Community Podcast of course) that it's better to have social functionality built into your site instead of using a plugin or toolbar, my question is are any of these steps implemented within a WordPress framework such as the Woo Framework since there are social plugins package within their themes? Will I lose stats if I switch off my sharing plugins and switch to placing the code in the single.php file for example?

I'm sorry I can't give a specific comment on this point without reviewing their framework in more detail (which can be arranged). In general use of many WP plugins should be avoided particularly when a user interface is not an imperative.

LOL, while I appreciate the offer of a review, I think you're well out of my price range for a consult. Frederick, you're work here and on the podcast is always tremendously helpful and I've learned so much from you (and Joost)

As a newbie to the aspects of running a blog/site a couple years ago I made, what I consider now, many mistakes in regards to trying out different plugins without thinking about performance, ranking, and overall presentation. I'm still learning new stuff everyday and it's hard to separate the wheat from the chaff if you haven't been knee deep in web design and optimization for years. Thanks for the knowledge, i'll definitely be implementing some of these tips.

There is one thing that you can do that will help all of the head section items to be faster so hopefully the javascript will be down way before the rest of the content, you can "flush" them from the server while it builds the rest of the page…. usually put just after the closing </head> tag

Thanks Andy, for tips like this that don't matter for the buttons, badges, widgets themselves exactly, I already linked to the Yahoo performance rules page in the first paragraph to make sure readers have context of the issues being addressed in the post.

This would help with the tweetmeme button, as the iframe would not get added to the HTML code till after everything else comes down.

Just so others know what the plugin does and don't have to go there, it puts a document.onload statement with a document.write statement encapsulated within it. in the document.write is a the stuff to write the iframe into the HTML.

I made it because iFrames will halt the loading of a page until they have loaded ans was getting all sorts of problems with my vimeo videos not loading quickly enough….

Thank you Frederick, I have added the jquery and swf snippets to my blog and will be looking for a noticeable improvement. I realize that it may not be readily noticeable but trust your advice. I use a social plugin named “Sexy Bookmarks” from Shareaholic. I don’t know if this uses an asynchronous load or not but my load time is a bit slow, may just be the host though?

Thanks for posting this, incredibly helpful and extremely easy to understand. I'd love to see more series on tips/techniques like this to improve sites. Hell, I'd even hire you for some help with that.

Let's hope that those companies that don't provide asynchronous code yet see the light and provide it soon!

Back in the day (2007), I wrote a WordPress plugin called IFrameWidgets, which basically created a text widget that ran as an iFrame. That let you load widgets via an iFrame, so it didn't slow down the page load. You'd have to be careful about which widgets ran in the iFrame, as it would break some of them (such as GA!), but it worked for the slow social widgets of the day (MyBlogLog and BlogCatalog). Some people were worried about the SEO impact, but it's only social widgets not the content.

I'm not actually recommending anyone try this plugin (my plugin skills weren't quite so refined back then). Asynchronous code from the providers is a much better solution and your hacks are a great option in the meantime. Thanks

I understand the concepts, however I’m not that familiar with editing the code. I agree that the Facebook like button is slow to load but I think the Facebook comments plugin adds to load times too. Don’t you agree? Thanks for these!

Are the implemenationsw above – beyond what your W3 Total Cache does when you minify javascript files and embed them as non blocking before /body, or are they extras steps that one can take – I would not want to cause conflicts with the plugin

Hey Frederick – thanks for this post. Im having trouble in that I just turned on Google DFP and boy is it slow. I implemented it according to what you have above but Im not sure how to handle the multiple slots in terms of where you say – “uses the single request command to make the render more responsive”

Do you know of any ways to tweak it further to help with load times? I’ve got multiple slots which ends up looking like this:

Is there a way to combine all of these so that you arent listing the adsense pub ID for each? Perhaps that doesnt matter but would love to figure out some way to make this faster.

Thanks in advance for any advice you can offer on this front. Thanks again.

The score on Firebug/YSlow(V2) of my home-made little website increased from 77 to 86 only by implementing these suggestions for facebook, LinkedIn and Twitter like buttons and facebook comment wall. Thanks a lot!

When I look at my load times, the social buttons (along with ads) seem to be some of the most complex and time consuming. Makes a lot of sense to load them, when possible, in places that don’t affect page rendering. Page loading speed is super important (just think of how impatient you are!). Have linked a resource (above) with about 15 sites to grade your blog speed and performance. It’s kind of fun to see how fast the world gets to your site.

Thanks Frederick for sharing this in detail. I finally found this useful tips. Hope after apply all the tweaks, it will help my site improve the performance. You almost covered all the necessary information i needed. Once again, thanks.

All of those social buttons are evil… You want 5 buttons – here you go – load additionally 5 javascripts that will load 5 iframes with tons of images / css inside with repeating javascript functions snd similar images / styles… So inefficient…

Simply fantastic.
I not realizing anything about encoding, but this tutorial is so good and easy to understanding that was fairly simple to implement on my website.
Great post Frederick !
Thanks a lot!

[…] them are lacking the script tag. Back in february, Frederick did an awesome post on his blog about optimizing the performance of widgets & buttons. I used the knowledge in this post, but took it a few steps further.Loading these Social Buttons […]

[…] them are lacking the script tag. Back in february, Frederick did an awesome post on his blog about optimizing the performance of widgets & buttons. I used the knowledge in this post, but took it a few steps […]