No tracking and performance isn’t shabby either, but some speed-improvements could be made:
By default the plugin includes a Google Font, which slows the page down. Changing this to “inherit from my website” in the “Styling”-settings, improves the performance.
Each share service’s image is fetched separately, from a performance point of view it would make sense to use one image sprite instead.
You can add a share counter: but without a caching plugin the page load is slowed down significantly, but with a caching plugin the counters aren’t updated any more. ideally the share counter would be empty on page load (i.e. just placeholders in HTML) and after the page has loaded an ajax call would get and set the correct numbers. The “backend” the ajax-call connects with could feature some light caching (5 minutes maybe)?
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;
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?
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.
Conclusion: if performance is of any importance for your website (and it should be), you really have to avoid using 3rd party widgetery!
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?
Last night I released WP DoNotTrack version 0.7.0, which adds a new filtering mode called SuperClean. Whereas the previous version only acted on elements added to the DOM, SuperClean now also allows you to filter the base HTML of your pages. To do this, SuperClean uses the PHP output buffer to catch the full HTML before it’s being sent to the browser. That HTML is then parsed with PHP Simple HTML DOM Parser and based on your black- or whitelist the filtering is applied (SuperClean + whitelist = running a very tight ship, really). Currently SuperClean is not available if you have configured WP DoNotTrack to only stop tracking for people who have set the DoNotTrack-flag in their browser.
While we’re on the subject of conditional filtering; I’ve updated the code that checks for the DoNotTrack-flag to work around differences in browser implementations. Conditional filtering is pretty important, as it can help websites to comply with the (for now UK-only) “EU Cookie Law” which requires websites to ask their visitors for explicit consent prior to setting cookies. With WP DoNotTrack you can have your cookie and eat it too; you have your existing tracking scripts for users who give consent, while still being able to serve a “clean” website for users who enabled DoNotTrack in their browser. Given the fact that similar laws will be coming to a EU-country near you, conditional filtering is something I’ll be looking into further, so any feedback on the current implementation is more than welcome!
Do contact me if you found a bug, if you have questions or if you’d like specific feature to be added, I tend to rely heavily on user feedback to improve my plugins! And if you’re happy with how it works, drop by on the WP DoNotTrack-page on wordpress.org to rate it and/ or to confirm it works with your version of WordPress!
network.cookie.thirdparty.sessionOnly: set to “true” or “false”
privacy.donottrackheader.enabled: set to “false” (default) or “true”, which gently asks sites not to track you
Setting “network.cookie.thirdparty.sessionOnly” to “true” is a low-impact change which should stop tracking-companies (think Media6degrees or Quantcast) from following you around the web.
If you want to stop Facebook, Google & Co to stop tracking you around the web as well, the above setting will not suffice. You should either log out of their sites as soon as you’ve done your business there or set “network.cookie.cookieBehavior” to “1” (which will break their “social widgets”). Or you can install Ghostery or NoScript, off course.