Slow Website? Understand Core Web Vitals and What to Fix First

01Understand the three measurements

Largest Contentful Paint, or LCP, measures loading of the main visible content. Interaction to Next Paint, or INP, concerns interaction responsiveness. Cumulative Layout Shift, or CLS, measures unexpected visual movement. They address different problems, so one change may not improve all three.

web.dev identifies good thresholds of LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Real-user evaluation considers the distribution of experiences, rather than one unusually fast run. These are diagnostic thresholds, not promises of business outcomes.

02Separate field and laboratory data

Laboratory tests use controlled conditions and help investigate causes. Field measurements reflect real devices, networks, and behavior. Both are useful, but they answer different questions and need not produce identical results.

A new or lightly visited site may lack enough field data. Use simulations and direct task checks while gathering usage experience. Avoid generalizing from a single powerful laptop on a fast connection to every customer.

03Review images, fonts, and initial content

Oversized images add transfer work. Match their dimensions to their display needs, choose appropriate formats, and provide intrinsic sizes so space can be reserved. Prioritize the visible opening image and load lower-page content as needed.

Review font families, font weights, autoplay video, and third-party scripts. Each component should have a justified role. Removing something that does not help customers can be more useful than optimizing an unnecessary effect.

04Investigate slow interactions

Try menus, search, filters, forms, and checkout. Record moments when the interface stops responding or a task becomes unclear. Long JavaScript work, expensive rendering, and additional integrations may need developer investigation.

Progress feedback explains an ongoing request, but does not replace responsiveness work. Ensure repeated clicks do not submit the same action multiple times. Also test slow networks and failed requests, not only successful interactions.

05Recheck important pages and tasks

Sample relevant page types such as the homepage, service details, articles, and ordering flow. Record test conditions and changes. Checking only the homepage can miss problems in product pages or forms even when the initial score looks strong.

Combine metrics with direct checks: can people read, choose, and submit their requirements comfortably? Preserve necessary functionality while reducing unnecessary work. Performance improvements should support the experience, rather than only producing a presentation score.

06Illustrative example: a heavy hero and slow controls

A service site uses a large opening video and several added scripts. Some devices wait for the main content and then experience a delayed menu response. The team separates loading problems from interaction problems: reducing the video may help one without resolving the other.

Developers test under documented conditions, inspect asset sizes, and examine work triggered by the menu. Images receive reserved space to reduce shifts. Unused additions are reviewed for removal. Essential functions are retested so optimization does not break the customer contact route.

Measurements and core tasks are repeated after changes. Simulated results are distinguished from insufficient real-user data. The improvement report explains what changed and the limits of testing instead of presenting one score without context.