There are a lot of services, plugins, and platforms that promise fast websites: image compression, static delivery, minification, and more. These are helpful, but they often only mitigate the cost of an unoptimized page load, rather than addressing the problems that are causing them. Aside from reliable hosting, the best service to improve performance is better development.
Example: a website has a retargeting script. It loads on every page, and immediately when a page begins to load. Even if this is asynchronously loaded, it’s being delivered with the same urgency as the website’s logo in the header. There’s no real signaling of interest here, so including users for retargeting that haven’t further engaged with your site costs your site bandwidth.
If you work in any sort of marketing environment, Core Web Vitals is Google’s primary measure of user experience. CWV scoring will be meaningful to your websites’ stakeholders, and consequently to you.
Core Web Vitals vs Lighthouse
Lighthouse performs a page load, on demand, in its own test environment. Lighthouse’s “lab” environment helps you accommodate for users that don’t have the latest phone or a software engineering-grade computer, where bandwidth and processing overhead is scarcer. As of writing this, Lighthouse conditions simulate a budget phone on a “slow” 4G network. It’s helpful for looking at problems, but isn’t necessarily reflective of or equate to what your users are experiencing.
What to look at
FCP and LCP
These web vitals are the two biggest pain points I see on sites and the indicators that I most understand of how fast a page is delivered to a user, so this is what this guide is mostly focused on. Other metrics fall into the rest of Google’s perspective on user experience. I’ve found that working to improve these two metrics are usually the most helpful path to improvement in other metrics as well.
If you’re unfamiliar: I have two reductive explanations for these metrics: First contentful paint is among the first things that a user sees when a page loads, like hero text. Largest contentful paint is the largest and most meaningful thing a user sees: a big hero image, and sometimes the same hero text is considered FCP.
FCP is largely affected by what’s being “front-loaded” at the initial page load. FCP is not a core web vital, but it often has results that affect LCP, and technically LCP can never be faster than FCP.
Other metrics
CLS
Anecdotally I have noticed that older websites don’t suffer layout shifting as much because there are less or no progressively loaded elements on the page. I’m skipping over this for now as minimizing or preventing it are usually very straightforward.
INP, FID, and TBT
These are all part of Google’s ongoing efforts to measure the effect of overly-intensive scripting or loading. They all translate to users experiencing latency when interacting with your page(s). Interestingly, TBT is a Lighthouse metric, while INP and FID are CWV metrics. TBT seems not to relate well to INP/FID, but it’s important to understand that if a page’s other CWV are passing/good, failing INP timing could mean scripting functions are too long or CPU-intensive. For now I’m linking to Google’s well-documented guide on INP mitigation.
What to actually do
Start from the beginning: FCP
Eliminate render-blocking resources, Google said. Why does that help, and what does it look like in practice?
Lazy loading is a recent implementation of render-blocking reduction by the browser itself: if an image or an iframe isn’t immediately visible to a user, then wait to load it. For every image that get deferred this way, more bandwidth is allocated to loading whatever the user needs to see first.