If your WordPress site feels sluggish, Google has almost certainly noticed too. Since the Page Experience update rolled Core Web Vitals into ranking signals, speed stopped being a “nice to have” and became part of the SEO game itself. The good news: most WordPress speed problems come from a small, predictable set of causes, and fixing them doesn’t require a full rebuild — just a focused checklist.
Below is the same audit process I run for client sites before any WordPress build, redesign, or migration. Work through it in order and you’ll usually see a measurable jump in your Core Web Vitals scores within a day.
What Core Web Vitals Actually Measure
Before touching any settings, it helps to know exactly what you’re optimizing for. Google currently scores three metrics:
- LCP (Largest Contentful Paint) — how long it takes for the biggest visible element (usually a hero image or heading) to fully render. Google wants this under 2.5 seconds.
- INP (Interaction to Next Paint) — how quickly your site responds when someone clicks, taps, or types. This replaced First Input Delay in 2024 and should stay under 200 milliseconds.
- CLS (Cumulative Layout Shift) — how much your page visually jumps around while loading (images popping in, ads shifting content, fonts swapping). Aim for under 0.1.
You can check where your site currently stands two ways: Google Search Console’s Core Web Vitals report (real user data, updated over time) and PageSpeed Insights (instant lab test plus field data if your site has enough traffic). Check both — lab data shows what’s fixable in code, field data shows what real visitors on real devices actually experience.
1. Start With Hosting, Not Plugins
No amount of caching or minification fixes a server that’s slow to respond in the first place. If your Time to First Byte (TTFB) is already high before WordPress even starts rendering the page, hosting is your bottleneck — not your theme or plugins.
Look for hosting with modern PHP (8.1+), server-level caching (LiteSpeed’s built-in cache, for example, is faster than most caching plugins), and enough resources that you’re not sharing a server with hundreds of other sites competing for CPU. If your audience is concentrated in a specific country or region, check that your host’s data center — or a CDN sitting in front of it — actually serves content from somewhere near your visitors; a server on the wrong continent adds latency no amount of caching fully cancels out.
This is the fix people skip most often because it feels less “technical” than tweaking plugin settings — but it’s usually the highest-leverage change available, and it’s the one every other item on this list builds on top of.
2. Choose a Lightweight, Well-Coded Theme
Many popular WordPress themes ship with page builders, animation libraries, and icon sets loaded on every single page — whether you use them or not. That’s dead weight your visitors’ browsers have to download and parse before anything renders.
A lean, purpose-built theme (GeneratePress and similar frameworks are popular for exactly this reason) loads a fraction of the CSS and JavaScript of a bloated multipurpose theme, which directly improves both LCP and INP. If you’re not sure whether your current theme is the problem, disable it temporarily and switch to a default WordPress theme, then re-run PageSpeed Insights — the difference tells you how much weight your theme itself is adding.
Mobile Is Where Most of Your Score Comes From
Google evaluates Core Web Vitals primarily using mobile data, since that’s how most people actually browse. A site that feels instant on your office wifi and a 27-inch monitor can score poorly the moment it’s tested against a mid-range Android phone on a throttled 4G connection — which is exactly the baseline PageSpeed Insights and the Chrome User Experience Report use.
This is why a fix that only looks at desktop performance is incomplete. When you test, always check the mobile score specifically, and pay attention to whether your theme is serving desktop-sized images and full-weight JavaScript bundles to phones that don’t need them. Responsive images (via srcset) and conditionally loaded scripts make a bigger difference on mobile than almost anywhere else on this checklist.
3. Compress and Modernize Your Images
Images are the single most common cause of slow LCP scores. A 4MB PNG hero image will tank your Largest Contentful Paint every time, regardless of how good your hosting is.
- Convert images to WebP (often 60–70% smaller than JPEG or PNG at equivalent visual quality).
- Serve correctly sized images — don’t let a 3000px-wide image get scaled down by CSS on a mobile screen.
- Lazy-load images below the fold, but make sure your actual LCP image (usually the hero) is not lazy-loaded — that can slow it down further.
- Set explicit
widthandheightattributes on every image so the browser reserves the right space before the image loads — this alone fixes a huge share of CLS issues.
4. Audit Your Plugins Ruthlessly
Every active plugin adds some combination of database queries, CSS, and JavaScript to your site — and most WordPress sites accumulate plugins over the years that nobody remembers installing. Go through your plugin list and ask, honestly, whether each one earns its keep.
Pay particular attention to plugins that load scripts on every page regardless of whether they’re needed there (a contact-form plugin loading its JS on your homepage, for instance). Tools like Query Monitor can show you exactly which plugins are adding the most load time, so you’re not guessing.
5. Implement Real Caching
Without caching, WordPress rebuilds every page from scratch — querying the database, running PHP, assembling the HTML — on every single visit. A good caching setup serves a pre-built static version instead, which is dramatically faster.
At minimum, set up page caching (many hosts now offer this at the server level, which outperforms plugin-based caching). If your site has more traffic or dynamic content, object caching (Redis or Memcached) reduces database load further and helps keep INP low even under heavier traffic.
6. Eliminate Render-Blocking CSS and JavaScript
By default, browsers pause rendering a page while they download and process CSS and JavaScript files in the document head. If you’re loading a dozen stylesheets and scripts before the page can even start painting, that delay shows up directly in your LCP.
The fix is a combination of minifying files (removing whitespace and comments), combining files where it makes sense, and deferring or async-loading JavaScript that isn’t needed immediately. Most modern caching plugins include tools for this, but test carefully after enabling — aggressive minification/combination settings occasionally break site functionality, so change one setting at a time and check the front end after each one.
7. Fix Font Loading
Custom fonts are a sneaky cause of both slow LCP and layout shift. If a webfont loads late and swaps in after the browser already rendered text in a fallback font, that swap counts against your CLS score — and if the browser hides text until the font loads (the default in many setups), that delays LCP too.
Preload your primary font file, use font-display: swap so text isn’t invisible while fonts load, and consider limiting yourself to one or two font weights instead of loading six variations you’re not using consistently.
8. Rein In Third-Party Scripts
Analytics tools, chat widgets, ad pixels, and embedded videos are frequently the biggest hidden cost on a page — because they’re scripts you don’t control, loading from servers you don’t control, at speeds you don’t control. Each one you add is a small tax on every visitor’s experience.
Load what you genuinely need, load it as late as reasonably possible (after the main content), and periodically audit whether every tracking script and widget is still earning its place on the page.
9. Re-Test and Monitor Over Time
Core Web Vitals aren’t a one-time fix — they drift as you add plugins, images, and content over months. Re-run PageSpeed Insights after any significant site change, and check the Core Web Vitals report in Google Search Console every few weeks to catch regressions before they affect rankings.
It’s also worth remembering that lab data (PageSpeed Insights) and field data (Search Console, based on real visitors using the Chrome User Experience Report) can disagree — field data is what actually affects your search performance, since it reflects real devices and real connection speeds, including the slower ones.
When It’s Worth Bringing In Help
Most of this checklist is doable without a developer if you’re comfortable in your WordPress dashboard. But a few situations usually call for a proper audit: your site scores poorly across the board and you can’t pinpoint why, a theme or plugin change you’re not confident reversing safely is involved, or you’re planning a redesign and want performance built in from the start rather than fixed after launch.
That’s the kind of work I do for clients — auditing an existing WordPress site’s Core Web Vitals, fixing the underlying causes (not just installing a caching plugin and hoping), and building new sites with performance as a requirement from day one rather than an afterthought. You can see the kind of results this approach delivers on the portfolio page, check what a WordPress performance project typically involves on the WordPress development services page, or look at pricing for a sense of scope.
If you’d rather just send me your site and get a straight answer on what’s actually slowing it down, get in touch — a Core Web Vitals audit is usually the fastest way to find out whether you’re dealing with a five-minute fix or a deeper structural issue.