[Home](https://hmbastion.com/) [Blog](https://hmbastion.com/blog/) Web hosting Web hosting 5 min read # A faster WordPress site starts with finding the slow layer A slow WordPress page can spend its time in several places: downloading images, waiting for PHP, querying the database or calling another service. Installing another cache plugin without identifying the delay can hide one problem and create a second. Start with a repeatable journey and a small set of measurements. HM Bastion Editorial Published 2026-10-26 ## In this guide - [Turn “the site is slow” into a reproducible observation](https://hmbastion.com/blog/wordpress-performance-cache-diagnosis/#define-a-repeatable-journey) - [Know what a cache actually reuses](https://hmbastion.com/blog/wordpress-performance-cache-diagnosis/#know-what-each-cache-stores) - [Trace uncached work before adding resources](https://hmbastion.com/blog/wordpress-performance-cache-diagnosis/#trace-work-before-adding-resources) - [Keep a change only after checking the whole journey](https://hmbastion.com/blog/wordpress-performance-cache-diagnosis/#verify-the-result-and-keep-it) [All hosting guides](https://hmbastion.com/blog/) ## The practical takeaway Measure the actual slow journey, distinguish cached and personalised responses, change one layer at a time, and confirm both speed and correctness before keeping an optimisation. ## Turn “the site is slow” into a reproducible observation Choose a page and describe the visitor state precisely. A first visit to an article, a returning shopper opening a cart and an administrator saving a post exercise different parts of WordPress. Record the URL, whether the person is signed in, the approximate time, the device and the access network. Repeat the same journey rather than comparing unrelated pages from memory. Keep private account details out of screenshots and shared diagnostic exports. Separate the wait for the first response from the work performed after it arrives. A browser can receive HTML quickly and still spend several seconds downloading oversized images or running third-party scripts. Conversely, a visually simple page can wait on slow server-side work. Note response duration, transferred bytes and failed requests together. An isolated score is less useful than knowing which request delays the part of the page that visitors need. | Observation | First layer to investigate | Useful comparison | | --- | --- | --- | | HTML arrives late | PHP, database or external calls | Same URL with the same login state | | HTML is quick, page remains heavy | Images, fonts and browser scripts | Transfer size and the browser request waterfall | | Only signed-in visitors are slow | Personalised application work | Anonymous and signed-in journeys separately | | A delay appears after an update | Changed component or configuration | The recorded version and a controlled rollback | ## Know what a cache actually reuses Page caching can reuse a generated response instead of rebuilding it for every request. That is useful for public content that looks the same to many visitors. It needs deliberate rules for login pages, carts, checkout, account screens and other personalised responses. A fast page that shows the wrong customer information is a failed optimisation. Test cache behaviour across separate browser sessions and confirm that private pages follow the application’s intended handling. Object caching reuses application data and is a different layer from caching an entire page. Browser caching governs what a visitor can reuse locally. A content-delivery cache can sit elsewhere along the request path. Draw the layers that actually exist in your installation, including their expiry and purge behaviour. Do not assume that a control panel, plugin or hosting range includes a particular cache service unless its available configuration confirms it. For a public article, compare the first request after a purge with later requests. A large difference can indicate that generation work is being reused; it does not prove which layer performed the reuse. Inspect the relevant cache diagnostics or response headers when available. For a shop, test a changed product price and an updated cart separately. Correct invalidation matters as much as a warm-cache timing result. ## Trace uncached work before adding resources Review the components involved in the slow journey. A theme can trigger repeated queries, a plugin can call a remote endpoint, and a scheduled task can compete with normal requests. Use diagnostics appropriate to your environment and remove temporary diagnostics after the investigation. Prefer a staging copy for component isolation. Changing several plugins on a busy production site makes the result harder to interpret and can disrupt content or orders. Database work deserves its own investigation when uncached requests remain slow. Record which queries are frequent or expensive and whether the application repeats the same lookup unnecessarily. An index change, a smaller query result or a corrected plugin behaviour may help more than extra CPU. If the database is waiting on locks, adding PHP workers can increase contention instead of increasing useful throughput. Interpret process counts alongside response duration and successful requests. Hosting resources still matter when measurements show a real constraint. Consider memory used by the full application, concurrent PHP work, database activity and storage growth. HM Bastion’s web-hosting cards describe website, storage and database limits; they are not a published number of guaranteed concurrent shoppers. If a project needs custom services or operating-system control, compare a VPS using its actual resources and the administration responsibility that comes with it. ## Keep a change only after checking the whole journey Write down the proposed change and the result you expect before applying it. For example, resizing oversized public images should reduce transferred bytes without changing article content. Excluding account pages from a page cache should preserve privacy even if those pages remain slower than public content. Retain a current recovery copy and know how to reverse configuration changes. Use the same measurement conditions after the change so the comparison remains meaningful. - Check a public page with both an empty and a warm cache. - Check login, logout, account pages, search and any shopping cart. - Confirm that content changes become visible within the intended time. - Compare errors and successful responses as well as page speed. - Record the setting, component version and rollback procedure. Keep a short performance record after the immediate improvement. Note normal page generation time, common heavy journeys and the amount of spare capacity seen during ordinary peaks. Revisit those observations after a theme change, a large import or a new campaign. The useful outcome is a site whose behaviour you understand and can maintain, rather than a collection of overlapping plugins whose apparent speed disappears when a visitor signs in. Product examples use the published HM Bastion catalogue. Availability, prices and selectable options are shown when you configure an order. ## Choose your next foundation. [Compare website hosting](https://hmbastion.com/hosting/?category=web) [Read the cPanel and Plesk guide](https://hmbastion.com/blog/wordpress-cpanel-or-plesk/) [Discuss a WordPress requirement](https://hmbastion.com/support/) ## Sources and further reading - [WordPress documentation: performance optimisation](https://developer.wordpress.org/advanced-administration/performance/optimization/) - [WordPress documentation: caching layers](https://developer.wordpress.org/advanced-administration/performance/cache/) ## Keep exploring [ Infrastructure 5 min read ## Size a SQL database around its working set and expensive queries Use query plans, concurrency, memory behaviour and storage growth to distinguish a database resource shortage from inefficient application work. ](https://hmbastion.com/blog/sql-database-sizing-query-bottlenecks/) [ Security 5 min read ## Keep HTTPS working through the whole certificate lifecycle Plan domain validation, certificate renewal, deployment and external checks so HTTPS remains correct after the first successful installation. ](https://hmbastion.com/blog/https-tls-certificate-lifecycle/)