Written by Harry Roberts on CSS Wizardry.
display: none;to the
display: none;and gradually fading the page into visibility.
Not only does this strike me as an unusual design decision—setting out to build a lazyloader and then having it intentionally block rendering—there had been no defensive strategy to answer the question: what if something goes wrong with image delivery?
‘Something wrong’ is exactly what happened. Due to an imperfect combination of:
…they’d managed to place 27.9MB of images onto the Critical Path. Almost 30MB of previously non-render blocking assets had just been turned into blocking ones on purpose with no escape hatch. Start render time was as high as 27.1s over a cable connection1.
If you’re going to build an image loader that hides the whole page until all images are ready, you must also ask yourself what if the images don’t arrive?
This isn’t the first time I’ve encountered such an odd choice of development
strategy. A popular A/B testing tool does something remarkably similar: they
instruct developers to drop a
<script> block into the HTML page that
opacity: 0 !important to the
<body> element. While the
the provider’s origin. This external file contains all of the information needed
to run the A/B test(s) on the page, and once the file applies the test(s), it
then removes the
opacity: 0;. However, the fatal flaw here is that the file
responsible for showing the page again is separate to the file responsible
hiding the page in the first place.
While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t. Remember the fallacies; think about resilience.
This short post feels like a summary of several other things I’ve been trying to teach for the past several years, so I would encourage you to also read:
5Mb up, 1Mb down, 28ms RTT. ↩
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
I am available for hire to consult, advise, and develop with passionate product teams across the globe.
I specialise in large, product-based projects where performance, scalability, and maintainability are paramount.