|View this newsletter on the web.
Core Web Vital Tooling
Core Web Vitals is how Google measures the performance of any given site and you might’ve already heard the buzzwords like LCP, FID, and CLP. But — these are actually really useful metrics to figure out how to improve performance. So here they are again:
- Largest Contentful Paint (LCP)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
In my head, I find it useful to translate these into questions:
- When can we see the content?
- When can we interact with the website?
- Is the website content stable yet?
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.
That’s why we need to think about performance from three different perspectives. So, for example: you might have a super fast LCP (meaning that the content is available very quickly). But! You might have a ton of ads and images and videos being loaded on the page which might impact the layout (CLS). This happens to me most frequently on large news websites — I try to click a link and then the rug is pulled out from beneath me and I’m now clicking a different link. Gah!
All of these different metrics for performance can be measured with a bunch of new tools, including SpeedCurve and Calibre, where Karolina Szczur wrote about their importance:
If you’re not tracking and improving your Core Web Vitals, your Performance Score will be lower. A worse Performance Score means lower search ranking and worse user experience for your customers.
Us web developers have to familiarize ourselves with this stuff if we want to make our websites fast and our customers happy.
Here’s another distinction that is worth wrapping your mind around. When doing performance testing, there is what is known as RUM (“real user monitoring”) and synthetic (e.g. run tests in a headless browser). Both of these are useful!
I mention this because I’ve seen some chatter recently talking about how one-or-the-other is the only one that matters. First, when it comes to Web Core Vitals, the metric First Input Delay (FID) can only be measured by RUM, so RUM is clearly important there, but also because, ya know, measuring actual users performance is important because that is real information about how your real users are experiencing your site. But once you have RUM, that means you’ve already shipped code to production. Synthetic data is the only kind you can get while you’re, say, running performance tests against Pull Requests, which is also a damn fine idea.