Fast websites: LCP, INP, and what actually speeds a site up

“A fast website” means nothing without a number. In 2026 a company site has two scores that matter on a phone: how fast the content appears, and how fast the page reacts to a tap.

A good Core Web Vitals result is LCP within 2.5 s and INP within 200 ms. LCP measures when the main content shows. INP measures the response to an interaction. At or below those lines Google treats the result as good. Above them, a visitor on a weak connection often never reaches the offer. The metrics are covered in more detail in Core Web Vitals on Next.js.

A PageSpeed score of 90+ is a lab measurement. A fast site holds that result on a real phone, after photos, fonts, and scripts are added.

Where a slow site comes from

The usual sources repeat:

• an image or video in the first screen, with no dimensions and no priority,
• several marketing scripts firing before the content,
• a font loaded from outside, shifting the layout,
• a theme or a builder that adds JavaScript to every page.

Sometimes a specific weight can be removed: images, fonts, third-party scripts. Sometimes the architecture is the weight. A theme assembled from plugins, or a platform whose scripts cannot be turned off, does not get faster from another cache plugin.

On a WordPress to Next.js migration, mobile FCP fell from 4.1 s to 1.2 s and Core Web Vitals moved to 90+. FCP is not LCP. The example shows the threshold: when views fall apart on mobile, patching the theme stops changing the result. The migration path is in how to speed a site up by moving to Next.js.

When a fix is enough

A fix fits when the site is already on a modern stack and one condition hurts. A heavy hero. A video in the first screen. Images of several megabytes. Three pixels before the content. The order of work is then short: one LCP image with priority and sizes, the rest of the images lazy, scripts after the content, reserved space for a banner so CLS does not grow.

That review ends with a list of files to touch. A Lighthouse report alone, without that list, does not say what to change.

When a rebuild makes sense

A rebuild comes in when every new view breaks on mobile and the platform adds code that cannot be removed. In that setup, image optimisation fixes a fraction of the problem. The rest stays in the theme, the builder, or the plugin stack.

Leaving a slow site alone makes sense only when the offer copy is missing. A fast empty landing page still does not answer the query the page is supposed to rank for.

How these thresholds sit inside the wider cost of a site is in what a website costs in 2026. The technical list before launch is in the Next.js SEO checklist.