lyteShare.js high-performance social widget for your sharing pleasure

Based on last week’s performance analysis of popular sharing-services (AddThis, ShareThis and Lockerz/AddToAny) I decided to continue working on my high-performance & privacy-respecting but rather ad-hoc lyteShare alternative. The result is a 1.6Kb JavaScript file (or the non-minimized version here) that, upon being included in a HTML-file, looks for a div like this one:
<div class="lyteShare twitter googleplus facebook"></div>
and adds sharing-buttons for Twitter, Google+ and Facebook to that div (Linkedin, Yammer and Tumblr are also supported). You can see lyteShare.js in action on this test-page. The webpagetest.org test result is great when compared to that of the big boys;

ShareThisAddThisLockerz/ AddToAnylyteShare.js
Document Complete0.677s0.487s1.352s0.364s
Start Render0.715s0.279s0.304s0.275s
Fully Loaded1.507s3.718s1.407s0.596s
Full Download size70 KB384 KB 111 KB9 KB
WebPageTest URLsharethis resultaddthis result lockerz/ addtoany resultlyteshare result
3rd party tracking?yes yes yesno

Now the question is; does the world really need yet another social sharing widget solution, even if it is easy, fast & not a vehicle for 3rd party behavioral web tracking? Does the world (and this blog) even need social sharing widgets at all?

Sharing widgets harm your website’s performance


[UPDATE: I reworked lyteShare into a standalone javascript-thingie]
Doing Web Performance can be so easy, really! I was asked to do a performance analysis of a new website and one of the things I didn’t like was the fact that the footer contained social media sharing buttons using the ShareThis widget. I’m not a fan of sharing widgets in general, as they tend to slow webpage loading and rendering down and as they almost invariably come with “3rd party tracking” for behavioral marketing purposes.
So why not do a quick comparison between a simple page with ShareThis, AddThis, AddToAny/ Lockerz share and one which uses inline javascript to render the buttons? For that purpose I quickly created lyteShare, an inline JavaScript thingie that dynamically adds the Facebook, Twitter and Google Plus sharing buttons after the load event has been fired. I’m not going to bother you with code (but you can look at the page’s source here if you want)  it’s probably far from perfect and it sure isn’t pretty, but it works and the webpagetest.org-results tell it all.

ShareThisAddThisLockerz/ AddToAnyinline JS (“lyteShare”)
Document Complete0.677s0.487s1.352s0.283s
Start Render0.715s0.279s0.304s0.298s
Fully Loaded1.507s3.718s1.407s0.500s
Full Download size70 KB384 KB 111 KB7 KB
Test Reportsharethis resultaddthis result lockerz/ addtoany resultlyteshare result
3rd party tracking?yes yes yesno

So yep, ShareThis, AddThis  and AddToAny/ Lockerz (and all sharing widgets really) are performance-hogs that also track your visitors’ every move while offering little or no added value to what anyone could do with some simple JavaScript (or server-side code, for that matter).
Conclusion: if performance is of any importance for your website (and it should be), you really have to avoid using 3rd party widgetery!

As found on the web (November 7th)

blog (feed #46)
generic (feed #49)
generic (feed #49)
generic (feed #49)
generic (feed #49)
frank posted Do You Wanna Touch.
generic (feed #49)
blog (feed #46)
generic (feed #49)

Dipping below the magical 1 second page load time

A couple of weeks ago I started looking into data-uri’s as a way to further optimize the performance of this personal playground of mine. Testing was easy enough; Autoptimize, the javascript/ css/ html opitimizing plugin I now use in conjunction with WP Super Cache, comes with support for data-uri’s in CSS and switching that option on indeed immediately resulted in less requests being made.
While testing I did find a small bug in Autoptimize (in /wp-content/autoptimize/classes/autoptimizeStyles.php) which caused jpeg images not to be taken into account. The regular expression in the code was ‘jpe?j’, while just below in a switch/case block ‘jpej’ and ‘jpg’ were referenced, resulting in neither ‘.jpg’ nor .’jpeg’ files ever being turned into data-uri’s. While reading the code I also noticed that the upper filesize limit for images to be turned into data-uri’s was set at 5120 bytes, but as base64-encoding does come with overhead, I decided to lower that limit to 2560 bytes.
So I made some minor changes in autoptimizeStyles.php on lines 207 and following:

if($path != false &amp;amp;amp;&amp;amp;amp; preg_match('#\.(jpe?g|png|gif|bmp)$#',$path) &amp;amp;amp;&amp;amp;amp; file_exists($path) &amp;amp;amp;&amp;amp;amp; is_readable($path) &amp;amp;amp;&amp;amp;amp; filesize($path) &amp;amp;lt;= 2560) {
   switch(end(explode('.',$path))) {
      case 'jpeg':
         $dataurihead = 'data:image/jpeg;base64,';
         break;
      case 'jpg':
         $dataurihead = 'data:image/jpeg;base64,';
         break;
      case 'gif':
...

I also  switched my “subscribe” widget from a paragraph- to a bulleted list-approach with the rss- and mail-icons as background images and defined the adfreeblog and creative commons badges as background-images as well. And then I was ready to test the real impact of using data-uri’s on webpagetest.org. Behold the results for my current blog homepage (i.e. the one just before this post got published) with and without the use of data-uri’s (but excluding those dog-slow calls to stats.wordpress.com):

 No data-uri’sWith data-uri’s
webpagetest results URLhttp://www.webpagetest.org/result/121106_12_6FZ/http://www.webpagetest.org/result/121106_4H_71R/
#requests (full page)2619
Bytes in (full page)116KB114KB
Start render (median)0.615s0.634s
Doc Complete time (median)0.969s0.870s
Full page load time (median)1.932s1.332s

Let it be clear that the use of data-uri’s for background-images is not a silver bullet, but if you have images that are on every page of your site and they’re small in file-size, migrating those into your CSS as background-images with data-uri’s can result in an important performance improvement for your site.