How to speed up a WordPress site: a practical guide - Zephyra Studio

A WordPress site that takes four seconds to load on a phone loses visitors before they ever see the offer. The fix rarely starts with new hosting. Most of the gain comes from three moves: full page caching, image optimisation, and cutting the number of plugins that load on every page. On decent hosting those moves bring load time under two seconds. On poor hosting no amount of tuning helps, because the PHP version and the database set a ceiling you cannot cross. This guide goes from the biggest gain to the smallest, with a measurement before and after each change.

Measure first, change second

Without a measurement before the change you cannot tell what helped and what merely happened to coincide. Open PageSpeed Insights and test the same page twice: once for mobile, once for desktop.

The report contains two different kinds of numbers. Field data comes from real Chrome visitors and is what Google uses for Core Web Vitals. Lab data from Lighthouse is a simulation on a fixed connection and is there for diagnosis. The Lighthouse score is not a ranking factor, so do not chase a hundred points at the cost of functionality.

Test several pages, not just the home page. On WordPress the home page is often the fastest, because it is cached or simply the lightest, while a product page with ten images and three plugins is far slower. If server response time is above 600 milliseconds, the problem is not the images but everything underneath them.

Three moves that deliver most of the gain

These are the changes that move the numbers most in practice, and they are listed in that order. The first two take a day. The third takes longer because it involves decisions.

• Full page caching: host-level cache where available, otherwise a caching plugin. Exclude the cart, checkout and admin screens
• Images: scale them to the size actually displayed, compress them, and serve WebP or AVIF
• Lazy loading for images below the first screen, but not for the main image, since that one defines the largest element on the page
• Plugins: delete inactive ones, then check which active ones load their files on every page
• Page builders: each one loads globally, including on pages that do not use it

Cache: which layer you actually need

There are four layers of caching and each solves a different problem. Page caching stores a finished page and serves it without starting PHP or the database, and that is the layer delivering most of the gain. It does not apply to signed-in users and must not be used on the cart or checkout.

Object caching stores the parts of the database that are read constantly, and it matters when a site makes many queries. It helps on dynamic pages where page caching cannot be used, such as the cart and filtered product lists. If the host offers Redis or Memcached, that is what gets switched on.

Browser caching is the third layer and is controlled by headers the server sends, so the browser keeps files instead of downloading them again. Trouble appears when something changes and the browser still uses the old version, which is why files are versioned or renamed with each edit.

A content delivery network is the fourth layer. It keeps static files on servers closer to visitors and shortens the download time for images and scripts. It does not fix a slow server, because dynamic requests still have to be handled by your hosting.

The most important part of caching is clearing it. After every content change the stored page has to be refreshed, otherwise visitors see the old state. If stale prices appear in the cart or products go missing, the first suspicion is two caching layers cancelling each other out, so one gets switched off and tested.

The practical rule is to use the smallest number of layers that solves the problem. One well-configured page cache plus object caching on the host covers most sites, while adding more optimisation plugins rarely pays off and often creates more trouble than it removes.

PHP, the database and the server: the ceiling you cannot skip

The same topic from the other side. WordPress runs noticeably faster on PHP 8.x than on older versions, and plenty of hosts still keep sites on a version that has been out of support for years. Check the health section of the admin area to see which version you are on.

On sites with more content, revisions, transients and autoloaded options pile up over time and get read on every request. Object caching, where the host offers it, removes part of that cost. Where it is not offered, changing host is often better value than stacking more optimisation plugins.

Online stores add one more layer. WooCommerce can load cart scripts on every page, even where the cart is nowhere on screen. It can be fixed, but it means editing the theme and testing after each change.

What does not help, and how to confirm the fix worked

Combining every JavaScript file into one often breaks the layout or the functionality, while the gain is small. The same goes for plugins that claim to remove query strings or disable emojis: the measures sound specific, and their effect on load time is negligible.

Two caching layers at once, for example a host cache and a plugin cache, frequently cause stale prices or a stuck cart. When that appears, switch one layer off and test again.

After the change, measure the same page on the same device. The lab result is visible immediately, while field data lags, because it is calculated over a 28-day window. Do not worry if PageSpeed Insights still shows the old picture in the first weeks, but do check on a phone that nothing broke visually.

Source

Key takeaways

• Measuring before the change is mandatory, because otherwise you cannot tell what actually helped.
• Page caching, image optimisation and fewer plugins account for most of the gain.
• The PHP version and the quality of hosting set a ceiling no plugin can lift.
• Combining scripts and adding more optimisation measures often cause more problems than they solve.
• Field data in PageSpeed Insights lags by up to 28 days, so results are not judged on day one.

Conclusion

Speed is not a single change but a series of small decisions that get re-checked over time. If you have no time to measure and test after every change, our website maintenance service covers exactly that work, including a speed check after each plugin update. If the site also looks dated, a redesign is the right moment to solve speed in the foundation instead of patching it with plugins afterwards.