Speed as a Competitive Advantage: Why Core Web Vitals Matter More Than Design

Site speed usually comes up last. Design first, then content, then “we should probably make it faster”. The real order is the reverse: a page that never opened has neither design nor content. The visitor simply did not wait.

Core Web Vitals are Google’s attempt to measure not abstract seconds but what a person actually feels: when the main thing appeared, whether the page responds to a tap, and whether the layout jumps under their finger.

Three metrics and their thresholds

Scoring uses the 75th percentile of real visitors. That matters: if three quarters of people have a good experience and one quarter does not, the metric still fails. Testing on your own laptop over a wired connection is meaningless.

LCP: what actually slows it down

In 90% of cases the largest element is either a big image or the first-screen headline. The causes of delay come from a short list:

• A heavy image in an outdated format. A 1.5 MB JPEG where WebP would deliver 200 KB at the same quality.
• Lazy loading on the first screen. A loading="lazy" attribute on the hero image defers precisely the thing that must appear first.
• Fonts that block text. Without font-display: swap the headline waits for the font to download.
• A slow server response. If the server thinks for a second, nothing downstream will save you.
• Video on the first screen. Beautiful, and expensive in seconds.

INP: why a page feels sticky

INP replaced FID and measures not the first response but the worst one across the session. That is a more honest metric: people remember exactly the moment they tapped and nothing happened.

The cause is almost always the same – long JavaScript tasks. While a script computes for 300 milliseconds, the browser cannot process the tap. Usual suspects: heavy third-party scripts, handlers firing on every scroll pixel, synchronous work on click, several analytics systems running at once.

CLS: layout jumps

The most irritating problem from the user’s point of view and the easiest to fix. Causes:

• Images without declared width and height. The browser does not know how much space to reserve and pushes content down once the image loads.
• Ads and widgets injected after load.
• Font swapping: different letter widths shift paragraphs.
• Cookie consent banners appearing over the content.

The rule is simple: anything that will appear later must reserve its space in advance.

Lab data versus real data

This is a common source of confusion. Tools like Lighthouse give a lab run: one execution, stable conditions, simulation. For ranking, Google uses field data – real visits by real people on real devices.

So a green Lighthouse score alongside failing Core Web Vitals in Search Console is entirely normal. Lab data is for finding causes; field data is for judging the state. Trust the second.

What this gives the business

Speed affects money in two ways. Directly: someone who did not wait will never see your offer or your button. Indirectly: speed is a ranking factor, and slow sites are crawled less often.

A practical benchmark: most of the loss from a slow site falls on mobile users with poor connections. That is exactly the audience nobody sees when testing in the office.

A sequence of work that produces results

1. Look at field data. Search Console, Core Web Vitals section. That is the starting point, not Lighthouse.
2. Find the worst page template. The problem is usually not site-wide but confined to one page type.
3. Start with images. Modern formats, correct dimensions, no lazy loading on the first screen. The cheapest win available.
4. Remove unnecessary third-party scripts. Count how many you actually have and whether all are needed.
5. Reserve space for everything that loads late. CLS can be cured in a day.
6. Return to field data after 28 days. Changes need that long to accumulate.

The most common mistakes

• Chasing a perfect Lighthouse score. The difference between 85 and 98 is often invisible to users and consumes more time than everything else combined.
• A plugin instead of a cause. A caching plugin hides the symptom but will not remove three megabytes of images.
• Optimising without a baseline. Without before-numbers you cannot say what helped.
• Testing on desktop only. The real losses are always on mobile.

Speed is rarely the main reason a site fails to generate enquiries. But it is almost always a multiplier: everything else performs worse while the page takes four seconds to load. Which is why it is worth starting there, rather than after the redesign.