A Double Victory for Web Speed: Chrome Breaks Records Again on Speedometer 3.1 and Jetstream 3

Performance is a core principle for Chrome. A faster browser directly translates to a better web experience, whether you’re loading a complex interactive web application or simply navigating a news article. To ensure our optimizations reflect real-world usage, we rely heavily on industry benchmarks like Speedometer and JetStream. By continuously driving improvements across our browser stack, we deliver continual wins so our users can better enjoy what the web has to offer.

Over the past year, our engineering teams have tackled a series of major projects to elevate our JetStream 3 and Speedometer 3.1 scores. Since just the start of this year, we’ve improved Chrome’s score on JetStream by 10% resulting in a record score of 469. In addition we improved Speedometer by 5% since our last blog post on benchmark performance about a year ago, resulting in a dual record across all browsers of 61. Both results were measured on a MacBook Pro M5 running MacOS 26.0.1. These wins directly translate into a meaningfully faster experience for our users.

Here is a deep dive look across three areas on how Chrome got faster.

JavaScript

Having fast JavaScript is at the heart of making a performant user experience and we’ve focused the majority of our optimizations here.

JavaScript relies heavily on built-in functions, which implement the JavaScript language specification to the letter, but often we only need a small part of this built-in functionality for common paths. We focused on inlining "fast paths" in the optimizing compiler for these common cases, allowing the engine to skip unnecessary execution steps. The largest impact came from inlining async operations, such as microtask dispatch and await resolution; we applied similar fast-path inlining techniques to sorting data and comparing strings, yielding highly significant speed gains across a wide variety of daily tasks. We have plenty more projects here that will be coming soon.

We've also done work on improving our heuristics of what JavaScript code to optimize and when. Optimization of JavaScript functions is a careful trade-off; we want to optimize functions so that they run faster, but this optimization takes time itself and we want to make sure we only do it if it's worth it. We improved the behaviour of async and generator functions to allow them to optimize earlier when running many of them in parallel, and we adjusted our reasoning around cross-function inlining to take into account what sorts of objects we're passing between functions, and boosted the inlining when it allowed us to reduce engine-internal allocations.

Finally, every new benchmark exposes new things that we haven't looked at before — that's why we work so hard on benchmark development. The recently released JetStream 3 exposed some missing optimizations in our BigInt handling, and a series of projects improved BigInt division, canonicalisation, and while we were at it, we changed how the data structures are allocated to also improve security in our sandbox.

WebAssembly

Thanks to our previous efforts on improving WasmGC performance through load and null-check elimination and speculative inlining of indirect function calls with deoptimization support, we already achieved great performance on many of the new line items. By investigating the latest iteration of the JetStream benchmark we’ve managed to land several further improvements to how Chrome handles WebAssembly workloads.

While digging into the new JetStream WebAssembly line items, we made improvements to how V8 manages internal data structures. We optimized code generation for SIMD instructions and register allocation that led to sizable performance improvements for AI, cryptography and interpreter use cases. And by reusing previously-used temporary memory in the compiler more efficiently, we improved compilation speed in certain scenarios significantly.

Additionally, we looked into reducing the overhead of function calls from JavaScript to WebAssembly. We now eliminate repeated type conversions and loads within loops more effectively. This was achieved by making the function call code integrate better with already existing optimizations which enables V8 to better inspect and remove unnecessary conversions.

Rendering engine

A browser is only as fast as its ability to display content on your screen. To make web pages feel more responsive, we made significant upgrades to the rendering engine (called Blink), focusing on style computation, DOM operations, and text processing.

To optimize style resolution and DOM interactions, we implemented smarter caching and streamlined lookup paths. We deployed a unified querySelector() cache across the rendering engine to cut down on redundant DOM lookups. Furthermore, we optimized element attribute handling by introducing a fast bailout path that skips unnecessary checks when attributes aren't present, and we began caching dataURI resources beyond the scope of a single document—which boosted performance for modern web frameworks. Finally, we reduced style recalculation delays for transitions and simplified how we cache and match CSS selectors to keep animations consistently fluid.

We also addressed foundational page-loading and text-processing performance. Since a significant portion of a page's initial load is spent parsing HTML and manipulating text, we leveraged SIMD (Single Instruction, Multiple Data) operations to make string copying significantly more efficient. In addition, we optimized string creation directly within our HTML fast-path parser, which reduces the time and overhead required to construct DOM elements from raw text when first loading a site.

Alongside style and loading optimizations, we resolved critical performance bottlenecks in typography and vector graphics rendering. We completed Apple Advanced Typography (AAT) shaping optimizations and fixed multiple font fallback issues, while simultaneously eliminating costly heap allocations during glyph width calculations. To accelerate the drawing of complex graphics, we introduced a cache to speed up SVG processing. Behind the scenes, we also streamlined DOM storage structures, reducing memory overhead and making fundamental page layouts lighter and more efficient.