How to Speed Up WordPress: A Practical 5-Step Guide

To speed up a WordPress website, first identify what is slow. A delayed server response, a large hero image and a sluggish checkout need different fixes. Use these five steps to establish a baseline, update safely, investigate expensive work, improve delivery and check the result.

The goal is a website that loads and responds well for its visitors. Treat a speed-test score as a diagnostic clue, alongside working forms, reliable purchases and usable pages.

• Measure performance before changing anything
• Update WordPress and choose supported PHP
• Find costly plugins, queries and background jobs
• Improve caching, images and front-end assets
• Retest the website and monitor real users

1. Measure performance before changing anything

Choose representative pages: your homepage, a content page and an important service or product page. Record the URL, device profile, test location where available, date and whether you are signed in. Run several tests under the same conditions and keep a typical result rather than selecting the fastest run.

PageSpeed Insights provides lab diagnostics and, when enough data exists, field data from real Chrome users. Lab tests help investigate a change immediately. Field data describes the previous 28 days; check whether the report covers that URL or the whole origin. Missing field data means insufficient samples, not a passing result. See Google’s explanation of the reports.

The three Core Web Vitals measure loading, responsiveness and visual stability. Their good thresholds are assessed at the 75th percentile of real visits, considering mobile and desktop separately:

Metric	What it measures	Good threshold
Largest Contentful Paint (LCP)	When the main visible content appears	2.5 seconds or less
Interaction to Next Paint (INP)	How promptly interactions get a visual response	200 milliseconds or less
Cumulative Layout Shift (CLS)	Unexpected movement of page content	0.1 or less

Use the report to decide where to investigate first:

• Long wait before the document arrives: inspect redirects, page-cache behavior, application work and hosting response. Time to First Byte is useful here, but it is not itself a Core Web Vital.
• Main content appears late: identify the LCP element and look for a large image, delayed font or render-blocking resource.
• Clicks or typing feel slow: inspect long-running JavaScript and third-party scripts during the affected interaction.
• The layout jumps: check image dimensions, font changes and banners or embeds inserted after the page starts rendering.
• Only the admin, account or checkout is slow: profile that workflow separately. A fast cached homepage does not demonstrate that these dynamic requests are fast.

2. Update WordPress and choose supported PHP

Keep WordPress, themes and plugins maintained, but plan updates as a controlled change. Take a current backup, confirm how to restore it and use staging for changes that could affect the site’s main functions. Review release notes and compatibility requirements, then check the site after updating.

Updates may fix performance problems or introduce new behavior. Measure the result instead of assuming every update will improve speed. Resolve security-critical issues promptly while keeping a recovery path.

Use Site Health as an inventory and warning system

Open Tools → Site Health. The Status and Info screens help identify configuration warnings and record the current WordPress environment. Review recommendations with your host when they involve server settings. Site Health is not a page-speed benchmark and does not identify every bottleneck.

Choose a supported PHP branch and test compatibility

Use a PHP branch that is still supported and compatible with your WordPress version, theme, plugins and custom code. Prefer an actively supported branch when the full stack is ready. The WordPress requirements page currently recommends PHP 8.3 or greater; that recommendation is not a guarantee that every third-party extension supports every newer release.

As of September 27, 2026, PHP 8.2 receives security fixes only, ending December 31, 2026. PHP 8.3 is also in security-only support, while 8.4 and 8.5 are actively supported. Consult the live PHP support table when planning an upgrade rather than treating one version as permanently ideal.

1. Check the compatibility information for WordPress, your theme, key plugins and custom code.
2. Test the proposed PHP version on staging, including forms, login, checkout and scheduled jobs relevant to the site.
3. Review PHP logs for errors and deprecation notices. A deprecation notice flags code that needs attention; it does not by itself prove a speed problem.
4. Confirm the required extensions and effective settings with your host, deploy the tested change and compare the same performance baseline.

Review PHP settings without stripping .htaccess

The correct place to configure PHP depends on how your host runs it. PHP directives in .htaccess can be valid when PHP runs as an Apache module. .user.ini support applies to CGI/FastCGI configurations. Managed hosts may provide their own control-panel settings.

Apache documents overhead from .htaccess processing, but deleting a few PHP directives does not establish a measurable improvement or eliminate those lookups. Do not remove rules simply because they are outside WordPress’s default block: redirects, access controls and host-managed directives may be necessary.

Ask your host which configuration method applies, back up the affected file and change only settings you understand. Verify the effective values and site behavior afterward. Raising memory or execution limits is not a substitute for finding expensive work.

3. Find costly plugins, queries and background jobs

There is no universal safe plugin count. What matters is the work each plugin performs: database queries, external requests, front-end assets and scheduled tasks. A single expensive feature can matter more than several small utilities. Removing an unused plugin is sensible housekeeping, but it is not proof that the site has become faster.

Start with a feature inventory and identify redundant tools. Use Query Monitor to inspect slow queries, PHP errors and HTTP API requests on affected WordPress pages. For issues that appear only under load, ask your host about application profiling and resource measurements. Administrative diagnostic requests and cached visitor requests can behave differently.

• Reproduce the slow action and save the diagnostic result before making changes.
• On staging, disable one suspected component or feature at a time, respecting plugin dependencies and required business functions.
• Repeat the same action and compare timing, errors and behavior. Re-enable components when the evidence does not support removing them.
• Check scheduled tasks, growing logs, oversized autoloaded options and repeated slow queries when the evidence points to database or background work. Identify what owns the data before removing it.

Back up before database cleanup. Avoid treating every unfamiliar table or option as unused; deleting active plugin data can break a working feature. Our Advanced Database Cleaner review explains one available tool, but diagnosis and a recovery plan should come first.

4. Improve caching, images and front-end assets

Match the cache to the type of request

Full-page caching can serve reusable HTML without rebuilding it for every visitor. A persistent object cache can reduce repeated data retrieval during dynamic WordPress requests; it does not replace page caching. Check what your host already provides before adding another tool, and verify cache hits, exclusions and content refresh behavior. The WordPress caching guide explains the different layers.

Personalized pages need different treatment. For WooCommerce, confirm that cart, checkout and account pages are excluded from shared page caching, along with the relevant session behavior. Follow WooCommerce’s caching guidance and test with separate customer sessions. Our WooCommerce performance guide covers store-specific considerations.

A CDN can reduce delivery distance for cached resources, but it does not automatically fix slow database queries or external API calls. Investigate consistently slow uncached responses with your host, using request timings and CPU, memory, disk or worker-limit evidence before choosing a larger plan.

Prioritize the content visitors see and use

• Images: serve appropriately sized, compressed images and reserve their display space. Lazy-load suitable images below the initial viewport, but avoid lazy-loading the image responsible for LCP. Verify it in the report; Google’s LCP guidance explains why discovery and loading priority matter.
• JavaScript and CSS: remove genuinely unused features and unnecessary third-party tags. Test deferring or delaying scripts individually; aggressive settings can break menus, forms, consent controls and checkout.
• Fonts: review how many families and weights each page downloads and check the visible result on mobile. If you use Elementor, see our font optimization walkthrough.
• Embeds: consider a preview that loads a video or other heavy embed only when needed, while keeping its function accessible to visitors.

5. Retest the website and monitor real users

After each meaningful change, repeat the baseline with the same URLs and test settings. Keep a short log of the change, before-and-after measurements and anything rolled back. Differences between a cold cache and a warm cache should be labeled rather than presented as equivalent runs.

• Check the affected pages on mobile and desktop, including navigation and visible layout.
• Test forms, login and search; for stores, use a controlled test-order flow and verify account and cart behavior.
• Check browser and PHP errors and confirm that tracking or consent behavior still works where relevant.
• Purge affected caches after deployment and verify that visitors receive the updated content.
• Review real-user metrics as traffic accumulates. PageSpeed Insights field data covers a rolling 28-day period, so one week will still include visits from before the changes.

Keep the site stable long enough to observe the result. Prioritize repeatable improvements to the slow pages and important user journeys over chasing a perfect score on one test.