www.simplify-data.de
Slow WordPress sites cost visitors, enquiries and revenue. Google measures user experience with three metrics, the Core Web Vitals, and uses them as one of many signals. This article explains what the metrics mean, how to measure them correctly and which measures make a WordPress website noticeably faster.
The three Core Web Vitals in brief
Core Web Vitals are metrics that describe how fast, responsive and stable a page feels to visitors.
| Metric | What it measures | Good value |
|---|---|---|
| LCP (Largest Contentful Paint) | When the largest visible element has loaded, such as a hero image | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How quickly the page responds to clicks and input | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much content shifts while loading | 0.1 or less |
Each metric is assessed at the 75th percentile of page views, split by mobile and desktop. A page only counts as good if at least three quarters of visits meet the thresholds. In 2024 INP replaced the earlier FID (First Input Delay) metric; it is stricter because it considers all interactions during a visit.
Measuring correctly: lab and field data
Before optimising, you need reliable numbers. There are two kinds of data:
- Field data comes from real Chrome users and is collected in the Chrome User Experience Report (CrUX). This is what counts for Google's assessment. You find it in PageSpeed Insights and in the Core Web Vitals report in Google Search Console.
- Lab data comes from a simulated test, for example with Lighthouse. It is useful for debugging but does not always reflect reality.
Smaller websites with little traffic often have no field data. In that case, rely on lab data and deliberately test with a throttled mobile connection. Note that field data is collected over 28 days, so improvements show up with a delay.
Improving LCP: getting to the main content faster
On WordPress, LCP usually depends on three factors: server response time, image size and render-blocking resources.
Hosting and caching: if the server has to run PHP and query the database for every request, a lot of time passes before the browser receives anything. A page cache stores finished HTML pages and serves them directly. An object cache such as Redis additionally speeds up database queries, especially for WooCommerce shops and sites with many logged-in users. Plugins can only partly compensate for undersized hosting.
Images: the LCP element is often a large hero image. Serve it in modern formats such as WebP or AVIF and at an appropriate size. WordPress automatically creates several image sizes on upload, which the browser selects via responsive image markup. The hero image itself must not be lazy-loaded. Recent WordPress versions try to detect the LCP image automatically and prioritise it, but this does not always work with page builders or sliders.
Render-blocking resources: CSS and JavaScript loaded in the page head delay rendering. Check which plugins load their files on every page even though they are only needed on a few, such as form or slider plugins.
Improving INP: responding faster
A poor INP value occurs when the browser is busy with JavaScript and cannot respond to input immediately. On WordPress, the most common causes are:
- heavy page builders that load a lot of JavaScript
- third-party tracking and marketing scripts
- cookie banners, chat widgets and embedded content
- plugins running jQuery-based effects across the whole page
Work systematically: list all embedded scripts and ask whether each one is needed. Non-critical scripts can be deferred or loaded only after user interaction. A tag manager with many tags is another common bottleneck.
Improving CLS: keeping things in place
Layout shifts occur when elements claim space after the fact. Typical causes and fixes:
- Images and videos without dimensions: specify width and height so the browser reserves space in advance. WordPress usually sets these automatically for images from the media library.
- Web fonts: if a font loads late and has a different width than the fallback, text jumps. Host fonts locally, limit the number of weights and choose a well-matched fallback font.
- Late-loading banners and ads: reserve fixed space for cookie notices, promotional banners or ad slots instead of inserting them at the top.
Checklist for your WordPress website
- Check field data in PageSpeed Insights and Search Console and record the baseline.
- Identify the slowest page types, usually home, product or category pages.
- Assess hosting and server response time and set up a page cache.
- Compress hero images, convert them to WebP or AVIF and do not lazy-load them.
- Inventory plugins and remove unused ones rather than just deactivating them.
- Reduce third-party scripts or load them later.
- Host fonts locally and reduce weights.
- Check image dimensions and reserved space to prevent layout shifts.
- Test after every change so you can see the effect of individual measures.
- Monitor values regularly, as new plugins or content can make them worse again.
A common mistake is installing several optimisation plugins at once. Overlapping caching or file-combining features quickly cause display errors.
When a rebuild makes sense
Sometimes optimisation hits its limits, for example when a heavy theme or page builder is the root cause. A leaner theme or a move to the block editor can then make more sense than ever more workarounds. Base this decision on measurements, not gut feeling.
How Simplify Data can help
Simplify Data analyses WordPress performance using field and lab data and implements improvements in the theme, plugins and hosting. We work with businesses in Kiel, Schleswig-Holstein, Hamburg and remotely across Germany. Get your WordPress performance optimised