This content originally appeared on Adactio: Journal and was authored by Adactio: Journal
When I was talking about monitoring web performance yesterday, I linked to the CrUX data for The Session.
CrUX is a contraction of Chrome User Experience Report. CrUX just sounds better than CEAR.
It’s data gathered from actual Chrome users worldwide. It can be handy as part of a balanced performance-monitoring diet, but it’s always worth remembering that it only shows a subset of your users; those on Chrome.
The actual CrUX data is imprisoned in some hellish Google interface so some kindly people have put more humane interfaces on it. I like Calibre’s CrUX tool as well as Treo’s.
What’s nice is that you can look at the numbers for any reasonably popular website, not just your own. Lest I get too smug about the performance metrics for The Session, I can compare them to the numbers for WikiPedia or the BBC. Both of those sites are made by people who prioritise speed, and it shows.
If you scroll down to the numbers on navigation types, you’ll see something interesting. Across the board, whether it’s The Session, Wikipedia, or the BBC, the BFcache—back/forward cache—is used around 16% to 17% of the time. This is when users use the back button (or forward button).
Unless you do something to stop them, browsers will make sure that those navigations are super speedy. You might inadvertently be sabotaging the BFcache if you’re sending a Cache-Control: no-store header or if you’re using an unload event handler in JavaScript.
I guess it’s unsurprising the BFcache numbers are relatively consistent across three different websites. People are people, whatever website they’re browsing.
Where it gets interesting is in the differences. Take a look at pre-rendering. It’s 4% for the BBC and just 0.4% for Wikipedia. But on The Session it’s a whopping 35%!
That’s because I’m using speculation rules. They’re quite straightforward to implement and they pair beautifully with full-page view transitions for a slick, speedy user experience.
It doesn’t look like WikiPedia or the BBC are using speculation rules at all, which kind of surprises me.
Then again, because they’re a hidden technology I can understand why they’d slip through the cracks.
On any web project, I think it’s worth having a checklist of The Invisibles—things that aren’t displayed directly in the browser, but that can make a big difference to the user experience.
Some examples:
- A web application manifest JSON file to help people install your website.
- A service worker, even if it’s just to cache static assets.
- Open Graph
metaelements in theheadof documents so they “unroll” nicely when the link is shared. - An appropriate content security policy header.
- A
Speculation-Rulesheader that points to a JSON file. - An OpenSearch XML file if your site has search functionality.
- An icon, or as us olds call it, a favicon.
- A
langattribute on thebodyof every page.
If you’ve got a checklist like that in place, you can at least ask “Whose job is this?” All too often, these things are missing because there’s no clarity on whose responsible for them. They’re sorta back-end and sorta front-end.
This content originally appeared on Adactio: Journal and was authored by Adactio: Journal