Core Web Vitals Triage: Fix the 3 Pages That Matter

Core Web Vitals can feel like this never ending to do list.

You open PageSpeed Insights. Everything is red. LCP is bad. INP is bad. CLS is… weirdly fine on some pages, totally broken on others. Then you look at your CMS and realize you have, what, 300 URLs. 2,000. 20,000.

And someone says, “We need to fix Core Web Vitals sitewide.”

Sure. In a perfect world.

In the real world, you need triage. You need to fix the 3 pages that matter. Not because the other pages are unimportant, but because you want results this month, not a six month performance project that quietly dies in Jira.

This post is about picking the right three URLs, fixing them the right way, and using that momentum to roll improvements across templates later.

The point of triage (and why “sitewide” usually fails)

Core Web Vitals are measured at the URL level, but in practice they’re influenced by:

• your theme or shared layout
• your header and footer scripts
• your font loading strategy
• your image patterns
• your third party tags

So yes, you often can get sitewide wins. But teams get stuck because they start too big:

• “Let’s rewrite the whole header.”
• “Let’s migrate to a new framework.”
• “Let’s remove all scripts.”
• “Let’s rebuild the design system.”

And then nothing ships.

Triage is simpler. You pick three pages that are disproportionately responsible for:

• revenue
• leads
• demos
• signups
• first impressions
• ranking potential

Then you fix those pages aggressively, learn what actually moved the metrics, and reuse the changes across your site later. Calm, controlled, repeatable.

First, quick refresher: what you’re actually optimizing

Just to ground this.

LCP (Largest Contentful Paint): how fast the main content appears. Usually the hero image, headline block, or product screenshot.
INP (Interaction to Next Paint): how responsive the page feels when a user clicks, taps, types. Often killed by heavy JavaScript.
CLS (Cumulative Layout Shift): annoying jumps. Usually missing image dimensions, late loading fonts, injected banners, cookie bars.

If you want a deeper tool roundup, this is a solid reference: Core Web Vitals optimization tools.

Now let’s do the triage method.

Step 1: Choose the 3 pages that matter (the only rule is impact)

Here’s the exact framework I use. It’s not fancy. It works.

You’re picking:

1) Your money page (or highest intent landing page)

This is the page that directly converts. Examples:

• /pricing
• /book-a-demo
• /contact
• /checkout
• a high intent “service” page for local businesses

If you have a local SEO setup, this might be a city landing page that already ranks and drives calls. (If you’re building those pages, see: build local SEO landing pages.)

Why it matters: if Core Web Vitals are hurting UX here, you’re bleeding conversions. Even small improvements can show up in signup rate.

2) Your top organic entrance page (the one Google already likes)

Go to Google Search Console and sort pages by clicks over the last 28 days.

Pick the page that:

• already brings traffic
• is not your homepage (if possible)
• has obvious engagement value

This page is your “free traffic faucet.” If it loads like a truck, users bounce, dwell time drops, and you’re leaving rankings and assisted conversions on the table.

3) Your “future winner” page (the one that should rank)

This is where most teams mess up. They only optimize what’s already working.

Instead, pick one page that has:

• impressions but low clicks
• decent average position (say 6 to 20)
• strong commercial value if it ranks

This is often a comparison page, a “best X” page, or a product-led use case page. Combine CWV fixes with title and snippet improvements and you can get a nice jump. For CTR specifically, this is worth reading: improve CTR with a title fix kit.

So that’s your three. Money page. Current winner. Future winner.

That’s it.

Step 2: Confirm you have real world CWV problems (not lab-only drama)

Before you start ripping scripts out, check whether the issue is showing in field data.

Use:

• CrUX / PageSpeed Insights field data if available
• Search Console Core Web Vitals report
• or your RUM tool (if you have one)

A lot of pages look “bad” in Lighthouse but pass in the field. Or the opposite, they pass in Lighthouse but users on mid-range Android phones are suffering.

Triage rule: prioritize fixes that show up in field data, because that’s what Google and real users actually experience.

Also. Segment by device. Mobile is usually where the bodies are buried.

Step 3: Run the same diagnostic checklist on each of the 3 pages

This is the part that saves time. You're not doing random performance whack-a-mole. You're going through the same "what's killing it" list per page.

A) LCP triage: find the LCP element and fix the chain

Open Chrome DevTools (Performance tab) or use WebPageTest. Identify the LCP element.

Common LCP culprits on SEO pages:

• a hero image loaded via CSS background-image
• a giant above-the-fold screenshot
• an H1 block that is delayed by font loading
• a slider. always a slider

Then fix the chain, in order:

1. Reduce TTFB (server response) if it's slow

• caching, CDN, full-page cache, reduce backend work
• if you're on WordPress, your hosting and cache setup matters more than people admit

2. Prioritize the LCP resource

• preload the hero image if it's truly the LCP
• don't lazy load the hero image
• use fetchpriority="high" for the hero image where appropriate

3. Compress and resize images properly

• use WebP or AVIF
• serve correct dimensions
• avoid shipping a 2400px screenshot into a 390px viewport

4. Stop blocking the render

• defer non-critical JS
• inline critical CSS (carefully)
• reduce giant CSS bundles when possible

A small but real tip. If your LCP is text, not an image, it's often font related. Which brings us to CLS too.

B) INP triage: hunt long tasks and third-party scripts

INP is the new pain metric because it's not one "thing." It's death by a thousand cuts.

On SaaS sites and marketing pages, the usual suspects are:

• chat widgets
• AB testing tools
• analytics stacks layered on analytics stacks
• tag managers firing too much too early
• heavy page builders
• big React bundles for basically static pages

What to do, in triage mode:

1. Delay non-essential third party scripts

• load chat after user interaction or after a timeout
• load heatmaps only on pages where you truly need them
• don't run experiments on every blog post

2. Break up long main-thread tasks

• code splitting if applicable
• remove unused JS
• reduce hydration cost if you're on a framework that hydrates everything

3. Be honest about your "must have" tools

If a script costs you 300ms of responsiveness on mobile, it better be paying rent.

INP improvements can feel less "visible" than LCP, but users feel it immediately. Especially on pricing pages where they click tabs, expand FAQs, change billing cycles. If that interaction lags, it kills trust.

C) CLS triage: stop the page from jumping around

CLS fixes are often the quickest wins.

Typical causes:

• images without width/height (or aspect ratio)
• ad slots collapsing then expanding
• cookie banners injecting above content
• late loaded fonts swapping and shifting headings
• embedded videos without reserved space

Fixes:

• add explicit dimensions or aspect-ratio for images and embeds
• reserve space for banners and sticky headers
• use font-display: optional or swap carefully, and preload key fonts
• avoid inserting DOM above existing content after load

Also, watch your "related posts" widgets. Some of them load late and shove the page down like a prank.

Step 4: Fix the template, but validate on the page

Here’s the subtle thing about “3 pages.”

You’re fixing pages, yes. But most of the time, the fixes are template-level:

• your global scripts
• your header CSS
• your font loading
• your image component
• your nav behavior

So you make changes at the theme or component level, and then you validate improvements on the 3 selected pages.

That’s triage done correctly. You don’t end up with one-off hacks that only work on one URL.

Step 5: Don’t let performance fixes wreck SEO basics

This happens more than anyone wants to admit.

A dev optimizes performance and suddenly:

• internal links disappear behind JS
• content is deferred in a way Google doesn’t reliably see
• titles or canonicals change in templates
• structured data gets removed
• important sections become hidden behind interactions

So while you’re doing CWV triage, keep an eye on on-page fundamentals. If you need a clean checklist to run after changes ship, use this: on-page SEO optimization fixes.

And if the page is content heavy, readability still matters. Performance does not compensate for a wall of text that nobody wants to read. This is useful for quick cleanup passes: SEO writing checker to fix readability issues.

Step 6: Measure like an adult (what to track after you ship)

Don't just re-run Lighthouse and call it a win.

Track:

• Search Console CWV status changes (over time)
• CrUX field data shifts
• conversions on the money page (signup rate, demo submits, checkout completion)
• engagement metrics on the organic entrance page (scroll depth, time on page, bounce)
• rankings and CTR on the future winner page

If your team is already KPI-driven, tie it into the metrics that actually matter for SaaS and SEO. This pairs nicely with the broader view: SaaS SEO KPIs that matter.

One more thing. CWV improvements can take time to show in field data because they're based on real user samples. So log your ship dates. Be patient, but not passive.

The exact "3-page" playbook I'd run this week

If I had to do this fast, here's the simple plan:

1. Pick the 3 URLs

• Pricing page
• Top non-homepage organic landing page
• One page sitting at positions 6 to 20 with commercial intent

2. Run PageSpeed Insights and record

• LCP, INP, CLS
• screenshot the diagnostics so you can compare later

3. Make the big obvious changes first

• compress hero images and stop lazy loading them
• defer non-critical scripts, delay chat, reduce tags
• reserve space for images, embeds, banners

4. Re-test

• lab metrics should improve immediately
• field metrics will lag, but you should see directionally better performance

5. Roll fixes into reusable components

• image component
• video embed component
• global script loader logic
• font strategy

Now you're not just "fixing pages." You're improving the whole system, without boiling the ocean.

Where SEO.software fits (if you want this to be repeatable)

Core Web Vitals triage is not only a dev task. It’s also a content and SEO ops task, because the pages you choose matter. The way you prioritize matters. The way you keep publishing while fixing performance matters.

If you’re trying to scale content without losing control of quality, internal linking, and on-page hygiene, that’s basically the workflow SEO.software is built for. You connect your site, get a strategy, publish consistently, and keep a tighter loop on which pages are winning and which ones need help.

Also, once your three pages are fixed, the next question is usually, “Cool, what else is dragging the site down?”

At that point, it helps to systematically audit and prioritize pages, not guess. If you want a good process for analyzing what competitors are doing and choosing which pages to build or improve next, this is a strong follow-up: reverse engineer competitor pages into a content plan.

Wrap up

If your site has CWV problems, don’t start with “fix everything.”

Start with three pages:

• the one that makes money
• the one that already gets traffic
• the one that’s close to ranking and would be valuable if it did

Fix LCP by prioritizing the main content and cutting render blockers. Fix INP by being ruthless with JavaScript and third party scripts. Fix CLS by reserving space and controlling late loading assets.

Then reuse what you learned across templates.

That’s triage. And honestly it’s the only way most teams ever get Core Web Vitals improvements to ship.