Tag Archives: webpagetest.org

WordPress-as-a-service tip: Flywheel

flywheelAt work I was asked to provide advice on WordPress hosting. As we don’t have in-house LAMP-experience and as I didn’t want to have to take care of server operations myself (been there, done that), I decided to look into WordPress as a service solutions. To make things a tad more complicated, hosting had to be in a European data-center as we wanted optimal performance for our local customers and as our Privacy Officer requires all company data to be in Europe.

I contacted several US companies, but eventually Flywheel came out on top; they confirmed they could host in Europe (Amsterdam), seemed pretty eager, had a great package and they could provide me with a test-account to play around with their solution. And so I did; I set up a stock WordPress 3.9.x with Autoptimize and WP YouTube Lyte (call me prejudiced, but I like my own plugins), imported a bunch of posts from this blog and had WebPageTest be the judge.

The results were quite impressive;

Document CompleteFully Loaded
Load timeFirst byteStart renderDOM elemsTimeReqsBytes InTimeReqsBytes In
First View (Run 3)0.457s0.120s0.292s9260.457s473 KB1.008s12152 KB

0.120s until first byte, 0.292s start render and 0.457s doc complete? Sweet! So yeah, given those numbers, their offering and the fact they can deploy to a datacenter in Europe I do think Flywheel is a great choice for those who are looking for WordPress-as-a-service (well, PAAS really) solution!

Nieuwe m.deredactie.be niet meer mobiel!

(Update December 2014: ik bouwde zelf een alternatieve versie die sneller en toegankelijker is op http://futtta.be/redactie/)


m.deredactie.be homepageIk ❤ mobiele websites, zelfs op de desktop. Bij het refreshen van m.deredactie.be vandaag (12 mei) kwam ik op de nieuwe versie uit. De developers hebben zich ongetwijfeld goed geamuseerd om niet alleen de nieuwe look & feel te implementeren, maar ook om de achterliggende technologie grondig te herbouwen naar een JavaScript-based UI volgens de “single page application“-filosofie (iemand heeft zich wel héél erg in angular.js verdiept, daar aan de Reyerslaan).

Maar ik, eenvoudige gebruiker, ben minder enthousiast. De site ziet er misschien moderner uit, maar is minder bruikbaar; zonder javascript is er niets te zien (neem een voorbeeld aan “cut the mustard“, progressive enhancement zoals de BBC die predikt), “above the fold” staan er enkel afbeeldingen en vooral; alles is plots trager!

Want over snelheid kun je niet discussiëren; sneller is beter, trager is slechter, zeker mobiel. De voorgaande versie van m.deredactie.be “woog” pakweg 150KB en laadde volledig in minder dan 2 seconden, maar de nieuwe versie tikt af op 2560KB in 6 seconden (gemeten op webpagetest.org met “cable” bandbreedte-profiel, met “fast mobile” wordt dat 17s).

Is m.deredactie.be een mobiele site? 2 megabyte aan data zeggen van niet.

Why I love the mobile web

This is why I’m a big fan of good mobile websites; the normal BBC Sport Formula 1 page loads in 6 seconds, where the mobile version loads in a mere 2 seconds (when over cable, DSL and 3G are off course slower). Same content, less clutter and based on progressive enhancement for ultimate responsiveness (from low-end phone on a mobile data network to a tablet on WiFi). Guess which site I use on all my devices (smartphone, netbook, the family tablet and my work laptop)?

The details, for both document complete and fully loaded (between round brackets) as seen from the Brussels webpagetest.org node using IE9 and the cable-bandwidth profile;

bbc sport desktop thumbnailbbc sport mobile
load time 6.011s (7.371s) 2.057s (3.243s)
download size 988 KB (1015 KB) 184 KB (657 KB)
requests 134 (141) 32 (65)
test report webpagetest.org result webpagetest.org result

Notice the big difference between document loaded and fully loaded on mobile; that’s where the progressive enhancement kicks in. If you visit the same mobile site with a small screen-size device or without JavaScript, page load time drops to 1.467s for just 76 KB.

An even more extreme example; the desktop news-site for the VRT (the non-commercial broadcaster here in the northern part of Belgium) loads in 10,598s (11,482s) for a whopping 4.337 KB (4.406 KB) (on cable, it gets way worse when on DSL-bandwidth!) while their (one site fits all) mobile site only needs 0,869s (1.475s) for 116KB (120KB). Guess which site I use?

The conclusion is simple; don’t assume that just adding some mediaqueries will make your dog-slow site truly mobile-ready. It’s 2013 and websites should be lean and mean, but most of them still remain way too fat for our smartphones.

WordPress’ Twenty Twelve theme: not so fast bro!

tiny twenty twelve thumbnailWordPress 3.5 was released a couple of days ago, one of the new features being a completely new theme. Twenty Twelve, as it is called, is a responsive, html5-based theme which is just clear, simple and beautiful. I like it that much, actually, that after 5 years with Journalist, I’m considering switching to Twenty Twelve for my blog.

But as with all things web (images, social sharing widgets, fonts, themes and plugins/ modules) there’s a potential performance-cost. Some themes by default come with heavy background-images, jquery and jquery-plugins, and a handful of webfonts to download. So let’s look into Twenty Twelve’s performance, shall we?

My tweaked Journalist implementation on my testblog will serve as a baseline:

Switching to an out-of-the-box Twenty Twelve gives:

Wow, that’s pretty sad, no? The reason for this performance-hit; Twenty Twelve comes with Google webfonts, causing 5 downloads (1 CSS file and 4 font-files) totaling over 124KB of webfont-fatness. I’m not a big fan of webfonts, so I dove into the code to disable them and the results all of a sudden are a lot more pleasing:

So I’ll probably look into the creation of a child theme which will be optimized for performance (there’s some CSS and JS minimizing to be done as well, for example) before switching to Twenty Twelve.

[UPDATE 20/12/2012; 2012.FFWD, a high performance Twenty Twelve child theme, is here]

Do background-images lazy-load with display:none?

So, do background-images lazy-load with display:none? I did a quick test by loading this testpage created by Steve Souders on webpagetest.org. These are the results:

Conclusion: don’t rely on setting display:none on background-images to have them lazy load.

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!