Improving WordPress performance usually involves several parts of the website stack, including caching, plugins, themes, images, database activity, PHP processing, and traffic patterns.

This guide helps you identify where performance is being lost, choose the appropriate optimisation path, test changes safely, and verify whether they improved the website.

1. Define the performance problem

Start by identifying what is slow and when it happens.

Record:

  • the affected URL or WordPress Admin action
  • whether the issue affects all visitors or only logged-in users
  • whether it occurs continuously or only during busy periods
  • the visitor location, when regional performance is relevant
  • the approximate date and time
  • any recent plugin, theme, PHP, content, or configuration changes

Distinguish between:

  • slow public pages
  • slow logged-in or personalised pages
  • slow WordPress Admin actions
  • slow database-heavy operations
  • slow media or asset delivery
  • intermittent performance during traffic peaks

Continue when: You can describe the performance issue precisely enough to reproduce or measure it.

2. Establish a baseline

Measure the current state before making changes.

Review website analytics to examine traffic, resource use, and response patterns.

Run a site audit to collect a repeatable performance snapshot.

Review access and error logs when the slowdown affects a particular URL, request, or time period.

Use the same page, location, device profile, and testing method when comparing results.

Continue when: You have recorded baseline measurements that can be compared with the results after optimisation.

3. Review page caching

Page caching can reduce the amount of work required from WordPress and the origin infrastructure.

Understand page cache to learn which requests can be served without running WordPress again.

Clear your website cache when cached content may be stale or after making changes that should appear immediately.

Identify cache behavior using HTTP headers to confirm whether a response was served from cache.

Purge additional paths when clearing cache when a custom application workflow requires related URLs to be cleared together.

Do not assume that every request should be cached. Logged-in sessions, personalised content, carts, checkouts, and some application requests may require different handling.

Continue when: You understand whether the affected pages are being cached and whether that behaviour is appropriate.

4. Review persistent object caching

Persistent object caching can reduce repeated database work by storing frequently reused query results.

Understand persistent object cache before changing its behavior.

Use object-cache information when:

  • WordPress repeatedly runs similar database queries
  • logged-in or dynamic requests are slow
  • WooCommerce, membership, LMS, or publishing workflows are database-heavy
  • WordPress Admin performance is inconsistent

Disable persistent object cache programmatically only when troubleshooting confirms that a specific compatibility issue requires it.

Continue when: You have confirmed whether object caching is helping the affected workflow or contributing to a specific compatibility issue.

5. Review plugins and themes

Plugins and themes can add PHP execution, database queries, external requests, JavaScript, CSS, and background tasks.

Review website plugins to identify:

  • recently installed or updated plugins
  • inactive plugins that are no longer needed
  • plugins with available updates
  • plugins with reported security or compatibility issues
  • overlapping plugins that perform similar functions

Review plugin performance impact to identify plugins that add significant processing or front-end work.

Test suspected plugins in staging by changing one component at a time.

Also review:

  • theme-generated scripts and styles
  • page-builder output
  • external fonts and tracking scripts
  • third-party widgets
  • repeated API calls
  • scheduled background processes

Remove components that are no longer required. Deactivating an unnecessary plugin does not remove its files or database data.

Continue when: You have identified and tested the components most likely to affect the slow workflow.

6. Optimise images and front-end assets

Large images, unused JavaScript, render-blocking CSS, and third-party resources can delay page rendering even when the server responds quickly.

Review image optimization to understand the available image-delivery improvements.

Configure image compression to reduce image file sizes.

Review WebP and AVIF delivery to use modern image formats where supported.

Review CSS and JavaScript optimization before enabling minification, concatenation, or other asset-processing features.

When testing front-end optimisation:

  • check the page visually
  • test menus, forms, sliders, and interactive elements
  • review the browser console for errors
  • test on mobile and desktop
  • compare loading behaviour before and after the change

Continue when: The page loads correctly and the transferred asset size or rendering behaviour has improved.

7. Review PHP configuration

The selected PHP version affects compatibility, security, and application performance.

Review supported PHP versions before changing the runtime.

Switch the PHP runtime to test a supported version for the selected environment.

Test the new version in staging before applying it to production.

After switching PHP:

  • open important public pages
  • log in to WordPress Admin
  • test forms and search
  • test purchases, memberships, or other dynamic workflows
  • review the error log
  • confirm that scheduled and background actions still run

Request a php.ini override only when an application has a documented requirement that cannot be met through the available Dashboard settings.

Continue when: The website operates correctly on the selected PHP version without new errors.

8. Review database activity

Database growth and inefficient queries can affect dynamic pages, WordPress Admin, scheduled actions, and ecommerce workflows.

Review:

  • expired transients
  • old revisions
  • unused plugin tables
  • autoloaded options
  • abandoned session data
  • large log or analytics tables
  • recurring queries introduced by plugins or themes

Export the website database before performing manual database work.

Use staging when testing database cleanup or application changes.

Continue when: Unnecessary database overhead has been reduced and the affected workflow has been tested.

9. Review scheduled and background activity

WordPress plugins and themes may use scheduled events for:

  • publishing
  • email delivery
  • synchronisation
  • imports and exports
  • backups
  • ecommerce actions
  • analytics
  • cleanup tasks

Review how WP-Cron runs on Pressidium to understand how scheduled WordPress events are triggered on the platform.

Look for plugins that create:

  • unusually frequent scheduled events
  • long-running background jobs
  • repeated failed tasks
  • large import or synchronisation workloads

Performance problems caused by scheduled work may appear only at certain times or during busy periods.

Continue when: You have confirmed whether background work overlaps with the reported slowdown.

10. Review traffic patterns and request activity

A website may become slower because of increased legitimate traffic, bots, repeated uncached requests, or unusual request patterns.

Review website analytics to identify changes in visitor activity and resource use.

Review the Access Log page to examine requests made during the affected period.

Review website firewall activity when repeated automated or unwanted traffic may be increasing origin work.

Look for:

  • repeated requests to expensive URLs
  • excessive requests from one source
  • traffic directed at login or XML-RPC endpoints
  • crawlers repeatedly requesting uncached pages
  • sudden regional or campaign-driven traffic increases
  • requests with unusual query strings

Apply blocking or caching changes only after confirming the pattern and considering the effect on legitimate visitors and external services.

Continue when: You understand whether traffic behaviour contributes to the performance issue.

11. Test changes in staging

Use staging for changes that may affect application behaviour.

Initialize a staging environment when one is not already available.

Pull a copy from production when staging needs current content and configuration.

Test the suspected optimisation in staging and reproduce the affected workflow.

Where possible:

  1. Record the staging baseline.
  2. Apply one change.
  3. Repeat the same test.
  4. Compare the result.
  5. Review logs and functionality.
  6. Keep or reverse the change.

A staging environment may not receive the same traffic or workload as production, so staging tests should be combined with production monitoring after deployment.

12. Apply the verified change

After validating the change:

Create an Instant backup before modifying production.

Deploy staging to production when the optimization was made through the staging workflow.

For a Dashboard setting that must be changed directly in production, confirm that you have:

  • tested the equivalent setting where possible
  • recorded the original value
  • created a backup
  • prepared a rollback path

Apply one significant production change at a time.

13. Verify the result

Repeat the original measurement using the same conditions.

Run another site audit and compare it with the baseline.

Review website analytics to check whether response times and resource use improved.

Identify cache behavior using HTTP headers to confirm the intended caching result.

Review access and error logs to confirm that the change did not introduce new errors.

Verify both:

  • measurable performance
  • correct website behaviour

A faster result is not successful if it breaks dynamic content, sessions, forms, purchases, or administrative workflows.

Choose the right performance action

Your situationRecommended action
Public pages are slow for most visitorsReview page caching, asset delivery, images, and front-end resources
Pages are slow only for distant visitorsReview global delivery, asset size, and regional testing results
Logged-in pages are slowReview application processing, plugins, database activity, and object caching
WordPress Admin is slowReview plugins, database queries, scheduled tasks, PHP errors, and background activity
The site slows down during traffic spikesReview cache coverage, access logs, traffic analytics, and repeated uncached requests
Performance declined after a plugin updateTest the plugin in staging, review logs, and compare performance with the plugin disabled
Performance declined after changing PHPReview compatibility, error logs, and the affected application workflow
Images load slowlyReview image size, compression, dimensions, and modern image formats
Pages are fast but interactive elements load slowlyReview JavaScript, CSS, fonts, external scripts, and third-party services
Only one page or endpoint is slowReview that URL’s cache status, access logs, plugin behaviour, and database activity
Performance is inconsistentCompare cached and uncached requests and review traffic or background tasks at the affected times
You do not know what is causing the problemStart with a site audit, analytics, access logs, error logs, and a clear reproduction case

Verification

After completing the relevant optimisation work, confirm that:

  • the original slow action or page performs better
  • the comparison uses the same test conditions
  • the intended pages are cached correctly
  • dynamic and logged-in workflows still behave correctly
  • important pages display correctly on mobile and desktop
  • forms, search, login, checkout, and other interactive features still work
  • no new PHP or WordPress errors appear
  • resource usage has not increased unexpectedly
  • the improvement remains visible during normal traffic
  • a rollback point is available

Monitor the website after applying changes to production. Some performance problems appear only under real traffic, scheduled work, or sustained load.

Common issues and solutions

Clearing the cache did not improve performance

Cache clearing removes existing cached responses but does not correct slow WordPress execution, database queries, large assets, or third-party requests.

Review site loading slowly to identify whether the delay comes from caching, origin processing, assets, or external services.

A page is not being cached

Resolve cache not working to check request cookies, logged-in sessions, exclusions, headers, query strings, and application behavior.

Images do not load after optimisation

Resolve images not loading to check transformed URLs, formats, plugin conflicts, and delivery settings.

The site became slower after a plugin or theme change

Resolve plugin compatibility problems or resolve theme display issues to isolate the affected component and restore the previous behavior.

WordPress Admin remains slow

Review application-level causes, including plugins, database activity, scheduled actions, external APIs, and PHP errors. Public page caching does not normally accelerate uncached WordPress Admin actions.

Performance declined without a recent website change

Review traffic analytics, access logs, scheduled tasks, external services, and origin availability. The cause may be related to workload rather than code or configuration.

Need help?

Contact Support when:

  • the website remains slow after you have identified and tested the likely causes
  • performance degrades suddenly without an identifiable change
  • production is unavailable or unstable
  • cache behaviour does not match the documented configuration
  • PHP or application errors continue after reverting recent changes
  • traffic patterns suggest abusive or automated activity
  • you need help interpreting logs, analytics, or audit results

Include:

  • the website name and domain
  • the affected environment
  • the affected URL or Dashboard action
  • the date and approximate time of the slowdown
  • whether the issue affects logged-in or logged-out users
  • the visitor or test location
  • steps to reproduce the issue
  • relevant audit results
  • access-log and error-log entries
  • recent plugin, theme, PHP, DNS, or configuration changes
  • screenshots or screen recordings when they help demonstrate the issue

Avoid sending only a general statement such as “the site is slow.” A specific URL, workflow, timestamp, and comparison point will make the issue easier to investigate.

Where to go next