Core Web Vitals in 2026: the complete website speed checklist.

A fast website is not a vanity metric. Speed decides whether a visitor sees your offer or the back button, whether a form feels trustworthy, and how Google’s page experience systems assess your pages. Core Web Vitals are the three measurements that turn “it feels slow” into numbers you can act on.

This is the checklist we use at RAIN Design Studio on every site we ship. It is built around the official thresholds, not wishful targets. A good site doesn’t need to load in under a second; it needs to pass the good thresholds for most real visitors on real phones.

The three Core Web Vitals and their thresholds

Two details matter more than most teams realize:

• Scores are assessed at the 75th percentile of page visits. Your typical visitor isn’t enough; three out of four must have a good experience.
• Mobile and desktop are assessed separately. Most failing sites fail on mobile.

Measure the right data first

Before optimizing anything, know which kind of data you are looking at.

• Field data comes from real users. Google’s Chrome UX Report (CrUX) aggregates it over a rolling 28-day window, and it powers the Core Web Vitals report in Google Search Console and the top section of PageSpeed Insights.
• Lab data comes from a controlled test, such as Lighthouse or the Chrome DevTools Performance panel. It’s ideal for debugging but doesn’t capture real interactions.
• Your own RUM (real-user monitoring), for example with the open-source web-vitals JavaScript library, tells you which pages, devices and interactions are actually slow.

A practical rule: diagnose in the lab, judge in the field. And remember that fixes take up to 28 days to show fully in CrUX.

LCP checklist: make the main content appear fast

The LCP element is usually a hero image, a large heading or a video poster.

• Fast server response. Serve HTML from a CDN or static hosting, and cache aggressively. A slow time to first byte delays everything after it.
• Don’t lazy-load the LCP image. Give it fetchpriority="high" and make sure it is discoverable in the HTML, not injected by JavaScript.
• Use modern formats and right-sized images. AVIF or WebP, with srcset and sizes so phones don’t download desktop images.
• Avoid render-blocking resources. Inline critical CSS, defer non-critical scripts, and keep third-party tags out of the critical path.
• Load fonts carefully. Self-host, subset, preload the one or two files that matter, and use font-display: swap or optional.
• Ship less JavaScript. Content that depends on a client-side framework to render will always be slower than HTML that arrives ready.

INP checklist: respond to every interaction quickly

INP replaced First Input Delay in March 2024 and is now the metric most sites struggle with, because it covers every interaction in the visit.

• Break up long tasks. Any main-thread task over 50 ms delays input. Split work into chunks and yield to the browser, for example with scheduler.yield() where supported or setTimeout as a fallback.
• Give immediate visual feedback. Update the UI first, then do the expensive work.
• Audit third-party scripts. Chat widgets, tag managers, A/B testing and heatmap tools are frequent INP offenders. Load them after the page is interactive, or not at all.
• Keep the DOM lean. Very large DOMs make every style recalculation and layout more expensive.
• Hydrate only what is interactive. Island architectures, such as Astro’s, ship JavaScript only for the components that need it.
• Debounce expensive handlers on input, scroll and resize.

CLS checklist: keep the layout still

• Set width and height (or aspect-ratio) on every image, video and iframe.
• Reserve space for embeds, ads and cookie banners before they load.
• Never insert content above existing content unless it’s a response to a user action.
• Match fallback fonts to web fonts using size-adjust and related descriptors, to reduce reflow when the font swaps.
• Animate with transform and opacity, not properties like top, height or margin.
• Keep pages eligible for the back/forward cache so returning visitors get instant, stable restores.

The full speed checklist at a glance

Build speed in, don’t bolt it on

The cheapest performance work happens before launch. Retrofitting speed onto a heavy theme with a dozen plugins is slow and fragile; choosing an architecture that is fast by default is not.

That is why most of the marketing sites we build at RAIN use Astro, which renders pages to static HTML and ships zero client JavaScript unless a component needs it. Our guide on what Astro is explains the model, and our Astro web development service describes how we use it. On the Media Progetti site, for example, 68 pages ship with JSON-LD, Pagefind search and a PWA on that same static foundation.

We also set Lighthouse performance budgets in CI on projects such as Origin Element. Treat budgets like these as guardrails that stop regressions, not as proof of field results; only real-user data tells you whether you pass.

Keep it fast after launch

Speed decays. New tracking scripts, larger images and extra widgets creep in month by month. To hold your scores:

1. Review the Core Web Vitals report in Search Console monthly.
2. Add a performance budget to CI so regressions fail the build.
3. Require a quick performance check before adding any third-party script.
4. Re-test key templates after every significant content or design change.

Talk to us about your site’s speed

RAIN Design Studio, based in Casablanca, builds websites with Core Web Vitals, semantic HTML and structured data treated as part of the design, not an afterthought. If your site is failing on mobile or you’re planning a rebuild, book a free 15-minute call. Custom projects start at $10,000, and a typical marketing site takes three to six weeks.