A page can feel quick on a fast office connection and still fail the person who opens it on a phone, between other tasks, on a weaker signal. Speed is not one impression. A business site has to show the thing the visitor came for, respond when they tap, and stay still while it does so. It also has to be usable on a small screen, and the way it is built has to stay efficient as pages and scripts accumulate.
Core Web Vitals are the three measurements Google asks site owners to use for loading, responsiveness and visual stability. They are not a formula that places a page first, and they are not the only thing worth measuring. They are a shared language for a problem that otherwise collapses into "the site feels slow".
What are Core Web Vitals?
Core Web Vitals are field metrics, described by Google on web.dev and in Search Central. The current three are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google's guidance is to judge each one at the 75th percentile of page views, and to do that separately for mobile and for desktop. A page is in good shape on a metric when at least three quarters of those visits meet the good threshold, not when a single run on a developer's machine looks fine.
The set can change. Google has said the definitions are meant to stay stable, with notice before they move. First Input Delay used to be the responsiveness metric. Interaction to Next Paint replaced it as a Core Web Vital in March 2024. Guidance that still treats First Input Delay as the current Core Web Vital is out of date.
LCP: Largest Contentful Paint
Largest Contentful Paint measures loading. It marks the point at which the largest image or block of text in the visible area has been painted. On a business homepage that is often the main image or the main heading. Google's published threshold for a good experience is 2.5 seconds or less from the start of the load. Above 2.5 seconds, and up to 4 seconds, needs improvement. Above 4 seconds is poor.
It matters because it is close to the moment a visitor can tell what the page is for. A logo that appears at once, followed by a long wait for the actual offer, can still be a poor result on this metric.
INP: Interaction to Next Paint
Interaction to Next Paint measures responsiveness. It observes clicks, taps and keyboard input through the visit, and reports a value that stands for the slower interactions, with outliers set aside. What the visitor feels is the gap between a tap and the next change they can see: a menu opening, a form acknowledging the input, a filter applying.
A good result, on Google's published thresholds, is 200 milliseconds or less. Above 200 milliseconds, and up to 500 milliseconds, needs improvement. Above 500 milliseconds is poor. A page can pass a check on load time and still feel stuck, which is why this metric is separate from Largest Contentful Paint. It replaced First Input Delay, which only measured the delay before the browser began handling the first interaction, not how long the page took to show a response, and not the interactions that came later.
CLS: Cumulative Layout Shift
Cumulative Layout Shift measures visual stability. It adds up unexpected movement of content the visitor can see. A good score is 0.1 or less. Above 0.1, and up to 0.25, needs improvement. Above 0.25 is poor. A score of zero would mean nothing moved. A small shift can be noticeable without making the page unusable, which is why the good line is not zero.
The shifts people resent are the ones that happen as they are about to tap. A banner pushes a button down. An image arrives without space reserved for it. A font swaps in and the paragraph reflows. Movement the visitor asked for, such as opening a section, is not what this metric is there to catch.
Why website performance matters to UK businesses
The direct effect is on the person using the site. A slow or unstable page is harder to read, harder to trust and easier to abandon, especially on a phone, which is how many people first open a business site. That shows up as enquiries and checkouts that never finish, even when nobody has run a formal test. It is also an accessibility issue. A page that jumps, or that responds only after a long script, is a worse page for someone who already finds the interface difficult.
Search is the indirect effect. Google's documentation on page experience says that its ranking systems use Core Web Vitals, that there is no single page-experience score, and that a good Core Web Vitals result does not on its own put a page at the top. Search can still show the most relevant page when the experience is poor. Where many pages are similarly useful, a better experience can contribute. Treat performance as care for the visitor that can support search. Do not treat it as a control that awards first place.
The same care matters if you want the site to be a source other systems can read fairly. A page that does not load cleanly is a weak page in ordinary search and a weak page for any tool trying to summarise it. That wider point is in the article on SEO and AI search.
What causes a website to become slow?
Slowness is usually several ordinary decisions added together.
- Images larger than the space they occupy, or in a format the browser works hard to decode.
- Too much JavaScript, including code for features the page never uses.
- Third-party scripts for chat, tags, advertising or embedded media, each adding a request and often competing with the page itself.
- Caching that is missing, or so short that every visit rebuilds the same page.
- A slow response from the server before the first byte of the page is sent.
- Fonts that are heavy, or that arrive late and move the layout.
- A dependency pulled in for one component, then shipped to every page.
- Components that request more data than the screen shows, or that wait on each other in a chain.
- API calls made on every view when the result could have been prepared earlier.
How modern web development can improve performance
The remedies are ordinary engineering, applied with restraint rather than as a checklist of tools.
- Optimise images: sensible dimensions, a modern format, and space reserved in the layout so the page does not jump.
- Lazy-load images and embeds that sit below the first screen. Do not lazy-load the image that is the Largest Contentful Paint.
- Split the code so a page does not download the JavaScript for the rest of the site.
- Cache pages and files that are the same for every visitor.
- Serve those files from a content delivery network, so distance is a smaller part of the wait.
- Render on the server, or generate the page ahead of time, when the content is known before the visit. A dashboard behind a sign-in is a different case, and it does not need the same treatment.
- Fetch the data that page needs, not a copy of everything the business stores.
- Remove scripts that do not earn their place.
- Load fonts in a way that limits reflow, and do not ship weights the design never uses.
Next.js, used with React and TypeScript, can help with several of these: image handling, splitting code by route, and choosing server rendering or static generation for each page. It does not make a site fast because it appears on an invoice. A Next.js site with an oversized hero, a chat widget on every template and a client component that pulls in a large library will miss the same thresholds. The comparison of React and Next.js is about that starting point. It is not a promise of a particular score.
How to measure website performance properly
Look past the homepage, and past a single tool.
- Core Web Vitals for loading, responsiveness and visual stability, at the 75th percentile, on mobile and on desktop.
- Field data, where there is enough traffic to have it. The Core Web Vitals report in Search Console, and the field section of PageSpeed Insights, reflect real Chrome users. A quiet page may have no field data yet. That is a limit of the data, not a pass.
- Lab tests, such as Lighthouse, to reproduce a fault and see which request or script is involved. A lab result is a controlled run. It does not replace the field report.
- Server response, the weight of the page, and how long JavaScript takes to run. These explain a poor Core Web Vitals result. They are not Core Web Vitals themselves.
- The pages that carry the business: service pages, landing pages from campaigns, the quote or checkout path, and important articles. A fast homepage with a slow service page is a slow site for the person who came to enquire.
Test again after a change, on a phone-sized screen as well as a desktop one. A fix that appears only in a lab, on a powerful computer, has not been shown to help visitors.
Core Web Vitals and search
The honest sequence is technical quality, then how the page feels to use, then the chance that this experience supports search. Google's own documentation says ranking systems look at a variety of signals, that Core Web Vitals are among the signals those systems use, and that a strong score is not a promise of a top position. Relevance still comes first.
What you can control is the page. Make the main content appear promptly, respond quickly to a tap and keep the layout still. Give each important service a URL that matches the search, with text a crawler can read. That is the same discipline as the rest of technical SEO, not a separate trick. If a new design is being discussed, check whether the performance problem is the assets and the layout, or the architecture. The article on redesign versus rebuild is the decision that follows. A visual redesign can improve the vitals when the cause is heavy media or an unstable layout. It does not remove a structural wait.
How Web Works Rise approaches website performance
Performance is part of web development, not a report written after the site is already live. Public sites are built with React, Next.js and TypeScript, with attention to what each page sends to the browser. Technical structure, metadata and internal links are part of the same build. Cloud hosting and maintenance are how that performance survives the next campaign script and the next round of content. Nothing in the stack guarantees a particular lab score.
Web Works Rise is a UK-led team based in Birmingham, with a development hub in Tunisia supporting delivery. If an important page is slow, or a rebuild is being considered because the current site cannot be made fast, contact the team with the URL. A measurement of the page that matters is a better start than a promise about a score.