8 Tech Ideas That Made the Web Move Quicker

Internet connections in 2010 were slower than today's, but not fifty times slower. Yet the web feels fifty times faster. Pages that once took eight seconds now render in under one. Video calls survive the walk from Wi-Fi to mobile data. Applications as demanding as Figma run comfortably inside a browser tab. Bandwidth alone cannot explain that gap. Ideas can.

The web got quicker because a handful of engineers refused to accept limits the rest of the industry treated as permanent  physics included. What follows are eight of those ideas, arranged in the order they attack the problem: distance first, then the browser, then the protocols underneath, then the payload itself, and finally the servers.

1. CDNs: When Physics Won't Move, Move the Content 

Light inside optical fiber travels at roughly 200,000 km per second  about two-thirds of its speed in a vacuum. That sounds fast until the math is applied to a request from Sydney to a server in New York: around 16,000 km each way, meaning a single round trip consumes 160 milliseconds before a single line of code executes. No amount of server tuning fixes that. It is a hard floor set by the universe.

In the mid-90s, Tim Berners-Lee, the inventor of the web itself, posed this congestion problem to researchers at MIT. A mathematician named Tom Leighton and his graduate student Danny Lewin answered it with algorithms for distributing content across a mesh of servers, and in 1998 that answer became a company: Akamai. The idea was almost insultingly simple. If the speed of light is fixed, shorten the trip. Replicate content across hundreds of locations and serve every visitor from the nearest one.

Today the model is invisible infrastructure. Cloudflare alone operates in more than 300 cities. A viewer streaming a cricket match in Delhi is almost certainly pulling video segments from a cache a few kilometers away, not from the broadcaster's origin server. The 160ms Sydney problem collapses into a 5ms local hop.

The economics matters as much as physics. Serving a byte from a nearby cache costs a fraction of hauling it across a backbone, which is why CDNs went from a luxury for large media companies to a feature bundled free with budget hosting plans. Lewin never saw the industry he co-created mature; he was killed aboard American Airlines Flight 11 on September 11, 2001, at age 31, widely believed to be the first victim of that day.

CDNs open this list for a structural reason: every idea that follows assumes they exist. Nobody optimizes a protocol handshake to save 50ms while the content is still crossing an ocean.

2. JIT Compilation: The Day JavaScript Stopped Being a Toy 

A fact that sounds wrong: for its first thirteen years, JavaScript was interpreted line by line, every single time it ran. Brendan Eich famously designed the language in ten days in 1995, and browsers treated it accordingly as a scripting toy for form validation and mouseover effects. Building serious software in it bordered on punishment.

That era ended on September 2, 2008, when Google shipped Chrome with the V8 engine, built by a team under Lars Bak, a virtual-machine veteran with a background in high-performance Smalltalk and Java runtimes. V8 attempted what browsers had never seriously tried: compiling JavaScript directly to machine code, on the fly, while the page ran. Hot functions executing thousands of times  were aggressively optimized based on runtime behavior the engine observed live.

The performance jump was not 20 or 30 percent. On computation-heavy benchmarks, early V8 ran JavaScript roughly ten times faster than the interpreters it replaced, and the gap widened with each release. More consequentially, it triggered an arms race:

● Mozilla answered with TraceMonkey in Firefox 3.5, its first JIT-enabled engine

● Apple responded with SquirrelFish Extreme (later Nitro) in Safari

● Microsoft eventually rebuilt around the Chakra engine for IE9

Within two years, shipping a browser without a JIT compiler meant losing benchmark headlines weekly. The practical consequence is the modern web application. Google Docs, Gmail, Figma, Canva, browser-based video editors  none are viable on an interpreted engine. When commentators say "the browser became an operating system," V8 marks the moment that claim became technically true rather than a slide-deck metaphor.

V8 deserves a bookmark here, because it makes a surprise second appearance at the end of this list.

3. HTTP/2 and HTTP/3: Fixing the Queue, Then Firing the Postman 

For most of the web's life, HTTP/1.1 (finalized in 1997) carried a traffic problem in its design: one connection handled one request at a time. A modern page needs 70-plus resources, so browsers worked around the limit by opening six parallel connections per domain, while developers stacked hacks on top  sprite sheets, domain sharding, inlined assets. Requests still queued behind each other, a condition engineers call head-of-line blocking. One slow image stalled everything behind it.

HTTP/2, standardized in 2015 and built on Google's SPDY experiments, fixed the queue. Multiplexing allowed a single connection to carry dozens of streams simultaneously, while HPACK header compression eliminated the redundant bytes browsers had been resending with every request.

One bottleneck survived, and it sat below HTTP entirely: TCP itself. When a single TCP packet went missing, the operating system froze every stream on the connection until retransmission completed. The queue vanished at the HTTP layer and was reborn at the transport layer.

Google's response was to route around TCP altogether. Engineer Jim Roskind began sketching a UDP-based transport in 2012, initially as a side experiment. That experiment became QUIC, and QUIC became the foundation of HTTP/3, published as RFC 9114 in June 2022. The redesign delivered three structural wins:

● Per-stream loss recovery  a lost packet stalls only its own stream, not the entire connection

● A merged handshake  transport setup and TLS encryption negotiate in a single round trip

● Connection migration  sessions are identified by a connection ID rather than an IP address, which is why a video call on an HTTP/3 service survives the switch from home Wi-Fi to mobile data without a hiccup

Adoption, however, tells an honest story. As of mid-2026, Cloudflare Radar data places HTTP/3 at roughly 21% of real traffic, with HTTP/2 carrying about half and a stubborn quarter still on HTTP/1.1  largely bots, corporate proxies, and legacy middleboxes. Protocol revolutions are real, but they move at the speed of the slowest firewall appliance.

4. TLS 1.3: The Upgrade That Made Security Free 

Encryption used to be a speed tax, and the entire industry priced it in. Through the 2000s, serving a site over HTTPS meant extra server load and, worse, extra round trips: the TLS 1.2 handshake required two full round trips of negotiation before the first byte of content could move. On a mobile connection with 100ms latency, that meant 200ms of pure ceremony, paid on every new connection. Plenty of site owners skipped HTTPS for precisely this reason, and for years the trade-off looked defensible.

TLS 1.3  finalized as RFC 8446 in August 2018 after a bruising four-year, 28-draft process at the IETF  deleted the trade-off. The redesign cuts the handshake to a single round trip: the client predicts the key-exchange method and transmits its half of the keys immediately, rather than politely asking what the server supports first. For returning visitors, 0-RTT resumption goes further, sending encrypted application data in the very first packet using keys remembered from the previous session.

The cleanup extended beyond speed. TLS 1.3 amputated every legacy cipher that had produced a decade of named vulnerabilities  RC4, static RSA key exchange, and the CBC constructions behind attacks like POODLE and Lucky13. The protocol got faster because it got simpler, a rarer combination in engineering than it ought to be.

The result reshaped the web's defaults. HTTPS moved from a checkout-page luxury to the baseline for effectively all meaningful traffic, and Chrome now flags plain HTTP as the anomaly worth warning about. Paired with the previous idea, this forms the modern stack: QUIC embeds TLS 1.3 directly in its transport handshake, so security and connection setup together cost one round trip. What was once a tax became a rounding error.

5. Smarter Compression: Brotli and the War on Page Weight 

Ask what the heaviest element on a web page is, and the answer has held steady for fifteen years: images. HTTP Archive's Web Almanac consistently reports median page weight above 2 MB, with images claiming the largest share by a wide margin. The least glamorous speed work of the past decade accordingly happened here, in the unfashionable trenches of compression research, along two fronts.

Text got Brotli. Gzip had served as the web's compressor since the early 90s and was showing its age. In 2015, Google engineers Jyrki Alakuijala and Zoltán Szabadka released Brotli, which pairs modern context modeling with a built-in 120 KB dictionary of strings common in web content  HTML tags, CSS properties, JavaScript keywords. On typical text assets it compresses 15-20% smaller than gzip at comparable settings. That sounds incremental until multiplied across every stylesheet and script bundle on every page load on Earth. Every major browser and CDN now supports it, and most serve it silently.

Images got new codecs. WebP (2010) trimmed 25-30% off JPEG sizes at equivalent quality. AVIF  derived from the royalty-free AV1 video codec and supported across major browsers from roughly 2021-2024  routinely cuts 40-50% versus JPEG, handling gradients and low-light photography especially well.

A 400 KB hero image becoming 180 KB  at a quality no viewer can distinguish  is the category of win users never see and always feel. The quiet lesson: no connection got faster here. The payload got lighter, which achieves the same result and costs the audience nothing.

6. BBR: Teaching the Internet to Stop Driving by Crashing 

This is the entry on this list least likely to have appeared in anything else the average reader has encountered  and it touches nearly every byte Google delivers.

For roughly thirty years, TCP decided how fast to send data using loss-based congestion control: push harder until packets start dropping, back off sharply, then ramp up and crash again. It is the algorithmic equivalent of measuring a hallway's width by walking into the walls. The approach made sense in the 1980s, when packet loss genuinely signaled an overflowing router buffer. On modern networks it fails in two opposite directions:

● Wireless links drop packets randomly, for reasons unrelated to congestion, causing loss-based TCP to slow down exactly when it shouldn't

● Deep router buffers absorb overload silently, so TCP keeps stuffing them, inflating latency for everyone sharing the link  the disease known as bufferbloat

In 2016, a Google team including Neal Cardwell and Van Jacobson  the same Van Jacobson who rescued the internet from congestion collapse in the 1980s  published BBR: Bottleneck Bandwidth and Round-trip propagation time. The philosophical shift is the entire story. Instead of probing until failure, BBR continuously measures two quantities: the actual bottleneck bandwidth of the path and the true round-trip time  and paces transmission to match what the path can genuinely carry. No crashing into walls. Just a live model of the hallway.

Google's published deployment numbers were startling. After switching YouTube to BBR, the company reported around 4% higher throughput globally, with gains exceeding 14% in some countries, alongside meaningful drops in rebuffering. On its private B4 backbone, Google measured throughput improvements of up to 2,700x on lossy long-haul links, because BBR simply refuses to interpret random loss as a stop sign.

BBR now ships in the Linux kernel and drives traffic at Google and, increasingly, elsewhere. No user will ever see a setting for it. Downloads just stopped stuttering.

7. Speculative Loading: The Browser That Reads Minds 

What if the fastest page load is the one that finished before the click?

The question has a longer history than most developers realize. The first answers arrived quietly in the 2010s as resource hints  small declarations in a page's head section that tip off the browser:

● dns-prefetch resolves a domain's IP address early, saving a lookup later

● preconnect goes further, completing the TCP and TLS handshake to a domain the page will soon need

● prefetch downloads a resource for the next navigation during idle time

● preload fetches something critical for the current page that the parser would otherwise discover late  a font buried inside a CSS file, for instance

These were useful but conservative: they warmed the machinery without committing. The aggressive version arrived in 2024, when Chrome shipped the Speculation Rules API. A site can now declare, in a small JSON block, which links should be prerendered, fully fetched, parsed, and executed in a hidden background context before the user clicks. On click, the browser simply swaps the finished page into view. Perceived load time: effectively zero milliseconds. Chrome performs a version of this automatically for the address bar, prerendering the top suggestion when confident about the destination, which is why typing a familiar URL often lands instantly.

The obvious objection is waste  prerendering pages nobody visits burns bandwidth and server capacity. The API therefore ships with eagerness levels, ranging from "prerender immediately" down to "wait until the pointer hovers over the link," which alone signals intent a few hundred milliseconds before the click. Libraries had validated the concept years earlier with hover-triggered prefetching, and the pattern reliably makes multi-page sites feel native.

Every previous idea on this list makes loading faster. This one makes loading disappear  and it is the clearest signal of where browser engineering is heading: from reacting to predicting.

8. Edge Compute: The Punchline V8 Was Setting Up All Along 

The bookmark from idea #2 pays off here. By 2017, CDNs had solved distance for content, but application logic still lived in a handful of centralized cloud regions. A cached homepage arrived from 10 km away; the API call that personalized it still crossed a continent. The obvious fix  running code inside the CDN's hundreds of locations  carried a fatal economics problem: containers and virtual machines are heavy. Cold-starting one consumes hundreds of milliseconds and a meaningful slice of memory. Multiplied across thousands of customers and 300 cities, the model collapses.

Cloudflare's answer, shipped as Workers in 2017 by a team led by Kenton Varda, skipped containers entirely and reached for V8 isolates  the same sandboxing primitive Chrome uses to keep browser tabs from reading each other's memory. An isolate is a featherweight security boundary inside a single process. It starts in about 5 milliseconds and consumes a fraction of a container's footprint, meaning one machine can safely execute code from thousands of different customers  and that code can exist in every city simultaneously. Deno Deploy and Vercel's Edge Functions followed into the same territory, while Fastly took a parallel path through WebAssembly.

The elegant part is the full circle. A JavaScript engine built in 2008 to make browsers fast ended up, a decade later, making servers fast enough to vanish into the network itself. The dreaded serverless cold start  a multi-second embarrassment on early cloud platforms  dropped below the threshold of human perception.

The practical result: authentication checks, A/B tests, geolocation logic, personalization, and API routing now routinely execute a few milliseconds from the user, before a request ever considers crossing an ocean. Distance  the problem that opened this list  got solved a second time, for logic instead of files.

All Eight at a Glance

The Verdict: Speed Is a Series of Surrenders

Line these eight ideas up and a pattern emerges that has nothing to do with raw horsepower. Nearly every one is a story of surrendering to a limit, then routing around it. Akamai surrendered to the speed of light and moved the content. QUIC surrendered to TCP's unfixable design and rebuilt on UDP. BBR abandoned the fantasy that packet loss means congestion and started measuring reality instead. Brotli and AVIF accepted that connections weren't getting faster and shrank the cargo. Speculation rules accepted that loading takes time and simply moved it before the click.

Brute force, more bandwidth, bigger servers  was never the interesting answer, and the numbers prove it: median connection speeds grew perhaps fivefold over the past decade while perceived web speed improved far beyond that multiple.

Which makes the next leap predictable in shape, if not in detail. It won't come from 6G. It will come from an engineer staring at a limit the rest of the industry treats as a law of nature: the DNS lookup, the render pipeline, the last unpredictable click  and quietly deciding it is optional. The web never got faster by pushing harder. It got faster by thinking sideways.