Month: December 2012

Are you wishing WP YouTube Lyte a responsive new year?

by

I’m spending some of the last hours of 2012 as a preparation for one of my 2013 resolutions; a new version of WP YouTube Lyte that will be fully responsive. I just finished a “template” (i.e. plain static HTML + CSS, not integrated in the plugin yet) which I’m pretty happy with.
It features:

  • A responsive player which in this test-case means a width of 820, shrinking when needed. The default width will remain an option.
  • Closer to current YouTube look & feel with a black play button that becomes red on hover
  • All player chrome loaded from just one image sprite (2 images in current, non-responsive version)
  • Embedded microformat data for better search engine discovery (will probably be configurable, “off” by default)
  • Works on all browsers (although e.g. positioning the play-button without CSS3 calc in e.g. IE8 and below is less precise)

You can check out the template on http://dl.dropbox.com/u/9207036/new_lyte_test.html. Feel free to give feedback on this early test-implementation.

2012.FFWD; high performance Twenty Twelve child theme

by

Twenty Twelve is beautiful but slow, so I created 2012.FFWD. This Twenty Twelve child theme looks pretty much the same as the original, but comes with the following performance-boosting changes under the hood:

  • no webfont downloaded: loading fonts slow sites down, always. Fallback-fonts as defined in Twenty Twelve (Arial, Helvetica, Sans-Serif) are used instead.
  • minimized style.css: the amount of CSS is staggering, even minimized we’re still at 28KB!
  • minimized and inlined navigation.js: the overhead for doing a separate request for small javascript-files is bigger then the increase in filesize when inlining.

And these small changes indeed seem to have a pretty good impact on performance when comparing my previous test with Twenty Twelve with a new one for 2012.FFWD;

  • from 9 to 3 requests
  • from 142KB to 15KB downloaded size
  • loadtime from 2.457s to 0.937s

You can download the child theme here for now, but I might upload it to wordpress.org’s theme repository later.
Before applying 2012.FFWD on my own blog, I had to do some emergency bugfixing in Autoptimize. Autoptimize is the plugin I use to aggregate and minify JS and CSS (including data-uri magic on background images), but it is currently unmaintained. It messed Twenty Twelve (and hence 2012.FFWD) up severely when viewed in IE7 and IE8, aggregating html5.js into a javascript-file loaded at the bottom of the HTML and loading the IE-specific CSS before the aggregated generic CSS. If anyone is interested in my bugfixed version of Autoptimize (there’s some other fixes in there as well), drop me a line.

WordPress’ Twenty Twelve theme: not so fast bro!

by

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]

As found on the web (December 12th)

by
blog (feed #46)
frank shared Site slower with CDN? Check your CSS!.
blog (feed #46)
frank published Site slower with CDN? Check your CSS!.
generic (feed #49)
frank shared Tags.
generic (feed #49)
frank posted Tags.
generic (feed #49)
frank shared Dries Buytaert: Giant Lego Druplicon.
generic (feed #49)
frank posted Dries Buytaert: Giant Lego Druplicon.
blog (feed #46)
frank shared Do background-images lazy-load with display:none?.
blog (feed #46)
frank published Do background-images lazy-load with display:none?.
generic (feed #50)
frank posted Answer by futtta for CSS Background Image Load Behavior.
blog (feed #46)
frank shared 44 en eindelijk de lucht in.
blog (feed #46)
frank published 44 en dan de lucht in.
generic (feed #49)
frank shared Mark Van den Borre: Binnenkort vrij.
generic (feed #49)
frank posted Mark Van den Borre: Binnenkort vrij.
facebook (feed #40)
frank Facebook-Syndizierungsfehler.

44 en eindelijk de lucht in

by

Jongensdromen, tja, hoe gaat dat? Het ene moment zijt ge 7 en ge zoudt -ondanks dat kleine probleem met uw bijna blinde rechteroog- piloot willen worden. De seizoenen wisselen, en voor ge het weet wordt ge 15. Uw bril is niet het enige praktische bezwaar tussen droom en daad, want blijkens uw schoolresultaten zijt ge niet echt de slimste van den hoop. Maar het leven gaat voort, computers en hormonen wenken en ge stapt verder, de grote mensen-wereld in. Doen alsof ge ergens iets van kent, op het werk. Verliefd, verloofd, getrouwd, een huisje, een tuintje en een koppel gekortwiekte kiekens ook. En een kindje, een lief klein dochterken.
Een paar weken voor ge alweer verjaart, begint dat kindje met blinkende oogjes vragen te stellen. Of ge graag met speelgoed speelt. Of ge zoudt willen kunnen vliegen en of dat dan met een vliegtuig of toch liever met een helikopter zou zijn. Uw vrouw probeert het te verbergen, maar ge ziet dat ze achter haar boek zit te grinniken.
Die zondag, de dag voor uw verjaardag, hoort ge vrouw en kind regelmatig fluisteren en lachen en als ge na het avondeten terug binnenkomt van bij de kiekens, staat uw fantastische wederhelft daar met een groot cadeau in haar handen. Ge scheurt het papier er van rond en ge zijt zo blij als een 7-jarig jongetje als ge ziet dat ge een helikopterken op afstandsbediening hebt gekregen. Vliegen lukt nog niet héél goed, maar plezierig is het zeker! Terwijl ge op de trein naar het werk een semi-nostalgisch verjaardags-blogpostje schrijft, verheugt ge U al op uw thuiskomst bij vrouw, kind en helikopterken. De kiekens, die wachten wel, wegvliegen kunnen ze toch niet meer.

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

by

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.

Site slower with CDN? Check your CSS!

by

A couple of days ago we implemented a CDN for a Drupal-based website, using MaxCDN/ NetDNA and the Drupal CDN module. We were very surprised to discover the site became … slower. It took us some time to identify the problem, but CSS turned out to be the culprit;

  1. The supplier created separate CSS-file for each and every template using SASS, causing some automated duplication of CSS
  2. Some of that CSS was not in the theme .info-file and wasn’t added using drupal_add_css either, but the link was hardcoded in the template-file
  3. The CSS that was added the normal way (i.e. not hardcoded in the template) was picked up and modified by the CDN module (changing paths for e.g. images and fonts into URL’s pointing to the CDN)
  4. CSS that was hardcoded in the template was not visible for the CDN-module, so the paths were not updated and still pointed to the origin webserver
  5. Because of duplication of e.g. background-images and fonts, pointing at both the CDN and the origin-server, these assets were downloaded twice and the extra file-size resulted in a site that was slower with than without a CDN

Once we understood the problem, the solution was pretty simple;

  1. clean up the CSS, avoiding to re-declare e.g. @font-face in multiple templates (resulting in a smaller CSS file download size as well)
  2. add CSS using drupal_add_css (with the option not to aggregate, as IE8 might choke on the massive amount of CSS) for the CDN module to take that into account as well

Web Performance Optimization can be so much fun!