Website performance and Core Web Vitals

Performance is a user experience issue

Every performance problem is experienced as something other than a number. A page that is blank for four seconds reads as broken. A button that does not respond for half a second gets pressed twice. A layout that shifts as the reader reaches for a link makes them tap the wrong one. People rarely describe any of this as slowness. They describe it as the site being awkward, or they leave.

What Core Web Vitals measure

The set is not permanent. INP replaced First Input Delay as the responsiveness metric in 2024, precisely because measuring only the first interaction flattered pages that became sluggish afterwards. Treat the specific metrics as current guidance rather than fixed law.

Lab data versus field data

Lab data comes from a controlled test: one load, one device profile, one simulated network. It is reproducible, which makes it excellent for diagnosis and for catching regressions before release.

Field data comes from real visits: many devices, many networks, many conditions, aggregated over time. It is the only source that describes what actually happened to your audience — and the source search platforms report against.

Why a high score can still hide problems

• The tested page is the homepage; the traffic and the conversions are somewhere else.
• The test runs on a fast machine with a fast connection and no browser extensions.
• Consent tools, chat widgets and tag managers are absent from the test and present in reality.
• Interaction cost never appears, because the lab test does not click anything.
• Logged-in and dynamic pages, where the heaviest work happens, are never measured at all.

Images and media

Images are still the largest single contributor to page weight on most content sites, and the easiest to improve. Serve modern formats, size them to their actual rendered dimensions rather than the original upload, always declare width and height so the space is reserved before the file arrives, lazy-load anything below the fold, and never lazy-load the hero — that is the element LCP is usually measuring.

Fonts

Web fonts affect both speed and stability. Self-host them to remove a third-party connection, subset them to the characters actually used, preload only the one or two faces needed for the first screen, and set a font-display strategy that shows text immediately rather than leaving a blank block. A fallback with mismatched metrics causes a visible reflow the moment the real font loads — a stability problem, not just a cosmetic one.

JavaScript

JavaScript is the most expensive resource on the page, because it must be downloaded, parsed, compiled and executed — and that execution competes with the browser's ability to respond to the user. It is the dominant cause of poor responsiveness, and the gap between a modern development machine and a five-year-old tablet is enormous.

• Ship less of it: audit what each dependency earns its weight for.
• Split by route so a page loads its own code rather than the whole application's.
• Defer anything not required for the first screen.
• Break up long tasks so the main thread stays free to answer interactions.
• Prefer HTML and CSS solutions where they exist — they cost nothing to execute.

CSS and rendering

Stylesheets block rendering by design: the browser will not paint until it knows how things look. Keep the critical path small, avoid enormous unused frameworks, and be careful with animations that force layout recalculation. Animate transform and opacity, which the compositor can handle, rather than properties that trigger a full relayout on every frame.

Third-party scripts

Third-party code is the most common cause of a site being fast in testing and slow in production. Each tag is a request to a server you do not control, executing code you did not review, on the same main thread as your interface. Inventory them, name an owner for each, load them after the first render, and remove any nobody can justify. Consent tools deserve particular scrutiny, because they are early, blocking and often heavy.

Hosting and delivery

Server response time sets the floor for everything after it. Serve from an edge network close to the audience, cache aggressively where content is stable, compress text assets, and use modern protocols. None of this compensates for a heavy page, but a slow first byte guarantees a slow page regardless of how well the rest is built.

Performance on older hardware

This is the gap that matters most and gets tested least. An older iPad or a mid-range Android phone has a slower CPU, less memory, an older browser engine and often a less reliable connection. JavaScript that executes in 100 milliseconds on a development laptop can take close to a second there, and a device that has been in service for years may never receive another browser update.

Older engines also affect correctness, not only speed: modern CSS features can fail outright on browsers that predate them, which is why graceful degradation belongs in the build rather than in a support ticket. The same discipline applies to application interaction paths, covered separately in app performance: what makes an application feel fast.

The loading path

Performance budgets

A performance budget is an agreed limit set before the work begins — a ceiling on JavaScript for a page type, a maximum weight for a hero image, a cap on third-party requests. Its value is not the number; it is that adding weight becomes an explicit decision with a trade-off attached, rather than an accumulation nobody noticed.

Budgets have to be set per project against real audience conditions. A universal figure copied from an article is not a budget, it is a slogan.

Measure the pages that matter

Homepage performance is the most measured and rarely the most important. Measure the templates that carry traffic and revenue: the service page, the article template, the listing with filters, the enquiry form, the checkout. Include the interactions, not just the load — opening a menu, applying a filter, submitting a form.

Performance has to be protected

Performance is not won once. It erodes through ordinary work: a new tag, a larger hero, another font weight, a component that ships more code than intended. Protect it the same way you protect anything else that regresses — measure it on a schedule, check it before release, and treat a budget breach as a defect rather than a preference.