The Core Web Vitals Checklist: Pass All Three Without Touching JavaScript (2026)

Pass all three Core Web Vitals (LCP, INP, CLS) in one focused week, without rewriting a single line of JavaScript. The seven steps below are the exact playbook we run on every site we migrate. The median result on a Wix or WordPress site is Lighthouse mobile 92 to 100 within five working days.

This is a checklist, not an essay. Skim the steps, do them in order, ship one improvement a day. The win is real and Google reads the result inside two weeks.

If your site is already on a modern static stack and you only need someone to do this work for you, the apply form takes ninety seconds. We do this every day.

What Core Web Vitals actually grade

Three metrics, measured on real Chrome users (not lab tests):

• LCP (Largest Contentful Paint): how long it takes for the biggest visible element to render. Pass = under 2.5 seconds at the 75th percentile.

• INP (Interaction to Next Paint): how long the slowest interaction takes to feel responsive. Pass = under 200 milliseconds at the 75th percentile. INP replaced FID in March 2024.

• CLS (Cumulative Layout Shift): how much stuff jumps around as the page loads. Pass = under 0.1.

You need all three green to "pass" Core Web Vitals in Search Console. Two out of three is a yellow flag. Google has been ranking the difference since June 2021 and the impact has steadily grown. As of 2026, sites that pass all three on mobile have measurably higher visibility on competitive queries than sites that fail one.

Step 1: Audit and write down your current numbers

You cannot fix what you cannot measure. Pull the real numbers before you touch anything.

Open PageSpeed Insights, paste your URL, screenshot both the field data (top of page, real user data from CrUX) and the lab data (Lighthouse). The field data is what Google actually ranks on. Lab data is your iteration speed.

Note your three numbers: LCP (seconds), INP (milliseconds), CLS (decimal). Do this for at least three pages: homepage, your top traffic landing page, and one blog post.

Open Chrome DevTools, Network tab, hard reload, and watch what loads. Sort by size descending. The first five resources are your biggest opportunity.

Action items: write down current LCP, INP, CLS for three URLs. Identify your top five biggest network resources. Should take 20 minutes total.

Step 2: Fix LCP by preloading the hero image

LCP is almost always the hero image on a marketing page or the first paragraph on a blog post. If yours is the hero image, this single change drops LCP by 40 to 60% on most sites.

Identify the LCP element. PageSpeed Insights tells you in the diagnostics section. It is usually a banner image, a hero photo, or the largest H1.

If it is an image, preload it in the head:

<link rel="preload" as="image" href="/assets/hero.jpg" fetchpriority="high">

Add fetchpriority="high" to the image tag itself as well. This is a 2023+ Chrome feature that tells the browser to prioritize this resource above lazy-loaded content.

Confirm the image is properly sized. If you are loading a 2400 x 1600 photo into a 1200-pixel-wide hero, you are wasting two-thirds of the bytes. Resize to 2x the display dimension at most.

Action items: identify LCP element on three pages, add preload + fetchpriority, resize oversized hero images. Should take 60 to 90 minutes.

Step 3: Defer everything below the fold

Stop loading images, embeds, and iframes that the user might never see.

Add loading="lazy" to every img tag below the first viewport. On most templates this is everything except the hero. WordPress 5.5+, Squarespace, and Webflow do this automatically; check that your template is not overriding it.

Lazy-load iframes the same way. YouTube embeds, Google Maps, social embeds: all of them. The single biggest LCP killer we see in 2026 is a Google Maps iframe in the footer that someone forgot was loading on every page.

Defer or remove third-party scripts: live chat widgets, heatmap trackers, A/B test scripts, comment systems. The 2025 HTTP Archive data shows the median e-commerce page loads 22 third-party scripts. Remove half of them and your INP and LCP both improve.

Action items: add loading="lazy" to all below-fold media, audit third-party scripts, remove anything you do not actively use. Should take 60 minutes.

Step 4: Fix INP by chunking JavaScript work

INP measures how long the longest interaction blocks the main thread. The fix is almost always: break long tasks into shorter ones, and stop running JavaScript on every input event.

Open Chrome DevTools, Performance tab, click the gear, set CPU throttling to 4x slowdown. This simulates a low-end Android phone, which is what most real users actually have.

Record a five-second interaction: click your menu, scroll, click a button. Look for the long task warnings (red triangles). Anything over 50 ms is a problem. Anything over 200 ms is your INP failure.

Audit your input handlers. Click handlers that fire heavy work on every click are the most common offender. Wrap heavy work in setTimeout(..., 0) or requestIdleCallback to yield to the browser.

Disable analytics auto-events. Google Analytics 4 with auto-tracking is responsible for a measurable INP regression on the median site. Switch to manual event tracking on the events that actually matter.

If you are on WordPress with Elementor or WP Bakery, the page builder JavaScript is often the INP killer. There is no fix short of replacing the builder; this is one of the biggest reasons sites leave WordPress.

Action items: profile a real interaction with 4x throttling, identify long tasks, disable unnecessary analytics auto-events. Should take 90 minutes.

Step 5: Eliminate CLS with explicit dimensions

CLS is the easiest of the three to fix and the most commonly broken. The cause is almost always: an element loads asynchronously and pushes content down.

Add width and height to every img tag. Even if you are using responsive CSS, the browser uses the attributes to reserve space before the image loads.

<img src="/photo.jpg" width="1200" height="800" alt="..." style="width:100%;height:auto">

Add explicit dimensions to embedded iframes for the same reason.

Reserve space for ads, banners, and dynamic widgets. If you have a cookie banner, a notification bar, or an ad slot, give it a fixed height container so the page does not jump when it appears.

Self-host your fonts. Or, if you must use Google Fonts, add font-display: swap and preload the font file. Late-loading fonts that swap in a different size cause the most invisible CLS hits.

Action items: add width and height to every image and iframe, reserve space for late-loading widgets, fix font loading. Should take 60 to 90 minutes.

Step 6: Compress and modernize images

Images are still 60 to 70% of total page weight on the median site. Modern formats and reasonable compression cut this in half.

Convert hero and content images to WebP or AVIF. WebP saves about 30% over JPEG at the same visual quality, AVIF saves 50%. Both are supported in 99% of browsers in 2026.

Use a CDN that does this automatically: Cloudflare Polish, Cloudinary, Imgix, ImageKit. If you are on WebForger this happens at the worker layer with no setup.

Compress with quality 75 to 85. Above 85 the file size jumps with no visible difference. Below 75 you start seeing artifacts on photos.

Strip EXIF metadata. A photo straight from a DSLR can carry 100 KB of metadata you do not need. Tools like Squoosh, ImageOptim, or any modern image CDN strip this by default.

Action items: convert hero and high-traffic page images to WebP, compress to quality 80, strip metadata. Should take 90 minutes.

Step 7: Lock it in with a monitoring habit

Core Web Vitals are not a one-time fix. A theme update, a new third-party script, or a content change can break them in a week. The sites that stay green have one of two habits.

Habit one: weekly Search Console check. Open the Core Web Vitals report every Monday. If the URL count in the "needs improvement" or "poor" buckets has grown, investigate before it gets worse.

Habit two: real user monitoring (RUM). Tools like Speedcurve, RUMVision, or the free Cloudflare Web Analytics show you actual field data continuously, not waiting for the 28-day CrUX update.

Set a budget: any new feature, plugin, or third-party script must keep LCP under 2 seconds, INP under 150 ms, CLS under 0.05. Reject anything that breaks the budget. This is the single highest-leverage habit you can build.

Action items: bookmark Search Console Core Web Vitals report, set a Monday calendar reminder, establish a performance budget. Should take 30 minutes once.

The expected results

If you do all seven steps over five working days on a site that started at Lighthouse mobile 50 to 70, the typical outcome is:

• LCP from 4.0+ seconds down to 1.5 to 2.2 seconds

• INP from 300+ ms down to 100 to 180 ms

• CLS from 0.2+ down to 0.02 to 0.06

• Lighthouse mobile from 60 to 90+

• Search Console reclassification from "needs improvement" to "good" within 28 days

Sites built on Wix and Squarespace can usually get into the 75 to 85 Lighthouse range with steps 1 through 6, but hitting the 95+ band requires the underlying platform to ship less JavaScript than those builders inject. That is the actual ceiling on those platforms, and the reason migrating to a static stack is the single highest-impact performance move available.

Frequently asked questions

How long does it take to see the change in Search Console? The Core Web Vitals report uses 28 days of CrUX field data, so you will see the improvement begin to show after one to two weeks and fully reflect after four. PageSpeed Insights field data updates faster, usually within a week.

Do Core Web Vitals actually affect rankings? Yes, but not as much as people fear. Google has stated repeatedly that CWV is a tiebreaker when content quality and relevance are similar. Sites with poor CWV get outranked by similar-quality sites with good CWV; sites with great CWV but weak content do not magically rise.

What is the difference between lab data and field data? Lab data (Lighthouse) is a single test from one location with simulated conditions. Field data (CrUX) is real user data from Chrome users over the past 28 days. Google ranks on field data. Use lab data to iterate, field data to verify.

My LCP element is the H1, not an image. What do I do? Make sure your CSS for the hero section is in a critical inline style, your fonts are preloaded with display: swap, and your above-fold HTML is in the initial response (no SSR streaming for the hero). Static sites have a major advantage here.

Will switching from WordPress to a static site automatically pass CWV? Almost always yes for a clean migration. The median WordPress-to-static migration goes from Lighthouse mobile 65 to 95+. Wix and Squarespace migrations see similar gains because the JavaScript payload drops by 70 to 90%.

The short version

Audit, then fix in this order: preload hero, lazy-load below the fold, chunk JavaScript, set explicit dimensions, compress images, monitor weekly. One day per step. Five working days to all-green for most sites.

If you would rather skip the work and start with a stack that passes by default, the apply form is the fastest way to talk to us. Every site we ship targets Lighthouse mobile 95+ and CWV all-green, and we will tell you upfront whether your specific site is a fit.