Introduction

A slow WordPress website does not necessarily need a faster hosting plan or another optimisation plugin. The delay may originate from an uncached PHP request, an inefficient database query, oversized images, excessive JavaScript or a third-party service that prevents the page from finishing loading.

These problems require different solutions. Page caching can reduce server processing for anonymous visitors, but it cannot correct inefficient JavaScript running in the browser. Compressing images can reduce transfer sizes without improving the time taken to execute an expensive database query. Upgrading hosting resources may help with server congestion but have little effect on a page dominated by external scripts.

Useful performance work begins with identifying the part of the request that is slow. Changes should then be measured against a baseline rather than judged solely by whether a website feels faster.

The following 20 techniques cover WordPress configuration, hosting, caching, database performance, front-end resources and ongoing maintenance. Not every technique is appropriate for every installation, and some require access to hosting settings or development tools.

Measure Performance Before Making Changes

A reliable comparison requires more than a single page-speed score. Test representative pages, including the homepage, an individual article, a category archive and any important interactive pages. A WooCommerce installation should also be tested separately for basket, checkout and account functionality.

Record the initial measurements before enabling optimisation options or replacing plugins.

Core Web Vitals describe aspects of the visitor experience, but they do not identify every underlying cause. A page can have reasonable LCP and still contain a slow administration interface or an expensive uncached search query.

For meaningful comparisons, use the same page, device conditions and test environment. Repeat measurements because network and server conditions fluctuate.

Hosting and Server Configuration

1. Use Hosting Appropriate to the Workload

WordPress performance depends partly on the resources available to execute PHP and database operations. Shared hosting can work well for a conventional content website, particularly when anonymous visitors receive cached pages. It becomes less suitable when resource restrictions are repeatedly reached.

Important hosting characteristics include CPU allocation, available memory, PHP worker capacity, database performance and storage latency. The limits matter more than marketing descriptions such as unlimited bandwidth or optimised WordPress hosting.

A site with a small number of relatively static articles has different requirements from a busy ecommerce store. Basket updates, checkout requests, authenticated dashboards and many administrative operations require server-side processing that cannot always be replaced with shared page caching.

Examine hosting resource reports if available. Sustained CPU saturation, PHP worker exhaustion, repeated process limits or slow database operations provide stronger evidence for upgrading than a low page-speed score alone.

A hosting upgrade is justified when the existing environment is demonstrably limiting performance. It should not be the first response to oversized images or unnecessary scripts.

2. Use a Supported, Current PHP Version

PHP executes most of WordPress’s server-side application logic. Its version affects compatibility, security and execution performance.

Newer supported PHP releases can contain improvements to the language runtime and underlying implementation. However, the performance difference depends on the application, and upgrading does not guarantee that every WordPress operation becomes faster.

Before changing PHP versions, check the requirements of WordPress core, the active theme and installed plugins.

Older custom code may use functions or language behaviour that have been deprecated or removed. A major PHP upgrade can expose these problems even when the website previously appeared stable.

Test the new version in staging where practical. Review PHP error logs, administration pages, scheduled tasks, forms and any custom functionality.

Do not retain an unsupported PHP release simply because an abandoned plugin depends on it. Replace or update the incompatible component through a controlled process.

The objective is to maintain a supported environment without disrupting the website’s essential functionality.

3. Configure PHP OPcache

PHP files normally need to be parsed and compiled into executable opcodes. OPcache reduces repeated compilation work by retaining compiled PHP code in memory.

WordPress loads numerous PHP files during uncached requests, so OPcache can reduce part of the processing overhead.

Many managed hosting environments already enable OPcache. Verify its status before attempting configuration changes.

Relevant settings include:

These are PHP configuration directives, not WordPress options.

Their appropriate values depend on the number of PHP files, available memory and deployment environment.

Avoid disabling timestamp validation on an ordinary website unless the hosting or deployment system explicitly handles cache invalidation after updates. Otherwise, modified PHP files may not be reflected promptly in executed code.

OPcache primarily improves PHP execution. It does not reduce image sizes, correct browser-side delays or eliminate expensive SQL queries.

WordPress Caching

4. Enable Full-Page Caching

Full-page caching is often one of the most effective improvements for a predominantly public WordPress website.

Without a page cache, a typical uncached request requires the web server to start PHP processing, load WordPress, initialise plugins, execute relevant database queries and generate the final HTML.

A page cache stores an HTML response so that subsequent eligible requests can receive it without repeating most of that application processing.

For a website publishing tutorials and reference articles, many anonymous visitors request the same pages. This makes full-page caching particularly suitable.

Page caching can operate through a WordPress plugin, the hosting environment, a reverse proxy or a content delivery network.

Before enabling an additional caching plugin, determine whether the hosting provider already supplies page caching.

Multiple page caches can work together when deliberately configured, but overlapping systems make invalidation and troubleshooting more complicated.

The central requirement is to distinguish public content from personalised or transactional content.

Pages containing private account details, shopping baskets or checkout information must not be delivered through an incorrectly shared cache.

Test both logged-in and logged-out sessions after making changes.

5. Use Persistent Object Caching Where It Provides Value

WordPress includes an Object Cache API that allows application code to store and retrieve frequently used data during a request.

Without a persistent object-cache backend, much of that cached information is discarded at the end of the request.

A persistent object cache, commonly backed by Redis or another compatible system, can retain suitable data between requests.

This can reduce repeated database work, particularly on websites that perform complex queries or repeatedly access the same options and metadata.

Object caching is different from full-page caching.

A page cache can bypass most WordPress execution entirely. An object cache supports WordPress while PHP is executing.

Persistent caching is therefore more relevant to uncached requests, administration operations and sites with substantial dynamic activity.

However, it is not automatically beneficial on every installation. A small website with effective page caching and inexpensive queries may see limited improvement.

The server must support the cache backend, and WordPress requires an appropriate integration. Merely installing a Redis server does not make WordPress use persistent object caching.

Check cache hit rates, memory usage and database load before and after implementation.

6. Configure Browser Caching for Static Assets

Browsers can store CSS, JavaScript, fonts and images locally, reducing the need to download unchanged resources during subsequent visits.

HTTP caching headers determine how a browser and intermediate caches handle those files.

A typical response might include:

Cache-Control: public, max-age=31536000, immutable

This example allows long-term caching and is appropriate only for static resources whose URLs change when their contents change.

It should not be applied indiscriminately to HTML pages or assets that are updated without changing their URLs.

WordPress can include version parameters when stylesheets and scripts are enqueued. However, cache behaviour depends on the server and intermediary caches, and some environments handle query-string versioning differently.

For long-lived asset caching, content-hashed filenames are particularly reliable because a changed file receives a new URL.

The relevant caching headers are usually configured through the web server, hosting control panel or CDN.

Avoid applying generic .htaccess examples to an Nginx installation. Apache and Nginx use different configuration mechanisms.

A useful test is to inspect the browser’s Network panel during a repeat page visit and determine whether unchanged assets are loaded from cache.

7. Use a Content Delivery Network When Geography Justifies It

A content delivery network distributes suitable resources through servers located closer to visitors.

This can reduce network latency for users who are geographically distant from the origin server.

A CDN is particularly useful for websites with an international audience, substantial static assets or high traffic that benefits from edge caching.

It may deliver images, stylesheets, scripts and, where configured appropriately, cached HTML pages.

A CDN does not automatically make an uncached WordPress backend faster. If every request must travel to the origin and execute an expensive PHP query, edge delivery alone may provide limited benefit.

Pay attention to cache invalidation and personalised content. Account pages, authentication responses and transactional requests need appropriate cache rules.

For a small website whose audience is concentrated near its hosting location, the improvement may be modest.

Evaluate the CDN using real visitor regions and request timings rather than assuming that more infrastructure always produces better performance.

Database and Application Processing

8. Identify Expensive Database Queries

WordPress relies on its database to retrieve posts, options, metadata, user information and taxonomy relationships. A slow query can affect every uncached request that executes it.

The problem is not necessarily the total number of queries. A hundred inexpensive indexed queries may complete more quickly than a single poorly constructed query scanning a large table.

Query performance can deteriorate when plugins repeatedly retrieve extensive metadata, perform expensive searches or request more records than necessary.

A query profiler can help identify repeated queries, slow operations and the PHP components responsible for them. Hosting-level slow-query logs may provide additional information.

When investigating, record the execution time and examine the SQL rather than immediately deleting database records.

For example, a query filtering a large post-metadata table may be slow because the requested value is not efficiently indexed. Deleting revisions would not necessarily address that underlying problem.

If database access is available, EXPLAIN can help show how the database server plans to execute a query. Interpreting that output requires understanding indexes, joins and the query structure.

Do not add arbitrary database indexes without evaluating their effect on writes, storage and WordPress updates.

9. Review Autoloaded Options

WordPress stores application configuration in the options table, conventionally named wp_options.

Some options are autoloaded so their values are available without individually querying the database each time they are needed.

This is appropriate for configuration frequently used during page generation.

Problems can arise when plugins store large quantities of data as autoloaded options, particularly when the data is rarely required.

Because autoloaded options are loaded into memory, excessive data can increase memory usage and processing overhead.

A useful investigation identifies both the total amount of autoloaded data and the options contributing most heavily to it.

On an installation with WP-CLI, the following command can report autoloaded option storage where supported by the installed WP-CLI packages:

wp option list --autoload=on --fields=option_name,size_bytes --format=table

Check the installed WP-CLI command capabilities before relying on a particular filter or output field. The meaning of autoload-related values also needs to account for WordPress version and the option API’s current autoload behaviour.

Do not remove an option simply because it has a large value or an unfamiliar name. It may belong to an active plugin, theme or essential WordPress component.

A safer approach is to identify the owning component, determine whether the data is still required and use its supported cleanup mechanism where available.

10. Remove Unnecessary Database Data Carefully

WordPress databases accumulate revisions, expired temporary data, trashed content and records created by plugins.

Some of this information is useful. Revisions provide a recovery history, and temporary data may support active application functions.

Database cleanup should therefore be selective.

Expired transients are a reasonable subject for investigation, although their storage location can vary depending on whether a persistent object-cache backend is active.

Old revisions may also be removed according to a deliberate retention policy.

For example, WordPress supports a revision-retention constant in wp-config.php:

define( 'WP_POST_REVISIONS', 10 );

This sets a limit of 10 revisions for post types using the normal revision mechanism, subject to WordPress’s applicable revision behaviour and filters.

It does not immediately delete every older revision already stored.

A revision limit should be chosen according to editorial requirements. A collaborative website may need a longer history than a small personal blog.

Do not routinely empty unknown database tables or delete post metadata based on age alone.

Some plugins retain data after deactivation or deletion. Identifying the plugin’s ownership and uninstall behaviour is preferable to guessing which database entries are safe to remove.

Database backups should be taken before bulk cleanup operations.

11. Limit Expensive WordPress Queries

Custom themes and plugins frequently use WP_Query to retrieve posts, products or reference entries.

A poorly configured query may retrieve more data than the page needs or perform unnecessary pagination calculations.

For example, a small recent-posts list does not normally require WordPress to calculate the total number of matching records.

The following query requests six published posts without pagination totals:

$query = new WP_Query(
    array(
        'post_type'           => 'post',
        'post_status'         => 'publish',
        'posts_per_page'      => 6,
        'ignore_sticky_posts' => true,
        'no_found_rows'       => true,
    )
);

The posts_per_page argument limits the number of returned posts.

The no_found_rows argument avoids the total-results calculation normally used for pagination.

This example creates a query object; it does not display the results by itself.

For queries that need paginated navigation, no_found_rows may be inappropriate because total result information is required.

Other useful techniques include requesting only necessary fields, avoiding expensive metadata filters where possible and preventing repeated queries for the same information.

WordPress query arguments should be selected according to the actual task rather than copied from a generic optimisation checklist.

12. Fix Excessive WordPress Cron Activity

WordPress uses WP-Cron to manage scheduled operations.

These can include scheduled publishing, maintenance tasks and background processing introduced by plugins.

By default, WordPress checks for due events in connection with website requests and may spawn a separate request to process them.

On a low-traffic website, scheduled events can run late because no suitable request occurs near their scheduled time.

On a busy website, expensive background tasks may compete with normal application processing.

The problem becomes more significant when a plugin schedules frequent or long-running operations that consume substantial PHP or database resources.

Inspect the scheduled events before changing the cron configuration. Identify which hooks are due, how often they run and whether any have accumulated unexpectedly.

On hosting that supports reliable system scheduling, a real cron job can invoke WordPress’s scheduling process at defined intervals.

If the normal request-triggered mechanism is disabled:

define( 'DISABLE_WP_CRON', true );

a replacement scheduler must be configured.

Disabling WP-Cron without a replacement can prevent scheduled posts and maintenance processes from executing on time.

For a straightforward content website, the default mechanism may already be adequate. Change it when measurements or missed events justify the additional configuration.

Themes, Plugins and Front-End Resources

13. Audit Plugin and Theme Assets

Plugins can load CSS and JavaScript on public pages, even when their features are not visible on every page.

A form plugin might load its styles and scripts on articles that contain no forms. A slider plugin might enqueue assets globally despite the slider appearing on only one landing page.

These resources increase download sizes and may also create browser processing overhead.

Use the browser’s Network panel to examine the files loaded by representative pages.

Identify asset filenames, transfer sizes, initiators and whether particular scripts execute during page loading.

However, avoid assuming that every stylesheet or script supplied by a plugin is unnecessary. A shared file may contain functions required by several features.

Where appropriate, a developer can conditionally enqueue custom assets using WordPress hooks.

For example:

function site_enqueue_reference_styles() {
    if ( ! is_page( 'reference-library' ) ) {
        return;
    }

    wp_enqueue_style(
        'site-reference-styles',
        plugin_dir_url( __FILE__ ) .
            'assets/css/reference.css',
        array(),
        '1.0.0'
    );
}

add_action(
    'wp_enqueue_scripts',
    'site_enqueue_reference_styles'
);

This example assumes the PHP code is inside a plugin and the specified stylesheet exists relative to that plugin’s main file.

The code loads the stylesheet only on the page with the slug reference-library.

Conditional loading is useful when a resource is genuinely page-specific. It becomes risky when other pages depend on the same asset indirectly.

For third-party plugins, use supported asset-management features rather than modifying their files.

14. Reduce Unnecessary JavaScript Execution

JavaScript can delay page rendering and make interactions feel unresponsive.

This is particularly noticeable on mobile devices with less processing capacity.

Large scripts may require downloading, parsing, compilation and execution. Some scripts also perform expensive DOM operations, register numerous event handlers or trigger repeated layout calculations.

The appropriate optimisation depends on the cause.

If a library is unnecessary, removing it may be more effective than minifying it.

If a script is required only after user interaction, delayed loading may be suitable.

If a script is required for the initial page layout or navigation, delaying it indiscriminately can create visible or functional problems.

Modern WordPress versions support script-loading strategies through wp_enqueue_script().

For example:

wp_enqueue_script(
    'site-resource-filter',
    plugin_dir_url( __FILE__ ) .
        'assets/js/resource-filter.js',
    array(),
    '1.0.0',
    array(
        'strategy'  => 'defer',
        'in_footer' => true,
    )
);

This code is a PHP fragment for use in an appropriate enqueue callback, with the JavaScript file present at the specified location.

The requested defer strategy allows compatible browser loading behaviour while preserving script execution ordering rules. WordPress determines an eligible strategy based on the script’s dependencies and other constraints.

Avoid automatically applying async to scripts with dependencies or required execution order.

Measure JavaScript execution and interaction responsiveness after making changes. A smaller download does not always mean less main-thread work.

15. Optimise Images Before and After Upload

Images frequently represent a substantial proportion of the data transferred by a WordPress page.

A photograph uploaded at several thousand pixels wide may be unnecessary when it is displayed in a narrow article column.

WordPress generates alternative image sizes for many uploads and can supply responsive image attributes such as srcset and sizes.

These mechanisms help browsers select suitable files, but they do not guarantee that every uploaded image is appropriately prepared.

Start by selecting reasonable source dimensions and file formats.

Photographs generally benefit from efficient lossy compression. Screenshots containing small text or interface details may need different settings to preserve readability.

Modern image formats such as WebP and AVIF can reduce transfer sizes in suitable circumstances, depending on image content, browser support and server processing capabilities.

Inspect the actual image served to the browser rather than assuming the smallest possible derivative is selected.

For images used below the initial viewport, lazy loading can reduce work during initial page loading.

However, the main image responsible for Largest Contentful Paint should not normally be delayed through unnecessary lazy loading.

Assign appropriate image dimensions to reduce layout shifts while images load.

Technical diagrams and screenshots should remain legible; aggressive compression that obscures code or menu labels reduces the value of the content.

16. Optimise Fonts and Avoid Unnecessary Font Files

Web fonts can improve a website’s appearance, but they introduce additional resources that must be downloaded before text is displayed in the intended typeface.

A theme may load several font families, each with multiple weights and styles. The combined files can add considerable overhead, particularly if only a small portion of the available styles is used.

Inspect the font requests in the browser’s Network panel. Determine which families and weights are actually required.

For a conventional WordPress article website, one body font and one heading font are often sufficient. In some designs, a single family works for both.

System fonts eliminate the need for external font downloads, although the exact appearance varies between operating systems.

When self-hosting web fonts, WOFF2 is generally a suitable compressed format for modern browsers. Appropriate font subsetting can further reduce file sizes.

The CSS font-display property affects how text is displayed while a web font loads.

For example:

@font-face {
    font-family: "Site Sans";
    src: url("/wp-content/themes/child-theme/assets/fonts/site-sans.woff2")
        format("woff2");
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

This example assumes the font file exists at the specified path. It is illustrative CSS, not a reference to a file supplied by WordPress.

The swap value permits fallback text to appear while the custom font is loading. It can improve text visibility, but differences between the fallback and final font may cause layout shifts.

Use a metrically compatible fallback where practical, and ensure that the custom font is necessary before adding it.

17. Reduce Unnecessary External Requests

External services can affect the time needed to load a WordPress page.

Examples include analytics scripts, advertising systems, video embeds, embedded forms, social widgets and externally hosted fonts.

These requests are not automatically harmful. Some provide important functionality.

The problem arises when a page loads several external services that contribute little to the visitor’s immediate task.

A third-party script may request additional files, execute JavaScript or wait for remote responses. The impact depends on how it is integrated.

Use the browser’s Network panel to identify external domains contacted by the page.

Check which requests are blocking rendering, which download substantial resources and which execute long JavaScript tasks.

For embedded videos, loading a preview image and deferring the full player until interaction can reduce initial page work, provided the implementation preserves usability and accessibility.

For external scripts, check whether they can be deferred, delayed or loaded only on relevant pages.

Be cautious about removing scripts that support consent management, authentication, payments or other essential functions.

The objective is to eliminate unnecessary work, not to remove external services indiscriminately.

18. Avoid Heavy Page Builder Layouts Where Simpler Markup Works

Page builders provide extensive layout controls, but complex pages can contain deeply nested containers, numerous style declarations and additional scripts.

The impact varies by builder, version and implementation. A carefully constructed page-builder layout can perform well, while a poorly implemented custom theme can perform badly.

The issue is unnecessary complexity.

An ordinary article does not necessarily require multiple nested sections and layout modules for every paragraph or heading.

For long technical content, conventional WordPress blocks or clean article markup may be easier to maintain and require less generated HTML.

Use page-builder features where they provide genuine value, particularly for landing pages, product presentations and specialised layouts.

Review the rendered HTML rather than relying solely on the visual editor.

Repeated decorative effects, excessive animations and complicated nested layouts can increase browser rendering work.

Avoid rebuilding an established website merely because a benchmark suggests its page builder is responsible for slow performance.

First establish whether the problem comes from generated markup, JavaScript, stylesheet size, third-party modules or something unrelated to the builder.

A simpler layout is useful when it reduces measurable processing or transfer costs without sacrificing functionality.

Operational Improvements

19. Control Background Tasks and Plugin Activity

Not all WordPress processing happens during a visitor’s page request.

Plugins may execute scheduled synchronisation jobs, generate reports, process media, clean database records or communicate with external services.

Some operations are necessary. Others may run more frequently than the website requires.

For example, a reporting function that processes extensive historical data every few minutes can generate avoidable database load.

Similarly, several plugins performing large scheduled tasks at the same time may compete for available PHP workers and CPU resources.

Inspect the application’s scheduled events and the hosting provider’s resource usage records.

Determine when CPU or database utilisation increases and whether those periods correspond to known background operations.

Where supported, adjust task schedules or processing batch sizes.

Long-running operations may benefit from smaller batches or properly designed asynchronous processing.

Do not simply disable background processes because they consume resources. Some may be responsible for order processing, security maintenance, email delivery or scheduled publishing.

For an ecommerce website, background processing is often part of normal operation.

The useful distinction is between necessary work performed efficiently and unnecessary work performed repeatedly.

20. Establish a Repeatable Performance Testing Process

A website can become slower gradually as content, plugins and functionality accumulate.

A new theme module may add another script. A plugin update may change database behaviour. A growing archive may increase the cost of a previously inexpensive query.

Without a baseline, these changes are difficult to identify.

Establish a small collection of representative pages and measure them regularly.

For a WordPress reference and digital product website, appropriate test pages might include the homepage, a long article with code blocks, a resource listing, a plugin-generated tool and a product page.

Measure both cached and uncached responses where possible.

Cached tests reveal the experience of many anonymous visitors. Uncached tests help identify server-side problems that can affect administrators, logged-in users and dynamic requests.

Record significant changes alongside the measurements.

For example, if the hosting provider upgrades PHP, record the date and compare representative responses before and after the change.

If an image optimisation system is introduced, compare downloaded image sizes and visual quality.

Avoid interpreting minor fluctuations as meaningful improvements.

Performance testing is most useful when the same conditions are used repeatedly and changes are large enough to distinguish from ordinary variation.

How to Prioritise WordPress Performance Work

The most appropriate optimisation depends on the observed symptoms.

This approach helps prevent unrelated changes from being applied to the same problem.

For example, enabling Redis is unlikely to correct a large hero image that delays LCP. Conversely, converting a few images to WebP will not correct a database query taking several seconds.

WordPress Performance Troubleshooting

A useful diagnosis separates server response time from browser processing.

Begin with a representative page and inspect its network waterfall. Determine how long the initial HTML response takes, when the main page resources arrive and which requests delay rendering.

If the HTML response is slow, compare cached and uncached behaviour. A fast cached response and slow uncached response suggest that PHP execution, database activity or another backend operation deserves investigation.

If the HTML arrives quickly but the page remains visually incomplete, inspect CSS, fonts, images and JavaScript.

For pages that become unresponsive after loading, focus on JavaScript execution and rendering rather than assuming that the web server is slow.

Some common problems have distinctive symptoms.

Use a staging environment when changing several interacting components.

Where practical, change one major variable at a time. This makes it easier to establish which adjustment produced a meaningful result.

Avoid Optimisation Changes That Create New Problems

Some performance improvements involve trade-offs that should be considered before deployment.

Minifying CSS and JavaScript can reduce transferred bytes, but modern compression already reduces much of the overhead. Combining or rewriting assets may cause compatibility problems if their loading order changes.

Lazy loading can improve initial page loading for below-the-fold resources, but delaying important above-the-fold content may worsen perceived performance.

Database cleanup can remove unnecessary data, but deleting records without establishing their purpose can damage plugin functionality.

Long cache lifetimes reduce repeat downloads, but only when updated assets receive appropriately changed URLs.

Aggressive page caching may improve response times while creating stale-content problems or incorrectly caching personalised information.

For each change, identify the expected benefit, the potential failure mode and the method for reversing it.

A Practical WordPress Performance Maintenance Schedule

Performance work should continue after the initial optimisation, although most stable websites do not require constant adjustments.

The schedule should be adjusted to the site’s activity. A small information website may need fewer checks, while a busy online store may require continuous monitoring.

Keep records of significant measurements and configuration changes. A documented baseline makes it much easier to identify whether a new problem originated with an update, a hosting change or a gradual increase in application workload.

Performance improvements should be retained because they solve a demonstrated problem. A website that already performs well does not benefit from additional layers of optimisation simply because more settings are available.