Adam Silverstein, a WordPress Core committer and Developer Relations Engineer on Chrome’s Web Platform team, explains how evolving browser features are changing what’s possible for WordPress developers and site owners. His WordCamp Europe 2025 talk surveyed new browser APIs that reduce JavaScript reliance, improve accessibility and performance, and enable capabilities that were previously impractical or impossible.
Three classes of browser capabilities
– Replacements for heavy JavaScript implementations: browser-native features that simplify development and cut bloat.
– User-experience improvements: smoother, more app-like interactions and accessibility benefits.
– Previously impossible features: powerful new possibilities such as in-browser image processing and local AI.
Collaboration and stability: Interop and Baseline
Browser vendors (Chrome, Firefox, Safari, Edge) now coordinate more closely. Interop is an annual, public process where browsers agree which features to implement. Baseline marks features available across major browsers—developers can depend on them. Many features Adam discusses are still rolling out across browsers, so fallback strategies may be needed.
Key browser features relevant to WordPress
Popover API
– Popovers (dialogs, tooltips, pointers) are common in WP admin and Gutenberg but are surprisingly complex to implement accessibly with JavaScript.
– The Popover API lets you create popovers with minimal CSS/HTML; the browser handles positioning, stacking, escape behavior, and window changes.
– Result: less JS, better accessibility, easier maintenance.
CSS capabilities and scroll-driven animations
– CSS has gained powerful features allowing programmatic-like behavior without JS.
– Scroll-Driven Animations API permits tying CSS animations to scroll position (e.g., fade-ins, reading progress). These animations run off the main thread, freeing JS for critical tasks and improving performance and responsiveness.
Speculative Loading (Speculation Rules API)
– Enables browsers to prefetch or prerender resources for links a user is likely to follow.
– WordPress 6.8 includes a conservative implementation: prefetching begins on mousedown (very high probability of navigation).
– More aggressive modes (hover, prerender) exist and can give near-instant transitions but increase server load and bandwidth.
– Tradeoffs: conversion improvements for commerce sites vs. extra server cost. WordPress shipped conservative defaults; plugins can expose more aggressive options.
CSS Carousels
– Over half of WP sites load slider/carousel libraries. Browser-native CSS carousels aim for parity with JS libraries (controls, indicators, grouped slides).
– Benefits: no heavy JS libraries, CSS animations on compositor thread, better accessibility by default, and simpler markup.
Customizable select elements
– Historically, select dropdowns were OS-rendered and limited. New support allows HTML inside select options (icons, images), preserving semantics and autofill.
– Advantages: visual clarity, accessible controls, consistent CSS styling across platforms.
View Transitions API
– Smooth transitions between pages or states: elements morph/scale from one page to the next (title grows into place, image expands), creating an app-like fluid experience.
– Can be auto-applied or customized via CSS. Performance Lab and recent feature plugins add opt-in theme support so themes can enable view transitions easily.
– This improves perceived speed and user experience without changing underlying network behavior.
Images and media: HDR and modern formats
– Phones capture HDR images, and modern formats (AVIF, WebP) support better compression and HDR. But WordPress image processing relies on server-side libraries (GD, Imagick) that lag in format support.
– Ultra HDR (ISO standard) combines SDR and a gain-map metadata layer so a single file can render properly on HDR-capable displays and degrade gracefully on SDR displays.
– Server-side processing limitations mean new formats take years to reach broad host support (AVIF support is still on ~30% of WP servers).
Browser-based image processing via WebAssembly
– WebAssembly lets complex native libraries run in-browser. This enables:
– Converting images to modern formats client-side during upload (even if the server lacks library support).
– Converting GIFs to videos for better performance.
– Workflow: image uploads can be processed asynchronously in the browser and then stored in optimized formats—shipping modern image support without waiting for hosts to upgrade server libraries.
– Experimental tools: Pascal’s Media Experiments plugin demonstrates current browser-based processing; Gutenberg has experimental integrations.
In-browser AI
– Transformers.js and similar libraries can run smaller AI models locally in the browser. Pros:
– No API key or cloud cost.
– Data stays private (processed locally).
– Useful for tasks like summarizing site content, moderating comments, or basic image analysis.
– Constraints: models are smaller and less capable than large cloud models, but reasonable for many site-focused tasks. Hybrid models (local first, cloud fallback) are possible.
Practical WordPress implications and approaches
– Core vs plugins: WordPress follows an 80/20 philosophy for Core features. Many browser-enabled features can be offered via canonical blocks or plugins that are one-click installable and maintained with Core compatibility.
– Examples already in motion:
– Speculative loading shipped in Core (conservative defaults).
– Performance Lab and plugins offer view transitions opt-in for themes.
– Gutenberg experiments and PRs explore adding scroll-driven animation toggles, image-processing hooks, and enhanced selects.
– Developers should think about whether features belong in Core, as a canonical plugin/block, or in third-party plugins.
Data, privacy, and performance measurement
– Chrome collects opt-in telemetry; aggregated, anonymized data is available via CrUX (Chrome User Experience Report). It’s a public dataset useful for plugin authors and researchers to understand web usage and performance trends.
– Developers should weigh heuristics and privacy implications when designing prefetching, AI, and heavy client-side features.
Call to developers
– Browsers and web-platform developers want feedback. The Interop GitHub process and browser repos are public. Developers—especially those working on large ecosystems like Gutenberg and WordPress—should file issues, propose use cases, and report pain points.
– WordPress contributors have successfully influenced Interop; continued engagement helps prioritize the APIs developers truly need.
Bottom line
Modern browsers now offer powerful native capabilities—CSS-driven UI, speculative loading, view transitions, modern image handling, in-browser processing, and local AI—that can reduce JavaScript bloat, improve accessibility and perceived speed, and enable features previously impractical on the web. WordPress is beginning to adopt and experiment with many of these features; theme and plugin authors should watch Baseline/Interop progress, try available experiments (Performance Lab, Gutenberg experiments, Media Experiments plugin), and provide feedback to shape the path forward. Adam’s final ask: get involved—test, give feedback, and help prioritise real developer needs so the web platform evolves in ways that benefit everyone.
