Core Web Vitals for Beginners: Measure and Fix Site Speed

Site speed is no longer a personal impression. Google measures visitor experience with clear numbers called Core Web Vitals and uses them in ranking. The good news: there are only three metrics, and the highest-impact fixes are known and available to everyone.

The three metrics in plain language

• LCP — largest visible element: how long a visitor waits to see the main content. Target under 2.5 seconds.
• INP — interaction response: the delay when clicking or typing. Target under 200 milliseconds.
• CLS — layout stability: do elements jump while loading? Target under 0.1.

How to measure without paid tools

1. Open PageSpeed Insights and test one important page, not only the homepage.
2. Check the Page Experience section in Search Console after a week of data.
3. Trust real user data, not only a synthetic lab run.

Measuring first stops you from fixing what does not matter. Your LCP may be losing to one image, not to every script as the folklore says.

Five fixes with the biggest impact

• Compress images: use WebP and sensible dimensions; do not upload a 4000px image to display at 800px.
• Set image dimensions: prevents layout jumps and improves CLS.
• Defer non-critical scripts: analytics and ads must not block the first paint.
• Enable caching: cached HTML arrives several times faster.
• Cut plugins: every plugin can add CSS and JS to every page.

Common optimisation mistakes

The first is optimising without measurement, then stacking conflicting cache plugins. The second is chasing a lab score while forgetting the real phone experience. The third is fixing the homepage and leaving article pages, which are where traffic actually lands. Start with the pages that bring visitors, not the ones you like.

Speed and hosting

A light theme cannot rescue a crowded server. If response is slow before any image loads, the problem is hosting. Read the website speed checklist to diagnose the right layer first, and what NVMe is to understand disk impact on response time.

Reading a speed report without confusing yourself

A full report may list dozens of items, and most are low impact. Start with three questions only: what is the largest LCP element? Which script blocks first paint? Is there an image without dimensions? Answering these three fixes most of the problem. Do not chase a perfect score; chase an experience nobody complains about on an average connection.

Lab versus real user data

A lab tool tests one device on a fast network, while field data comes from many phones and connections. Your site may look excellent in the lab and average on a real phone. Look at both, and treat field data as the final judge. If you have many pages, start with those receiving the most visits or leading to signups, because improving them returns money, not just a number.

A practical priority table

• Week 1: images and dimensions.
• Week 2: deferred scripts.
• Week 3: caching and hosting.
• Week 4: re-measure and record the result.

What to do after each measurement

Write the date, the worst metric and your next fix in a small file. A month later, compare the numbers. If the metric did not improve, either the fix did not work or the real blocker is elsewhere, so step back. This log stops you repeating the same fixes and turns speed work into evidence instead of impressions. Note that improving LCP can hurt CLS, or the reverse, if you add random placeholder space; change one thing at a time.

Speed is not a one-off project; it is maintenance. Measure monthly, fix the single biggest blocker, and document the change. In three months you will beat most competitors, and the results will show in both rankings and conversions.