Core Web Vitals Got Worse After a Redesign

A redesign can make a site look sharper while making it slower, less stable, and harder to use.

Core Web Vitals regressions after redesigns are common because visual change tends to arrive with heavier media, new fonts, animation, component libraries, third‑party scripts, layout changes, and more client‑side work. None of those are automatically wrong. The problem is when nobody measures the cost until after release.

The fix is not to argue whether the old design was better. The fix is to isolate which metric moved, which template moved, and which change introduced the cost.

Start with Field Data Where Possible

Lab tools are useful. Field data tells you what real users experienced.

Compare before and after release for:

• Largest Contentful Paint (LCP)
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)
• page type
• device class
• country or market
• connection type where available
• browser
• traffic source

The Web Vitals documentation explains the metrics and thresholds. The important debugging point is that each metric points at a different kind of regression.

If LCP worsened, look at hero content, server response, render blocking, image priority, fonts, and data fetching. If INP worsened, look at JavaScript, hydration, event handlers, third‑party scripts, and long tasks. If CLS worsened, look at dimensions, injected content, fonts, ads, banners, and late‑loading components.

Segment by Template

Do not treat the redesign as one change.

Check:

• homepage
• article pages
• service pages
• product pages
• category pages
• search or filter pages
• checkout‑adjacent pages
• account pages

One template may be responsible for the regression. A new homepage hero might affect LCP. A product grid redesign might affect CLS. A new filter drawer might affect INP. A consent banner may affect every route.

This is where release evidence matters. If you have no template‑level before and after data, the team ends up debating taste instead of cost.

Inspect the New Lcp Element

After a redesign, the LCP element may have changed.

It might now be:

• a larger hero image
• a background image
• a heading using a web font
• a video poster
• a product image
• a carousel slide
• a CMS‑controlled image with poor dimensions

Check whether the LCP element is discoverable early, correctly sized, compressed, prioritised where appropriate, and not hidden behind client‑side rendering.

Chrome's Lighthouse documentation on Largest Contentful Paint is a useful reference, but use it alongside real page inspection. Lighthouse can point you at symptoms. It cannot tell you whether the new hero is worth the cost.

Review Third‑Party Script Changes

Redesigns often attract tracking changes.

New analytics, consent tools, personalisation, experimentation, chat widgets, review widgets, product recommendations, heatmaps, and marketing tags can all arrive around the same time as visual changes.

Check:

• scripts added during the redesign
• scripts moved earlier in the page
• tag manager changes
• consent banner timing
• A/B test wrappers
• personalisation blocking render
• scripts running on templates that do not need them

The article on third‑party script cost and Core Web Vitals covers this in more depth. The short version is that business‑critical scripts still need ownership and budgets.

Check Images and Layout Stability

CLS regressions are often caused by missing or unstable dimensions.

Look for:

• images without width and height
• responsive art direction without stable aspect ratios
• injected banners
• late‑loading related content
• cards changing height after data loads
• carousels changing size
• fonts swapping after layout
• cookie banners moving content

For redesigned components, define stable dimensions and responsive constraints. A page should not jump because a title wraps, a product image loads, or a module receives data after hydration.

Check JavaScript and Hydration Cost

INP regressions often come from interaction‑heavy redesigns.

Look for:

• larger client bundles
• more components marked client‑side
• expensive event handlers
• filter panels doing too much work
• animations tied to layout
• hydration of static content
• third‑party scripts on interaction paths
• unnecessary useMemo or state complexity hiding bigger work

React and Next.js can support rich interactions, but redesigns often turn static content into client‑side components unnecessarily. If a section does not need browser state, do not make users hydrate it.

Compare the Old and New Performance Budget

If the project had no performance budget, the redesign created one by accident. The budget was whatever shipped.

Set explicit limits for:

• JavaScript per template
• image size
• font count
• third‑party scripts
• LCP target
• CLS target
• INP target
• critical request chain
• route‑level data fetching

Performance budgets for real teams is the wider process article. For a regression, the budget gives the team a way to decide what to remove, defer, or redesign.

Turn Findings into an Engineering Roadmap

Avoid handing over a list of Lighthouse complaints.

Group fixes by owner:

• design decisions
• image pipeline
• front‑end components
• data fetching
• CMS constraints
• third‑party scripts
• platform configuration
• analytics and experimentation

Then rank by impact and risk. The fastest fix might be image priority. The most important fix might be removing an unnecessary script from every page. The most politically difficult fix might be changing a visual treatment that causes layout shifts.

The article on turning Lighthouse findings into an engineering roadmap covers that handover problem directly.

Wrapping Up

A Core Web Vitals regression after a redesign is not a verdict on the design. It is evidence that the new experience has costs the team needs to understand.

Segment by metric and template, inspect the LCP element, review scripts, stabilise layout, reduce unnecessary JavaScript, and turn the findings into owned work. Performance recovery is much easier when it is treated as product quality rather than a late technical complaint.

Key Takeaways

• Use field data where possible, then support it with lab evidence.
• Segment regressions by metric, template, device, and release.
• Inspect the new LCP element after visual changes.
• Review third‑party scripts added or moved during the redesign.
• Stabilise image, font, banner, and card layout.
• Convert findings into an owned roadmap rather than a raw audit dump.