WordPress Performance Optimization: The Complete Guide

A slow WordPress site loses traffic, conversions, and search rankings simultaneously. Google’s Core Web Vitals are a direct ranking signal, and visitors leave pages that take more than 3 seconds to load at a rate that makes the performance cost measurable in real revenue. This guide covers every layer of WordPress performance optimization - from server infrastructure to database tuning to frontend asset delivery - with the specific configurations that move the needle on a production site in 2026.

This is not a list of general best practices. Every section here addresses a specific, measurable performance bottleneck with concrete steps for fixing it. We cover what actually changes your Core Web Vitals scores, what the common mistakes are, and where to spend optimization effort first for the biggest gains. For sites where security hardening is also a priority alongside performance, our WordPress security hardening checklist covers the complementary hardening steps.

Understanding WordPress Performance: Where Time Goes

Before optimizing, you need to know what is slow. WordPress page generation time has three distinct components, and treating them as a single problem leads to wasted effort on the wrong layer.

Server Response Time (TTFB)

Time to First Byte is the time between a browser sending a request and receiving the first byte of the response. For an uncached WordPress page, TTFB includes: DNS resolution, TCP handshake, TLS negotiation, PHP execution time (WordPress bootstrap + database queries + template rendering), and the time to transmit the first byte of HTML.

An uncached WordPress page on a shared hosting environment with a large plugin stack can show TTFB of 800ms-2000ms. A properly configured WordPress site with full-page caching and Redis object cache should hit TTFB under 200ms. Google’s Core Web Vitals target is under 800ms for TTFB - achievable with proper caching but not without it.

Resource Loading (LCP and INP)

Largest Contentful Paint measures when the largest visible content element renders. For most WordPress sites, this is either the featured image in the hero section or a large text block above the fold. INP (Interaction to Next Paint) replaced First Input Delay in 2024 as a Core Web Vitals signal - it measures responsiveness to user interactions throughout the page lifetime, not just the first click.

LCP is primarily affected by image optimization, resource prioritization, and render-blocking scripts. INP is primarily affected by JavaScript execution time - heavy JavaScript frameworks, unoptimized event listeners, and render-blocking third-party scripts all damage INP scores.

The thresholds worth holding yourself to: LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1. Google treats the 75th percentile of real-user traffic as the pass mark, so a lab score that clears these on your laptop is not the same as passing.

Visual Stability (CLS)

Cumulative Layout Shift measures how much page elements move during loading. WordPress sites frequently fail CLS because of images without explicit dimensions, web fonts that cause layout shifts when they load, and lazy-loaded content that pushes existing content downward. CLS is often the easiest Core Web Vitals score to fix with simple HTML changes.

Measuring Before Optimizing

Optimization without measurement produces guesswork. Run these tests first and record the baseline numbers. Every change after this should be measured against that baseline.

• Google PageSpeed Insights: Measures real-user Core Web Vitals data from the Chrome User Experience Report plus lab data from Lighthouse. Test on mobile (the harder scoring environment) and desktop. Record LCP, INP, CLS, TTFB, and the Total Blocking Time.
• GTmetrix: Provides detailed waterfall analysis showing exactly which resources load in what order and how long each takes. The waterfall view is essential for identifying render-blocking scripts and slow-loading third-party resources.
• Query Monitor plugin: Identifies slow database queries, missing indexes, and excessive query counts on any page. Install on staging and run on your heaviest pages. Any page with more than 30 database queries or any single query taking more than 50ms is a performance problem.
• New Relic or Datadog APM: For production monitoring, application performance monitoring shows where PHP execution time goes across all requests, not just manually tested pages.

Layer 1: Server and Hosting Configuration

No amount of plugin-level optimization overcomes a fundamentally under-powered or mis-configured server. Get this layer right first.

PHP Version

Running PHP 8.2+ is not optional for performance-focused WordPress sites in 2026. PHP 8.0 brought JIT compilation. PHP 8.1 added fibers and enum types. PHP 8.2 and 8.3 added further memory efficiency improvements. The performance difference between PHP 7.4 and PHP 8.2 for typical WordPress workloads is 15-25% reduction in execution time. If your host does not support PHP 8.2 or above, that is a reason to switch hosts.

Web Server: Nginx vs Apache

Nginx handles concurrent requests more efficiently than Apache’s prefork model for WordPress workloads. With Nginx + PHP-FPM, you get event-driven request handling that scales better under load than Apache’s per-process model. Most managed WordPress hosts (Kinsta, WP Engine, Cloudways with Nginx) use this configuration by default. If you manage your own server and are still on Apache, the migration to Nginx + PHP-FPM is worth the configuration effort.

PHP-FPM Configuration

PHP-FPM’s process manager configuration directly affects how many simultaneous WordPress requests your server handles. The key settings are pm.max_children, pm.start_servers, pm.min_spare_servers, and pm.max_spare_servers. Setting these too low causes request queuing under load; too high causes memory exhaustion. A rough starting formula: pm.max_children = available_RAM_for_PHP / average_PHP_process_memory. For most WordPress sites, average PHP process memory is 32-64MB. On a server with 2GB allocated to PHP, that is 32-64 max children.

OPcache Configuration

PHP OPcache stores compiled PHP bytecode in memory, eliminating the compilation step on every request. WordPress with dozens of plugins can involve hundreds of PHP files being compiled on every uncached request. OPcache with correct settings cuts that compilation overhead entirely. Critical settings:

• opcache.memory_consumption=256 – at least 256MB for a full WordPress plugin stack
• opcache.max_accelerated_files=10000 – default of 2000 is too low for WordPress + plugins
• opcache.revalidate_freq=60 – check for file changes every 60 seconds (set to 0 in production if you manage deployments explicitly)
• opcache.validate_timestamps=0 – disable timestamp validation entirely in production for maximum performance (requires explicit cache clear on deploy)

The recommended production OPcache configuration that matches these settings:

MySQL/MariaDB Tuning

WordPress is database-heavy. Every page load triggers dozens of queries, and poorly tuned MySQL is often the bottleneck. Proper database tuning can speed up WordPress dramatically, focus on these key variables in your my.cnf:

[mysqld]
# InnoDB Buffer Pool - set to 70-80% of available RAM on dedicated DB servers
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 4

# Query Cache (MariaDB) - WordPress benefits significantly
query_cache_type = 1
query_cache_size = 128M
query_cache_limit = 2M

# Connection and thread handling
max_connections = 150
thread_cache_size = 16

# Temporary tables
tmp_table_size = 64M
max_heap_table_size = 64M

# Logging for optimization
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Enable the slow query log in development to identify problematic queries. Plugins like Query Monitor surface these during page loads, making it straightforward to trace slow queries back to specific plugins or themes.

Essential wp-config.php Constants

Your wp-config.php file controls critical performance behavior. Add these constants for production environments:

// Limit post revisions to reduce database bloat
define('WP_POST_REVISIONS', 5);

// Increase autosave interval (default is 60 seconds)
define('AUTOSAVE_INTERVAL', 120);

// Disable file editing in admin (security + performance)
define('DISALLOW_FILE_EDIT', true);

// Empty trash automatically after 7 days
define('EMPTY_TRASH_DAYS', 7);

// Optimize cron - disable wp-cron.php on every page load
define('DISABLE_WP_CRON', true);

// Increase memory limits
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// Concatenate admin scripts (reduces HTTP requests in admin)
define('CONCATENATE_SCRIPTS', true);

When you disable WP-Cron, set up a real system cron job to handle scheduled tasks:

# Add to crontab (crontab -e)
*/5 * * * * cd /var/www/html && wp cron event run --due-now --quiet 2>&1 | logger -t wp-cron

This runs WordPress cron every 5 minutes via WP-CLI, which is far more efficient than the default approach of triggering wp-cron.php on every front-end page load.

Layer 2: Caching Strategy

Caching is the single most impactful WordPress performance improvement available. A properly cached WordPress site can serve thousands of concurrent visitors from a small server. An uncached WordPress site crumbles under moderate load.

Full-Page Caching

Full-page caching stores the complete HTML output of a WordPress page and serves it directly without executing PHP or querying the database. For a site where the majority of visitors are not logged in, full-page caching is transformative. TTFB drops from 500ms+ to under 50ms when serving from cache.

Options ranked by efficiency:

• Nginx FastCGI Cache: Caches at the web server level before PHP even executes. The fastest option available. Requires Nginx and direct server access.
• WP Rocket or LiteSpeed Cache: Plugin-level full-page caching. LiteSpeed Cache is specifically optimized for LiteSpeed server environments. WP Rocket works on any server and has excellent cache management. Both are paid.
• W3 Total Cache or WP Super Cache: Free options that work but require more configuration to achieve equivalent performance to WP Rocket.

Cache exclusion rules are as important as the caching itself. Never cache: logged-in user pages, WooCommerce cart and checkout pages, pages with personalized content, and pages with query string parameters that affect content. Incorrect exclusions cause users to see each other’s cart data or account information - a serious problem that requires careful testing.

Object Caching with Redis

WordPress’s native object cache stores frequently-accessed database query results in memory for the duration of a single PHP request. This is useful but limited - the cache resets on every page request. A persistent object cache using Redis or Memcached stores these results across requests, so repeated database queries return cached results from memory rather than hitting the database.

Redis is the preferred option in 2026 due to its richer data structure support and better WordPress plugin ecosystem. The Redis Object Cache plugin (by Till Kruss) is the most reliable WordPress Redis integration available. Install Redis on the server, install the plugin, and point it at the Redis socket or TCP connection. The performance impact is most visible on WooCommerce sites (which run many queries per page) and sites with complex home page queries.

Transient caching deserves a specific mention here. WordPress plugins frequently use transients to cache API responses, computed values, and external data. When persistent object caching is active, transients automatically use Redis rather than the database, which reduces database write load significantly on sites with many plugins using transients.

Database Query Cache vs MySQL Query Cache

MySQL’s built-in query cache was removed in MySQL 8.0. Do not attempt to re-enable it on modern MySQL versions. Instead, rely on WordPress’s object cache (Redis) for query result caching at the application layer, and use proper database indexing to reduce query execution time at the database layer. These two together are more effective than MySQL query cache was in practice.

Layer 3: Database Optimization

WordPress’s database grows and degrades over time without regular maintenance. A database that performed well at 1,000 posts can slow significantly at 50,000 posts or after years of accumulated post revisions, spam comments, and transient records.

Autoloaded Options Bloat

Every WordPress request loads the wp_options table rows where autoload = ‘yes’ into memory before any page content renders. This is a fundamental WordPress mechanism. The problem: plugins frequently add large datasets or entire configuration objects to autoloaded options. After years of plugin installs and uninstalls, the autoloaded options payload can grow to multiple megabytes, adding hundreds of milliseconds to every uncached page load.

WordPress 6.7 added Site Health checks specifically for autoloaded options bloat - it will flag if your autoloaded options exceed recommended thresholds. To check the current state, run this query against your database:

Any single option over 1MB is a candidate for review. The Autoloaded Options Clean Up plugin helps identify and safely remove orphaned options from uninstalled plugins. Do not delete autoloaded options without verifying they are genuinely orphaned - deleting active plugin options breaks functionality.

Post Revisions

WordPress stores a revision every time a post is saved. On an active site with frequent edits, the wp_posts table accumulates revisions faster than content. A post edited 200 times over its lifetime has 200 rows in wp_posts that serve no purpose beyond the last 3-5 revisions. Limit revisions in wp-config.php and periodically clean up historical ones:

WP-Optimize or the free WP Sweep plugin provides safe revision cleanup with a UI. Run cleanup on a database backup first to confirm no content is lost.

Database Table Optimization

MySQL tables accumulate overhead over time as rows are deleted and updated. Running OPTIMIZE TABLE on the WordPress tables periodically defragments them and updates table statistics, which helps the query planner make better execution decisions. WP-Optimize automates this. Schedule a monthly optimization during off-peak hours on production sites.

Custom Indexes for WP_Query

If your site uses custom post meta fields for filtering or sorting - for example, displaying posts filtered by a custom ‘featured’ meta key or sorted by a ‘price’ meta value - adding indexes to wp_postmeta for those specific meta keys dramatically improves query performance. WordPress does not add custom indexes for plugin-added meta keys by default. Any WP_Query using meta_query on a large postmeta table is a candidate for index analysis. Use Query Monitor’s database tab to identify which queries are running slow and what indexes they might benefit from.

Layer 4: Image Optimization

Images are typically the largest contributor to page weight on content-heavy WordPress sites. A single unoptimized hero image can add 2-4MB to a page that should weigh under 1MB total. Image optimization at every level - format, compression, sizing, delivery - has a direct, measurable impact on LCP.

WebP Format

WebP provides 25-35% smaller file sizes compared to JPEG at equivalent visual quality, and 25-50% smaller compared to PNG. WordPress 5.8 added native WebP upload support. In 2026, browser support for WebP is universal across all modern browsers. There is no reason to serve JPEG or PNG for photographs on a WordPress site when WebP is available.

Enable WebP conversion in your image optimization plugin (Imagify, ShortPixel, or Smush Pro all support automatic WebP conversion on upload). For existing image libraries, run a batch conversion tool. Most optimization plugins include a bulk optimizer for existing images.

AVIF format provides even better compression than WebP but has slightly lower browser support (around 93% as of early 2026). Serve AVIF with a WebP fallback using the picture element for maximum optimization without compatibility risk.

AVIF: The Next Step Beyond WebP

AVIF offers even better compression, with 20-50% smaller file sizes than WebP at equivalent quality. As of 2026, AVIF support is at 95%+ across modern browsers.

To enable AVIF in WordPress, ensure your server has the necessary libraries:

# Check for AVIF support
php -r "echo 'GD AVIF: ' . (function_exists('imageavif') ? 'YES' : 'NO') . PHP_EOL;"
php -r "echo 'Imagick AVIF: ' . (in_array('AVIF', Imagick::queryFormats('AVIF')) ? 'YES' : 'NO') . PHP_EOL;"

# Install libavif support (Ubuntu)
sudo apt install libavif-dev
sudo apt install php-imagick
sudo systemctl restart php8.3-fpm

Responsive Images and srcset

WordPress automatically generates srcset attributes for uploaded images, providing multiple size options for different viewport widths. The browser selects the appropriate size based on the rendered element width and device pixel density. This mechanism only works correctly if your theme declares the correct image sizes and uses wp_get_attachment_image() rather than hardcoded img tags. Check that your theme registers the sizes your design actually uses - WordPress defaults often generate sizes that do not match your design breakpoints.

LCP Image: Preload and Prioritization

The LCP image - usually the hero image or the post featured image on single post pages - should be loaded as a high-priority resource, not a lazy-loaded one. WordPress 6.3 added automatic LCP detection and removed lazy loading from the first image in the content. But themes that use background images via CSS, or that add the loading=”lazy” attribute to their hero image via custom code, break this optimization.

Add a preload link tag for your LCP image in the document head to further accelerate it. The browser can begin fetching it before the image tag is discovered during HTML parsing. WP Rocket and LiteSpeed Cache both offer LCP preload options in their settings.

Image CDN vs Local Optimization

An image CDN (Cloudinary, Bunny Optimizer, or Cloudflare Images) delivers optimized images from edge servers close to the user, transforming images on-the-fly based on the browser’s capabilities and the requested dimensions. This approach is more effective than local optimization for sites with large media libraries because it eliminates the need to regenerate all images when you change size requirements, and it automatically serves the best format for each browser.

Layer 5: JavaScript and CSS Optimization

WordPress’s plugin ecosystem is notorious for adding JavaScript and CSS to every page regardless of whether it is needed. A typical WordPress site with 20 active plugins can load 40-60 separate JavaScript and CSS files on a single page, many of which are only needed on specific pages or not at all for most visitors.

Minification and Concatenation

Minification removes whitespace, comments, and unnecessary characters from JavaScript and CSS files without changing their functionality. Concatenation combines multiple files into one, reducing the number of HTTP requests. Both are standard features in WP Rocket, LiteSpeed Cache, and W3 Total Cache.

With HTTP/2 (standard on all modern hosting), the request count benefit of concatenation is reduced - HTTP/2 multiplexing allows multiple requests over a single connection. However, minification still provides meaningful savings by reducing file sizes. Enable minification; be more selective about concatenation on HTTP/2 hosts.

Defer and Async Script Loading

Scripts loaded in the head without defer or async block HTML parsing until they are downloaded and executed, directly increasing Time to First Contentful Paint. WordPress 6.3 added script loading strategy support via wp_enqueue_script - developers can now specify ‘defer’ or ‘async’ directly in the registration call without filter hacks. Themes and plugins that use this correctly have noticeably better Total Blocking Time scores.

For scripts you cannot control (third-party plugins that do not use the script loading strategy API), WP Rocket’s “Delay JavaScript Execution” feature defers third-party scripts until user interaction, which dramatically improves lab-measured performance scores. Use with testing - some scripts need to execute before interaction for correct functionality.

Remove Unused CSS

Many WordPress themes and plugins load their entire stylesheet on every page even if only 10% of the rules apply to any given page. Critical CSS extraction - identifying the styles needed to render above-the-fold content and inlining them in the head while deferring the full stylesheet - is the most impactful CSS optimization for LCP.

WP Rocket includes “Remove Unused CSS” as a feature that generates page-specific CSS files containing only the rules used on that page. LiteSpeed Cache offers similar capability. These tools are not perfect - JavaScript-conditional styles can be incorrectly removed - but they work well for standard blog and landing page content.

Critical CSS and Render-Blocking Resources

The browser cannot render any content until it has downloaded and parsed all render-blocking CSS. Eliminating render-blocking resources is one of the most effective ways to speed up WordPress page rendering. Inline the critical CSS needed for above-the-fold content and defer the rest:

// Generate and inline critical CSS
function attowp_inline_critical_css() {
    $critical_css_path = get_template_directory() . '/assets/critical.css';
    if (file_exists($critical_css_path)) {
        echo '<style id="critical-css">' . file_get_contents($critical_css_path) . '</style>';
    }
}
add_action('wp_head', 'attowp_inline_critical_css', 1);

// Defer non-critical stylesheets
function attowp_defer_stylesheets($html, $handle, $href) {
    $critical_handles = ['wp-block-library', 'theme-style'];

    if (in_array($handle, $critical_handles) || is_admin()) {
        return $html;
    }

    return str_replace(
        "rel='stylesheet'",
        "rel='preload' as='style' onload=\"this.onload=null;this.rel='stylesheet'\"",
        $html
    );
}
add_filter('style_loader_tag', 'attowp_defer_stylesheets', 10, 3);

Resource Hints: Preconnect, Prefetch, and Preload

Resource hints tell the browser about resources it will need soon, allowing it to start fetching them early:

function attowp_resource_hints() {
    // Preconnect to CDN and font providers
    echo '<link rel="preconnect" href="https://cdn.example.com" crossorigin>' . "\n";
    echo '<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>' . "\n";

    // DNS prefetch for analytics and third-party services
    echo '<link rel="dns-prefetch" href="https://www.google-analytics.com">' . "\n";

    // Preload critical font
    echo '<link rel="preload" as="font" type="font/woff2" href="' .
         get_template_directory_uri() . '/fonts/primary.woff2" crossorigin>' . "\n";
}
add_action('wp_head', 'attowp_resource_hints', 0);

Per-Page Asset Loading

The cleanest solution to CSS/JS bloat is preventing plugins from loading their assets on pages where they are not needed. This requires using wp_dequeue_script() and wp_dequeue_style() with conditional logic to remove plugin assets from pages where the plugin is not active. This is developer work but produces the cleanest results - no unused assets loaded, no cleanup tools needed.

Layer 6: Content Delivery Network (CDN)

A CDN serves your static assets (images, CSS, JavaScript, fonts) from edge servers distributed globally, reducing the physical distance between the server and the visitor. For visitors far from your origin server, a CDN can reduce asset load time by 60-80%. It also offloads bandwidth from your origin server, reducing its resource usage during traffic spikes.

Cloudflare

Cloudflare is the most widely used CDN for WordPress sites. The free tier provides CDN delivery, DDoS protection, and a basic WAF. The Pro tier ($20/month) adds image optimization, mobile redirects, and better analytics. Enterprise plans include edge-side customization and SLAs. Cloudflare sits as a reverse proxy in front of your origin server, caching static assets at edge nodes and optionally caching HTML (with page rules or cache rules).

Enable Cloudflare’s Rocket Loader to defer non-essential JavaScript loading, Browser Cache TTL to extend how long browsers cache assets, and Auto Minify for an additional layer of CSS/JS minification. The Polish feature (Pro+) automatically converts images to WebP for supporting browsers.

Pull CDN vs Push CDN

A pull CDN (Cloudflare, BunnyCDN) automatically fetches content from your origin server when a visitor first requests it, then caches it at the edge. A push CDN requires you to explicitly upload assets to the CDN. Pull CDNs are far simpler for WordPress use - plugin and theme updates automatically get served from the CDN after the first request without any manual file uploads.

BunnyCDN offers pull CDN functionality at roughly 1/10th Cloudflare’s cost for pure asset delivery, without the full reverse proxy and security features. For simple asset CDN use without the security layer, it is excellent value.

Layer 7: Plugin Audit and Management

Every active WordPress plugin adds PHP execution time to every request. A plugin that adds 5ms to each uncached page request adds 5ms permanently, regardless of whether that plugin’s feature is relevant to the visited page. Fifteen such plugins add 75ms to every page load, before a single business feature has executed.

Audit Active Plugins

Use Query Monitor’s “Hooks” tab to identify which plugins are registering the most actions and filters. Use the “PHP Errors” tab to catch deprecated function calls. Use the database tab to identify which plugins generate the most queries. Plugin Performance Monitor (a newer plugin specifically for this purpose) tracks per-plugin execution time across page loads.

The plugins most frequently responsible for performance problems:

• Slider plugins that load CSS/JS globally regardless of whether the current page has a slider
• Contact form plugins that load recaptcha scripts on every page (see our piece on reCAPTCHA alternatives for the performance cost)
• Page builder plugins with large front-end libraries loaded globally
• WooCommerce extensions that load cart fragments and session data on non-shop pages
• Backup plugins running database scans during peak traffic

Replace Heavy Plugins with Lightweight Alternatives

Many popular WordPress plugins have lightweight alternatives that provide equivalent functionality with a fraction of the resource overhead. Some common replacements to evaluate:

Layer 8: Frontend and Block Editor Performance

Block-based themes and the Gutenberg editor have their own performance considerations that differ from classic themes.

Block Theme CSS Architecture

Block themes generate per-block CSS stylesheets served via the inline style API, rather than a single monolithic stylesheet. WordPress loads only the CSS for blocks actually used on the current page. This is architecturally better than classic themes but requires the block registration to declare styles correctly. Custom blocks that enqueue a global stylesheet rather than using block-specific styles negate this optimization.

Interactivity API vs jQuery

The WordPress Interactivity API, introduced in 6.5 and maturing through 6.7, enables reactive frontend behavior from server-rendered blocks without a separate JavaScript framework. For sites still loading jQuery for basic interactions (toggling menus, showing/hiding elements, basic AJAX), the Interactivity API is a lighter alternative. jQuery weighs approximately 87KB minified + gzipped. The Interactivity API runtime is around 12KB.

WordPress 6.7 deprecated jQuery Migrate on new block-based theme installations. Sites still relying on jQuery for plugin compatibility should audit those plugins - many popular plugins have updated to remove the jQuery dependency in 2025.

Font Loading

Web fonts are a common CLS cause and can contribute to LCP delays when the font file is not available at render time. Best practices for 2026:

• Host fonts locally (not from Google Fonts CDN) to eliminate a cross-origin DNS lookup
• Use font-display: swap to prevent invisible text while fonts load
• Preload the primary font files with a link rel=”preload” in the document head
• Limit font variants to what is actually used - each weight and style is a separate file download
• Use WordPress 6.0+’s native font management in the Site Editor for block themes, which handles font optimization automatically

WP-CLI Automation: Performance Maintenance Scripts

Automate recurring performance maintenance with a WP-CLI bash script. Run it weekly via cron or as part of your deployment pipeline:

#!/bin/bash
# wp-performance-maintenance.sh
# Run weekly via cron: 0 3 * * 0 /path/to/wp-performance-maintenance.sh

SITE_PATH="/var/www/html"
LOG_FILE="/var/log/wp-performance.log"

echo "$(date): Starting performance maintenance" >> "$LOG_FILE"

cd "$SITE_PATH" || exit

# 1. Clean expired transients
wp transient delete --expired --network 2>> "$LOG_FILE"

# 2. Optimize database tables
wp db optimize 2>> "$LOG_FILE"

# 3. Delete old revisions (keep last 5 per post)
REVISIONS=$(wp post list --post_type=revision --format=ids 2>/dev/null)
if [ -n "$REVISIONS" ]; then
    wp post delete $REVISIONS --force 2>> "$LOG_FILE"
fi

# 4. Clear orphaned postmeta
wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL;" 2>> "$LOG_FILE"

# 5. Check autoloaded options size
AUTOLOAD_SIZE=$(wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';" --skip-column-names 2>/dev/null)
echo "$(date): Autoloaded options size: ${AUTOLOAD_SIZE} bytes" >> "$LOG_FILE"

# 6. Flush object cache
wp cache flush 2>> "$LOG_FILE"

# 7. Regenerate rewrite rules
wp rewrite flush 2>> "$LOG_FILE"

echo "$(date): Performance maintenance complete" >> "$LOG_FILE"

Performance Optimization Checklist: Priority Order

Run optimizations in this order. Each layer builds on the previous one, and early layers provide the largest absolute gains.

1. Verify PHP 8.2+ and configure OPcache correctly
2. Install and configure full-page caching with correct exclusion rules
3. Add Redis persistent object cache
4. Clean up autoloaded options bloat and set post revision limit
5. Optimize all images to WebP and add explicit dimensions
6. Enable LCP image preloading
7. Enable CSS and JS minification
8. Add a CDN for static assets
9. Audit plugins for per-page impact; dequeue unused assets
10. Enable defer on non-critical scripts
11. Configure font preloading and local hosting
12. Test with PageSpeed Insights, GTmetrix, and Query Monitor - record results
13. Address any specific failing Core Web Vitals signals with targeted fixes

WordPress Performance and Headless Architecture

For sites that have hit the limits of what optimization can achieve within the traditional WordPress architecture, headless WordPress is the architectural path to significantly better performance. With a headless setup, WordPress serves as the content backend via its REST API, and a JavaScript framework (Next.js, Nuxt, Astro) handles frontend rendering.

The performance advantage of headless WordPress is most pronounced for highly dynamic sites where full-page caching is difficult (logged-in users, personalized content, frequently updated feeds) and for sites where static site generation is viable (documentation sites, marketing sites, blogs with infrequent updates). Statically generated pages from a headless WordPress backend can achieve TTFB under 20ms served from a CDN edge.

The trade-off: headless WordPress increases architectural complexity and requires JavaScript frontend expertise alongside WordPress backend knowledge. The performance gain is real but comes at a development and maintenance cost. Our headless WordPress guide covers the full setup for teams evaluating this path.

Frequently Asked Questions

What is the most important WordPress performance optimization?

Full-page caching has the largest single impact for most WordPress sites. A page that takes 800ms to generate from PHP can serve in under 50ms from cache. If you only implement one optimization, implement full-page caching with a plugin like WP Rocket or LiteSpeed Cache. Every other optimization builds on top of caching to refine the experience further.

How many plugins are too many for performance?

Plugin count alone is not the issue - quality and configuration are. A site with 30 well-coded, properly configured plugins can outperform a site with 10 poorly optimized ones. What matters is whether each plugin loads assets globally rather than conditionally, whether it runs database queries efficiently, and whether it has excessive hooks registered on every request. Use Query Monitor to measure per-plugin impact rather than counting plugins.

Does WordPress hosting make a significant difference?

Yes, substantially. Shared hosting environments with limited PHP workers, no persistent object cache, and shared database servers produce fundamentally different performance characteristics than managed WordPress hosting with dedicated resources, server-level caching, and Redis. For a performance-focused site, the hosting environment sets the performance ceiling. No amount of plugin-level optimization overcomes an under-resourced server.

How do I improve my WordPress INP score?

INP (Interaction to Next Paint) is affected by the amount of JavaScript running during and after user interactions. Improve it by: deferring non-critical JavaScript execution until after page load, breaking up long JavaScript tasks into smaller chunks (using setTimeout or requestIdleCallback), reducing the JavaScript payload (removing unused scripts, using lighter alternatives), and auditing third-party scripts that run during interaction events. Use Chrome DevTools’ Performance tab to identify which scripts are running during interaction events and how long they take.

Should I use a page builder or the native block editor for performance?

The native block editor produces leaner output than page builders in most cases. Elementor, Divi, and similar builders load substantial JavaScript and CSS libraries globally. The block editor with a well-built block theme loads only the CSS and JS for blocks actually used on the page. For performance-sensitive sites, building with the native block editor and custom blocks provides the most control over the frontend asset footprint.

WordPress performance is a layered problem with a clear priority order. Start with server configuration and caching, move to database and image optimization, then refine JavaScript and CSS delivery. Measure at every step. The sites that achieve consistently fast Core Web Vitals scores are not using magic plugins - they have worked through each layer systematically and addressed the specific bottlenecks their site generates. The tools and techniques covered in this guide are all the same ones production WordPress engineers use on high-traffic installations.

We audit WordPress sites for performance bottlenecks across all layers - server configuration, caching, database, images, and frontend delivery - and implement the fixes. If your Core Web Vitals scores are falling short or your site is slow under load, reach out for a performance review.