WordPress performance: what actually matters (and what’s just noise)

There’s an entire industry of content around WordPress optimisation. “10 plugins to speed up your site”, “5 secret tricks to make your site fly”, “the ultimate cache plugin”. Most of it is noise.

After optimising dozens of WordPress sites, what I’ve learned is that most performance problems come from 3 sources. And that most of the “tricks” you read online either don’t make a measurable difference, or are actively counterproductive.

The Core Web Vitals that matter in 2026

Google changed the Core Web Vitals in 2024. Today, the three that count are:

• LCP (Largest Contentful Paint): time until the largest visible element appears. Target: under 2.5 seconds
• INP (Interaction to Next Paint): response time to user interactions. Target: under 200ms
• CLS (Cumulative Layout Shift): visual stability during loading. Target: under 0.1

INP replaced FID in March 2024 and is significantly more demanding. Many sites that had green FID now have red INP.

Important: Google measures Core Web Vitals on real user data (CrUX), not synthetic tests. Your PageSpeed Insights might show 95 in tests, but if real users have slow devices and 4G connections, their experience is what counts.

The 3 problems that solve most cases

1. Inadequate hosting

This is, by far, the most underestimated problem. A WordPress site on a cheap shared €3/month host will never have good performance, no matter what you do in code.

For a professional site, the decent minimum is managed hosting with PHP 8.2+, MySQL 8 or MariaDB 10.6+, Redis or Memcached for object cache, HTTP/3, and native server-level caching support. This typically costs €15-40 per month and makes a drastic difference.

For more demanding projects, VPS or dedicated server with LiteSpeed, Nginx with FastCGI cache, or specialised stacks (Cloudways, Kinsta, WP Engine).

2. Unoptimised images

In almost every site I audit, images account for 60-80% of the total page weight. And typically, many images are served in the wrong format, wrong size, or without proper lazy loading.

In 2026, the minimum standard is:

• WebP or AVIF format (never JPEG or PNG for web photography)
• Responsive images with correct srcset and sizes
• Native lazy loading with loading="lazy" (except LCP, which should be eager)
• Aggressive compression: 75-85 quality is visually indistinguishable in photography
• Correct dimensions in code to avoid CLS

3. Too many plugins

Rule of thumb: every active plugin adds between 50ms and 300ms to load time, depending on what it does and how well it’s written. A site with 40+ plugins is physically incapable of having good performance.

My personal rule on custom projects: maximum 15 plugins, each with a clear function and justification. Simple features (sliders, accordions, basic forms, social share) should be implemented in the theme, not via plugins.

Why cache plugins aren’t enough

Many people install WP Rocket or W3 Total Cache and think their performance problem is solved. It isn’t.

Cache plugins solve a specific problem: preventing WordPress from dynamically generating the page on every request. This is useful, but it doesn’t help with LCP from badly optimised images, INP from heavy JavaScript, or CLS from missing media dimensions.

Cache is part of the solution. It’s not the solution.

Performance and accessibility: two sides of the same coin

A point rarely discussed: performance optimisation and accessibility go hand in hand. A fast site with clean semantic structure, proper lazy loading, and non-blocking JavaScript is also a more accessible site for users with assistive technologies.

For projects requiring WCAG 2.1 AA compliance (increasingly mandatory in public and regulated sectors), performance optimisation must be thought of alongside accessibility from the start. It’s possible to score high on both, but it requires discipline from the theme’s initial architecture.

The checklist I use before delivering any project

• Hosting with PHP 8.2+, MySQL 8+, HTTP/3
• Active object cache (Redis or Memcached)
• Server-level page cache (LiteSpeed, Nginx FastCGI) or dedicated plugin
• Images in WebP/AVIF, with srcset and explicit dimensions
• Fonts with font-display: swap and preload of the main font
• Critical CSS inline, rest with media="print" onload
• Non-critical JavaScript with defer or conditional loading
• No redundant or duplicate plugins
• HTTPS with active HSTS
• Brotli or Gzip compression
• CDN for static assets (Cloudflare minimum)
• Green Core Web Vitals on PageSpeed Insights and CrUX
• Accessibility score matching the project requirements

Tools I use to measure

• PageSpeed Insights: lab data + real user data (CrUX)
• WebPageTest: detailed per-request analysis, visual filmstrip
• Chrome DevTools Lighthouse: local audit
• Google Search Console: Core Web Vitals on real users, per URL
• GTmetrix: historical dashboard and comparison
• Query Monitor (plugin): identify slow queries, heavy hooks

Conclusion: performance isn’t magic, it’s discipline

Fast sites aren’t built with magic plugins or secret tricks. They’re built with attention to detail in every decision: choice of hosting, theme architecture, discipline with plugin usage, media optimisation, and continuous testing.

If your site is slow and you want a technical diagnosis, I can run a performance audit. You’ll get a report with identified problems, priorities, and estimated impact for each optimisation.