WordPress performance in 7.1: caching layers, images and speculative loading

A slow WordPress site costs visitors, search visibility and server money. Most advice on the topic is a list of plugins to install. This guide takes a different route: it explains the layers where WordPress spends time, shows how to measure each one, and describes what WordPress 7.1 already does for you, so you only add tools where they fix a real bottleneck.

Everything here is checked against the official Advanced Administration Handbook, WordPress core developer notes and the 7.1 release announcement. The current version is WordPress 7.1.3 (October 2026).

Start with the platform: PHP and database versions

WordPress.org recommends PHP 8.3 or later, and MySQL 8.0+ or MariaDB 10.11+, for new and existing sites. The optimisation handbook notes that software upgrades often fix bugs and improve performance, and that running current versions of the operating system, web server, database and PHP "is essential". If your host still runs PHP 7.4, upgrading is likely the cheapest improvement available, and it is also a security fix, since that version is end-of-life.

Check what you are running under Tools → Site Health → Info → Server. Test the PHP upgrade on a staging copy first, because old plugins are the usual source of incompatibilities.

Understand the four cache layers

"Caching" means several different things in WordPress. The wp-config.php page of the handbook separates them clearly:

The handbook lists common misconceptions worth knowing:

• WP_CACHE does not enable caching by itself. It only tells WordPress to load the advanced-cache.php drop-in, which a caching plugin or host supplies.
• WP_CACHE does not enable Redis, Memcached or browser caching.
• Page cache and persistent object cache are separate systems; an object cache can work without WP_CACHE.

// wp-config.php
// Only has an effect if a page-cache drop-in exists at wp-content/advanced-cache.php
define( 'WP_CACHE', true );

For a mostly public site (a brochure site, blog or documentation), a page cache delivers the biggest gain; the handbook's optimisation page recommends starting with caching for "the biggest benefit for the smallest hassle". For sites where many users are logged in (membership sites, shops, forums), pages cannot be fully cached, and a persistent object cache matters more.

Measure before you change anything

WP-CLI can tell you quickly which object cache is active and how heavy your autoloaded options are:

# Which object cache is active? "Default" means none (in-memory per request only)
wp cache type

# Total size of autoloaded options, in bytes
wp option list --autoload=on --format=total_bytes

# The largest autoloaded options, to find the culprits
wp option list --autoload=on --fields=option_name,size_bytes --orderby=size_bytes --order=desc | head -n 15

Autoloaded options are settings that WordPress loads on every request. The handbook recommends keeping them under 800 KB in total. Large values usually come from plugins storing logs or caches in options, or from plugins you removed long ago that left their settings behind. Investigate the biggest entries before deleting anything, and back up the database first.

For page-level measurements, use a lab tool such as Lighthouse and real-user data such as the Chrome UX Report where your site has enough traffic. Measure a few representative templates (home, an article, a product or listing page), not only the home page.

Use transients carefully

The Transients API is the standard way for plugins and themes to cache expensive results, such as remote API calls. Where transients are stored depends on your setup, which the handbook spells out:

• With a persistent object cache, transients can live in Redis or Memcached.
• Without one, they are stored in the wp_options table.
• Transients with an expiration are not autoloaded; transients set without an expiration are autoloaded on every request.

So always give a transient an expiry, and treat it as a cache that can disappear at any time:

<?php
function acme_get_exchange_rates() {
	$rates = get_transient( 'acme_exchange_rates' );
	if ( false !== $rates ) {
		return $rates;
	}

	$response = wp_remote_get( 'https://api.example.com/rates', array( 'timeout' => 5 ) );
	if ( is_wp_error( $response ) || 200 !== wp_remote_retrieve_response_code( $response ) ) {
		return array();
	}

	$rates = json_decode( wp_remote_retrieve_body( $response ), true );
	if ( ! is_array( $rates ) ) {
		return array();
	}

	// Expiring transients are not autoloaded; without a persistent
	// object cache they are stored in wp_options.
	set_transient( 'acme_exchange_rates', $rates, HOUR_IN_SECONDS );
	return $rates;
}

Let WordPress 7.1 handle more of the image work

Images are usually the heaviest part of a page. WordPress 7.1 changed how uploads are processed. According to the core developer note on client-side media processing:

• Compression, resizing, format conversion, rotation and thumbnail generation now run in the browser of the person uploading, using a WebAssembly build of the libvips image library. The feature is on by default in supporting browsers.
• The note states that libvips produces better-compressed output than GD or Imagick, with JPEGs reduced by about 15 percent using MozJPEG-like encoding, so visitors download smaller files.
• Large uploads no longer fail on PHP memory limits, and server CPU is freed for serving pages.
• Opaque animated GIFs can be converted to a companion MP4 or WebM video, an opt-in feature that typically produces much smaller files.
• The full WebAssembly pipeline is Chromium-only; other browsers fall back to server-side processing.

WordPress 7.1 also added native support for AVIF and HEIC uploads. In practice, this means fewer site owners need an image-optimisation plugin just to resize uploads. You may still want a CDN that serves modern formats and handles caching headers.

Speculative loading: faster navigation for free

Since WordPress 6.8, core outputs Speculation Rules that tell supporting browsers to fetch the next page before the visitor finishes clicking. The 6.8 developer note explains the defaults:

• It is on for the front end of all sites, except for logged-in users and sites without pretty permalinks.
• The default is prefetch with conservative eagerness, which starts loading when the user begins to click a link.
• URLs with query parameters are excluded automatically, which covers most "action" URLs such as add-to-cart links.
• The Speculation Rules API is supported by Chromium-based browsers; others simply ignore it.

You can make it more eager with the wp_speculation_rules_configuration filter. Allowed values are auto, prefetch or prerender for mode, and auto, conservative, moderate or eager for eagerness:

<?php
// Prefetch a little earlier than the default (on hover instead of on press).
add_filter(
	'wp_speculation_rules_configuration',
	function ( $config ) {
		if ( is_array( $config ) ) {
			$config['eagerness'] = 'moderate';
		}
		return $config;
	}
);

The filter receives null when speculative loading is disabled for the request, which is why the example checks for an array. If your site has paths that change state on a GET request and do not use query strings, exclude them:

<?php
// Never prefetch URLs that change state when visited with GET.
add_filter(
	'wp_speculation_rules_href_exclude_paths',
	function ( $href_exclude_paths ) {
		$href_exclude_paths[] = '/cart/*';
		$href_exclude_paths[] = '/my-account/*';
		return $href_exclude_paths;
	}
);

Be careful with prerender: it runs the page's JavaScript before the visitor arrives, which can affect analytics and other scripts that should only run on a real visit. WordPress 7.1 also lets hosts and site owners set speculative-loading defaults through environment variables or constants, without writing a plugin; check your host's documentation before adding your own filter.

Themes, plugins and the database

• Theme weight matters. The optimisation handbook says a lightweight theme "will perform much more efficiently than a heavy graphic-laden inefficient one".
• Audit plugins. Remove plugins you do not use; each active plugin can add queries, scripts and autoloaded options. Use a profiling plugin on staging to see which ones are slow.
• Move cron off page loads on busy sites. WordPress runs scheduled tasks during page requests by default. On high-traffic sites, set DISABLE_WP_CRON and run wp cron event run --due-now from a real system cron instead.
• Limit revisions if the database is huge. WP_POST_REVISIONS can be set to a number such as 3 to cap revisions per post.
• Put static files on a CDN if visitors are far from your server; the handbook notes geographical distance has a measurable effect.

A performance checklist

Summary

Fast WordPress sites come from a current PHP version, the right cache layer for the type of traffic, a lean options table, sensible image handling and a light theme. WordPress 7.1 now does more by default: images are processed in the browser with better compression, and speculative loading speeds up navigation. Measure first, change one thing at a time, and measure again.