A practical Core Web Vitals checklist

Core Web Vitals are Google's attempt to reduce "is this site fast?" to three numbers you can actually act on. They matter for ranking, but the stronger argument is commercial: people leave slow sites, and they leave before they have seen anything you paid to put there.

The three metrics, in plain terms

Largest Contentful Paint (LCP) — target under 2.5 seconds

How long until the biggest visible thing — usually a hero image or headline — finishes rendering. It is the closest proxy for "the page looks ready".

Interaction to Next Paint (INP) — target under 200 milliseconds

How quickly the page visibly responds when someone taps or clicks. It replaced First Input Delay in 2024 and is stricter, because it measures every interaction rather than only the first.

Cumulative Layout Shift (CLS) — target under 0.1

How much content jumps around while loading. This is the metric behind the universal experience of tapping a button just as an advertisement pushes it aside.

Fixing LCP

1. Find the LCP element. PageSpeed Insights names it. It is nearly always a hero image, a heading, or a large block of text.
2. Serve images in modern formats. WebP or AVIF, typically 25–50% smaller than an equivalent JPEG at the same visual quality.
3. Size images correctly. A 4000px photograph displayed in a 800px column is the most common single cause of a slow page. Use srcset and let the browser choose.
4. Preload the hero image with <link rel="preload" as="image"> so the browser starts fetching it before it has finished parsing the CSS.
5. Never lazy-load what is above the fold. Lazy loading is excellent below it and actively harmful above it.
6. Self-host fonts, or preconnect. Add font-display: swap so text is visible while a webfont downloads.
7. Use a CDN. Cutting the physical distance to the server is the cheapest performance win available.

Fixing INP

1. Audit your third-party scripts. Analytics, chat widgets, heatmaps, four tag-manager containers and two A/B testing tools all compete for the same single thread. Remove anything nobody has looked at in six months.
2. Defer what is not needed immediately. defer or async on scripts, and load chat widgets and similar on interaction rather than on page load.
3. Break up long tasks. Any JavaScript task over 50ms blocks input. Split heavy work, or move it to a web worker.
4. Send less JavaScript. Code-split by route so a visitor downloads what the page needs, not what the whole site might need.
5. Give immediate visual feedback. If an action genuinely takes time, show that it started. Perceived responsiveness is most of responsiveness.

Fixing CLS

1. Always set width and height on images and video, or use an aspect-ratio in CSS. The browser then reserves the space before the file arrives.
2. Reserve space for ads and embeds with a min-height container. A collapsed slot that suddenly fills is a guaranteed shift.
3. Never insert content above existing content after load — cookie banners, promotional bars and notifications belong in space that was already reserved.
4. Match fallback and webfont metrics using size-adjust and ascent-override so the swap does not reflow the page.
5. Use transform for animation, never properties like top, width or margin, which trigger layout.

The pre-launch checklist

We run this on every site before it goes live. It takes about an hour and prevents most of the problems people discover three months later.

• All images in WebP or AVIF, correctly sized, with explicit dimensions
• Hero image preloaded; nothing above the fold lazy-loaded
• Fonts preconnected or self-hosted, with font-display: swap
• Third-party scripts inventoried, justified and deferred
• JavaScript code-split by route
• Compression (Brotli or gzip) and long cache headers on static assets
• CDN in front of the site
• Tested on a throttled connection and a mid-range Android device, not only a laptop
• Field data monitoring configured so regressions are visible

Staying fast after launch

Performance is not a task you complete. Sites degrade because a marketing tag is added here and an unoptimised image is uploaded there, and six months later nobody can point to the change that did it.

Three habits prevent it: set a performance budget and fail the build when it is exceeded; review field data monthly rather than waiting for complaints; and require a written justification before any new third-party script is added. A tag that costs 300ms of INP should have to earn it.

Written by the team at AKASH Tech Inc., a software studio in Saskatoon, Saskatchewan. Questions about your own project? Email support@akash-tech.online or call +1 (306) 500-7938.