Website speed is easy to reduce to one number, but real user experience is more complicated. A page can appear quickly and still feel frustrating because buttons respond slowly. Another page may load fast but jump around as ads, images, or banners arrive. Core Web Vitals separate those problems into measurable signals.
In 2026, the three Core Web Vitals remain Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They measure loading performance, responsiveness, and visual stability.
What are the Core Web Vitals?
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP | Loading performance of the largest visible content element | 2.5 seconds or less |
| INP | Responsiveness to user interactions | 200 milliseconds or less |
| CLS | Unexpected visual movement | 0.1 or less |
Google’s web.dev guidance evaluates these thresholds at the 75th percentile of page loads. That means one perfect laboratory test is not enough if a meaningful share of real visitors still have a poor experience.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest relevant content element in the initial viewport to render. On a magazine or news page, the LCP element is often the featured image, hero image, large headline block, or another prominent visual.
Common LCP problems
- Slow server response time.
- A large, poorly compressed hero image.
- The browser discovers the LCP image too late.
- Critical content is inserted by JavaScript.
- Render-blocking CSS or fonts delay painting.
- Too many redirects before the final page loads.
How to improve LCP
Start by identifying the actual LCP element in PageSpeed Insights or Chrome DevTools. If the featured image is the LCP element, use appropriate dimensions, modern compression, responsive srcset, and avoid lazy-loading that above-the-fold image. Make the resource discoverable directly in the HTML and prioritize it when appropriate.
Server response matters too. Page caching, appropriate hosting, efficient database queries, a CDN, and avoiding unnecessary uncached dynamic work can reduce the time before the browser receives useful HTML.
Interaction to Next Paint (INP)
INP measures how responsive a page is to interactions such as clicks, taps, and keyboard input. It considers interaction latency across the page visit rather than looking only at a single early event.
Common INP problems
- Large JavaScript tasks blocking the main thread.
- Heavy analytics or advertising scripts.
- Menus or search interfaces that execute too much work on click.
- Complex DOM updates.
- Third-party widgets loading unnecessary JavaScript.
- Plugins that attach many event handlers or perform synchronous work.
How to improve INP
Reduce the amount of JavaScript executed on the main thread. Break long tasks into smaller work, delay non-critical third-party code, avoid loading scripts on pages where they are not needed, and simplify interaction logic.
For WordPress sites, plugin selection matters. A visually simple feature can still load a large framework. Audit what each plugin adds to the front end instead of judging only by its admin interface.
Cumulative Layout Shift (CLS)
CLS measures unexpected layout movement. A common example is reading a paragraph and having it jump downward because an advertisement, image, cookie banner, or font changes the layout.
Common CLS problems
- Images without width and height dimensions.
- Ads inserted into space that was not reserved.
- Embeds that resize after loading.
- Web fonts causing large text reflow.
- Sticky banners appearing without reserved space.
- Dynamic content inserted above existing content.
How to improve CLS
Reserve space for media and advertisements. Set image dimensions or use CSS aspect ratios. Give ad slots a predictable minimum size when possible. Avoid injecting new banners above content after the reader has started consuming the page.
Fonts should also be loaded thoughtfully. A custom font that changes character width dramatically can move headings and paragraphs when it arrives.
Lab data vs field data
Lab tools simulate a page load under controlled conditions. They are excellent for debugging. Field data comes from real users and reflects actual devices, networks, caches, geography, and interactions.
A page can score well in a lab and still have poor field performance because real visitors encounter slow hosting regions, heavy ads, third-party scripts, or devices that the test environment does not represent.
A practical Core Web Vitals workflow
- Start with field data. Check Search Console Core Web Vitals reports and PageSpeed Insights where enough real-user data exists.
- Group similar pages. A shared template issue can affect hundreds of URLs.
- Use lab tools to reproduce the problem. Lighthouse and DevTools help identify render blocking, long tasks, and layout shifts.
- Fix the largest root cause first. Do not optimize tiny files while a multi-megabyte hero image dominates LCP.
- Deploy carefully. Performance changes can affect layout or functionality.
- Monitor field data over time. Real-user metrics take time to reflect changed behavior.
WordPress-specific improvements
Use page caching
For pages that do not need unique generation on every request, full-page caching can reduce server work dramatically. Confirm that logged-out visitors receive cached HTML and that cache exclusions are limited to pages that genuinely require them.
Control plugins
Remove abandoned or overlapping plugins. More importantly, inspect what active plugins load on the front end. A plugin used only on the contact page should not necessarily load assets on every article.
Optimize images before upload
Use appropriate dimensions, responsive sizes, and modern formats supported by your stack. Avoid uploading a 5000-pixel image and relying on CSS to visually shrink it to 600 pixels.
Reserve advertising space
Magazine sites often lose CLS performance because ad slots collapse when empty or expand when an ad arrives. Define predictable containers and avoid moving the article after the reader starts consuming it.
Limit third-party scripts
Advertising, analytics, social embeds, heatmaps, chat tools, video players, and consent platforms can all affect INP and LCP. Load only what provides enough value to justify the performance cost.
Should you chase a perfect 100 score?
No. A 100 lab score can be useful as an engineering target, but it is not the business objective. A publication may legitimately use advertising, analytics, video, and interactive features. The goal is to provide a fast, stable, responsive experience while meeting business requirements.
Prioritize real-user performance and the most important templates instead of making cosmetic changes solely to move a synthetic score from 97 to 100.
Core Web Vitals and SEO
Page experience is one part of search performance, not a replacement for relevance, helpful content, crawlability, trust, and site structure. Improving Core Web Vitals benefits users regardless of ranking effects: faster pages reduce friction, stable pages are easier to read, and responsive controls improve engagement and conversions.
Frequently asked questions
What replaced First Input Delay?
Interaction to Next Paint replaced FID as a Core Web Vital. INP evaluates responsiveness across interactions rather than focusing only on the first input.
What is a good LCP?
Google’s web.dev guidance defines good LCP as 2.5 seconds or less.
What is a good INP?
A good INP is 200 milliseconds or less.
What is a good CLS score?
A good CLS score is 0.1 or less.
Can a CDN fix Core Web Vitals?
A CDN can improve network delivery and sometimes server response, but it cannot fix every problem. Large JavaScript tasks, unreserved ad slots, and poorly sized images still need application-level work.
Sources and further reading
