Core Web Vitals: What to Fix First on a Slow Website

On a slow website, fix Core Web Vitals in order of impact: first the Largest Contentful Paint (usually the hero image, fonts and server response), then Interaction to Next Paint (third-party scripts and heavy JavaScript), then Cumulative Layout Shift (ads, embeds and images without reserved space). Start from field data in Search Console or PageSpeed Insights, not from a lab score, and fix the metric that fails for real visitors on mobile. Speed is a confirmed Google ranking input, but a modest one: it helps a relevant page win, it does not rescue an irrelevant one.

The three metrics and their thresholds

Core Web Vitals are three user-centric metrics that Google measures on real Chrome visits. A page passes when at least 75% of visits, counted separately for mobile and desktop, fall into the "good" range for all three.

• Largest Contentful Paint (LCP) measures loading: how long until the largest image or text block in the viewport is rendered. Good is 2.5 seconds or less, poor is above 4 seconds.
• Interaction to Next Paint (INP) measures responsiveness: the delay between a click, tap or key press and the next visual update, taken across the whole visit. Good is 200 milliseconds or less, poor is above 500 milliseconds.
• Cumulative Layout Shift (CLS) measures visual stability: how much content jumps around unexpectedly. Good is 0.1 or less, poor is above 0.25.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. The change matters for older audits: FID only measured the delay before the first interaction was handled, so many sites that "passed" on FID fail on INP, especially JavaScript-heavy ones. If a report or agency proposal still talks about FID, it is out of date.

How much speed actually matters for rankings

Google's own page experience documentation is careful here, and it is worth reading it the same way. It states that Core Web Vitals are used by its ranking systems, that there is no single page experience signal, and that Search always tries to show the most relevant content even if the page experience is sub-par. Good scores do not guarantee top positions, and beyond Core Web Vitals, other page experience aspects do not directly help a site rank higher.

In practice this means:

• Content relevance and quality come first. A fast page with weak content will not outrank a slow page that answers the query much better.
• Between comparable pages, a good experience can be the tiebreaker, and failing all three metrics on mobile is a real handicap.
• The bigger business effect is often outside rankings: fewer abandoned visits, better ad landing page performance and more completed forms.

So treat Core Web Vitals as hygiene with a measurable ceiling, not as a growth hack. The goal is "good" for real users, not a perfect 100 in a lab tool.

Field data vs lab data: where to look first

Two kinds of numbers get confused all the time, and the confusion leads to fixing the wrong thing.

• Field data comes from real visitors. The Chrome UX Report (CrUX) aggregates anonymized measurements from Chrome users who opted in, and this is what Google uses. The Search Console Core Web Vitals report shows it grouped by similar pages, with mobile and desktop separately, and a group's status is set by its worst metric. Low-traffic pages may have no data of their own and fall back to origin-level numbers.
• Lab data comes from a single simulated load, such as Lighthouse in Chrome DevTools or the lower part of a PageSpeed Insights report. It is reproducible and great for debugging, but it uses one device profile and one network, and it cannot measure INP directly because nobody clicks anything.

PageSpeed Insights shows both: the top block is CrUX field data (when the URL or origin has enough traffic), the diagnostics below are a Lighthouse run. Our rule: decide what to fix from field data, then use lab tools to find out why. A common mistake we see is a team chasing a Lighthouse performance score while the Search Console report says the real problem is INP on mobile product pages.

The prioritized fix list

On most slow marketing sites, the same causes appear again and again. In rough order of payoff:

• The LCP image. The hero image is usually the LCP element. Serve it in a modern format at the size it is displayed, do not lazy-load it, give it a high fetch priority and make sure it is in the initial HTML rather than injected by a script or a slider. Background images set in CSS are discovered late; a real image element is found sooner.
• Fonts. Several families and weights from a third-party font service delay text rendering and can shift layout when they swap in. Self-host only the weights you use, preload the one used above the fold and use a matched fallback so the swap does not move text.
• Third-party tags and chat widgets. Tag managers carrying old pixels, A/B testing tools, heatmaps, review widgets and live chat often account for most of the main-thread work. Remove what nobody reads, load the rest after the page becomes interactive, and replace a chat widget with a lightweight button that loads the full script only on click.
• Hydration-heavy JavaScript. Sites built as single-page apps or with large component frameworks can ship megabytes of JavaScript to render mostly static text. That hurts INP directly. Server-render or pre-render content pages, hydrate only interactive islands and split bundles per route.
• TTFB, hosting and CDN. If the server takes a second to answer, every other metric starts a second late. Cache full pages, serve static assets and HTML from a CDN close to US visitors, and move off overloaded shared hosting if the time to first byte stays high under normal traffic.
• Layout shifts from ads and embeds. Ad slots, cookie banners, video embeds and images without width and height push content down after it renders. Reserve space with fixed dimensions or aspect ratios, and show banners as overlays instead of inserting them above content.

Page builders: where optimization hits a ceiling

Wix, Squarespace, Webflow and WordPress page builders such as Elementor or Divi make sites easy to edit, but each limits how far performance can go.

• Hosted builders (Wix, Squarespace). The platform controls the server, the core scripts and much of the markup. You can compress images, trim apps and widgets, and simplify the first screen, but you cannot remove the platform's own JavaScript or change how pages are rendered.
• Webflow. Clean output and a global CDN make it a reasonable starting point, but interactions, heavy animations and third-party embeds still add up, and custom code control is partial.
• WordPress page builders. Every widget adds markup, CSS and scripts, and plugins pile on their own assets on every page. Caching and optimization plugins help, but they patch the output rather than reduce what is generated.

On any of these, the realistic target is usually "good" or close to it, with a clean first screen and disciplined third-party scripts. When a site stays in "poor" after that work, the limit is the platform, not the effort.

When to optimize and when to migrate

Optimizing the current site is the right first step in most cases: it is cheaper, faster and keeps content workflows intact. Migration makes sense when the platform itself is the bottleneck.

• Optimize when the failures trace to fixable causes: oversized images, too many tags, fonts, a slow host or missing caching.
• Migrate when INP stays poor because of platform JavaScript you cannot remove, when the builder's markup keeps LCP above 4 seconds on mobile after the image and font work is done, or when the redesign needed for the business is fighting the builder anyway.

A migration is also an SEO event. URL parity, redirects, metadata and a post-launch check of Search Console are part of the job, otherwise speed gains can be offset by lost pages. Our performance-focused migration covers both sides, and for teams that like Webflow's editor but have outgrown another builder, a Webflow migration is often a middle path.

How to choose: our decision rule

Open the Search Console Core Web Vitals report for mobile and note which metric fails on which page groups. Fix in this order: LCP image and server response, then third-party scripts, then layout shifts, and recheck field data after the 28-day window rolls over. If a page group is still "poor" after one focused optimization pass and the remaining cause is platform code you cannot change, plan a migration; if it reaches "good", keep it there with a monthly check, because new tags and widgets are the most common way fast sites become slow again. Ongoing support and maintenance exists largely for that reason.