What Core Web Vitals tell you
Core Web Vitals are three measures of a visitor’s experience on a web page. Largest Contentful Paint (LCP) concerns loading, Interaction to Next Paint (INP) concerns responsiveness, and Cumulative Layout Shift (CLS) concerns visual stability. Together, they can reveal friction that a visitor might describe more simply: “I waited for the page,” “the button felt slow,” or “the content moved while I was reading.”
These metrics are useful diagnostic signals, not a complete definition of a good website. A fast page can still have confusing navigation or unhelpful content. Likewise, improving a metric does not guarantee better search rankings. Treat the numbers as a way to identify and test changes that make pages easier to use.
LCP: When the main content becomes visible
LCP measures when the largest eligible image or text block in the visible part of the page finishes rendering. Depending on the page, that element might be a hero image, a headline, or a large block of text. A commonly used “good” threshold is 2.5 seconds or less. If LCP is slow, visitors may see a shell of a page while the content they came for is still missing.
Start by identifying the LCP element on a slow page template. If it is an image, check whether its file is larger than needed, whether the browser receives an appropriately sized version, and whether unnecessary lazy loading delays it. If it is text, look for slow server responses, blocking stylesheets, or fonts that hold up rendering. Third-party scripts and excessive page resources can also compete with the content that matters most.
Prioritize the pages and templates people use most rather than optimizing every image indiscriminately. A change to a shared template may help many pages, but measure the result: moving or replacing an element can also change which element counts as the LCP.
INP: How promptly the page responds
INP assesses responsiveness across a visitor’s interactions with a page, such as clicking a menu, selecting a filter, or typing in a form. It considers the time from an interaction until the browser can display the next visual update. A commonly used “good” threshold is 200 milliseconds or less. INP is not a measure of how long every network request takes; it focuses on the feedback a visitor sees after interacting.
Poor INP often points to a busy browser main thread. Large amounts of JavaScript, complex event handlers, or expensive rendering work can prevent the page from responding promptly. Test important interactions on a less powerful device as well as a desktop computer. A menu that feels immediate on a developer’s machine may be frustrating elsewhere.
Useful fixes depend on the cause. Remove scripts that serve no clear purpose, break up lengthy tasks, simplify costly updates, and provide prompt visual feedback where an action requires more processing. Avoid hiding a slow action behind an animation: the goal is a genuinely responsive interface.
CLS: Whether the layout stays put
CLS measures unexpected movement of visible elements while a page is in use. Unlike LCP and INP, it is a score rather than a duration; 0.1 or less is commonly considered good. A shifting page is more than a cosmetic issue. Someone may lose their place in an article or tap the wrong control when content moves beneath their finger.
Common causes include images without reserved space, advertisements or embeds that expand after loading, banners inserted above existing content, and fonts that change text dimensions when they appear. Give images and video containers dimensions or an appropriate aspect ratio, reserve space for variable content where possible, and avoid adding new elements above what a visitor is already viewing.
Watch the page through loading and interaction, not just in a finished screenshot. Layout shifts can occur after an embed arrives or a component updates, so a page that looks stable at first glance may still need investigation.
Measure, prioritize, and check again
Use real-user, or field, data when it is available to understand what visitors experience across devices and connections. Lab tests can help reproduce a problem and examine its likely causes, but one simulated run does not represent every visit. A URL may also have too little field data for a meaningful page-level result, so check whether a report is showing the individual page or a broader group of similar pages.
Work through one issue at a time: identify an affected template, reproduce the symptom, make a targeted change, and compare the result. Segment by device when you can, since mobile and desktop experiences may differ. Keep an eye on usability as well as scores. The most valuable improvement is one that helps visitors reach, read, and use the content they came for.
