Core Web Vitals got worse after a redesign, how do I isolate the cause?

Here’s a practical way to isolate why Core Web Vitals got worse after a redesign.

1) First, identify which metric regressed

Look at the three separately:

• LCP = loading/rendering of the main content
• INP = responsiveness to user interactions
• CLS = layout instability

Use:

• CrUX / PageSpeed Insights for field data
• Lighthouse / WebPageTest for lab debugging
• RUM if you have it, to confirm real-user impact

If all three worsened, it’s usually a broader delivery/rendering issue. If only one changed, focus there.

---

2) Compare old vs new on the same page type

Don’t compare the homepage to a product page, or one URL to another. Use:

• Same template
• Same device class
• Same network profile
• Same browser

If possible, compare:

• before redesign vs after redesign
• staging vs production
• same page with feature flags on/off

---

3) Break the page into the usual suspects

For LCP

Check whether the LCP element changed:

• larger hero image/video
• new web font blocking text render
• heavier CSS
• JS delaying rendering
• server response slower
• third-party banner injected above the fold

Ask:

• What is the LCP element now?
• Is it the same element as before?
• Is it delayed by loading, rendering, or discovery?

Typical causes:

• bigger images or missing responsive images
• lazy-loading the actual LCP image
• client-side rendering replacing server-rendered content
• render-blocking CSS/JS
• font loading differences
• slower backend / CDN / cache changes

---

For INP

Check if the redesign added:

• more JS overall
• large bundles
• hydration overhead
• expensive event handlers
• long tasks on main thread
• third-party scripts
• heavy animations or menu interactions

Ask:

• Which interaction is slowest?
• Does it happen on first tap/click or only after load?
• Is the main thread busy when interaction occurs?

Typical causes:

• framework rehydration
• too much JS on initial load
• large rerenders on interaction
• event delegation issues
• third-party tags

---

For CLS

Check for:

• images without width/height
• ads/embeds loading late
• fonts swapping metrics
• banners/cookie prompts injected at top
• dynamic content inserted above existing content
• accordion/menu content shifting surrounding layout

Ask:

• Which element moved?
• Was space reserved?
• Did content load after first paint?

Typical causes:

• missing dimensions
• late-loaded components
• font metric changes
• sticky headers changing size
• animations affecting layout instead of transform/opacity

---

4) Use a diffing approach

Treat it like debugging a regression:

A. Capture before/after waterfall

Use WebPageTest or DevTools:

• document request
• CSS
• JS
• images
• fonts
• third-party resources

Look for:

• new requests
• larger transferred bytes
• later start times
• extra redirects
• cache misses
• blocking resources

B. Compare DOM and computed styles

Look for:

• changed hero structure
• extra wrappers
• different image formats/sizes
• font changes
• hidden elements that become visible later

C. Compare JS execution

Profile:

• total JS size
• scripting time
• long tasks
• hydration time
• layout/recalc style frequency

---

5) Isolate by turning things off

If you can reproduce in staging or behind flags, disable pieces one by one:

• third-party scripts
• new animation library
• chat widget
• new font loading strategy
• new carousel/hero component
• client-side personalization
• A/B test code
• cookie consent banner
• new analytics tags

If performance improves significantly when something is removed, you’ve found a likely culprit.

---

6) Use “filmstrip + trace” tools

Best tools for this:

• Chrome DevTools Performance
• Lighthouse
• WebPageTest
• PageSpeed Insights
• SpeedCurve / Calibre / New Relic / Akamai mPulse if available

What to look at:

• when the LCP element appears
• main-thread long tasks
• layout shifts in the trace
• network waterfall timing
• render-blocking resources

---

7) Check whether the redesign changed the delivery model

A redesign often introduces architecture changes:

• SSR → CSR
• static → server-rendered with personalization
• fewer images → more heavy JS components
• plain CSS → CSS-in-JS
• simple HTML → component framework hydration

These can cause all three metrics to worsen, especially if:

• too much content depends on JS
• CSS is injected late
• above-the-fold content isn’t server-rendered
• fonts/images are not prioritized correctly

---

8) Make a short hypothesis list

Usually the culprit is one of these:

1. Bigger or later LCP asset
2. More JavaScript and hydration
3. Missing image/font optimization
4. Late third-party injection
5. Layout reservation/regression
6. Slower backend or cache miss
7. Changed rendering path from SSR to CSR

---

9) A fast debugging workflow

1. Identify which CWV regressed
2. Identify the affected template/page type
3. Compare old vs new waterfall
4. Profile main-thread activity
5. Inspect LCP element / CLS sources / slow interactions
6. Disable suspect features one at a time
7. Confirm with field data after deploy

---

10) If you want the quickest next step

Run a before/after WebPageTest on the same URL and compare:

• LCP element
• total JS/CSS bytes
• long tasks
• layout shifts
• third-party requests
• hero image/font loading

That usually points to the cause very quickly.

If you want, I can also give you a step-by-step debugging checklist for LCP, INP, or CLS specifically, or help interpret a waterfall/trace screenshot.