futtta's blog

You can do great things in JavaScript; accessing the DOM and adding, changing or removing nodes as you please. It is exactly that technology that WP YouTube Lyte is based upon; the PHP-part writes out an almost empty div’s with className “lyte” and with as id the YouTube ID, which the JS-part finds after the main document has loaded to render the “LYTE player”. Great for performance, so I was pretty surprised when DerTux, one of WP YouTube Lyte users wrote;

BTW, Google Page Speed dislikes Lyte:

“The following JavaScript call stack (executed 4 times) caused reflows that took 52 milliseconds: @wp-content/plugins/wp-youtube-lyte/lyte/lyte-min.:1:0“

Although 52ms for a page with 3 “LYTE players” is minimal when compared to loading the same page with the full embedded YouTube player, the above statement bugged me enough to search the web for information about reflows and how to prevent them. Some of the more interesting articles:

• Speed up your JavaScript Part 4 by by Nicholas C. Zakas
• Speeding up JavaScript: Working with the DOM on Google Code
• Rendering: repaint, reflow/relayout, restyle by Stoyan Stefanov

And this video by Paul Irish does a great job explaining reflows:

Based on these pointers I started reworking lyte.js while testing on Google’s Page Speed Online (as far as I can tell the only tool that can detect reflows and then only as an experimental feature) to minimize reflows. I ended up:

• adding the pL div, which contains the LYTE player UI (play-button, controls & YouTube thumbnail), only after all styles have been applied
• adding the tC div, which contains the title, only after the tT div (with the title as received in the YouTUbe jsonp-call) has been added to it
• replaced el.clientWidth (and el.clientHeight) with el.style.width.match(/\d+/g)[0]
• some widths and heights did not have a unit specified in the dynamically generated CSS and this sloppy coding apparently also (indirectly) caused reflow

WP YouTube Lyte 1.1.1 will get pushed out in a couple of days (Thursday, probably) and will ship with these performance optimizations (and a fix for a regression which causes some styles not to be applied any more).

Nope, 1.0.0 wasn’t WP YouTube Lytes final destination, the train has left that station to arrive at version 1.1.0 yesterday. Main new features include:

• an updated LYTE-player UI:
• larger display of preview image (background-size:cover instead of contain)
• changed look of title placeholder
• updated controls image
• support for “Infinite Scroll” as proposed by “der Tuxman” and Olivier
• beta-support for YouTube’s JS API as requested by Yun
• annoyance-avoidance: check for “Karma Blocker” addon and warn, based on feedback from Leona
• translation: added Romanian, thanks to Alexander and Web Hosting Geeks

I’ll leave it to Avi Buffalo to show you how the new UI looks like:

And I changed the short description (which features prominently on the wordpress.org plugin page) to better match main features:

High performance YouTube video, playlist and audio-only embeds which don’t slow down your blog and offer optimal accessibility.

Next stop: 1.2.0. Any feature requests?

It was time to put my money where my mouth is, or at least to give the use of a CDN a try. Based on previous tests MaxCDN seemed like a decent, dirt-cheap solution, so that’s what the js, css & images for this blog are served from now.

Setting this up was very easy:

1. log into MaxCDN and set up a pull zone on static-cdn.blog.futtta.be with origin blog.futtta.be
2. create static-cdn.blog.futtta.be in the web interface of my DNS-provider (as a CNAME to the domain-name provided)
3. configure WP Super Cache to use static-cdn.blog.futtta.be instead of the non-cdn static.blog.futtta.be)

The speed difference can be huge, especially when routing to my origin VPS-server in Germany isn’t great. I’m sure my 2 overseas users and Google will approve!

Bandwidth-wise, with 10MB/day, I seem to be far from the 1TB/year I’m allowed, so if you’d like me to setup a (temporary) pull zone for your blog so you can check out if this would work for you then just drop me a line.

On a blog that uses WP YouTube Lyte which I happened to stumble across, the following warning was displayed:

Hey! If you’re browsing in Firefox, there’s a very good chance that you won’t see youtube / video embeds.

As I really don’t like bugs but couldn’t reproduce any issue myself, I contacted the blog’s owner to find out what was happening. The description of the problem was pretty confusing:

The still shot/first frame of the video is there with the play icon, so things look hopeful, but when you click on the play icon the entire video disappears from the page. Page structure / layout does not change, but you are left staring at a blank white box where the embed should be.

A white div of death, really … Anyway, to cut a long story short, the misbehavior was caused by “Karma Blocker“. This Firefox addon “blocks resources based on their karma”, using a ruleset that scores behavior to blocks banners, trackers and also WP YouTube Lyte (or rather, the YouTube iFrame). Apparently the combination of the bad karma of JavaScript and the iFrame triggered the blocking mechanism.

I couldn’t code around Karma Blocker and chances are small the default configuration will give YouTube iFrames better karma, but the next version of WP YouTube Lyte (1.1.0, to be available soon) will display a simple message kindly letting users know they might want to adapt their Karma Blocker’s weightings.

But why is karma punishing me?

Look at Opera Mobile 12 stealing Chrome Mobile’s & Firefox Mobile’s thunder:

And while there’s more to browsers then just HTML5-support, Opera Mobile 12 also seems to offer greater support for modern web technology features than IE9.

To be honest, Opera Mobile 12 doesn’t shine in the JavaScript performance benchmarks (2843,6ms for Sunspider, 463 on the Google V8 test, both of  which at least Firefox Mobile does a better job at), but with the upcoming Firefox Mobile 12 and the (Android 4-only) Chrome Mobile beta the mobile browser “wars” have certainly shifted into a -much- higher gear. Let’s hope Microsoft (and Apple, but Safari Mobile isn’t too far behind yet) follows suit.

Although browser addons such as NoScript and Ghostery (which is cross-browser with some limitations) provide great protection against tracking, some people prefer not to have to install plugins. Firefox does have configuration options to somewhat limit what trackers can do. You can follow the knowledge base article here to learn how to disable 3rd party cookies (the default setting in Safari, which Google was caught circumventing).

If you’re up to it, you also simply open up the almighty “about:config” and tinker with the following settings (some of which aren’t available in the browser UI):

• network.cookie.cookieBehavior with values:
• “0″: allow all cookies (default)
• “1″: don’t allow 3rd party cookies
• “2″: don’t allow any cookies
• network.cookie.thirdparty.lifetimePolicy with values:
• “0″: keep cookies for as long as the server asks
• “1″: ask the user on each and every cookie set (try it out if only for fun, you’d be surprise how much cookies are set)
• “2″: cookie gets deleted when you close your browser (i.e. at the end of the session)
• “3″: cookies have a lifetime as defined in the “network.cookie.lifetime.days ” preference
• 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.

Let’s apply the duck-test to Google;

1. They’re changing their privacy policy without offering users a true opt-out
2. They severely limited access for Scroogle, the Google-scraper for privacy-nuts, to the point where it is effectively out of service (although apparently Google isn’t the only one to blame)
3. They have been caught with their hands in your cookie jar, not only bypassing user’s cookie preferences in Safari but also in Internet Explorer

So if Google looks, swims and quacks like it doesn’t care about user privacy, it must be that it … doesn’t care about user privacy.

I on the other hand do care about my privacy, so I decided to put even less eggs in Google’s basket: I’ve switched my search-engine to startpage.com, which is operated by a Dutch company (i.e. one which has to comply with stricter European privacy laws) and which guarantees privacy while being powered by Google.

Startpage’s only downside: they are blocked by our company internet-filter because they provide proxy-services, so as an alternative I also use the less powerful DuckDuckGo (I changed keyword.url in Firefox’ about:config to “https://duckduckgo.com/?q=”). And a nice bonus; DuckDuckGo also has a nice Android-app, which I have installed to replace Google Search on my Sammy SII as well.