 | frank published ShareThis kills your website’s performance. |
| |
Year: 2012
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;
| ShareThis | AddThis | Lockerz/ AddToAny | lyteShare.js | |
|---|---|---|---|---|
| Document Complete | 0.677s | 0.487s | 1.352s | 0.364s |
| Start Render | 0.715s | 0.279s | 0.304s | 0.275s |
| Fully Loaded | 1.507s | 3.718s | 1.407s | 0.596s |
| Full Download size | 70 KB | 384 KB | 111 KB | 9 KB |
| WebPageTest URL | sharethis result | addthis result | lockerz/ addtoany result | lyteshare result |
| 3rd party tracking? | yes | yes | yes | no |
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.
| ShareThis | AddThis | Lockerz/ AddToAny | inline JS (“lyteShare”) | |
|---|---|---|---|---|
| Document Complete | 0.677s | 0.487s | 1.352s | 0.283s |
| Start Render | 0.715s | 0.279s | 0.304s | 0.298s |
| Fully Loaded | 1.507s | 3.718s | 1.407s | 0.500s |
| Full Download size | 70 KB | 384 KB | 111 KB | 7 KB |
| Test Report | sharethis result | addthis result | lockerz/ addtoany result | lyteshare result |
| 3rd party tracking? | yes | yes | yes | no |
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 21st)
 | frank liked 2 videos.   |
| | frank published Now you can have my Facebook password as well!. |
Now you can have my Facebook password as well!
It’s been almost a year since I volunteered to give my readers my Google password, after enabling 2-step verification that is. I ended the blogpost on that topic with
And now off to Facebook security settings, to enable login notifications & approvals.
And although I did activate “login notifications” at that point, I did not enable approvals (for reasons I don’t remember, maybe I was just being lazy).
Fast-forward to yesterday evening, when I received a mail from Facebook that stated that my account was temporarily locked because my is was logged into from a location I had never used before. I immediately changed my password and finally enabled “login approvals” this morning as well. “Approvals” sends a security code via SMS when logging in from an unknown location, which you’ll have to enter before effectively logging in. I was pleasantly surprised to see Facebook added a Google Authenticator-like code generator to their Android and iOS apps that you can use to generate a security code as well. Adding the extra security of login approval is easy enough. If you’re on Facebook or Google, you really should consider enabling those (with or without their respective smartphone-based security code generators).
One downside though; using an external chat client (Mozilla Thunderbird in my case) to access Facebook Chat over XMPP doesn’t work any more as Facebook doesn’t provide “application specific passwords” like Google does. Update: as Jensen points out in the comments below Facebook does have application passwords, so I reenabled Facebook Chat in Thunderbird. But that might be a good thing anyway, as the warning mail I received from Facebook seems to refer to the use of Facebook chat over XMPP;
It looks like someone logged into “Rtgw_xmpp_username_password_
login” on Wednesday, November 14, 2012 at 9:04pm.
Not 100% sure if this was a real login attempt or a false positive, but apparently I’m not the first one to receive such a warning.
As found on the web (November 7th)
| | |
 | frank posted I meet Tumblr whizz-kid David Karp. |
| | |
| | |
| | frank posted Do You Wanna Touch. |
| | frank posted Progress update on WebRTC for Firefox on desktop. |
| | frank published Dipping below the magical 1 second page load time. |
| | frank posted Zweden het best in Engels. |
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; preg_match('#\.(jpe?g|png|gif|bmp)$#',$path) &amp;amp;&amp;amp; file_exists($path) &amp;amp;&amp;amp; is_readable($path) &amp;amp;&amp;amp; filesize($path) &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’s | With data-uri’s | |
|---|---|---|
| webpagetest results URL | http://www.webpagetest.org/result/121106_12_6FZ/ | http://www.webpagetest.org/result/121106_4H_71R/ |
| #requests (full page) | 26 | 19 |
| Bytes in (full page) | 116KB | 114KB |
| Start render (median) | 0.615s | 0.634s |
| Doc Complete time (median) | 0.969s | 0.870s |
| Full page load time (median) | 1.932s | 1.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.
Jetpack Notifications puts Quantcast tracking in your WordPress Admin
WP DoNotTrack user Marco Donati asked why the plugin did not stop Quantcast from being included in the WordPress admin pages. After some research (with the kind assistance of Marco), I discovered not one but two problems;
WP DoNotTrack relies on “output buffering” in WordPress to filter/ modify the HTML when in “Forced (default)” or “SuperClean” mode. Apparently WordPress does not use output buffering in the admin-pages, so WP DoNotTrack did not get triggered. My bad! I’ve updated the code to fallback to “Normal” mode when in admin and will push out a new version with this fix soon.
But then it got slightly ugly; even with this fix in place, the Quantcast-tracker kept on appearing! It was being called from within an iFrame, outside the reach of WP DoNotTrack. The culprit turned out to be the brand new “Jetpack Notifications” feature which -as most of Jetpack- is activated by default. As from Jetpack 1.9, you’ll see a small icon next to the greeting text on the right side of the admin-bar. When you click that icon a drop-down appears which contains the iFrame and the tracking code. To disable, in “Notifications” click on “Learn more” to reveal the “Disable”-button. Click that one and the icon, iFrame and tracker code are gone. Good riddance!
My advice to Jetpack users; explicitly disable any feature you do not use. Jetpack might offer some nice functionality, but of that is available in other plugins as well and being tied in that heavily into wordpress.com does come at a price. Moreover it seems there are some security concerns; as an user with author permissions I had access to the Jetpack overview page and I was able to activate the “Jetpack Comments” feature on Marco’s blog, but I couldn’t disable it. Call me a paranoid security-zealot, but non-administrator users should not really be able to do that, should they?