Core Web Vitals are Google’s measures of how a page feels to a real visitor: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and whether things jump around while it loads. They feed into search ranking signals, but the better reason to care is that slow, jumpy pages lose people.

WordPress gets blamed for poor scores, but WordPress itself is rarely the problem. The usual causes are heavy themes, too many plugins, unoptimised images, third-party scripts and cheap hosting. This guide covers what actually moves the numbers, in the order we usually tackle them.

The three metrics in plain English

  • Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element, usually a hero image or headline, to appear. Google’s “good” threshold is 2.5 seconds or less.
  • Interaction to Next Paint (INP) measures how quickly the page visibly responds after a click, tap or key press, across the whole visit. It replaced First Input Delay in March 2024. Good is 200 milliseconds or less.
  • Cumulative Layout Shift (CLS) measures how much content moves unexpectedly while the page loads. Good is 0.1 or less.

Google judges these on real-user data collected from Chrome, looking at the 75th percentile of visits. That means a fast result on your office laptop does not count for much. What matters is how the site performs for ordinary visitors on ordinary phones and connections.

Measure before you change anything

Start with field data, not lab scores. Search Console has a Core Web Vitals report grouped by URL type, and PageSpeed Insights shows real-user data at the top when enough exists for that page or origin. The lab score lower down is useful for diagnosis, but it is a simulation.

Pick a handful of representative templates to work on: the home page, a typical service or product page, a blog post and any high-traffic landing pages. Fixing a template fixes every page built on it, which is far more efficient than chasing individual URLs.

Record your starting numbers for each template before making changes. Field data takes around four weeks to fully reflect improvements, so you need a baseline to know what worked.

Hosting and caching: the foundation

If the server takes a long time to send the first byte, nothing else you do will rescue LCP. On WordPress, that usually comes down to three things.

  • Hosting quality. Shared hosting crammed with other sites often struggles under load. Managed WordPress hosting or a well-configured VPS with current PHP is usually a clear improvement.
  • Page caching. Serving pre-built HTML instead of running PHP and database queries on every request is the single biggest server-side win. Many managed hosts include it. Otherwise a reputable caching plugin will do the job.
  • A CDN. Serving static files, and ideally cached pages, from locations close to your visitors cuts latency, especially for international audiences.

Object caching with Redis or Memcached helps sites with heavy database work, such as WooCommerce stores, membership sites and sites with complex queries, where full-page caching cannot always be used.

Fixing LCP

Once the server is responding quickly, LCP is mostly about the hero element.

  • Serve images in modern formats such as WebP or AVIF, at sizes that match how they are displayed. A 3000-pixel image squeezed into a 600-pixel slot is a common culprit.
  • Never lazy-load the LCP image. WordPress lazy-loads images by default and tries to skip the first one, but page builders and sliders sometimes defeat this. Check that the hero image loads eagerly and consider adding a fetch priority hint.
  • Avoid hero sliders where possible. They usually load several large images and a chunk of JavaScript before anything useful appears.
  • Cut render-blocking CSS and fonts. Self-host web fonts, load only the weights you use and use a sensible font-display setting.

Fixing INP

INP problems almost always come from too much JavaScript running on the main thread. When the browser is busy executing scripts, it cannot respond to a tap.

  • Audit third-party scripts: chat widgets, heatmaps, tag managers carrying old tags, social embeds and multiple analytics tools. Remove what nobody uses. Delay the rest until after interaction where that is acceptable.
  • Check what each plugin loads on the front end. Many plugins load their scripts on every page even when they are only used on one, such as a form plugin used only on the contact page.
  • Be cautious with heavy page builders and animation libraries on mobile. They can add a lot of script that runs on every interaction.
  • Watch for slow event handlers in custom code, such as menus or filters that rebuild large parts of the page on every click.

Plugins that “delay all JavaScript” can help, but test carefully. They can break forms, consent banners and checkout flows in ways that are not obvious until a customer complains.

Fixing CLS

Layout shift is usually the easiest of the three to fix once you find the cause.

  • Give every image, video and iframe width and height attributes, or reserve space with CSS aspect ratios.
  • Reserve space for ads, cookie banners and embeds that load late.
  • Avoid injecting banners or notices above existing content after the page has loaded.
  • Match fallback font metrics to your web font, so text does not reflow when the custom font arrives.

Themes, builders and plugins: the honest trade-offs

Theme and plugin choices set the ceiling for how fast a WordPress site can be.

Setup Speed potential Trade-off
Custom or lightweight block theme Highest Needs a developer for layout changes beyond the block editor
Lightweight theme with a page builder Good, with discipline Builder output can be heavy if not configured carefully
Multipurpose theme with bundled plugins Often poor Loads features you do not use on every page

Plugin count on its own is a poor measure. A site with forty well-built plugins can be faster than one with ten badly built ones. What matters is what each plugin does on the front end. Query Monitor and the browser’s network panel will show you quickly which ones are adding weight.

Keeping it fast

Speed work is not a one-off. New plugins, marketing tags and oversized uploads gradually wear down a fast site. A few habits help:

  • Check the Search Console report monthly.
  • Test new plugins and tracking scripts on staging before they go live.
  • Set clear image guidance for editors, or automate resizing and conversion on upload.
  • Keep WordPress core, PHP and plugins up to date, as newer versions often bring performance improvements.

If you are planning a rebuild, performance is far cheaper to design in than to retrofit. Our WordPress development and WooCommerce builds treat Core Web Vitals as part of the brief from day one.

Need help with a slow WordPress site?

If your Core Web Vitals report is showing red and you are not sure where to start, contact us and we will take a look.