A WordPress site that takes longer than 2.5 seconds to load measurably loses visitors. Google has rated page speed as a ranking factor for years — and since the Core Web Vitals it has even been formalised into LCP, INP and CLS. In my training sessions I regularly see sites languishing at 25 out of 100 points in PageSpeed Insights even though the content is first class. In this pillar article I show you the ten levers with which I reliably bring client sites to scores above 90 — from choosing a host to database maintenance.
At a glance — the 10 levers
| # | Lever | Effort | Effect | When is it essential? |
|---|---|---|---|---|
| 1 | Change host | High | Very high | With TTFB > 600 ms |
| 2 | Set up a caching plugin | Low | High | Always |
| 3 | Optimise images & use WebP | Medium | High | Always |
| 4 | Lazy loading for images & iframes | Low | Medium | Always |
| 5 | Host fonts locally | Medium | Medium | With Google Fonts |
| 6 | Minify / combine CSS & JS | Low | Medium | Always |
| 7 | Clean up the database | Medium | Medium | Every 3–6 months |
| 8 | Reduce plugins | High | High | With > 30 active plugins |
| 9 | Use a CDN | Medium | Medium–high | International or high load |
| 10 | Check PHP version & HTTP/3 | Low | Medium | With PHP < 8.2 |
What are Core Web Vitals, and why do I count them first?
Before you optimise anything, you have to know what you are optimising for. Google has measured three central metrics since 2021:
- LCP (Largest Contentful Paint) — how quickly is the largest visible element loaded? Target: ≤ 2.5 seconds.
- INP (Interaction to Next Paint) — how quickly does the page respond to clicks/taps? Target: ≤ 200 ms. (INP replaced the older FID metric in 2024.)
- CLS (Cumulative Layout Shift) — how much do elements jump around while loading? Target: ≤ 0.1.
You can measure this in PageSpeed Insights (pagespeed.web.dev) or more directly in Chrome DevTools → Lighthouse. Important: PageSpeed Insights shows you two data levels. The lab data are simulations — good for a tendency. The field data come from real Chrome usage of your site over 28 days — that is what Google uses for ranking. On a new site there are no field data yet; lab values are then your only orientation.
Lever 1: The host — the invisible brake
It sounds banal, but the most important lever is usually not WordPress itself but the server WordPress runs on. If the time to first byte (TTFB) is over 600 ms, no caching plugin in the world will help — delivery of the HTML already starts too late.
Host categories roughly:
- Mass shared hosts (Strato, 1&1, GoDaddy standard plans, for example): cheap but often slow. TTFB of 800 ms–1.5 s is not unusual.
- WordPress-specialised hosts (Kinsta, WP Engine, Raidboxes, World4You "Optimized WordPress", for example): more expensive (€15–50/month), but TTFB under 300 ms.
- VPS / cloud (Hetzner, DigitalOcean): cheap per unit of performance, but you manage the server yourself — only sensible with prior knowledge.
Changing host is work, but easy to plan. More on this in the existing article Migrating WordPress to a new host.
Lever 2: Caching — the fastest speed gain
Caching stores the fully rendered HTML version of your page so that WordPress does not have to run through the database and PHP again on the next request. Effect: TTFB drops below 200 ms, often to 50 ms.
The most important plugins:
- WP Rocket (paid, around €60/year for one site): my standard. Very good default settings, combining caching + minification + lazy loading + database cleanup.
- LiteSpeed Cache (free): excellent, but only sensible if your host uses LiteSpeed servers (World4You, Easyname, for example). Otherwise you get half the effect.
- W3 Total Cache (free): powerful, but a configuration nightmare. More for professionals.
- WP Super Cache (free, Automattic): solid, simple, no frills.
Configuration rule of thumb: after activating the plugin, first let the defaults run, measure PageSpeed, then change one option and measure again. Avoid the temptation to tick all the aggressive options straight away — that almost always leads to broken pages (vanished sliders, jumping fonts).
Lever 3: Images — the biggest cause of loading time
In every second audit, images are the size factor. Example: a stock photo PNG at 4,000 × 2,700 px quickly weighs 4–6 MB. On a page with five images that is 25 MB for images alone. Mobile connections give up at that point.
Three interventions, in order:
- Switch the format to WebP. At the same quality around 30 % smaller than JPEG, around 70 % smaller than PNG. Plugins: Imagify (paid), ShortPixel (paid), Smush (free tier with a limit). A deeper comparison in my article ShortPixel vs. Optimole.
- Match the resolution to the display size. An image displayed at only 800 px wide in the theme should not be uploaded at 3,000 px. WordPress does generate various sizes automatically, but the original still eats storage and backup volume.
- Enable lazy loading. Built in natively since WordPress 5.5 for images, and since 5.7 for iframes too. Active as long as your theme does not override
loading="lazy".
Do you want to understand the optimisation of your WordPress site from front to back — not just react, but get systematically better? In my online course I show you each of the 10 levers step by step on a real site. → To the online course
Lever 4: Lazy loading for iframes & videos
The loading="lazy" attribute also works for embedded YouTube videos and Google Maps. These are often the biggest render blockers. If you have a lot of video embeds, the plugin WP YouTube Lyte is worthwhile — it replaces YouTube players with a preview image and only loads the player on click. Effect: 1 to 2 seconds off the LCP.
Lever 5: Host fonts locally (no Google Fonts CDN)
Google Fonts via the Google CDN was standard for years. Since GDPR rulings that has become legally delicate in German-speaking countries (the issue being IP transfer to Google without consent). An extra DNS lookup plus an extra request is also slower than a local .woff2 file.
Solution: download the fonts and embed them in the theme. Plugin: OMGF (Optimize My Google Fonts) — automatic download and local hosting in two clicks. More on the legal side in the existing articles GDPR compliance checklist Austria and GDPR compliance checklist Germany.
Lever 6: Minify CSS & JS
Minifying = removing whitespace and comments from CSS/JS files. The effect individually is small, but cumulatively noticeable (15–25 % less file size for CSS/JS).
Combining (merging several files into one) has been less relevant since HTTP/2 — modern servers deliver many small files almost as fast as one large one. On HTTP/1.1 servers it still helps.
Careful with aggressive minifying and combining: broken sliders and jumping layouts are the most common consequence. Always enable it step by step and check the front end.
Lever 7: Clean up the database
Over the years WordPress accumulates things in the database: post revisions, auto-drafts, transients, deleted comments, spam comments, expired sessions. On a five-year-old site there can easily be 200,000 unnecessary rows — and the database becomes sluggish.
Clean up with:
- WP Rocket (built in, simple)
- WP-Optimize (free, more powerful)
- Directly via phpMyAdmin (only with a backup beforehand and database knowledge)
Mandatory before every cleanup: a backup. In my existing article WordPress backup strategy 2026 this rule is the first paragraph too.
Lever 8: Reduce plugins
Every active plugin loads code, and some load CSS and JS on every page (including where they are not needed). The most important question: which plugins are still active that I no longer use at all?
A practical audit: go through the plugin list with three columns — "need daily", "sometimes", "can't remember". Deactivate the last group, observe for a week, then delete. What you genuinely need I describe in WordPress plugins 2026: which ones do you really need?
Lever 9: Use a CDN
A content delivery network mirrors your static files (images, CSS, JS) on servers worldwide. Visitors are served by the geographically nearest server. Noticeable above all for international audiences.
- Cloudflare (the free tier is sufficient for many): my standard for German-speaking sites with occasional visitors from abroad.
- BunnyCDN: cheap ($1/month minimum cost), a good EU footprint.
- KeyCDN: similar, somewhat more expensive.
Cloudflare additionally brings security advantages (DDoS protection, bot detection), which I set out in my existing article WordPress security measures.
Lever 10: PHP version and HTTP/3
PHP version: WordPress officially runs from PHP 7.4, but only performs well from PHP 8.0. Current state in 2026: PHP 8.3. Raising 7.4 to 8.3 typically brings 30–50 % faster back-end processing. The change usually takes two clicks at your host — but check beforehand that all plugins are compatible (tools: the PHP Compatibility Checker plugin).
HTTP/3 (also QUIC) is the next step after HTTP/2. Faster TLS handshakes, better performance on mobile networks. Activation happens server-side — either directly at your host or via Cloudflare.
A measurement workflow for your optimisation sessions
This is how I proceed in an audit session:
- Measure a baseline: PageSpeed Insights (mobile + desktop), GTmetrix, WebPageTest. Screenshots of the values.
- Select lever 1 (the highest effect at the lowest effort for your situation).
- Implement, then measure again immediately, one round of values.
- Only then move to the next lever.
Never everything at once. Otherwise you will not know afterwards which change brought the boost — or which one destroyed the layout.
Frequently asked questions
How long does a complete performance optimisation take?
For an average WordPress site with 30–50 plugins I budget 6–10 hours, spread over two to three sessions. A first noticeable improvement (PageSpeed score +20 points) is usually achievable in 90 minutes.
What score is realistic?
Mobile 80+ and desktop 90+ in PageSpeed Insights are achievable for any normal WordPress site. 100/100 is possible but costs disproportionate effort — not always economical.
Does a new host really make that much difference?
Yes, if the old host is the bottleneck. A TTFB measurement with WebPageTest settles that in 30 seconds.
Should I get rid of Elementor for performance reasons?
Not necessarily. Elementor can be tuned well — see Elementor performance optimisation. But yes, a well-made block editor plus Astra/Kadence will tend to be faster.
Is a static site generator worth it instead of WordPress?
For pure blogs and magazines: yes, technically considerably faster. But you lose the ease of editing. For most of my clients that is not a good trade.
Conclusion
Page speed is not a one-off project but a recurring discipline. The ten levers above are the inventory — the art lies in the order and in measuring cleanly. If you want to understand WordPress performance completely, my online course is the direct route: there I go through lever after lever with you and show you how to bring your site permanently into the green — not just for a snapshot audit.
Image source, featured & inline: illustrations created specifically in the pletzenauer design (no stock photos).
Tags