Nathan Wrigley speaks with Weston Ruter, long‑time WordPress contributor, core committer for a decade, ex‑agency engineer, former Google developer relations engineer, and current contributor to the WordPress Core Performance Team. Their conversation covers why speed matters, how to measure it correctly, what the Performance Team has shipped, and what’s next for WordPress performance.
Why speed matters
Weston says nobody likes a slow web page. Performance affects user satisfaction, conversions, retention, and can influence search ranking when content relevance is equal. But measuring performance properly is crucial: lab tools like Lighthouse simulate loads and can give a 100 score, yet real user experience may differ. True performance should be judged by field metrics (real users), notably Core Web Vitals such as Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). LCP under 2.5s is “good,” but there’s meaningful difference between 2.4s, 1.5s, and fractions of a second—there’s still room to improve even after a 100 Lighthouse score.
WordPress out of the box
A vanilla site running the 2025 theme often scores very well in Lighthouse. But good lab scores don’t eliminate opportunities: Core improvements and additional optimisations can still reduce real‑user LCP and other vitals. The Performance Team’s aim is to make WordPress fast by default so site owners don’t need to become performance experts.
Democratizing performance
WordPress should implement best practices automatically, so users don’t need to configure lots of options. The team adopts the “decisions, not options” philosophy: sensible defaults should benefit the majority. The open ecosystem creates variability (themes, plugins), so tools that surface plugin performance impact—alongside security and code quality checks—would help site owners make better choices.
History and work of the Performance Team
Formed roughly four years ago, the team started tackling practical problems:
– Lazy loading: Core added lazy loading for images, but the team found lazy loading above‑the‑fold images can harm LCP. Fixes include not lazy loading initial viewport images and adding fetchpriority to critical images (e.g., featured images set to high).
– Emoji scripts: Inline JS used to detect emoji support caused long tasks on lower‑end devices and harmed LCP; that was optimised.
– Modern image formats: Support for WebP and AVIF helps reduce bytes sent for images.
– Speculative loading: Landed in 6.8, WordPress now prefetches HTML on pointerdown by default (a conservative approach). The Performance Lab plugin exposes options for more aggressive behaviours like prefetch on hover and pre‑render (download and render pages in the background), which can shave hundreds of milliseconds or even make transitions feel instantaneous when set appropriately.
– Enhanced responsive images: A Performance Lab plugin uses block structure to generate more accurate sizes attributes so browsers request the best image size for each container. In tests this often produced larger LCP improvements than switching to AVIF alone, because it avoided downloading needlessly large images on desktop.
– Back‑forward cache (bfcache): WordPress traditionally sends headers that prevent browsers from caching some pages, which breaks the bfcache and makes back/forward navigations slow and state‑loss prone (e.g., unsaved editor content). There’s a plugin experimenting with enabling bfcache behavior and a plan to land safer defaults and fixes in core (targeted for 6.9), including addressing privacy concerns around authenticated pages so the bfcache can be used safely. Chrome data shows back/forward navigations are common (≈10% desktop, ≈20% mobile), so enabling this is high value.
Speculative loading and tradeoffs
Speculative loading can prefetch or pre‑render pages based on user intent signals (pointerdown, hover). Defaults are conservative: only act for logged‑out users and when page caching is present, to avoid overwhelming origin servers. Admins can opt into more aggressive modes with warnings about caching and server load. Pre‑rendering fetches HTML and resources and can make navigation nearly instantaneous, but indiscriminate pre‑rendering could waste bandwidth if many links are hovered. Good caching mitigates server impact.
Script modules, Interactivity API, and script prioritization
The Interactivity API encourages server‑side rendering for block UI (so HTML/CSS are output server‑side), but interactive blocks still need client scripts. Script modules (ESM) are deferred by default and don’t block parsing, yet they still compete on the network and can deprioritise critical resources like LCP images. The team is adding fetchpriority low to interactivity scripts so that the browser prioritises critical visual content first. The Interactivity API also pushed forward the Script Modules API and better practices for non‑blocking interactive code.
JavaScript, long tasks, and INP
Even when initial rendering is fast, long JavaScript tasks after load cause jank and harm INP (Interaction to Next Paint). The team promotes best practices like breaking up long handlers with scheduler.yield and avoiding heavy synchronous work in event handlers to keep UI responsive.
Cumulative Layout Shift (CLS)
CLS remains a core issue: unexpected layout changes (e.g., ads or late image injections) displace content and frustrate users. Work continues on predictable sizing, reserving space for dynamic content, and encouraging patterns that avoid shifts.
Block themes vs classic themes
Block themes have performance advantages because the server renders blocks to determine needed CSS and JS, allowing selective loading of assets for each page. Classic themes often output larger global CSS/JS regardless of page content. Combined with enhanced responsive images and modern image formats, block themes can significantly reduce bytes and improve LCP.
Device diversity matters
Testing only on powerful new machines masks issues. Weston emphasises testing on mid‑ or low‑end devices or using CPU throttling in DevTools. Issues like the emoji detection script only surfaced on less capable devices where long tasks were apparent. Real user metrics and device diversity reveal the problems that most users experience.
Ecosystem and standards influence
WordPress changes can influence browser features. Responsive images in WordPress helped accelerate browser support years ago; speculative loading adoption by WordPress encouraged broader implementation in browsers. There’s ongoing collaboration between WordPress contributors and browser teams to ensure web platform features align with CMS usage patterns.
Tools and learning resources
Weston recommends following curated newsletters and experts rather than trying to keep up with everything on social media. He mentions Remkus de Vries’ Within WP newsletter and Jono Alderson’s performance content as good resources. Performance Lab plugins in the WordPress.org repo let site owners test and opt into experimental features.
Practical advice
– Rely on field metrics (Chrome UX Report, Core Web Vitals) to understand real user performance, not just lab scores.
– Use block themes and enhanced responsive image techniques where possible.
– Ensure page caching and persistent object cache before using aggressive speculative loading or enabling features for logged‑in users.
– Test on average/low‑end devices and use throttling to reveal hidden long tasks.
– Prefer plugins that do one thing well; avoid “kitchen sink” plugins that bloat pages and make replacement hard.
– Watch plugin performance impact; improved auditing and directory checks could help surface issues to site owners.
What’s next
6.8 delivered speculative loading defaults; 6.9 aims to expand bfcache compatibility and refine Interactivity API behavior (e.g., fetchpriority adjustments). The Performance Team will keep iterating on server defaults, plugins, and core changes to democratize speed.
Closing
Weston enjoys the work and appreciates the collaborative nature of improving WordPress at scale. The hope is that WordPress will continue to lift performance for the vast number of sites that use it so that site owners don’t need to become performance specialists to deliver fast experiences.
