A practical Core Web Vitals checklist for small product teams

Technology · 2026-02-14 · 11 min read

By Arjun Mehta, Engineering & product

Interaction to Next Paint changed which optimisations matter. Here is the order we work through when a page feels slow.

Core Web Vitals rewards boring engineering. Nothing in this checklist is clever; the value is in the order, because fixing render-blocking CSS before you have measured the largest element wastes a week.

It helps to remember what the three metrics actually measure: how fast the main content appears (LCP), how quickly the page responds when you touch it (INP), and how much the layout jumps around while it loads (CLS). Loading speed, responsiveness, visual stability — everything below is just those three in priority order.

Start with field data. Lab tools tell you what could be slow on the hardware you happen to own. Field data from real sessions tells you what is slow for the phone your median visitor actually carries, which is usually three generations behind yours.

The gap between the two is where teams waste months. A page that scores well on a fast laptop on office wifi can be painful on a mid-range phone on a train, and only field data — from the Chrome UX Report or your own real-user monitoring — tells you which one your visitors are living with.

Then attack Largest Contentful Paint by identifying the element itself. In most marketing pages it is a hero image or a headline blocked by a webfont. Preload the image, serve it in a modern format at the exact rendered width, and give the font a sensible swap fallback so text paints immediately.

A quick way to find the culprit: most performance tools will name the LCP element for you. Nine times out of ten it is one image or one heading. Fix that single element first and the score moves more than a week of diffuse tinkering ever will.

Interaction to Next Paint is where modern single-page apps lose. Long tasks on the main thread delay the visual response to a tap, so break heavy work into chunks, defer anything the first screen does not need, and avoid re-rendering entire trees on keystrokes.

The usual offenders are hydration on load and oversized event handlers. If tapping a button or typing in a field feels a beat behind, profile the main thread, find the long task, and either split it, defer it, or move it off the critical path. Users forgive a slow load far more readily than a sticky tap.

Cumulative Layout Shift is the cheapest win: reserve space for every image, embed and ad slot. If an ad unit can collapse, give its container a fixed minimum height so the article below never jumps under a reader mid-sentence.

This one matters doubly on ad-supported pages, which is most pages trying to earn revenue. An ad that loads late and shoves the paragraph down is the fastest way to make a careful reader misclick and leave. Fixed slot heights cost nothing and protect both the score and the reader's patience.

Finally, re-measure in the field a week after shipping. Performance is a ratchet, not a project — one un-sized image in a new section undoes a month of care.

Tags: performance, seo, frontend

Arjun Mehta — Arjun writes about web performance, developer tooling and applied AI for ESPYCRUX. He has spent the last decade building and maintaining production web apps, and most of his articles start from something that broke in one of them.