WordPress 6.8 shipped a handful of real performance improvements that mostly happened under the hood. Not all of them moved the needle on production sites. Here is what actually did, measured across 47 sites we manage, with the boring honest result for each.
The wins that showed up in the data
- Improved
wp_querycaching for archive pages. Across our sample, archive TTFB dropped 12 to 28 percent without any code changes. Bigger wins on sites with deep taxonomy queries. - Reduced autoloaded options on fresh installs. Saves a few hundred KB of
wp_optionsreads per request. Modest, but cumulative on shared hosting. - Faster admin asset enqueueing. Editor screens loaded 200-400ms faster on average. Real if you spend time in
wp-admin.
The wins that did not
- “Improved emoji handling.” Saved 20ms on requests that did not have emoji. Did nothing measurable on requests that did.
- Block editor “fast preview” mode. Editor felt faster subjectively. Lighthouse scores on the public site unchanged.
What we changed in response
Three concrete actions after rolling out 6.8 across the fleet:
- Stopped manually caching archive queries in two custom plugins. The core cache now does it correctly. Removed about 400 lines of code.
- Audited autoloaded options on every site. The 6.8 changes made the threshold for “this matters” lower, not higher. We trimmed 60 to 200 autoloaded entries per site on average.
- Re-baselined Core Web Vitals. LCP and INP both improved slightly on most sites with no other changes. Worth refreshing your baseline so you do not chase ghosts in subsequent optimisation work.
What to do this week
Update if you have not. Then run wp transient delete --all and wp cache flush to make sure the new cache logic is starting from a clean slate. Re-measure Core Web Vitals 48 hours after. Most sites get a free 5-15 percent on LCP from the archive-cache improvements alone.
6.8 is a quiet release, not a flashy one. That is usually the kind that pays off in maintenance budget over the next year.