Louis Lazaris demonstrates a very simple way of doing this.
- Hide the body (with JavaScript) right away with a CSS class that declares
opacity: 0 - Wait for all the JavaScript to execute
- Unhide the body by transitioning it back to
opacity: 1
Like this:
Louis demonstrates a callback method, as well as mentioning you could wait for window.load or a DOM Ready event. I suppose you could also just have the line that sets the className to visible as the very last line of script that runs like I did above.
Louis knows it’s not particularly en vogue:
I know nowadays we’re obsessed in this industry with gaining every millisecond in page performance. But in a couple of projects that I recently overhauled, I added a subtle and clean loading mechanism that I think makes the experience nicer, even if it does ultimately slightly delay the time that the user is able to start interacting with my page.
I think of stuff like font-display: swap; which is dedicated to rendering your text as absolutely fast as possible, FOUT be damned, rather than chiller options.
The first line says to hide the body with JavaScript, but the example hides it with css.
Ah, that is a little unclear. It is hidden with CSS, but it’s applied with JS. Just updated that!
You can also add opacity 0 to the style tag and remove that property with JS, while also putting a noscript tag with styles which force the body to be shown, so it will work without javascript too.
This is a fun technique and when it works it does look nice (I’ve used something similar at a client’s request), but I think this link post on CSS Tricks could have highlighted the dangers of this technique a bit better and point out that this isn’t going to be a good idea for all sites.
This is going to have an impact on First Contentful Paint scores (https://web.dev/fcp/) and impact sites Lighthouse scores in a negative way. That means potentially a decrease in Google ranking now that Core Web Vitals are a ranking factor.
Perhaps someone doesn’t care about Lighthouse scores, and they don’t think they should have to build websites the way Google tells them to. That’s a fair criticism! :)
But what happens when the JS that removes the
opacity:0CSS fails to be executed? This could be because of a bug in our code that stops the callback from ever firing, or it could be caused by a bug in a browser extension that one of our users has downloaded, or perhaps even by an over-zealous adblocker blocking something from loading because it looked ad-related.The web is a weird environment where we have no idea what hardware or software a user could visit our site from next, and so it makes sense for us to build websites that fail gracefully rather than fail in a blank state.
Even if the JS doesn’t fail with an actual error or bug, lots of things can make it very slow. Perhaps someone might end up delaying the transition until a third party JS file used for ads has loaded, or analytics, or a big CDN hosted library that could take minutes to load on a spotty 3G connection. Or maybe the user is on their phone while travelling on a train or metro or bus, and the user goes through a tunnel just as the page starts to load? In that time the user would have no choice but to stare at a blank page, or most likely, leave and go elsewhere.
I think there are safer techniques to fix the issues the author mentions (flashes of unstyled text, cumulative layout shift from images not reserving space before they load etc) compared to this technique. Instead of hiding those problems behind a slow splash screen we can now use modern solutions to get around them, giving people a nice user experience while keeping our sites resilient to things like bad networks or unforseen bugs.
Love how simple this is. I wonder how (if at all) it would alter the accessibility score during a lighthouse test, like overall contrast for example.
Yes, I like smooth transitions! And that’s coincidence: I was building last weeks something on the same prnciples; together with some speed improving other css and js for compensation. – Have a plan to make an “How it’s build” page (in EN), but first I’ve to make the (Dutch) site itself. :-)
Test page for the homepage:
* clba.nl/experiments/fadingtest
Not an awfull CLS (Cumulative Layout Shift: 0.007) and Google’s Page Speed Insights is satisfied for Desktop, with 100/100.