Hitting sub-second load times takes more than basic Core Web Vitals fixes. The most effective advanced techniques are prefetching and prerendering with the Speculation Rules API, optimizing for the back/forward cache (bfcache), upgrading to HTTP/3, deploying edge caching through a CDN, and using multi-layer caching. Together, these can make repeat and predicted navigations feel near-instant.
Most teams stop optimizing once their Core Web Vitals turn green. That’s a fair milestone—Largest Contentful Paint under 2.5 seconds is a solid baseline. But “good enough” and “instant” are two very different experiences, and the gap between them is where conversions and rankings are won or lost. Every 100 milliseconds of added latency can cost an e-commerce site 1% in sales, which means the difference between a 2-second page and a 1-second page is far from cosmetic.
Sub-second load times represent the next frontier. They demand a deeper layer of techniques that go beyond compressing images and minifying scripts—the kinds of strategies that shape how you approach website development from the architecture up. The good news is that the browser platform has matured dramatically, with new APIs and protocols that make near-instant navigation achievable without exotic infrastructure.
This guide assumes you’ve already nailed the fundamentals: passing Core Web Vitals, serving modern image formats, and using a content delivery network. From there, it walks through the advanced techniques that close the gap between “fast” and “instant”—predictive loading, browser caching tricks, protocol upgrades, and edge strategy. Each section explains what the technique does, why it works, and when to reach for it.
Why aren’t good Core Web Vitals enough for sub-second speed?
Core Web Vitals set a floor, not a ceiling. Google’s “good” LCP threshold is 2.5 seconds—a respectable target, but a full 1.5 seconds slower than a sub-second experience. Passing the assessment proves your site isn’t broken; it doesn’t prove your site is fast.
The numbers explain why the extra effort pays off. Pages that load in under two seconds see a 9% bounce rate, while pages taking five seconds watch that figure climb to 38%—roughly four times as many people leaving before the content appears. On mobile, 53% of users abandon sites that take longer than three seconds. Shaving load time from two seconds to under one doesn’t just polish the experience; it directly protects revenue and rankings.
There’s also a ceiling problem baked into the metrics themselves. LCP can never be faster than your Time to First Byte, and INP depends entirely on how your JavaScript behaves during interactions. To break past “good” into “instant,” you have to attack latency at the network, browser, and architecture levels at once.
How does the Speculation Rules API deliver near-instant navigation?
The Speculation Rules API is the single most powerful tool for sub-second navigation between pages. It lets you tell the browser to prefetch or prerender pages a user is likely to visit next, so the destination is ready before they click. When prerendering works, the next page appears instantly—the load time the user perceives is effectively zero.
The API targets full document URLs rather than individual resource files, which makes it well suited to multi-page sites. You define rules in a small block of JSON, either listing specific URLs or letting the browser decide which links to speculate on based on user behavior, like hovering over or starting to tap a link.
A layered approach works best. Prerendering offers the biggest payoff but consumes the most resources, so reserve it for high-confidence predictions—the “next” button in a paginated article, or the top result on a search page. Use lighter prefetching more broadly for links a user might plausibly follow. This balance, recommended by performance engineers like Harry Roberts of CSS Wizardry, gives you instant navigation where it matters most without wasting bandwidth on pages nobody visits.
Choose prerendering when you can reliably predict the next page and the destination is safe to load early (no side effects like logging the user out). Choose prefetching when the prediction is weaker but you still want a head start on the download.
What is bfcache and how do you keep your pages eligible?
The back/forward cache—bfcache—stores a complete, in-memory snapshot of a page when a user navigates away. When they hit the back or forward button, the browser restores that snapshot instantly instead of reloading from scratch. A bfcache hit is one of the fastest experiences the web can offer, because nothing is re-downloaded, re-parsed, or re-executed.
The catch is that certain coding patterns silently disqualify your pages. The most common offender is a Cache-Control: no-store header, which tells the browser not to keep the page in memory at all. The legacy unload event listener is another frequent culprit, since browsers can’t safely cache a page that expects to run cleanup code on exit.
To maximize bfcache eligibility, audit your pages in Chrome DevTools, which reports exactly why a page was rejected. Replace unload listeners with the modern pagehide and visibilitychange events. Avoid no-store on pages that don’t contain sensitive, per-request data. These changes cost little and make a huge share of your repeat navigations effectively instant—a benefit that also feeds into stronger Core Web Vitals scores, since bfcache restores count as fast loads.
Should you upgrade to HTTP/3?
HTTP/3 is the latest version of the protocol that carries web traffic, and it offers a meaningful speed advantage over HTTP/2—especially on mobile and unreliable networks. It runs on QUIC, a transport built on UDP that eliminates the head-of-line blocking that can stall HTTP/2 connections when a single packet is lost.
The practical benefit shows up most on the connections where users are least patient: spotty cellular, congested public Wi-Fi, and high-latency international routes. Because QUIC combines the connection and security handshakes, it establishes connections in fewer round trips, trimming the delay before any content can start flowing.
For most sites, enabling HTTP/3 is straightforward. Major CDNs—Cloudflare, AWS CloudFront, and others—support it with a configuration toggle rather than a code change. If your audience skews mobile or international, this is one of the lowest-effort wins available, since the protocol does the work for you once it’s switched on.
How does edge computing reduce latency at the source?
Physical distance creates latency that no amount of code optimization can erase. A user in Australia connecting to a server in New York waits 200–300 milliseconds for data just to make the trip—before a single byte of content renders. Edge strategy attacks this problem by moving content closer to the user.
A content delivery network caches your static assets on servers worldwide, so visitors connect to the nearest node instead of your origin. The impact is immediate: international visitors routinely see 50–70% faster load times once a CDN is in place. Cloudflare’s free tier delivers most of this benefit with little more than a DNS change, which makes it an easy starting point for almost any site.
Edge computing pushes the idea further by running logic—personalization, redirects, A/B test assignment, even rendering—at the edge rather than the origin. This keeps Time to First Byte low even for pages that need dynamic behavior, removing the round trip to a distant central server. For sub-second targets, a low and consistent TTFB at the edge is foundational, because every other metric inherits that head start.
What does a multi-layer caching strategy look like?
Caching is the highest-leverage technique for repeat performance, and the strongest setups stack several layers. A first-time visitor might wait three seconds for a page, while a properly cached return visit loads the same page in half a second—a 3–5x improvement for minimal effort.
A complete strategy works across four levels:
- Browser caching stores static assets on the visitor’s device. Set long cache lifetimes—up to a year for images, fonts, CSS, and JavaScript—and use file versioning so updates still propagate.
- CDN caching keeps copies of your assets on edge servers worldwide, cutting the distance data must travel for every visitor.
- Server-side caching stores fully rendered HTML so dynamic sites skip database queries and template processing on each request. Tools like Redis and Memcached handle this efficiently.
- Database query caching stores the results of expensive queries that don’t change often, removing a common bottleneck on data-driven sites.
The principle is simple: never do the same work twice. Each layer you add removes a category of repeated effort, and the combined effect is what makes return visits feel instantaneous.