Performance and Caching

Google’s Core Web Vitals are three field metrics, each judged at the 75th percentile of page views:

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, so guides that still optimise for FID are out of date. Field data comes from the Chrome User Experience Report (shown by PageSpeed Insights and Search Console); lab data comes from Lighthouse in Chrome DevTools or PageSpeed Insights. A Lighthouse score is a lab estimate on a simulated mid-range phone, not a measurement of real visitors, and the two can disagree.

For WordPress sites, LCP is usually limited by the server response time and the hero or featured image, INP by JavaScript from plugins, page builders and third-party tags, and CLS by images without dimensions, late web fonts and injected banners.

Time to First Byte (TTFB) is the time until the first byte of the HTML response arrives. It is not a Core Web Vital, but it comes before LCP and is where server-side caching shows up. web.dev treats 0.8 seconds or less as good. curl reports it directly; on the Lumen Press test site, three requests to an uncached post gave:

Source: web.dev: Time to First Byte (TTFB)

Taken on the same machine, these show only PHP and database time; measure from outside the data centre too, and repeat each measurement, since the first request after a deploy or cache flush is always slower.

Query Monitor is a free plugin from the WordPress.org directory, maintained outside core, that adds a developer panel to the admin bar. For the current request it lists every database query with its caller and time, duplicate and slow queries, the hooks that ran, HTTP API calls, PHP errors, enqueued scripts and styles, and the object cache hit rate. It is a development and staging tool; install it in production only temporarily and only for administrators.

Tools > Site Health runs several performance tests in core (see Debugging, Site Health and Troubleshooting for the screen itself):

The page cache test sends a loopback request from the server to itself, so it fails when loopbacks are blocked; that is a separate problem that also breaks WP-Cron and the editors.

The WP_CACHE constant does not cache anything. Early in wp-settings.php, before plugins load, core checks it and includes wp-content/advanced-cache.php if that file exists and the enable_loading_advanced_cache_dropin filter (4.6) allows it. A caching plugin writes that drop-in and sets the constant in wp-config.php; the drop-in looks up the current URL in its store and, on a hit, prints the stored page and exits.

Source: Code Reference: enable_loading_advanced_cache_dropin hook

The Advanced Administration Handbook names WP Super Cache, W3 Total Cache and Cache Enabler as caching plugins; many others exist, and managed hosts usually run their own page cache and ask that no caching plugin be installed. Two common pitfalls follow from how the drop-in works. Removing a caching plugin by deleting its folder leaves advanced-cache.php and WP_CACHE behind, so the site keeps serving old pages or fails on a missing include; deactivate the plugin through WordPress so it can clean up. And because the drop-in runs before plugins load, it cannot ask WordPress whether a user is logged in; it decides from cookies.

A page cache is safe only for responses that are the same for every visitor. A cache configuration for WordPress bypasses:

Nonces embedded in a cached page are a subtler trap. A nonce is valid for 12 to 24 hours, so a page cached for longer serves expired nonces and any form or AJAX action that relies on them starts failing with a 403. Keep cache lifetimes below 12 hours for pages with nonces, or fetch the nonce with a separate uncached request.

A cache in the web server or in a reverse proxy in front of it (Varnish, nginx, a host’s proxy) is faster than a plugin cache because PHP never starts. On nginx with PHP-FPM, fastcgi_cache does it with a few directives. The Lumen Press production configuration caches anonymous HTML for ten minutes, bypasses the cases above, serves stale pages while PHP is down or a page is being refreshed, and reports the cache status in an X-Cache header:

Source: nginx: Module ngx_http_fastcgi_module

nginx -t accepts this file on nginx 1.29. The X-Cache header reads MISS, HIT, BYPASS, EXPIRED or STALE, and Site Health’s page cache test recognises a HIT in it. The one-year max-age on static files is safe because WordPress adds a ?ver= query string to the URLs of enqueued scripts and styles, which changes when their version changes. Media files do not get such a string, so a replaced image needs a new file name.

Open-source nginx has no purge command, so a published change appears only when the entry expires. That is why the lifetime above is short. Sites that need instant updates use a proxy with purging (Varnish with PURGE or BAN requests, a host’s cache, or nginx with a third-party purge module) together with a plugin that sends a purge when a post is saved. The general nginx setup for WordPress is in Web Servers: Apache and nginx.

A content delivery network serves files from locations close to the visitor. For WordPress the usual first step is offloading static assets (uploads, theme and plugin CSS and JavaScript, fonts); the Advanced Administration Handbook notes that newer CDNs can also cache the full HTML at the edge. Core has no CDN setting: assets reach the CDN either through a pull zone in front of the whole site, through DNS (the CDN becomes the reverse proxy), or through a plugin that rewrites asset URLs. A full-page edge cache needs the same bypass rules as any page cache, and a way to purge it on publish.

The Redis Object Cache plugin (3.0.0, by Till Krüss) ships a drop-in and bundles the Predis client, so it works without the phpredis extension; it uses PhpRedis or Relay when they are installed. The following Compose file runs Lumen Press locally with MariaDB, Redis 7 and the plugin’s settings. The general Compose, wp-env and Playground setups are in Local Development Environments.

Source: Docker Hub: wordpress (official image)

The comment in the file records a pitfall found while testing it. The official image’s wp-config.php reads WORDPRESS_CONFIG_EXTRA with getenv() on every request instead of copying it into the file. A WP-CLI container without the variable therefore does not see WP_REDIS_HOST; the plugin then falls back to 127.0.0.1 and wp redis enable fails with "Connection refused". The YAML anchor gives both containers the same environment. On a normal server, the same constants go into wp-config.php directly.

With the stack running (DB_PASSWORD set in the shell or an .env file), install WordPress and enable the cache:

Source: WordPress.org Plugins: Redis Object Cache

wp redis enable copies the plugin’s drop-in to wp-content/object-cache.php. Shortened output:

wp cache type is a core WP-CLI command and works with any drop-in: it prints Default without one and the backend name (Redis) with one. wp plugin list --status=dropin lists the drop-in as object-cache.php.

The object cache counts its own hits and misses. This script, run twice with wp eval-file cache-stats.php, reads ten posts and an option and prints the counters and the number of database queries:

Source: Code Reference: WP_Object_Cache

With the Redis drop-in, after wp cache flush, and then with the plugin deactivated (which removes the drop-in):

The second persistent run needs no database query at all after WordPress has loaded, while the per-request cache repeats the same nine queries every time. On the Redis side, redis-cli info stats reports server-wide keyspace_hits and keyspace_misses, and keys are named prefix, blog prefix, group and key, such as lumenpress:wp:options:alloptions.

Transients move to Redis with an expiry, and no row is written to wp_options:

Source: WP-CLI Commands: wp transient set

The query returns 0 and ttl returns about 3594 seconds. This is why transients must never be treated as storage: with a persistent cache they live in memory and can be evicted at any time, long before their expiry.

By default, core prints speculation rules only for visitors who are not logged in and only when pretty permalinks are enabled. The default is prefetch with conservative eagerness: the browser fetches the next page’s HTML when the visitor starts to click or tap a link (on pointer down). On the Lumen Press test site, the footer contained:

Source: Make WordPress Core: Speculative Loading in 6.8

The rule excludes WordPress’s PHP endpoints, the admin, everything under wp-content, URLs with a query string and links with rel="nofollow". A link or a block with the class no-prefetch (and, in prerender mode, no-prerender) is also excluded.

The three eagerness values are conservative (on pointer or touch down), moderate (on hover for about 200 ms on desktop) and eager (as soon as the browser finds the link, or soon after). prerender also runs the target page’s JavaScript and renders it in a hidden tab, which makes the navigation instant but costs more server and client resources.

WordPress 7.1 lets a site or host change what the auto default resolves to without writing a plugin. Two values are read from a constant or, if no constant is defined, from an environment variable of the same name:

Invalid values are ignored, and so is immediate, a valid API value that WordPress does not allow for the document-level rules it generates. Lumen Press runs its production site behind a full-page cache, where an extra prerendered request is cheap, so it uses:

Source: Code Reference: wp_get_speculation_rules_configuration()

These were checked with wp eval 'var_export( wp_get_speculation_rules_configuration() );'. With the two constants the result was prerender and moderate, and the page then printed a "prerender" rule with "eagerness":"moderate". With the eagerness constant removed and WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS=eager in the environment, the result was eager. With immediate in the environment it fell back to conservative. A logged-in user got NULL (disabled). The Compose file above sets the environment variable for the web container; Apache’s PHP module and PHP-FPM must pass it through (PHP-FPM clears the environment unless clear_env = no or an env[...] line is set).

The constants change only the auto default. A plugin that sets an explicit mode or eagerness through the wp_speculation_rules_configuration filter still wins, and returning null from that filter disables speculative loading entirely. Before 7.1 that filter, in a plugin or must-use plugin, was the only way to change the defaults.

Any URL whose response changes per visitor, or whose GET request changes state, must be excluded: prefetching a "add to wishlist" or "log out" link performs the action. Core already excludes wp-login.php and the admin. Lumen Press adds its wishlist pages with wp_speculation_rules_href_exclude_paths, in the must-use plugin shown in the next section. With that filter and the 7.1 constants, the printed rule became:

Source: Code Reference: wp_speculation_rules_href_exclude_paths hook

Further rules (for example, prerendering a specific landing page eagerly) can be added with the wp_load_speculation_rules action, which receives the WP_Speculation_Rules object.

Two side effects need attention. Analytics scripts that count page views on load count prerendered pages that the visitor never opens, unless they check document.prerendering or support prerendering. And server load rises with eagerness, which is why conservative is the default and why a site without a page cache should not raise it.

Block themes, and classic themes that opt in through the should_load_separate_core_block_assets filter (5.8), load the CSS of each core block only on pages that contain it, instead of one large wp-block-library stylesheet. Small block stylesheets are printed inline up to a total of 40,000 bytes (styles_inline_size_limit, raised from 20,000 in 6.9), which saves requests. Neither feature concatenates or minifies a theme’s or plugin’s own CSS; that is up to the theme’s build step.