We’ve covered how Core Web Vitals metrics have evolved and what INP specifically changed. This is the practical checklist - what we actually walk through, step by step, when a client’s site is scoring poorly and needs concrete fixes, not just an explanation of what the metrics mean.
Step 1: Establish an accurate baseline
Test using real field data (Chrome User Experience Report data via PageSpeed Insights or Search Console), not just a single lab test - field data reflects real users on real devices and connections, which can differ meaningfully from a lab test run on a fast development machine. Fixing based on lab data alone can miss the actual experience your real user base is having.
Step 2: Fix Largest Contentful Paint (LCP) issues
- Identify the actual LCP element (usually a hero image or main heading) and ensure it isn’t lazy-loaded - we’ve covered this specific mistake in more depth elsewhere, since lazy-loading the LCP element directly delays the metric it’s supposed to help.
- Ensure the LCP element loads with high priority - proper preloading or fetchpriority hints for critical above-the-fold resources.
- Reduce server response time (TTFB) - a slow backend response delays everything downstream regardless of frontend optimization, so this is worth checking early, not after exhausting frontend fixes.
Step 3: Fix Interaction to Next Paint (INP) issues
- Break up long JavaScript tasks that block the main thread during user interactions - we’ve covered specific techniques for this elsewhere.
- Audit and reduce third-party script impact - frequently the largest, least-controlled contributor to poor interaction responsiveness.
- Reduce unnecessary re-renders in JavaScript-framework-driven interfaces, which compound interaction delay especially on lower-powered devices.
Step 4: Fix Cumulative Layout Shift (CLS) issues
- Add explicit width and height attributes to every image and embedded element, so the browser reserves the correct space before the content loads, rather than shifting the layout once it arrives.
- Reserve space for dynamically injected content - ads, cookie banners, dynamically loaded widgets - rather than letting them push existing content down after the page has already rendered.
- Avoid inserting content above existing content after initial page load, which is one of the most common and most visible causes of layout shift complaints from real users.
Step 5: Verify against real user data, not just the fix itself
After implementing fixes, confirm the improvement shows up in real field data over time, not just an immediate lab test - some fixes take time to reflect in the rolling field data Google actually uses for ranking purposes, and lab test improvement alone doesn’t guarantee the real-world metric has genuinely improved for actual users across varied devices and conditions.
What we actually recommend as an ongoing practice
Treat this as recurring maintenance, not a one-time project - we’ve covered why performance regresses by default as a site grows, unless something actively prevents it. Re-running this checklist periodically, particularly after adding new features or third-party integrations, catches regressions before they become a real ranking or conversion problem.
We run this exact process as part of our web performance work. Get in touch for a current Core Web Vitals audit against this checklist.