Core Web Vitals: what to measure and what to fix first

Which pages should you inspect?

You cannot judge a website’s performance from one homepage test. Choose an important service page, a longer article and an interface where visitors take action: searching, adding to a cart or requesting a quote. Record the device, network and sign-in state used for testing.

Keep a simple measurement log: URL, date, device, observed problem, suspected cause and next test. A slow mobile menu needs a different investigation from a late hero image. Prioritize the visitor journey most important to the business, not the easiest score improvement.

LCP: when does the main content appear?

LCP measures when the largest visible content element appears. A good target is 2.5 seconds or less. Identify that element on the page: often an image, but sometimes a large text block. For an image, check its size, when loading starts and whether the phone receives an appropriate resolution.

For example, a 4000-pixel hero image may waste bandwidth on a 390-pixel screen. Do more than change the file format: inspect the actual file served and the page’s network timeline. Treat the main content image differently from an off-screen illustration loaded later.

INP and CLS: does the page remain usable after loading?

INP measures the delay before visual feedback following a user interaction; a good value is 200 milliseconds or less. CLS measures unexpected layout shifts; a good value is 0.1 or less. Assessment uses the 75th percentile of real visits, so one fast personal test does not replace real-user data.

Test menus, search and form validation errors. If a click produces no visible response for too long, capture a browser performance trace. For layout shifts, investigate image sizing, late banners and fonts. Reserving image dimensions is often a simpler, more reliable fix than an elaborate animation.

Lab data and real-user data

PageSpeed Insights and browser developer tools provide different perspectives. Controlled runs help with troubleshooting, while field data shows how the website performs on different devices. If the tool does not provide enough field data, treat that as missing evidence, not automatic success.

For your own checks, repeat the same three actions before and after the fix. For an online store, these might be opening a product, choosing a variant and opening the cart. Record which steps improved and what stayed the same. The measurement log should also make sense to someone who was not involved in development.

Prioritizing fixes and verifying completion

Start by identifying one bottleneck. Compare test results with the baseline while checking that contact and purchasing still work. Changing images, caching and plugins simultaneously makes it difficult to tell what helped or caused a problem.

At completion, document the change, tested journeys and rollback option. Speed is part of a working service: a fast but broken form is not a good result. Improving Core Web Vitals alone does not guarantee search rankings; content and helping users complete their tasks also matter.

Example: a slow enquiry page

Suppose the hero image appears quickly, but submitting a form gives no visible response for two seconds. Do not start by compressing images further: check when validation runs, whether the request starts and how long the browser waits to render feedback. A visitor clicking repeatedly may submit multiple requests. Accurate progress feedback matters too.

Test valid and invalid data, including on slower devices and networks. Client-side feedback and the server response happen at different times. Document the steps so a developer can reproduce them: which field you filled in, what you selected, what you expected and what actually appeared.

What evidence should you request after a fix?

Handover should include before-and-after measurements under the same conditions and a brief functionality test. Ask which component caused the delay, what changed and what remains outstanding. An improved score alone does not explain the cause or whether the result is reproducible.

Over time, monitor the mobile visitor experience and important business actions separately. A new marketing script or larger hero image can degrade the website again. Repeat a short, representative check after every significant content or technical release.

• Check the live URL: status code, indexability and canonical URL.
• Record a baseline: date, affected page and a reproducible test.
• Measure again after the change: also test important user actions.