How to Speed Up a WordPress Website

Speed up WordPress by measuring a representative page, locating the slow layer and making one controlled change at a time. Installing a cache plugin before diagnosis can hide the cause or break dynamic features.

1. Record a baseline

• Test representative public pages and the admin area
• Record mobile and desktop results
• Note server response, largest content element, layout shifts and interaction delays
• Repeat tests to identify unstable results
• Capture functional checks for forms, search and checkout

2. Check the server response

If the first response is consistently slow, investigate hosting resources, PHP workers, database activity, object caching and external calls. Front-end image compression will not solve a server that waits several seconds before returning HTML.

3. Optimise the largest media

Resize images to their displayed use, generate responsive variants, choose an appropriate format and avoid lazy-loading the likely above-the-fold hero image. Set width and height to reduce layout movement.

4. Audit plugins and theme output

1. List scripts and styles loaded on the slow page.
2. Identify the theme or plugin that adds each large or blocking asset.
3. Disable the suspected component on staging.
4. Retest the same page and user journey.
5. Replace or reconfigure only when evidence supports it.

5. Configure caching for the site type

Static brochure pages can usually be cached aggressively. Logged-in pages, baskets, checkout, personalised content and form confirmations need careful exclusions. Use one authoritative caching layer where possible.

6. Reduce third-party work

• Remove unused tracking and marketing tags
• Load maps or video embeds on interaction where suitable
• Review chat and review widgets
• Self-host fonts only when licensing and maintenance make sense
• Do not load a site-wide script for a feature used on one page

7. Investigate the database and scheduled actions

Large autoloaded options, expired transients, repeated background jobs and inefficient queries can affect both public and administrative performance. Use profiling and a backup before database cleanup.

8. Test the result safely

Post-change checks

Area	Test
Cache	Logged-out and logged-in users receive the correct content
Forms	Validation, confirmation and email delivery still work
Commerce	Basket, checkout, payment callbacks and account pages work
Consent	Scripts respect the selected consent state
Mobile	Menu, images and interaction work on a real device
Operations	Editors can publish and scheduled jobs continue running

When hosting is the constraint

Consider a hosting change only after collecting evidence. Ask the provider about limits and profiling, then compare with a representative staging copy on the proposed environment.

Practical next step

Run a baseline on three pages, identify the single largest measured bottleneck and change only that layer. Keep the before-and-after evidence with the change log.

Prioritise changes by evidence and risk

A large uncompressed hero image is often a low-risk, high-value fix. Replacing hosting, combining scripts or changing database configuration has broader consequences. Rank opportunities by measured benefit, implementation effort and rollback complexity.

Watch for false improvements

• A test tool receives a cached page while first-time visitors do not.
• Scripts are delayed until the first click, making that click feel slow.
• Consent or analytics stops working and reduces page weight.
• Mobile images look blurred because the selected variant is too small.
• Checkout is excluded from testing even though it is the key journey.

Keep functional evidence with performance results so a faster score does not hide a broken system.

Sources and date checked

This guide was checked on 21 July 2026. WordPress, hosting environments and extensions change, so recheck the relevant official documentation before making a major change.

• Web performance guidance
• WordPress performance handbook
• Responsive images guidance