The Core Web Vitals are a set of metrics for measuring performance and user experience on the web. They are scores for particular aspects of the web experience which can be calculated against live sites, and include advice on ways to optimize those scores to improve your web apps.
There are currently three Core Web Vitals:
- Largest Contentful Paint (LCP): the time before the biggest block of content is rendered on a page.
- First Input Delay (FID): how quickly a page reacts after the first tap or click.
- Cumulative Layout Shift (CLS): how much the content of the page "jumps around" as slower resources load.
A larger LCP means people wait a long time for your visuals in your site to show up. High CLS means that users go to tap on something and it "jumps" away as your page re-organizes itself. And a high FID means that tapping seems to not do anything, and makes your site feel slow.
Each of these scores are measuring things users actually care about, and if the scores are bad then the website is similarly bad. It is this aspect that our founder James is utterly passionate about. The simple mantra of "a good website has good performance and user experience" led to a mission to improve our Core Web Vitals score.
After a few months, we achieved PageSpeed Insights scores of 100 for both mobile and desktop. The below methods act like a case study – this is what we did to identify areas of our website that needed improvement.
Caring about mobile...
You need to care about mobile viewers, if anything, more than desktop users. If your site's analytics are similar to most others then you're seeing at least 50% of your web usage being on mobile (and maybe quite a lot more).
But the Core Web Vitals are about performance and user experience – things can differ dramatically on a phone with a less-powerful processor, limited battery life, or completely different layout. What this means, of course, is that you have to test your sites and assess their Core Web Vital scores on mobile as well as on desktop. But how can you do that?
...in the browser
The simplest way, but also the least accurate, is to use in-browser tools. Your dev team are almost certainly already doing this. Each browser has a "mobile mode" built into its DevTools (here's Chrome's DevTools as an example).
These modes resize the screen to be the size and shape of a phone of your choice. It can also pretend to be a mobile phone by emulating touch events, throttling the network to a slow connection, and simulating a mobile viewport to show how page layout will look on a smaller screen. Chrome also has Lighthouse built into the DevTools, which will measure the Core Web Vitals for a site.
This is very useful for a "quick look" at problems and to work on layout issues, and it's by far the easiest technique. But it's not a real test of the areas that the Core Web Vitals help to measure: performance and user experience.
If you take nothing else away from here, take this: testing in browser DevTools is not a good guide to performance or user experience on actual mobile devices.
So, what can you do instead?
...in the simulator
A step closer to reality is to use a mobile emulator. These are the tools of native phone app developers, coming as part of those native development tools such as XCode for iOS on a Mac, or Android Studio for Android on most platforms.
This can be a little awkward to set up at first because the required developer tools can be quite heavy if you're not a developer. But it's worthwhile as they run the actual phone's software and browser (actual Android and actual Chrome for Android, or actual iOS and actual Safari for iOS), and this increases the fidelity of what they're testing. Desktop Chrome and Android Chrome are not the same, macOS Safari and iOS Safari are not the same, and desktop Chrome is certainly not the same as iOS Chrome, since all iOS browsers are really Safari under the covers.
Using a mobile phone emulator (for example, the iPhone Simulator or the Android Emulator) is a good way to test how your site actually appears on a phone and will give some sense of performance and network impact, more so than a pretend version in the browser DevTools. But it's still not actually a phone, and testing in an emulator on a laptop still doesn't get to the heart of the important metrics – the ones that the Core Web Vitals are measuring.
And that's where we get to the most important part of testing: real devices.
...on actual phones
There is no substitute for testing on real devices. Really, there isn't. I know it's annoying, but... nobody promised this stuff would be easy. Having said this, testing on one device is easy: the one in your pocket.
Although you're not getting a precise metric for how the performance and the UX shake out, you will get an immediate visceral sense of the website. Did tapping that button react instantly, or did it feel sluggish? Did the layout jump around the screen as external resources loaded in? Did your app show a spinner for one second (or 21 seconds) before it displayed anything?
This sort of smoke testing feels much more reliable on an actual device because faking a mobile CPU struggling with image decoding is a lot harder than having the actual chip in your phone really struggle. However, this is only your own phone, or only your dev team's phones, and those are a small subset (and tend to be higher-end devices, at that). What is harder to do is testing on multiple devices which cover the width and depth of your user base, and that's where a device lab comes into play.
Device labs used to be physical things, and in some cases still are; some teams or agencies have a room full of phones to be a device lab. If you're a community project or writing open code, then there may be a local device lab near you which you can use or borrow access to; some groups or companies club together to fund a joint physical device lab and share its use.
But a more common alternative is a virtual device lab; a paid-for online service which runs your code on a physical device but is plugged into someone else's computer somewhere else. You might think of this like BrowserStack, and indeed BrowserStack themselves are one of the main providers of live remote devices in a device lab, with Perfecto Mobile being the other.
It doesn't have the same visceral feel as holding the device in your hand; you've massively increased your test fidelity (because you're testing on actual devices) but thrown away all ability to feel the results of that testing yourself (because the actual device you're testing on is on the other side of the world).
Fortunately, this is where the two strands come together. Calculate the Core Web Vitals on a real device to give yourself a rigorous measure of how your web app will perform on the devices that your users are actually using. The ultimate goal of the Core Web Vitals is to quantify those things that make a site feel performant (or clunky) to actual users on their actual phones.
Testing the Largest Contentful Paint, the First Input Delay, and the Cumulative Layout Shift on multiple devices gives you immediate access to a metric that you can optimize until it hits the targets you've set. Drive layout shift and input delay down to nothing and the largest paint to as close to zero as possible and you know you'll be being marked well by search results and appreciated by users.
Measure for real to understand
So that's the technique. Measure your Core Web Vitals scores across many devices. Make changes, re-measure, iterate. This can be a laborious process (and it is definitely worth automating as much as possible) but there really is no substitute for doing this. It's what we did at 51Degrees, and if we can blow our own trumpet a little, it worked: we achieved 100 scores on PageSpeed Insights for both mobile and desktop.
We got that way by testing over and over on real devices to assure ourselves that what we were seeing is what our users would see. All this was aided by our own device detection platform, which is able to configure our site for different devices.
So go forth my friends with the valuable knowledge to improve your Core Web Vitals! And if you need a hand, or someone to automate part of the process for you, try out our device detection.
This page has been updated for 2021. To see the previous version of the page, visit Mobile Browser Emulators.