Omdat “2013” zo’n prachtige televisie was, omdat de muziekkeuze uitmuntend was (erg Duyster-ig eigenlijk met onder andere Apparat, Girls from Hawaii, The National, Junip en Marble Sounds) en omdat Spotify-playlists niets voor mij (en dus misschien ook niet voor U) zijn;
Month: February 2014
Muziek van Onze Buis; Zwaaien naar Eefje De Visser
In het Nederlands deze keer, Eefje De Visser met het melancholische “Ongeveer” als muzikale zusje van José González. Ontdekt dankzij “2013” op Vier, sterke televisie met een straffe muziekeuze.
Na de winter smelt de sneeuw
en als Eefje langs rijdt
dan zwaai ik
langs de wegkant
Should you inline or defer blocking CSS?
You care about web performance and so you dutifully aggregate and minify your CSS. But then a couple of months ago Google PageSpeed Insights (for mobile) started identifying CSS as a render blocking resource and so you wonder if you should you inline your CSS, or even defer loading it. Based on tests executed on a multi-site WordPress installation, deferring CSS is not the best idea just yet, but inlining might be worthwhile! Read on for the hard numbers and other details.
The test-setup
- 4 test-blogs on a multi-site WordPress instance
- using the Expound theme (which is interesting because its main stylesheet imports 2 other CSS-files)
- using Lite Cache for page caching (new WordPress page caching plugin by the Hyper Cache author)
- the same content was imported on all 4 blogs
- all 4 had Autoptimize HTML & JS optimization active
- the difference was in the Autoptimize CSS settings, where:
- blog 1 had no CSS optimization at all (baseline )
- blog 2 had standard CSS aggregation and minification, linked in head
- blog 3 inlined the optimized CSS
- blog 4 deferred the optimized CSS
- each blog was tested on webpagetest.org‘s Amsterdam node on a DSL-profile using IE9 and doing 9 test-runs on one specific blogpost with contained a 16KBimage (I excluded favicon.ico as it seemed to pollute results)
- each blog was analyzed by Google PageSpeed Insights for both mobile & desktop
The results
test report url | first byte | start render | doc complete | fully loaded | mobile pagespeed | desktop pagespeed | |
1. no css optimization | 140212_Z1_MKN | 0.299s | 2.246s | 2.221s | 2.221s | 79 | 92 |
2. optimized CSS linked | 140212_H7_MKP | 0.239s | 0.608s | 1.390s | 1.390s | 91 | 97 |
3. optimized CSS inlined | 140212_A3_NJA | 0.232s | 0.348s | 0.658s | 0.658s | 99 | 99 |
4. optimized CSS deferred | 140212_8J_P1G | 0.248s | 0.357s | 1.034s | 1.034s | 99 | 95 |
The conclusions
Based on these tests (your mileage may vary, always test your results):
- deferring all CSS is useless, performance is worse, desktop PageSpeed score is (slightly) lower and there is a “flash of unstyled content” between the rendering of the page and the application of the CSS.
- Inlining CSS yields the best results both from a page speed and PageSpeed perspective. Although the base HTML is larger as it has the CSS payload, this has almost no impact in this specific context and rendering is almost instantaneous. Off course in a context where multiple other pages from the same site, with the exact same CSS would be loaded, the impact would be significant. Hence inlining CSS is especially interesting for sites with a low pageviews/ visitor ratio.
The future; inline + defer
Deferring CSS may seem pretty useless, but the sweet spot may just be inlining base CSS (everything needed for initial rendering above the fold) and deferring everything else. This is what CSS optimizing tools should focus on in 2014 and you can certainly expect something along these lines in one of the next major Autoptimize releases (although diehards can already test this approach).
Music from Our Tube; Ensemble Du Verre – Snow
No snow to be seen in Belgium, so why not have the Germans electro-jazzers of “Ensemble Du Verre” sing about it?
Music from Our Tube; “Wham City” by Dan Deacon
“Toffe muziek met een hoek af”. That’s how I would describe Dan Deacon‘s “Wham City” in Dutch. “Nice music with a corner missing” doesn’t have any meaning to it, but maybe that’s OK. Just enjoy!
WP YouTube Lyte 1.4.0; support for accessibilityFeature
A new version of WP YouTube Lyte was released over the weekend. Benetech, a U.S. nonprofit that develops and uses technology to create positive social change, offered a patch that adds the accessibilityFeature property to videos that have captions. If you have microdata enabled, WP YouTube Lyte now will automatically check if captions are available and if so, adds the accessibilityFeature property with value “captions” to the HTML-embedded microdata.
As YouTube only offers information on captions in their API v3, which requires authentication, the check is done in a separate, asynchronous call via a proxy-webservice on api.a11ymetadata.org. You can see an example of what the response looks like here and look at the source code on Github. This webservice-request for captions can be disabled by simply switching off microdata. Alternatively, if you want microdata but not the accessibilityFeature-property, you can use the “lyte_docaptions”-filter to set captions to false (you can find an example in lyte_helper.php_example).
This was the first time someone actively submitted code changes to add functionality to a project of mine, actually. Working with Benetech was a breeze and GitHub is a great platform to share, review and comment code. I for one am looking forward to more high-quality contributions like this one!