WordPress Speed Optimization: A Practical Guide to Passing Core Web Vitals

A slow WordPress site costs you twice. Visitors leave before the page finishes loading, and Google uses page experience signals — including Core Web Vitals — when it ranks pages. The good news: most WordPress sites fail for the same handful of reasons, and they can be fixed in a predictable order.

This is the process I follow when a client’s site fails PageSpeed Insights. It is written for site owners, not developers, so you can follow it — or at least know what to ask for.

What Core Web Vitals actually measure

Core Web Vitals are three measurements of how a page feels to a real visitor:

Google judges these on field data — measurements from real Chrome users — at the 75th percentile. That means 3 out of 4 visits must hit the “good” threshold. The lab score in PageSpeed Insights is useful for debugging, but the field data at the top of the report is what counts.

Step 1: Measure before you touch anything

Run your homepage and your most important landing page through PageSpeed Insights. Note three things: the field data for each metric, which element is flagged as the LCP element, and the top items under “Diagnostics”. Check Google Search Console’s Core Web Vitals report too — it groups failing URLs so you can see whether the problem is one template or the whole site.

Test on mobile first. Most sites pass on desktop and fail on mobile, and Google primarily uses the mobile version of your site for ranking.

Step 2: Fix hosting and caching

No plugin can rescue a slow server. If your server takes more than about 600ms to send the first byte of HTML, start here.

• Run a current PHP version. Older PHP versions are noticeably slower and no longer receive security fixes. Your host’s control panel usually lets you switch in one click — test on a staging copy first.
• Turn on page caching. Caching saves a finished copy of each page so WordPress does not rebuild it for every visitor. On LiteSpeed servers use LiteSpeed Cache; elsewhere, WP Rocket is the simplest paid option.
• Use a CDN. Cloudflare’s free plan serves static files from a location near each visitor, which helps a lot when your audience is in a different country from your server.

Step 3: Get images right

Images are the most common cause of a slow LCP. Fix them in this order:

1. Resize before uploading. A 4000px photo shown at 800px wide wastes most of its bytes.
2. Serve modern formats. WebP or AVIF files are much smaller than JPEG at the same quality. Most caching and image plugins can convert automatically.
3. Lazy-load images below the fold — but never the LCP image. WordPress lazy-loads images by default, and some themes wrongly apply it to the hero image too. The main image at the top should load immediately, ideally with fetchpriority="high".
4. Always set width and height. This lets the browser reserve space, which prevents layout shift.

Step 4: Tame fonts and scripts

Once the server and images are fast, the remaining delay is usually code that blocks the page from rendering or responding.

• Fonts: use two families at most, host them locally, and use font-display: swap so text shows immediately in a fallback font.
• Third-party scripts: chat widgets, heatmaps and social embeds are frequent INP killers. Delay them until the visitor interacts with the page, or remove the ones nobody uses.
• Plugins: deactivate anything you cannot name a reason for. Page builders, sliders and “all-in-one” plugins often load their files on every page, even where they are not used.

Step 5: Stop the layout from jumping

CLS problems are usually caused by something appearing late and pushing content down. Common culprits: cookie banners inserted at the top of the page, ads or embeds without reserved space, and web fonts that are much wider than the fallback font. Reserve space for anything that loads late, and place banners as overlays rather than pushing content.

A quick WordPress speed checklist

• Current PHP version and server response under about 600ms
• Page caching on, CDN in front of the site
• Images resized, converted to WebP/AVIF, with width and height set
• Hero image not lazy-loaded
• Two font families or fewer, hosted locally
• Non-essential third-party scripts delayed or removed
• Unused plugins deleted, not just deactivated

Field data takes up to 28 days to reflect changes, so don’t panic if Search Console does not turn green the next morning. Re-test in PageSpeed Insights straight away to confirm the lab numbers improved, then watch the field data catch up.