Speeding Up a Website: Core Web Vitals in Practice

The visitor clicks the ad, the page loads... loads... is still loading. On the fourth second, the back button. You will never see this person in the analytics; they never got the chance to become a "visitor." A slow site is dangerous because its losses are invisible.

Website speed earns or loses money on two fronts: user patience (conversion) and Google's assessment (visibility). The good news: on a typical site, most speed problems come from three or four standard causes and get fixed without technical depth. This article shows that short road.

Core Web Vitals: Google's three measures

Translated into plain language: let the page appear quickly (LCP), respond instantly when touched (INP), and keep the buttons from shifting while loading (CLS). The third is the least discussed but the most user-infuriating problem: you are reading the text, an ad loads, everything slides down.

Do not start without measuring: two free tools

PageSpeed Insights (pagespeed.web.dev): you type the address, you get a report — both a lab test and real-user data (where available). The second address is Google Search Console's Core Web Vitals section: the real-world picture of all your pages. The rule: measure first, fix, then measure again. Working from a "the site feels slow" feeling is repairing in the dark.

One important distinction: the lab score (0–100) and the real-user metrics are different things. 65 points + green real metrics is a better situation than 95 points + red real ones. Do not fall into score fetishism; the real-user data is the basis.

The 7 highest-yield fixes

• Compress images and serve them in the right format: on a typical site the biggest load is the images. The WebP format + shrinking before upload (a 4000px phone photo down to 1200px) is in most cases the single biggest win.
• Lazy loading: let below-the-fold images load later; on modern platforms it is one setting.
• Caching: for repeat visits; activated at the hosting/plugin level (the cache plugin we covered in the WordPress starter is exactly this).
• Delete surplus plugins and scripts: every plugin is load; the unused ones are simply ballast.
• Font discipline: more than two font families is both a design and a speed problem.
• Embed video, do not upload it: let video come from a hosting platform, not your own server.
• Hosting quality: all of the above sinks on a weak server; if TTFB is persistently high, the problem is in the hosting.

The typical culprits of CLS

The jumping problem usually comes from three places: images with no declared size (the browser cannot reserve space), banner/ad blocks that load later, and late-arriving fonts changing the text size. The fixes, correspondingly: width/height attributes on images, a pre-reserved fixed slot for the banner, a swap strategy in font loading. Depending on the platform these are a setting or a small code job; the PageSpeed report shows concretely which one you need.

How much speed is "enough"?

The honest answer: green Core Web Vitals + the subjective "opens instantly" feeling is enough; every millisecond after that is diminishing returns. The week spent turning 95 points into 99 usually earns more if spent on content. Speed is not the race itself but the entry condition; once the condition is met, attention should move to the remaining visibility factors.

Sources and further reading

Where to verify the source

The thresholds and methodology are updated by Google; read the current definitions at the official source.

• Google Search Central — Core Web Vitals: the official explanation and thresholds
• PageSpeed Insights: the measuring tool

Continuing the topic

Speed is one part of the technical foundation; the rest:

• The technical SEO checklist
• Choosing hosting in 2026
• WordPress setup and the first settings
• Moving a site up on Google
• Other articles on this topic

This evening's task takes five minutes: measure your site in PageSpeed and write down the biggest red item. Tomorrow's work is already known; on a report, not a guess.