performance

Speed matters: re-evaluating WP YouTube Lyte’s performance

by

So stupid me made a (smallish) mistake when working on 1.1.0, which caused WP YouTube Lyte (rapidly approaching 80.000 downloads, thanks guys & girls) to load immediately instead of waiting for the “document loaded” event (lazy loading). That got fixed in 1.1.2 (which also loads the CSS differently, resulting in 1 file less to request), but the mistake did get me to re-investigate performance.
Exactly how fast is WP YouTube Lyte nowadays? I fired up some webpagetest.org IE9-instances in the Amsterdam node to compare this WP YouTube Lyte powered post on my test-blog with an identical blogpost with default YouTube embedded video. These are the jury’s results for the fastest of 10 runs in both cases (click on the image to actually see the details):

The main figures to compare (normal YouTube embed vs WP YouTube Lyte):

  • time till document complete: 1.612s vs 1.047s
  • time till fully loaded: 4.358s vs 1.385s
  • total number of requests: 13 vs 9
  • combined size of requests: 446 KB vs 77 KB

So using WP YouTube Lyte instead of normal YouTube embeds results in less files to download, less data to transport, the page being ready for interaction quicker and having everything loaded a whole lot faster. These figures are for a single YouTube on a page, but the impact is all the more important if you have multiple video’s on one page (e.g. a category or tag-page for “music” or “videos”) off course.
The full comparison based on 10 tests on both pages:

YouTube embed (full results)Lite YouTube Embed (full results)
doc completefully loadeddoc completefully loaded
min:1612380810471385
median:1918463111911524
max:3221511020782881

So there you go. When in doubt, check these stats and then go install WP YouTube Lyte, because after all speed matters!

Going against the reflow

by

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:

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

HTML5, CSS3, and DOM Performance

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).

CDN to the Max

by

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.

Fiesta: WP YouTube Lyte reaches 1.0.0

by

I just released the one dot ohhhh dot ohhhhhhhhhh version of WP YouTube Lyte!
From the changelog:

  • new: also works on (manual) excerpts; just add a httpv link to the “excerpt” field on the post/page admin (based on feedback from [email protected])
  • new: if youtube-url contains “start” or “showinfo” parameters, these are used when playing the actual video. This means that you can now jump to a specific time in the YouTube video or stop the title/ author from being displayed (based on feedback from a.o. Miguel and Josh D)
  • update: javascript now initiates either after full page load or after 1 second (whatever comes first), thus avoiding video not showing due to other requests taking too long
  • update: bonus feature stops lockerz.com tracking by addtoany (you’ll still want to hide the “earn pointz” tab though)
  • bugfix: prevent the playing video to be in front of e.g. a dropdown-menu or lightbox (thanks to Matt Whittingham)
  • bugfix: solve overlap between player and text when option was set not to show links (reported by Josh D)

And an appropriate vid to go with this new release:

Toolbox: BrowserMob

by

A month ago I added BrowserMob to my toolbox. I’m sure I’m the last web-guy in the world to discover BrowserMob (or “Neustar Web Performance”, as of yesterday), but just in case you don’t know them either, it is an online service that provides availability- and performance-monitoring for websites and -applications.
Great stuff, really; create a simple script by providing a URL, choose what datacenters you want the test to run from, set the interval and there you go. After a couple of minutes you can start gazing at charts & reports or check your mailbox for alerts. You can create more complex tests using a JavaScript-based syntax or you can import Selenium-scripts (hello Selenium IDE for FireFox). The free account I started out with offers a substantial amount of pageviews/ month (40.000) that tests can generate.

Choosing a CDN in a whim

by

I had to look into CDN’s some time ago, to find a suitable temporary solution for a problem at work. There are a lot of players in this field, Akamai and Amazon (Cloudfront) being market leaders of some sort, but there’s also Microsoft with their Azure CDN (which we already had some experience with), other big guns such as Rackspace and Level3 and specialized shops such as CacheFly, CDNetworks and NetDNA as well. So how to choose?

Results only relevant for Belgium (and even then …)avg. speed (ms) for 64kBspeed delta % from fastest
softlayer121.3100%
gogrid123.0101%
microsoft azure132.0109%
level3132.0109%
amazon cloudfront133.3110%
maxcdn136.7113%
cotendo138.7114%
cachefly147.3121%
rackspace156.3129%
highwinds226.3187%
voxcast227.7188%
flexiscale317.3262%
amazon s3 eu417.3344%
cloudflare
invalid result		575.0 NA474% NA
google appspot668.0551%
voxel nl814.0671%
amazon s3 us932.0768%
voxel ny942.0776%

Well, if you’re in a hurry, you could compare price and features via cdnplanet.com. The info might not always be complete, but it does give you a good first idea and you can always visit the CDN’s proper site for more details, can’t you?
After comparing features & pricing, you really should get an idea of the speed of these CDN’s, of their performance relative to your customers. I found this CDN Speed Test on cloudclimate.com very useful; it performs a live test of approximately 20 CDN providers, requesting a 64 kilobyte file 10 times for each CDN from within your browser. So if you can get a sample of your customers to perform that test and provide you with the results, you’ll have some very useful information about performance. Together with your overview of features and price, you should be able to make at least a vaguely educated decision, no?
To have an idea about performance for our market (Belgium), I asked some Facebook-friends to provide me with the results of the CDN Speed Test. Most data I received was for Telenet or Skynet/Belgacom, not coincidentally the biggest ISP’s here. You can see the aggregated results in that ugly table on the left (or a couple of paragraphs up, if you’re subscribed to the RSS-feed).
My conclusion: as I was looking for a pay-as-you-go (no obligations, no monthly fee) CDN for static files, with support for Origin-Pull, HTTPS and some administration features (for example to purge the cache and watch nice graphs), MaxCDN fit the picture pretty well. With a great introductory price ($40 for the first Terabyte and even less if you find the coupon code) and performance that is at 113% of the fastest competitor, they seem to have found somewhat of a sweet spot for my specific context.
The only problem; I’ve got to wait for a “GO” from some people higher up the food chain. Maybe I should already implement it on my blog, just for the fun of it?

Firefox Mobile: the best mobile browser no-one uses

by

I’ve always enjoyed riding the Firefox-bandwagon and that hasn’t changed, even though Google Chrome seems to be the browser of choice amongst the cool kids nowadays. And if only because I’m a faithful guy, I’ve been running Firefox Mobile ever since I bought a Samsung Galaxy SII as well. Sure it doesn’t do Flash, but I’m not that Flash-inclined anyway.
Now, I haven’t met too many people that use Firefox Mobile and indeed when reading about mobile browsers, Firefox is rarely if ever mentioned. But what if I told you that Firefox Mobile is by far the best browser on mobile when taking performance, features and security into consideration?
I won’t beat around the bush, here’s the pretty objective data.

browserhardwareSunspiderv8 benchm.html5test score
Firefox Mobile 9bSamsung Galaxy SII1421.9ms832314
Android 2.3 browserSamsung Galaxy SII3454.4ms369177
Android 4 browserGoogle Galaxy Nexus1983ms1387230
Mobile SafariiPhone 4s2260.9ms368296
Opera Mobile 11.5Samsung Galaxy SII1699.9ms461285
Dolphin HD 7.2Samsung Galaxy sII3593.4ms318177

Some remarks:

  • the hardware is pretty comparable; all dual-core CPU’s and plenty of RAM.
  • higher is better, except for Sunspider which measures time (in microseconds).
  • I’ve got no screenshot or URL of the google v8 test results on my phone, but I’ll be glad to reproduce.
  • sunspider and v8 are javascript performance benchmarks.
  • html5test is an indication for support of “modern” browser features (html5, css3 and much more).
  • the features of the browser GUI arent’t measured byhtml5test, but I’m pretty pleased with Firefox Mobile in that respect as well; great tabbed browsing, plugins (including noscript!), sync-ing of all relevant data between desktops & mobile, …
  • I added Opera Mobile and Dolphin HD to the list. Opera’s not too shabby but not a winner either?

And last but not least; as Firefox Mobile isn’t native and since it’s on the same (crazy) rapid release cycle as the desktop-version, I consider it to be a lot more secure when compared to the slow evolving, rarely updated native browsers in Android and iOS.
My advice; if you’re an Android-user and you’ve got a recent handset or tablet, you really should consider switching to Firefox Mobile. It’s the best mobile browser no-one is using! Except for you?

Ranting & Raving at Drupal Summit 2011

by

I attended Drupal Summit in Genk a couple of days ago and amidst the general “Drupal is the best thing since sliced bread” atmosphere, there were some interesting discussions about the platform’s maturity. Especially the presentations of Peter Van Den Broeck (for VRT) and Wouter Mertens (for competitor VMMA) seemed to be on opposite sides, with VMMA having multiple successful Drupal-sites in production and VRT struggling to get their projects finished, telling Captain Buytaert “Dries, we’re not there yet“. But underneath the surface and despite the differences (a dedicated team of sysadmins & developers at VMMA vs fixed price, project-based external development for VRT), both were talking about the same problems on a technical level; modules & performance.
The Drupal module community is a great bunch of enthusiastic developers, building an impressive number of modules that cover almost any feature one would want to have in a website. But module quality, support & compatibility varies enormously. Some modules seem to be true Rube Goldberg machines, providing tons of functionality that only few people need but which makes the the UI a usability-hell and the code complex, error-prone and possibly a real performance-hog.
And while we’re on the subject; performance doesn’t come out of the box and Drupal as such does not scale very well. Install it with a bunch of modules, generate a reasonable amount of page requests and you have a CPU-intensive system that generates a crapload of database-connections. Adding memcache between your Drupal & MySQL helps, as most requests will be handled from cache. And putting a caching reverse proxy (Varnish, Squid or even Apache’s mod_proxy+mod_cache if you insist) in front of your Drupal does miracles, serving visitors the same content without the need for Drupal to bootstrap. So sure, you can build a scalable solution that provides great performance, but one could say this is despite Drupal, not because of it. After all, when using Memcache & Varnish almost any CMS will have great performance, won’t it?
So yeah, Drupal can be a nice solution to your problem, but it does require more than just a superficial knowledge of how to install it together with some modules and a theme. Make sure there are smart people on your team or project, that have a profound knowledge of modules & module development and who know a lot about MySQL (and clustering, mirroring or master/slave setups), Memcache and Varnish (or Squid, forget about mod_cache if you can). You’re bound to run into some problems, as Peter Van Den Broeck confirmed, but with the right people and architecture your Drupal-project can indeed be the best thing since sliced bread.

Quick & dirty “CDN” in WordPress

by

If you want a quick & dirty way to speed up WordPress without any plugins:

  1. create a subdomain in DNS, e.g. static.yourblog.org
  2. add that subdomain as a ServerAlias to your Apache config (remember to restart apache)
  3. add the following to your wp-config.php:
    define('WP_CONTENT_URL','http://static.yourblog.org/wp-content');

If you want to do this the right way; plugins such as WP Super Cache or W3 Total Cache do a much better job at this.

3 Apache mod_cache gotchas

by

If you want to avoid the learning curve of Squid and Varnish or the cost of a dedicated caching & proxying appliance, using Apache with mod_cache may seem like a good, simple and cheap solution. Rest assured, it can be -to some extent- but here are 3 gotchas I learned the hard way:

  1. mod_cache ignores Cache-control if Expires is in the past (which it shouldn’t according to RFC2616), so you might have to unset the Expires-header.
  2. mod_cache by default caches cookies! Let me repeat; cookies are cached! That might be a huge security-disaster waiting to happen; sessionid’s (that provide access for logged-on users) are generally stored in cookies. If a logged on user that request an uncached page, then that user’s cookie will get cached and sent to other users that request the same page. Do disable this by adding “CacheIgnoreHeaders Set-Cookie” to your config
  3. mod_cache by default treats all browsers like the one that triggered the caching of the object. In the field that approach can cause problems with e.g. CSS-files that are stored gzipped (because the first browser requested with header “Accept-Encoding: gzip, deflate”). If a browser that does not support gzipped content requests the same file, the CSS will be unreadable and thus not applied. The solution; make sure the “backend webserver” sends the “Vary: Accept-Encoding” header in the response (esp. for CSS-files). This will tell mod_cache to take different Accept-Encodings into account, storing and sending different versions of the same CSS-file.