I still think the Google-devised Core Web Vitals are smart. When I first got into caring about performance, it was all: reduce requests! cache things! Make stuff smaller! And while those are all very related to web performance, they are abstractly related. Actual web performance to users are things like how long did I have to wait to see the content on the page? How long until I can actually interact with the page, like type in a form or click a link? Did things obnoxiously jump around while I was trying to do something? That’s why Core Web Vitals are smart: they measure those things.
The Lighthouse Tab in Chrome DevTools has them now:
They are nice to keep an eye on, because remember, aside those numbers having a direct benefit for your users once they get to your site, they might affect users getting to your site at all. Web Core Vitals are factoring into SEO and for the new carousel requirements that were previously reserved only for AMP pages.
Tracking these numbers on one-off audits is useful, but more useful is watching them over time to protect yourself from slipping. Performance tooling like Calibre covers them. New Relic has got it. SpeedCurve tracks them.
Cumulative Layout Shift (CLS) is a tricky one. That’s the one where, say, the site has an advertisement at the top of an article. The request for that ad is asynchronous, so there is a good chance the ad comes in late and pushes the content of the article down. That’s not just annoying, but a real ding to performance metrics and, ultimately, SEO.
Nic Jansma’s “Cumulative Layout Shift in Practice” offers deep dive.
CLS isn’t just “does page do it or not?” There is a score, as that illustration above points out. I’d say 0 is a good goal as there is no version of CLS that is good for anybody. There is lots of nuance to this, like tracking it “synthetically” (e.g. in a headless browser, especially for performance tooling) and with real users on your real site (which is called RUM, or Real User Metrics). Both are useful.
If you’ve got CLS that you need to fight, that can be tricky. SpeedCurve has some new tooling that helps:
For each layout shift, we show you the filmstrip frame right before and right after the shift. We then draw a red box around the elements that moved, highlighting exactly which elements caused the shift. The Layout Shift Score for each shift also helps you understand the impact of that shift and how it adds to the cumulative score.
That would make it pretty easy to root out and fix, I’d hope. Particularly the tricky ones. I didn’t know this, but CLS can be caused by far more subtle things which Mark Zeman points out in the post. For example:
- An image carousel that only moves horizontally can trigger CLS. That feels like a bummer as that’s what they are supposed to do, but apparently, you can trick it by moving carousels only with CSS
- If you have a very large area, that’s extra risky to move. If it moves just a smidge, it will affect CLS by a lot.
- Flash of Unstyled Text (FOUT) is a cause of CLS. Even though that’s good for performance for other reasons! Catch 22! It’s a good excuse to reach for perfect font fallbacks.
Tricky, yet important stuff. I really need to get performance tests into my CI/CD, which will really help with this. Feels more and more like web performance is a full-on career subgenre of web development. Front-end web developers really need to understand this stuff and help to some degree, but we’ve already got so much to do.
If i understand you correctly. I don’t really agree with what you said on web performance being a sub genre. I think it’s just part of the job.
The post is saying the same thing: it’s an ongoing part of the job (i.e. not going away) and, as such, we need to understand these metrics and how our work affects them.
I am really very frustrated with FCP, CLS and other. My website page speed is not working properly.
Was thinking how all this reminded me of a great Increment article I read until I remembered the author
I’m all for improving performance, but I object to the notion that Google has any right to make pronouncements from on high about developer best practices. Their made up terms like CLS shouldn’t be a ranking factor either.
You’re free to suggest a new term Michael. It was previously called the Layout Jank API. But it’s currently there to describe a condition of a page load. Do you agree that the content bouncing up and down is a poor user experience? Because if so – you and Google are on the same page. Nomenclature can certainly be debated. You’re free to file an issue.
Hi Chris, thanks for letting us know.
And here is a story on optimizing a high-traffic e-commerce app (1 million sessions daily) in Greece. You maybe find it interesting.
Be aware that Core Web Vitals and in particular CLS don’t play nice with PWAs and Single Page Apps. You can have a decent CLS in Lighthouse but Core Web Vitals can be much higher since it keeps increasing the longer a user stays on your page.
These metrics and concepts have allowed the commonplace developer to dig into details around performance, that they did not previously. I too side with the idea that this is good for everyone. And what some tend to overlook is that this is evolving and tweaked as we move on.
You might also find this resourceful Chris, published just a few days ago: some edits to how CLS is handled moving fwd, with changes currently live in Canary 88.
Noticed that web.dev (i.e. Google) is giving out this free eBook: Optimize for Core Web Vitals