I’ve done a small test.
I created two versions of a simplified Metro homepage. It has a “mosaic” component which is part of the initial viewable area, and a “breaker” component which is further down the page.
Version 1
Version 1 is all served server-side (from flat files). It takes 1.2 seconds to render the initial viewable area.
Version 2
Version 2 lazy loads the breaker component something like this…
$(".metro-breaker").load("breaker.html");
… where breaker.html contains the component’s css inline.
It takes 1.1 seconds to render the initial viewable area. That’s roughly 10% faster.
- If we had five components on the page lazy-loaded it might be 50% faster!
- It’s an easy way of optimising the critical path as suggested by Filament Group.
- Some components are the same across different pages – these will benefit from browser caching.
The downside is no caching of CSS and JS across multiple pages/visits, but…
- Lazy-loaded components don’t have to be fast, they just have to be there before the user gets to them.
- Most page requests will have an empty cache anyway. (A) Our CSS/JS is short-lived. We generally deploy new versions every couple of days and ~75% of our users don’t return within 3 days. (B) We get massive traffic but our average pages per visit is low.
- Given that most page requests have an empty cache… lazy-loading reduces the download because it only downloads what is actually used. Our main css file is 150kb – i’m guessing that only about half of it is actually used on any one page.
The real winner
The real winner is the lazy-loaded version, not because it’s faster, but because the component is completely modular.
The component includes markup, inline css (which is modular using SMACSS) and potentially any required javascript too.
This means that a “micro architecture” can be used, with each component deployed in isolation (e.g. ui.metro.co.uk/just-in/news/?number=5).
- No waiting on a third party to deploy code. No merging CSS.
- Possible to deploy a new beta version in parallel with a stable version – good for “feature toggling” and A/B testing.
- Easy to try out new technologies and incrementally migrate to new platforms.
References
- Modular content and the AJAX-Include pattern by Filament Group
- The performance test was carried out using the awesome WebPageTest.org
A note on data
Currently some of our components generate markup client-side, based on JSON written to the page. It seems the JSON is nearly three times bigger than the HTML.
The “breaker” widget used in this test has markup of 12kb and JSON of 32kb. (The CSS is another 3kb).