How to improve LCP (Largest Contentful Paint)
LCP measures when the largest element in the viewport finishes rendering. A good LCP is 2.5 seconds or less at the 75th percentile. Most LCP problems come from a slow server response, render-blocking resources, or an unoptimised hero image. Here is what moves the needle, in rough order of impact:
- Serve the LCP element fast: if it is an image, compress it, use a modern format like AVIF or WebP, set explicit width and height, and add fetchpriority high so the browser loads it first.
- Cut server response time (TTFB): cache HTML at the edge, use a CDN, and avoid slow database calls on the critical path. A TTFB above 800ms makes a good LCP almost impossible.
- Remove render-blocking CSS and JavaScript: inline critical CSS, defer the rest, and avoid synchronous third-party scripts above the fold.
- Preload the LCP resource: add a preload link for the hero image or font so it starts downloading before the browser discovers it in the DOM.
- Do not lazy-load the LCP image: lazy-loading the above-the-fold hero delays it. Lazy-load only what is below the fold.
Example: preload and prioritise the LCP image
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<img src="/hero.avif" width="1200" height="600" fetchpriority="high" alt="Hero image">
How to improve INP (Interaction to Next Paint)
INP replaced First Input Delay as a Core Web Vital in March 2024. It measures how quickly the page responds to user interactions across the whole visit, not just the first one. A good INP is 200ms or less at p75. INP problems are almost always long main-thread tasks. To improve it:
- Break up long tasks: split work that runs longer than 50ms (a long task) into smaller chunks and yield to the main thread so input can be processed between them.
- Defer non-urgent work: move analytics, hydration, and heavy computation off the interaction path, for example with requestIdleCallback or by waiting until after the interaction paints.
- Ship less JavaScript: code-split by route and remove unused third-party scripts that hog the main thread.
- Keep event handlers light: debounce expensive updates and avoid layout thrashing inside handlers so an interaction can paint quickly.
- Move heavy computation to a web worker so it never blocks the main thread during an interaction.
How to improve CLS (Cumulative Layout Shift)
CLS measures unexpected layout movement while the page loads. A good CLS is 0.1 or less. Shifts almost always come from content that loads without reserved space. To fix it:
- Set explicit width and height, or an aspect-ratio, on images, videos, and embeds so the browser reserves their space before they load.
- Reserve space for ads, banners, and embeds with a min-height so late-loading content does not push the page down.
- Preload fonts and use font-display optional or a closely matched fallback to avoid the shift from a late web-font swap.
- Never insert content above existing content unless it is in direct response to a user interaction.
- Animate with transform and opacity, not properties that trigger layout such as top, left, width, or height.
WordPress Core Web Vitals
WordPress sites usually fail Core Web Vitals for the same few reasons: heavy themes, unoptimised images, render-blocking plugin CSS and JS, and slow hosting. The highest-leverage fixes:
- Add page caching, through a caching plugin or a host-level cache, so HTML is served fast, plus a CDN for assets. This alone often fixes LCP.
- Optimise images with a modern image plugin that serves AVIF or WebP, correct sizing, and lazy-loading for below-the-fold images only.
- Reduce plugin bloat: every plugin that enqueues CSS or JS on each page hurts INP and LCP. Audit and remove what you do not need.
- Choose a lightweight theme and avoid page builders that ship large amounts of CSS and JavaScript.
- Upgrade hosting if TTFB is high. Cheap shared hosting often cannot deliver a good LCP no matter what you optimise on the page.
Do Core Web Vitals affect SEO?
Yes. Core Web Vitals are part of Google's page experience signals and can influence ranking, most clearly as a tie-breaker between pages of similar relevance and quality. They are not a silver bullet that outweighs content and links, but poor vitals can hold a page back, and good ones remove a handicap.
The bigger win is usually commercial. Faster, more stable pages convert better and bounce less, so improving Core Web Vitals tends to pay off in revenue before it pays off in rankings. Google measures the signal on real-user field data from CrUX, so lab-only fixes that never reach real users will not move it.
Related: Core Web Vitals Checker · What are Core Web Vitals · Page Speed Monitoring