Evidence-led WordPress performance guides.

Measure representative pages and wp-admin before making changes. Record response time, Core Web Vitals, cache status and server resource use so you can identify whether the bottleneck is the browser, WordPress, database or hosting layer.

Test the homepage, a typical content page and the pages tied to enquiries or sales. Include logged-in or uncached actions where they matter, because a fast cached homepage does not prove that search, account or checkout requests are healthy.

No. Page caching can reduce repeated server work, but it cannot repair slow uncached queries, external scripts or undersized hosting. Incorrect rules can also cache baskets, accounts or personalised pages that must remain dynamic.

Identify the layer serving the old content and follow the cache clearing guide. Check the browser, plugin, Elementor, host and CDN where used. Object-cache or PHP-cache resets need a specific reason and hosting guidance; clearing every cache indiscriminately is unnecessary.

Preserve originals, then follow the image optimisation guide to resize a copy, choose a suitable format and compare quality. Allow enough pixels for the intended display and high-density screens. Test one representative image before processing a library.

Removing unneeded records can reduce storage and backup size, but that result does not establish a faster page. Use the database size guide to identify the largest tables and their owners. For settings loaded on each request, investigate autoloaded options without deleting unfamiliar values.

A cached public page can bypass work that an administrator's request still needs. Plugin dashboards, external requests and database work can therefore affect the two differently. Follow the slow dashboard guide to compare screens and collect evidence before disabling features.

Only partly. They describe important parts of the user's loading and interaction experience, while server response is one contributor. Images, fonts, scripts, layout movement and main-thread work can remain slow even with a fast server.

First confirm that Heartbeat requests contribute to the observed load. The Heartbeat guide explains a targeted reduction and the editing features that need testing. Disabling it without that check can disrupt features while leaving the real slowdown unchanged.

Get help when the bottleneck is unclear, server load is unstable, checkout or logged-in actions are slow, or optimisation plugins conflict. A developer can profile the request and fix the cause instead of stacking more cache settings onto it.