The WordPress Performance Lab plugin is the official staging ground for performance features being developed for WordPress core. Features that are too experimental, too configuration-dependent, or too audience-specific for a default WordPress install land here first. Some ship to core eventually. Others remain as opt-in Performance Lab modules because they require specific server capabilities or have trade-offs that make them unsuitable for universal deployment.
As of 2026, “wordpress performance lab” is consistently appearing in the top WordPress search queries, which makes sense given how much Google’s Core Web Vitals ranking signals have increased in importance. The plugin currently ships with more than a dozen modules spanning image optimization, resource loading, database efficiency, and speculative loading. Not all of them are worth enabling on every site. For a broader look at what to optimize, see our performance optimization guides.
This guide covers every module that is currently stable and the specific scenarios where it delivers measurable improvement, and which ones to skip or test carefully before enabling on production.
How Performance Lab Works
Performance Lab installs as a standard WordPress plugin. After activation, it shows a “Performance” settings page in the WordPress admin where each module can be enabled or disabled independently. Each module is a self-contained feature with its own settings. You can enable one module without activating the others, there are no dependencies between modules.
The plugin requires WordPress 6.4 minimum and PHP 7.4+. PHP 8.x is strongly recommended for all performance work. The modules that interact with image handling require that your server’s PHP installation has the GD or Imagick extension, standard on virtually all hosted environments.
Performance Lab also installs a Health Check indicator in the WordPress Site Health dashboard for any module that detects a configuration issue. If a module you have enabled is not working correctly, for example, if WebP upload support is enabled but your server’s image library does not support WebP encoding, the Site Health panel will flag it.
Image Modules: Enable All of These
Modern Image Formats (WebP, AVIF)
WordPress 6.1 added native WebP output when uploading JPEG or PNG files, the server converts them automatically and serves WebP to browsers that support it. Performance Lab’s image format module extends this to AVIF, which produces files 30–50% smaller than WebP at equivalent quality, at the cost of slower encoding time.
Whether to enable AVIF depends on your server. AVIF encoding is CPU-intensive, on a shared hosting server that already runs close to its CPU limits during uploads, enabling AVIF can cause media uploads to timeout. On a dedicated server or VPS with available CPU headroom, AVIF is worth enabling for the file size savings. The module includes a self-test that checks encoding speed before activating, if encoding a sample AVIF takes more than 10 seconds, the module warns you.
WebP output (without AVIF) is the safe default for every site. Enable the WebP module if your WordPress version is below 6.1 or if you want more control over conversion quality settings than core provides.
Image Placeholders (LQIP)
Low Quality Image Placeholders show a blurred, tiny version of an image while the full-resolution version loads. This is the technique popularized by Gatsby.js and Next.js for near-zero CLS scores on pages with large above-the-fold images. WordPress did not have this natively until Performance Lab added it.
Enable this for any site where above-the-fold images cause layout shifts, you will see it in CLS reports as the page jumping when images load. The placeholder is a 20×20 pixel base64-encoded image embedded inline in the HTML, so it loads with zero additional HTTP requests and prevents the layout shift entirely. The visual effect is a blurred placeholder that transitions smoothly as the full image loads, far better than the empty white space that causes CLS.
Enhanced Responsive Images
WordPress generates srcset attributes for registered image sizes automatically. The Enhanced Responsive Images module improves the algorithm that selects which sizes to include in the srcset, producing better-matched sizes for high-DPI (Retina) displays and narrow mobile viewports. The practical effect is that mobile visitors on Retina screens download an appropriately sized image rather than a desktop-sized image scaled down in CSS.
Enable this unconditionally, it has no performance cost and improves mobile image delivery for every image on the site.
Fetchpriority for LCP Images
This module adds fetchpriority="high" to the image most likely to be the Largest Contentful Paint element. The browser uses this hint to download the LCP image before other images in the queue, directly improving LCP scores. WordPress 6.3 shipped a version of this in core, but Performance Lab’s version uses an improved detection algorithm that handles more layout patterns, particularly themes with hero images in custom block markup rather than core Image blocks.
This is the single highest-impact image module for LCP scores. Enable it on every site. The TTFB optimization guide covers the server-side complements to this, faster server response combined with fetchpriority on the LCP image produces the best LCP outcomes.
Loading Optimization Modules
Speculative Loading
The Speculative Loading module uses the browser’s Speculation Rules API to prefetch or prerender pages the user is likely to navigate to next. The browser detects when a user hovers over or moves toward a link, and begins loading the destination page before the click. The result is that navigation between pages feels instantaneous, the next page is already loaded before the user clicks.
Two modes are available: prefetch (downloads the page HTML and assets but does not execute JavaScript) and prerender (fully renders the page in a background tab, ready for instant display). Prerender delivers the most dramatic perceived performance improvement but uses more memory and bandwidth. Prefetch is the safer default.
Enable speculative loading on: marketing sites, blogs, documentation sites, and WooCommerce product archives where users browse multiple pages in sequence. Do not enable prerender mode on WooCommerce checkout flows or pages with side effects (form submissions, tracking pixels that fire on page load). The module respects rel="nofollow" and provides a filter to exclude specific URLs from speculation.
Browser support: Chrome 109+, Edge 109+. Safari and Firefox do not support Speculation Rules yet, the module gracefully degrades with no effect on unsupporting browsers.
Embed Optimizer
WordPress embeds (YouTube videos, Twitter/X posts, Vimeo, etc.) are notoriously bad for Core Web Vitals. Each embed loads third-party JavaScript and iframes that trigger layout shifts (CLS) and block main thread execution (INP). The Embed Optimizer module replaces embeds with facades, static thumbnails that look like the embedded content but only load the actual iframe when the user clicks to interact.
This is especially valuable for YouTube embeds, which load over 400KB of JavaScript just to display a play button. A YouTube facade loads a static thumbnail (a single image request) and only fetches the full YouTube player on click. The CLS and INP improvement on pages with embedded videos is dramatic.
Enable this on any site that uses WordPress oEmbed for videos, social posts, or other rich media. The performance improvement on pages with multiple embeds consistently brings them from failing to passing Core Web Vitals.
Database and Options Modules
Autoloaded Options Health Check
The autoloaded options module adds a Site Health check that alerts you when your autoloaded options table exceeds a threshold (default: 800KB). It also shows which options are largest and which plugins own them, actionable information that was previously only visible by running raw SQL queries. Enable this as a diagnostic tool. It does not change anything automatically, it just surfaces information you need to make optimization decisions.
Once you identify large autoloaded options via the health check, the object cache guide covers how persistent caching mitigates the performance impact of autoloaded data, a cache in front of the options table is the fastest fix while you work on reducing the autoload data size.
Optimized Autoloaded Options (Experimental)
This experimental module goes a step further: it intercepts option loads and groups them into a single bulk query rather than individual get_option() calls. For sites with many plugins that each call get_option() independently, this can reduce database round-trips on the options table by 70–80%.
Mark it experimental because it has behavioral edge cases with plugins that use options in unusual ways (options with null values, options that should not be cached, etc.). Test on a staging environment before enabling on production. For sites with more than 100 autoloaded options and no persistent object cache, the improvement is significant.
What to Skip or Test Carefully
Not every Performance Lab module is universally safe. These deserve caution:
- Prerender (Speculation Rules aggressive mode), fully rendering pages in the background consumes significant memory and can trigger analytics events prematurely. Use prefetch mode instead, or exclude analytics-heavy pages from speculation.
- AVIF encoding on constrained servers, as noted above, CPU-intensive encoding on shared hosting causes upload timeouts. Run the built-in encoding speed test before enabling.
- Optimized Autoloaded Options (experimental), test on staging first. Some plugins behave unexpectedly when their options are batched rather than fetched individually.
- Any module marked “experimental” in the plugin UI, the Performance Lab team flags these explicitly. They are functional but may have edge cases that are still being resolved. Use them on staging or non-critical sites first.
The Recommended 2026 Configuration
| Module | Enable? | Notes |
|---|---|---|
| WebP Uploads | Yes | Required if WP < 6.1; still useful for quality control on 6.1+ |
| AVIF Uploads | Test first | Only on servers with CPU headroom; run the encoding speed check |
| Image Placeholders (LQIP) | Yes | Eliminates CLS from image loading with zero HTTP overhead |
| Enhanced Responsive Images | Yes | No cost, better Retina/mobile image sizing |
| Fetchpriority (LCP) | Yes | Highest single-module LCP impact, always enable |
| Speculative Loading (prefetch) | Yes | Massive perceived navigation speed improvement |
| Speculative Loading (prerender) | Selective | Exclude checkout and form pages; enable on browse/read flows |
| Embed Optimizer | Yes, if using oEmbeds | Critical for sites with YouTube/Vimeo embeds |
| Autoloaded Options Health Check | Yes | Diagnostic only, surfaces problems, changes nothing |
| Optimized Autoloaded Options | Test on staging | High impact if you have 100+ autoloaded options; test carefully |
Frequently Asked Questions
Does Performance Lab conflict with caching plugins?
No conflicts with WP Rocket, LiteSpeed Cache, or W3 Total Cache have been reported with the stable modules. The image optimization modules work at upload time (not at serving time), so they are independent of caching. The fetchpriority and speculative loading modules modify HTML output, which means they interact with page caching, the cached HTML will include the fetchpriority attributes and speculation rules, which is the correct behavior. If you clear your page cache after enabling these modules, the new HTML will be cached with the improvements included.
Will modules that ship to WordPress core be removed from Performance Lab?
Yes. When a Performance Lab module ships in a stable WordPress release, it is removed from the plugin and becomes a core feature. The fetchpriority module, for example, shipped in core in WordPress 6.3. The Performance Lab version remains available with enhancements beyond what core ships, but if you are running a recent WordPress version and have not installed Performance Lab, you already benefit from the core version of several of these features. Installing Performance Lab gets you the enhanced version plus features still in the pipeline for core.
How do I measure whether Performance Lab modules are actually helping?
Enable one module at a time and measure before and after using PageSpeed Insights or the Chrome User Experience Report (CrUX) for real-user data. PageSpeed Insights lab data refreshes immediately; CrUX data takes 28 days to reflect changes for real users. For immediate validation, use Chrome DevTools Lighthouse in incognito mode, run 3 tests before enabling the module, average the scores, then run 3 tests after enabling, and compare. The fetchpriority module’s impact on LCP is visible immediately in Lighthouse. Speculative loading’s impact is best measured through Time to Navigate metrics in web analytics rather than Lighthouse scores.
Does Performance Lab work with page builders like Elementor or Divi?
The image optimization modules (WebP, AVIF, LQIP, fetchpriority, responsive images) work with any page builder because they operate at the media upload and output level, independent of which tool built the page. The speculative loading module works with page builders that output standard <a> tags for internal links, which covers Elementor, Divi, Bricks, and virtually all others. The embed optimizer works for any embed inserted via the standard WordPress oEmbed system; embeds inserted via custom Elementor widgets that bypass oEmbed may not benefit.
Is Performance Lab safe to use on production sites?
The stable modules (WebP/AVIF uploads, image placeholders, fetchpriority, enhanced responsive images, speculative loading, embed optimizer, autoloaded options health check) are safe for production. They are built and tested by the WordPress Core Performance team and are on the path to core inclusion. The modules marked “experimental” in the plugin UI are not yet considered stable, they may have edge cases that cause issues on specific configurations. The Performance Lab team uses the “experimental” label deliberately: enable those modules on staging first. For a site you cannot afford to have disrupted, stick to the non-experimental modules. Browse our WordPress plugins hub for more plugin recommendations and reviews.
What Changed in Performance Lab Since 2024
Performance Lab has evolved significantly in the past 18 months. If you installed the plugin in 2024 and have not revisited its module list, several new modules have shipped and some older ones have graduated to core:
- INP optimization work, Interaction to Next Paint replaced First Input Delay as a Core Web Vitals metric in March 2024. Performance Lab has been adding modules focused on reducing main thread blocking, particularly around the block editor’s JavaScript footprint. The INP-related modules are still maturing but worth watching.
- Speculative loading is now stable, was experimental in 2024, promoted to stable in 2025 after extensive cross-site testing. The prefetch mode is safe for general use; prerender mode remains recommended for testing before broad deployment.
- Image placeholders expanded, LQIP support was limited to JPEG and PNG in early versions. The 2025 update added WebP source image support, which matters now that most uploaded images are already WebP.
- Fetchpriority algorithm improvements, the LCP image detection algorithm now handles more complex layout patterns, including images inside CSS
background-imageon Covers, images in carousels that are lazy-loaded except for the first slide, and hero images delivered via the Site Editor’s featured image block. - Embed Optimizer added YouTube nocookie domain support, YouTube facades now default to the privacy-enhanced
youtube-nocookie.comdomain, reducing the tracking cookies loaded when a visitor views a YouTube embed on your site.
The plugin’s changelog is worth reading with each new version. Performance Lab ships updates roughly monthly, and each update either adds a new module, promotes an experimental module to stable, or removes a module that has shipped to WordPress core. Keeping the plugin updated ensures you get improvements automatically as they stabilize.
Before You Install: A Server Requirements Check
Before installing Performance Lab, verify your server meets the requirements that make the key modules effective:
- PHP 8.x with GD or Imagick, required for image format modules (WebP, AVIF, LQIP). Check in WordPress admin → Tools → Site Health → Info → Server to see which image library is active and which formats it supports.
- WordPress 6.4+, the minimum for the full module set. WordPress 6.5 or 6.6 is recommended for the best integration with the speculative loading module’s newer features.
- Browser support awareness, Speculation Rules API (speculative loading) requires Chrome/Edge 109+. If your audience is heavily Firefox or Safari, speculative loading will not benefit them, though it will not harm them either (graceful degradation). Worth knowing before you expect dramatic improvements in analytics.
- A page caching layer in place, Performance Lab modules optimize HTML output and images. For those optimizations to serve fast, you still need page caching. Performance Lab does not replace WP Rocket or LiteSpeed Cache, it complements them. The correct order: set up page caching first, then layer Performance Lab modules on top.
Combining Performance Lab with a Full Performance Stack
Performance Lab is most effective as one layer of a complete performance stack, not as a standalone solution. The full stack for a well-optimized WordPress site in 2026 looks like this:
- Fast hosting, LiteSpeed or nginx, PHP 8.3, NVMe storage. This sets the TTFB floor that everything else builds on.
- Page caching, WP Rocket, LiteSpeed Cache, or equivalent. Serves pre-built HTML to non-logged-in users, eliminating PHP execution per request.
- Object caching (Redis/Valkey), speeds up dynamic pages and transient access that page caching does not cover.
- CDN (Cloudflare), serves static assets from edge nodes near your users, reducing latency for visitors far from your origin server.
- Performance Lab modules, LCP fetchpriority, LQIP, speculative loading, embed optimizer. These optimize the HTML and assets that reach the browser, improving Core Web Vitals scores even after all the server-side optimizations are in place.
Each layer addresses a different bottleneck. A site with all five layers in place consistently passes Core Web Vitals thresholds, not because any single layer is magic, but because they eliminate every major performance bottleneck systematically. Skipping any one layer leaves a measurable gap. Performance Lab addresses layer five, and because it is a free plugin with a 15-minute setup, there is no reason not to have it.
The Bottom Line
The WordPress Performance Lab plugin is the easiest way to get ahead of Core Web Vitals improvements before they ship to WordPress core. The five modules that should be enabled on virtually every site, WebP uploads, LQIP placeholders, enhanced responsive images, fetchpriority, and speculative loading (prefetch mode), deliver measurable improvements to LCP, CLS, and perceived navigation speed with minimal configuration, zero cost, and no risk to existing WordPress functionality.
Enable the safe modules today, test the experimental ones on staging, and revisit the plugin’s changelog with each WordPress release to see what has graduated to core. Performance Lab is both a set of immediate improvements and a preview of where WordPress performance is heading, staying current with it keeps your sites ahead of the Core Web Vitals optimization curve rather than catching up to it one Google algorithm update at a time.
Core Web Vitals Performance Lab Plugin Performance Optimization WordPress Performance
Last modified: March 26, 2026
