Core Web Vitals Checklist: How to Speed Up Your Website

Fast websites keep visitors, convert better and are easier for search engines to serve. Google’s Core Web Vitals turn “fast” into three measurable user-experience metrics, and they are part of how Google evaluates page experience. This checklist explains what they measure, how to test them and which fixes make the biggest difference.

It is written for site owners and developers alike. Where a fix is technical, we explain the idea in plain language first.

The three Core Web Vitals

Metric	What it measures	“Good” threshold
LCP (Largest Contentful Paint)	How quickly the main content appears	2.5 seconds or less
INP (Interaction to Next Paint)	How quickly the page responds to taps, clicks and key presses	200 milliseconds or less
CLS (Cumulative Layout Shift)	How much the layout jumps around while loading	0.1 or less

Google assesses these using real-user data at the 75th percentile: to pass, at least three quarters of visits need to meet the “good” threshold. INP replaced the older First Input Delay (FID) metric in 2024, so references to FID are out of date.

One important note: Core Web Vitals are one signal among many. Great content that answers what people are searching for still matters most. But a slow, jumpy site frustrates visitors regardless of rankings, so the work pays off either way.

Step 1: Measure before you change anything

Start with data, not guesses. Two kinds of data are useful:

• Field data comes from real visitors. Google Search Console’s Core Web Vitals report and the Chrome UX Report show how real users experience your site.
• Lab data is a controlled test. Lighthouse (built into Chrome DevTools) and PageSpeed Insights let you reproduce and debug problems.

Use field data to see whether you have a problem and lab tools to find why. Test on mobile first, since it is usually the harder case, and use a throttled connection to approximate typical conditions.

Step 2: Improve LCP (loading speed)

LCP is usually a hero image, a large heading or a big block of text. To make it appear sooner:

Fix the server and network

• Use a CDN so content is served from locations near visitors.
• Enable caching with sensible cache headers for static assets.
• Reduce server response time. Slow back-end processing delays everything else. Static or pre-rendered pages respond fastest.
• Compress text with Brotli or gzip.
• Use modern protocols such as HTTP/2 or HTTP/3, which most CDNs provide by default.

Optimise the LCP element

• Use modern image formats like WebP or AVIF, sized appropriately for the display.
• Serve responsive images with srcset and sizes so phones do not download desktop-sized files.
• Do not lazy-load the main image. Lazy loading is great for images below the fold, but it delays the one you need first. Consider marking the LCP image as high priority.
• Preload critical resources, such as the hero image or key font, when it helps.

Remove render-blocking work

• Inline or defer non-critical CSS and keep critical CSS small.
• Defer or async scripts that are not needed for the first paint.
• Limit web fonts. Load only the weights you use, and use font-display: swap so text shows immediately.

Step 3: Improve INP (responsiveness)

INP measures delays between a user action and the next visual update, across the whole visit. Poor INP is almost always caused by too much JavaScript running on the main thread.

• Ship less JavaScript. Remove unused libraries and avoid heavy frameworks for simple pages. Static-first sites can send very little script.
• Split code so each page loads only what it needs.
• Break up long tasks. Work that blocks the main thread for more than 50 milliseconds makes the page feel stuck. Split it into smaller chunks, or move heavy computation to a Web Worker.
• Keep event handlers light. Do the minimum needed to update the interface, and defer the rest.
• Audit third-party scripts. Tag managers, chat widgets, ads and analytics tools are frequent culprits. Load them after the page is interactive, and remove any you do not need.
• Avoid forced layout thrashing, where code repeatedly reads and writes layout properties, causing the browser to recalculate again and again.

Step 4: Improve CLS (visual stability)

CLS measures unexpected movement, like when you go to tap a button and an ad pushes it down. To prevent it:

• Set width and height (or an aspect-ratio) on images, videos and embeds so the browser reserves space.
• Reserve space for ads, banners and dynamic content. Give containers a minimum height instead of letting them pop in and shove everything down.
• Avoid inserting content above existing content after load, unless it is in response to a user action.
• Handle fonts carefully. Font swaps can shift text. Use font-display with a well-matched fallback font, or preload key fonts.
• Animate with transforms. Animating properties like transform and opacity does not trigger layout shifts the way changing top, height or margin can.

If you plan to show advertising on your site, CLS deserves special attention, because late-loading ad slots are a very common cause of layout shift. Reserve fixed space for each ad unit in advance.

Step 5: Build performance in from the start

Fixing problems after launch is slower than avoiding them. A few habits go a long way:

• Choose the right architecture. For marketing sites and blogs, static generation delivers pre-built HTML that loads very quickly. This site is built that way.
• Set a performance budget, such as a maximum page weight or JavaScript size, and check it in your build process.
• Optimise images in your workflow, not as a one-time clean-up.
• Monitor continuously. Scores drift as you add features. Re-test after significant changes.

If you want a fast, search-friendly site built on this kind of foundation, see our web development service.

Core Web Vitals checklist

Loading (LCP)

• Content delivered through a CDN with caching
• Images in WebP or AVIF, correctly sized and responsive
• Hero image not lazy-loaded; prioritised or preloaded
• Non-critical CSS and JavaScript deferred
• Fonts limited and set to swap

Responsiveness (INP)

• Unused JavaScript removed
• Code split by page or feature
• No long main-thread tasks
• Third-party scripts audited and delayed

Stability (CLS)

• Width and height set on all media
• Space reserved for ads and embeds
• No late-inserted content above the fold
• Font fallback tuned to match

Process

• Baseline measured in Search Console and PageSpeed Insights
• Mobile tested on throttled network
• Re-tested after each major change

Final thoughts

Core Web Vitals reward the same things visitors appreciate: pages that show up quickly, respond instantly and stay put while they load. Measure first, fix the biggest problem, and test again. Small, steady improvements add up.

Need help auditing your site or building a faster one? Talk to our team, or read about how the same thinking applies to apps in our guide to planning a mobile app MVP.