bfcache, Speculation Rules and AI Debugging – Three Browser Features That Kill Page Load Delays

What bfcache, Speculation Rules and AI Debugging Actually Solve

Most performance work targets the first page load. TTFB optimisation, image compression, script deferral – all of it focuses on that initial request. The gap nobody talks about is the second navigation: the back button tap, the next-article click, the category page hop.

bfcache eliminates reload time for backward and forward navigations by storing a complete page snapshot in memory. The Speculation Rules API goes further and begins fetching or even rendering the next page before the user taps anything. Chrome DevTools MCP connects your AI coding agent directly to a running browser session, turning runtime debugging from a manual chore into an automated conversation. These three features target different moments in the browsing timeline, but they share one goal: making wait time disappear. Publishers who have adopted them report 9-18% revenue increases and double-digit jumps in page views per session.

bfcache alone reduced INP-related delays in real-world tests because the restored page skips parsing, layout and paint entirely.

How the Back-Forward Cache Works (and What Breaks It)

When a user navigates away from a page, the browser can freeze that page’s entire state – DOM tree, JavaScript heap, layout – and store it in memory. Hitting the back or forward button restores that snapshot instantly instead of firing a new HTTP request, parsing HTML, and re-executing scripts. The result is a perceived load time of zero milliseconds.

The problem is that several common patterns block bfcache eligibility. The unload event listener is the biggest offender: browsers cannot safely restore a page if it registered code that expects to run only once on exit. Cache-Control: no-store headers also prevent caching because they signal that the response must not be reused under any conditions. Open IndexedDB transactions and active WebSocket connections create the same issue since the browser cannot guarantee consistent state after a freeze-thaw cycle. HTTP-only session cookies tied to stateful server responses add another layer of complexity because the browser must decide whether the cached snapshot still represents a valid authenticated session.

Fixing these blockers requires auditing your response headers and event listeners.

// Replace unload with pagehide
window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    // Page is entering bfcache - clean up non-critical resources
    analytics.flush();
  }
});

// Use visibilitychange for most cleanup tasks
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    navigator.sendBeacon('/analytics', JSON.stringify(payload));
  }
});

The pagehide event fires both for bfcache-eligible and non-eligible navigations, making it a safe drop-in replacement. Chrome DevTools has a dedicated bfcache testing panel under Application > Back-forward cache that lists every blocker on the current page. Run it before and after your changes to verify eligibility. You can also check the notRestoredReasons property via the PerformanceNavigationTiming API to programmatically detect bfcache failures in production telemetry.

Sites that serve content through HTTP/3 connections benefit even more from bfcache because the protocol’s multiplexed streams close cleanly, reducing the chance of stale connection blockers.

Prefetching the Next Click with the Speculation Rules API

Traditional “ hints are static. You hardcode which resources to fetch, and the browser decides whether to honour the hint based on network conditions and memory pressure. The Speculation Rules API replaces this guesswork with a declarative JSON block that tells the browser exactly which URLs to prefetch or prerender, and how aggressively to do it.

{
  "prefetch": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": "/logout" } },
        { "not": { "href_matches": "/cart/*" } },
        { "not": { "href_matches": "/checkout/*" } }
      ]
    },
    "eagerness": "moderate"
  }]
}

The eagerness property controls timing. "moderate" starts prefetching when the user hovers over a link for 200ms – enough intent signal to avoid wasted bandwidth, fast enough to feel instant on click. "eager" fetches immediately on viewport entry (suitable for pagination links or prominent CTAs), while "conservative" waits for a mousedown or touchstart event, which is the safest option for bandwidth-constrained environments.

Choosing between prefetch and prerender depends on the target page’s complexity. Prefetch downloads the HTML and subresources but does not execute JavaScript or build the DOM. Prerender does both, giving you a truly instant transition, but it costs more memory and CPU. For content-heavy pages with minimal client-side logic, prerender is the better choice. For pages that run heavy JavaScript on load – a WooCommerce checkout, for instance – prefetch avoids unexpected side effects like duplicate analytics events or premature session creation.

WordPress sites can install the Speculative Loading plugin maintained by the WordPress Performance Team, which injects the speculation rules JSON automatically. The plugin defaults to moderate eagerness and prefetch mode, which is a sane baseline for most blogs and content sites. Custom themes can override these defaults by filtering the output through the plsr_speculation_rules filter hook.

Testing matters here. Speculation rules can trigger server-side events prematurely if your asynchronously loaded scripts include tracking pixels or session-dependent logic. Always verify on a staging environment that prefetched pages do not inflate analytics, fire conversion events, or cause layout shifts from dynamic ad injection when they finally render. Chrome’s chrome://speculation-rules-internals page shows active rules and their status in real time, which makes debugging much faster than checking network logs manually.

Connecting AI Agents to Chrome DevTools via MCP

Chrome DevTools MCP (Model Context Protocol) exposes browser internals to external AI agents through a standardised server interface. Instead of copying error messages from the console and pasting them into a chat window, MCP lets an AI agent read console output, inspect network requests, analyse performance traces, and even modify CSS or DOM elements – all inside the live browser session.

The setup requires running the DevTools MCP server locally. Your AI agent (Claude, Cursor, Gemini CLI, or any MCP-compatible client) connects to it and gains access to the same data you see in DevTools panels. The difference is that the agent can correlate errors across sources, trace the call stack through third-party scripts, and suggest fixes in context. This is particularly useful when debugging minified vendor code where manual source-mapping is tedious and error-prone.

# Install and start the DevTools MCP server
npx @anthropic-ai/devtools-mcp-server

# The server exposes a local endpoint your AI agent connects to
# Example: Claude Code connects via MCP configuration

A practical scenario: you notice a runtime error on a WooCommerce product page, but the stack trace points into a minified third-party script. Manually debugging this means source-mapping, reading through unfamiliar code, and guessing at state. With MCP, the AI agent reads the full execution context, identifies the failing condition, and proposes a patch – or applies one directly if configured with write access.

This approach is especially effective for diagnosing cache-related TTFB regressions where the issue only appears in production with warm caches. The agent can compare DevTools performance profiles from cached and uncached requests and pinpoint the bottleneck without you switching between browser tabs. Built-in AI assistance inside Chrome DevTools also helps outside of MCP: Gemini integration in the Console panel explains errors in plain language and suggests fixes, while the Performance panel can summarise trace data and highlight the most impactful bottlenecks.

CyberAgent, one of Japan’s largest web companies, reported fully automated error resolution using this exact MCP workflow.

Real Revenue Impact from These Features

Yahoo! JAPAN News implemented bfcache and measured a 9% increase in mobile ad revenue alongside 13% more page views per session. The speed improvement came entirely from eliminating back-button reload latency – no server changes, no CDN upgrades.

Netzwelt, a German tech news publisher, focused on Core Web Vitals optimisation (including bfcache eligibility) and saw an 18% jump in ad revenue with 27% more page views. Their approach combined bfcache fixes with script DOM reduction through selective script disabling on non-essential pages.

Monrif, an Italian publisher group, achieved an 8.9% engagement increase and 17.9% faster LCP after enabling bfcache. Ad creative loading on mobile improved by up to 17.1%, directly translating to higher viewability scores and CPMs. The pattern is consistent across all three case studies: faster navigations produce more page views, more ad impressions, and higher per-session revenue.

These numbers are not outliers. Every millisecond shaved from navigation time increases the probability that a user stays, scrolls, and sees an ad impression. The SEO benefits compound over time as improved Core Web Vitals scores feed into search ranking signals.

Deployment Checklist for WordPress Sites

Start with bfcache. Open Chrome DevTools, go to Application > Back-forward cache, and click “Test back/forward cache” on every major template (homepage, single post, archive, product page). Fix every listed blocker before moving to speculation rules.

Add the Speculative Loading plugin from the WordPress plugin repository. Activate it, keep the default moderate eagerness, and monitor your staging environment for 48 hours. Check Google Analytics real-time reports for ghost page views caused by prefetch requests hitting your tracking endpoints. If you spot inflated numbers, switch your analytics to use the pagehide event or the Beacon API instead of inline scripts that fire on DOMContentLoaded. For WooCommerce stores, exclude /cart/, /checkout/, and /my-account/* from speculation rules to avoid prefetching stateful pages that depend on session data.

For MCP-based AI debugging, install the DevTools MCP server on your development machine and connect it to your preferred AI coding assistant. Run a Lighthouse audit through the agent and let it propose fixes for any flagged performance or accessibility issues. Review the suggestions, apply them on staging, measure the delta, and ship.

The pattern across all three features is the same: remove friction between the user and the content they came for.

Често задавани въпроси