Core Web Vital Tooling

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 transform.
• 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.