Why Chrome Is Faster Than Ever: V8, Blink, and WebAssembly Overhauled

Chrome posted record scores on two industry-standard browser benchmarks this week, and the numbers themselves are almost beside the point. What's more interesting is the engineering work behind them a coordinated overhaul spanning three separate subsystems that reveals how much the browser's job has changed.

Google's JetStream 3 score climbed 10% since the start of 2026 to reach a record 469, while its Speedometer 3.1 score rose 5% year-over-year to hit 61, according to the Chromium Blog. Google says both scores represent a high-water mark across all browsers. The gains came from work across V8 (JavaScript execution), Blink (rendering), and the WebAssembly runtime running in parallel, not from a single optimization pass. Both results were measured on a MacBook Pro M5 running macOS 26.0.1 worth keeping in mind when evaluating the "fastest ever" framing.

All performance claims here originate with Google. No third-party benchmark validation is present in the current source record.

What Speedometer and JetStream actually measure

The methodology matters here, especially given the source. Speedometer is a collaborative industry standard maintained by all major browser engine developers not a Google-proprietary test. Its scores carry a strong statistical correlation of -0.8 with 99th-percentile interaction latency measured against real users in the field, Google reported about two months ago. That correlation is what allows the company to argue benchmark improvements translate into something users can feel.

JetStream 3, released about two months ago, was built to reflect high-performance, compute-heavy web applications. Every included workload must represent a real, end-to-end use case rather than a synthetic microbenchmark, according to Google's benchmark introduction. WebAssembly workloads now make up 15-20% of the suite, more than double the 7% share they held in JetStream 2, with coverage expanded to include Wasm compiled from Java, Dart, Kotlin, Rust, and C#. That expansion is why Chrome needed changes across all three engines, not just one: Speedometer stressed the JavaScript layer, while JetStream 3's heavier Wasm profile forced a different kind of work entirely.

Chrome performance overhaul: what changed in V8, Blink, and WebAssembly

V8: fewer detours through the JavaScript engine

The core logic behind V8's gains is straightforward. JavaScript built-ins implement the language specification completely, but most real-world code only ever needs a fraction of that behavior. Google's engineers focused on inlining "fast paths" in the optimizing compiler shorter routes through common operations that let the engine skip execution steps the full spec path would require.

The biggest single source of gains came from inlining async operations, specifically microtask dispatch and await resolution. Google applied the same fast-path approach to array sorting and string comparisons. Think of it like a kitchen that has memorized the three combinations that cover 80% of orders: the full menu still exists, but most requests never reach it. Async and generator functions were also reworked to optimize earlier when running many in parallel, and cross-function inlining was adjusted to account for what object types move between functions prioritizing inlining when it reduced internal allocations, the company says.

JetStream 3's newer workloads surfaced gaps in BigInt handling. Google addressed these by improving BigInt division and canonicalization, then restructured the associated memory allocations in a way that also tightened sandbox security a case where the performance fix and the security improvement pointed in the same direction, according to the same post.

The practical effect: faster execution of async JavaScript, the kind that powers interactive web apps, form handling, and framework-rendered interfaces. Applications running many concurrent async operations should see the most benefit, though Google has not published field data specifically quantifying this for desktop users.

Blink: rendering changes users will actually feel

"A browser is only as fast as its ability to display content on your screen," Google writes. The Blink changes operationalize that. The pattern running through all of them is the same: eliminate repeated lookups and recalculations that were being triggered on every interaction, every animation frame, or every page load.

Chrome deployed a unified querySelector() cache across the rendering engine to cut redundant DOM lookups. Modern front-end frameworks call this method repeatedly, so reducing the overhead compounds across every interaction. Element attribute handling gained a fast bailout path that skips unnecessary checks when attributes are absent, and Chrome began caching dataURI resources beyond the scope of a single document a change Google specifically flags as a boost for modern web frameworks, per the announcement.

HTML parsing and initial page construction also got faster through two related changes. SIMD operations now handle string copying more efficiently during the parse phase, and string creation was optimized inside the fast-path HTML parser itself, cutting the overhead of converting raw markup into DOM elements on first load. On the visual side, style recalculation delays for CSS transitions were reduced, selector caching was simplified to keep animations fluid, SVG rendering gained a dedicated cache, and DOM storage structures were simplifyd to reduce memory overhead on basic layouts, Google says.

The cumulative effect: pages appear faster on first load, framework-driven interfaces respond more quickly to interaction, and animations run with less stutter. Text-heavy pages also benefit from font shaping optimizations and reduced heap allocations during glyph width calculations.

WebAssembly: what the Wasm changes signal about where browsers are headed

The Wasm work is the most forward-looking part of the overhaul. It is not primarily about faster page loads. It is about the browser becoming a credible execution environment for workloads AI inference, cryptography, compiled application runtimes that until recently required native apps.

Chrome improved SIMD instruction code generation and register allocation for WebAssembly workloads, with measurable gains for AI, cryptography, and interpreter-style applications, Google says. Compiler memory reuse was improved to cut compilation time in specific scenarios, and the engine now eliminates repeated type conversions and redundant loads inside loops more effectively. Prior WasmGC work load and null-check elimination, speculative inlining of indirect function calls had already laid groundwork on several JetStream 3 workloads; this round built on that foundation.

The benchmark itself tells the same story. JetStream 3 added 12 new Wasm workloads because its predecessor underrepresented them, and expanded toolchain coverage to include Java, Dart, Kotlin, Rust, and C# compiled to Wasm, according to the benchmark introduction. Scoring well on it now requires competence at things browsers barely attempted five years ago.

What the gains mean in practice and what remains unproven

The most direct evidence that Chrome's benchmark improvements translate into real-world changes comes from Android, where Google has visibility into field data. Benchmark gains of 20-60% year-over-year on newer flagship phones corresponded to page loads that are 4-6% faster and high-percentile interactions that are 6-9% faster for real users, the company reported about two months ago. Google attributes part of this to deep integration across Android hardware, the operating system, and the Chrome engine an advantage desktop Chrome does not have to the same degree.

For desktop, the position is narrower. Google says the benchmark wins "directly translate into a meaningfully faster experience," but the scores were measured on a MacBook Pro M5, and the company has not published field data tying this week's desktop results to real-world latency improvements for mainstream users. That gap is worth noting, not because the improvements are implausible, but because the Android evidence is the stronger link in the chain.

The arc here stretches back years from RenderingNG in 2021 through 2023 performance work to this week's announcement. This looks less like a sprint and more like an ongoing architectural commitment. The record scores are real. Whether they feel as significant on a mid-range laptop as they do on an M5 MacBook is the question independent testing would need to answer.