# the fast and the curious Published articles for the fast and the curious. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## JetStream 3: A modern benchmark for high-performance, compute-intensive Web applications DevFeed: [JetStream 3: A modern benchmark for high-performance, compute-intensive Web applications]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2026-03-31T18:25:00Z Content type: release Language: en Sources: [Chromium Blog]() Topics: [jetstream](), [Benchmark](), [benchmarking](), [Web](), [web applications]() Tags: [benchmark](), [benchmarking](), [browser](), [jetstream](), [none](), [the-fast-and-the-curious](), [web](), [web-applications]() ### AI overview This article introduces JetStream 3, a benchmark for high-performance, compute-intensive Web applications. It explains the benchmark's methodology, the reasons for updating JetStream 2, and the collaborative governance involving major browser-engine contributors. ### Source excerpt We're incredibly excited to announce the release of JetStream 3, built in close collaboration with Apple, Mozilla, and other partners in the web ecosystem! While we've covered the high-level details of this release in our shared announcement blog post, we wanted to take a moment here to dive a little deeper. In this post, we'll pull back the curtain on the benchmark itself, explore the methodology behind our choices, and share the motivations driving these major updates. Why Do We Benchmark, Anyway? Before we get into the "what," it helps to talk about the "why." Why do browser engineers care so much about benchmarks? At its core, benchmarking serves as a critical safety net for catching performance regressions before they ever reach users. But beyond that, benchmarks act as a powerful motivation function--a sort of "gamification" for browser engineers. Having a clear target helps us prioritize our efforts and decide exactly which optimizations deserve our focus. It also drives healthy competitiveness between different browser engines, which ultimately lifts the entire web ecosystem. Of course, the ultimate goal isn't just to make a number on a chart go up; it's to meaningfully improve user experience and real-world performance. Driven by Open Governance Just like Speedometer 3, JetStream 3 is the result of a massive collaborative effort across all major browser engines, including Apple, Mozilla, and Google. We adopted a strict consensus model for this release. This means we only added new workloads when everyone agreed they were valuable and representative. This open governance model has led to an incredibly productive collaboration with buy-in from multiple parties, ensuring the benchmark serves the best interests of the overall Web ecosystem. Ripe for an Update The last major release, JetStream 2, came out in 2019. In the technology space--and especially on the Web--six years is an eternity. There's a well-known concept in economics called Goodhart's Law, which stat ## Android Sets New Record for Mobile Web Performance DevFeed: [Android Sets New Record for Mobile Web Performance]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2026-03-25T17:01:00Z Content type: news Language: en Sources: [Chromium Blog]() Topics: [web applications]() Tags: [android](), [benchmarks](), [browser](), [chrome](), [latency](), [mobile](), [none](), [performance](), [the-fast-and-the-curious](), [user-experience](), [web]() ### AI overview Android reports record mobile web-browsing performance on flagship devices, citing Speedometer and LoadLine benchmarks. The article explains that responsiveness and page-load speed are central to the Android web experience. ### Source excerpt A core part of the Android experience is the web. Whether you are browsing in Chrome or using one of the >90% of Android apps that utilize WebView, the speed of the web defines the speed of your phone. Today, we are proud to celebrate a major milestone: Android is now the fastest mobile platform for web browsing. Through deep vertical integration across hardware, the Android OS, and the Chrome engine, the latest flagship Android devices are setting new performance records, outperforming all other mobile competitors in the key web performance benchmarks Speedometer and LoadLine and providing a level of responsiveness previously unseen on mobile. Android flagship phones reach new high-scores in web performance benchmarks (Chrome 146, March 2026) Why web performance matters Web performance isn't just about high scores--it's about how your device feels every day. On Android, web content and its performance is central to the user experience. Whether searching for information, catching up on the latest news, or online-shopping, Android users spend a significant portion of their daily screen time interacting with web content. Chrome is one of the most popular Android apps in the US and worldwide. Furthermore, this usage increases sharply on tablets and foldables, where productivity use cases are key. While the web is clearly important, a great web experience necessitates a fast browser and device: Modern websites are highly complex, with more than 200 million active sites serving everything from blog posts with dynamic ad auctions to desktop-class productivity tools. This complexity makes for a demanding workload that can stress even powerful devices. To ensure a high-quality user experience, we focus on two critical pillars when evaluating web performance: responsiveness and page load speed. Speedometer: Measuring web responsiveness Speedometer is the collaborative industry standard used by all major browser engine developers to measure web app responsiveness. It simulates ## Introducing Skia Graphite: Chrome's rasterization backend for the future DevFeed: [Introducing Skia Graphite: Chrome's rasterization backend for the future]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-07-08T17:46:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [GPU](), [Interaction to Next Paint](), [browser](), [OpenGL](), [shaders](), [Web](), [glsl]() Tags: [chrome](), [gpu](), [graphics](), [graphics-apis](), [interaction-to-next-paint](), [multithreading](), [none](), [performance](), [render](), [screen](), [shaders](), [the-fast-and-the-curious](), [vulkan](), [web]() ### AI overview The article introduces Skia Graphite, a new GPU rasterization backend for Chrome on Apple Silicon Macs. Graphite uses fewer code paths, supports modern graphics APIs such as Metal, Vulkan, and D3D12, and is multithreaded by default. It improved Motionmark 1.3 scores by almost 15% on a MacBook Pro M3 and improved several real-world performance metrics. ### Source excerpt Today's The Fast and the Curious post covers the launch of Skia's new rasterization backend, Graphite, in Chrome on Apple Silicon Macs. Graphite is instrumental in helping Chrome achieve exceptional scores on Motionmark 1.3 and is key to unlocking a ton of future improvements in Chrome Graphics. A brief history of Skia in Chrome In Chrome, Skia is used to render paint commands from Blink and the browser UI into pixels on your screen, a process called rasterization. Skia has powered Chrome Graphics since the very beginning. Skia eventually ran into performance issues as the web evolved and became more complex, which led Chrome and Skia to invest in a GPU accelerated rasterization backend called Ganesh. Over the years, Ganesh matured into a solid highly performant rasterization backend and GPU rasterization launched on all platforms in Chrome on top of GL (via ANGLE on Windows D3D9/11). However, Ganesh always had a GL-centric design with too many specialized code paths and the team was hitting a wall when trying to implement optimizations that took advantage of modern graphics APIs in a principled manner. This set the stage for the team to rethink GPU rasterization from the ground up in the form of a new rasterization backend, Graphite. Graphite was developed from the start to be principled by having fewer and more comprehensible code paths. This forward looking design helps take advantage of modern graphics APIs like Metal, Vulkan and D3D12 and paradigms like compute based path rasterization, and is multithreaded by default. Results With Graphite in Chrome, we increased our Motionmark 1.3 scores by almost 15% on a Macbook Pro M3. At the same time, we improved real world metrics like INP (interaction to next paint time), LCP (time to largest contentful paint), graphics smoothness (percent dropped frames), GPU process malloc memory usage, and others. This all means substantially smoother interactions, less stutter when scrolling, and less time waiting for sites to show ## Chrome achieves highest score ever on Speedometer 3.1, saving users millions of hours DevFeed: [Chrome achieves highest score ever on Speedometer 3.1, saving users millions of hours]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2025-06-05T17:00:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Benchmark](), [web applications](), [Latency](), [Optimization]() Tags: [2025](), [apple](), [benchmark](), [benchmarks](), [browser](), [chrome](), [css](), [html](), [javascript](), [json](), [macos](), [none](), [optimization](), [performance](), [the-fast-and-the-curious](), [web-performance]() ### AI overview Chrome reports a 22% improvement on the Speedometer 3.1 benchmark since August 2024, achieving its highest score to date. The article explains that the work optimized rendering paths and components involved in web application responsiveness, including HTML parsing, JavaScript and JSON processing, DOM interaction, CSS layout, pixel rendering, and internal data structures. ### Source excerpt Update (6/10/2025): This blog was updated to reflect that testing was done using the Speedometer 3.1 benchmark, and resulted in a 22% performance improvement. The previous version incorrectly noted that the performance improvement was 10% and that the benchmark was Speedometer 3. Performance has always been one of the core pillars of Chrome and it's something we've never stopped investing in. Publicly available and open benchmarks, which we create in open collaboration with other browsers, are useful tools for tracking our overall progress, understanding new areas of improvement, and validating potential optimizations. In today's The Fast and the Curious post, we'd like to go through Chrome's recent work that enabled it to achieve the highest score ever on the Speedometer benchmark. For Speedometer, these optimizations have resulted in a 22% improvement since August 2024. That 22% improvement leads to better browser experiences, higher conversions for businesses, and deeper enjoyment of what the web has to offer. If each Chrome user used Chrome for just 10 minutes a day, these improvements collectively save 116 million hours or roughly 166 lifetimes worth of waiting around for websites to load and do things. Speedometer 3.1 score measured on Apple Macbook Pro M4 with MacOS 15 Speedometer is a benchmark created in open collaboration with other browsers and measures web application responsiveness through workloads that cover a large variety of different areas of the Blink rendering engine used in Chrome: HTML parsing JavaScript and JSON processing JavaScript and Document Object Model (DOM) interaction DOM manipulations (element insertion and removal) Text size computation (font shaping) Cascading Style Sheet (CSS) application and layout calculation Pixel rendering In essence, Speedometer tests critical components of the entire rendering pipeline. For a deeper dive into these individual parts, we recommend the presentation Life of a Script at Chrome University. Achievi ## How Chrome doubled its Speedometer scores on Android DevFeed: [How Chrome doubled its Speedometer scores on Android]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-12-04T14:00:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Chrome](), [Android](), [Benchmark](), [V8](), [JavaScript](), [web browser](), [CSS](), [HTML]() Tags: [android](), [benchmark](), [chrome](), [css](), [html](), [javascript](), [none](), [performance](), [the-fast-and-the-curious](), [v8]() ### AI overview The article explains how Chrome more than doubled Speedometer 2.1 scores on many Android devices since Chrome M112. It attributes the gains to build optimizations, V8 and Blink improvements, and closer coordination with Android operating-system scheduling and SoC partners. ### Source excerpt Today's The Fast and the Curious post covers how Chrome achieved best-in-class Speedometer scores on mobile devices, resulting in faster and smoother web experiences for Android users. Chrome has always been about speed. Whether it's loading pages quickly, running complex web apps smoothly, or delivering a seamless browsing experience, performance is at the heart of our browser. And we're always looking for ways to make Chrome even faster. Over the last two years, we have been hard at work on a number of performance improvements for Android devices. We're excited to share some of the progress we've made. Speedometer on Android One of the key metrics we use to track Chrome's performance is the Speedometer benchmark. This benchmark is developed in collaboration with other major web browser engines and measures how quickly Chrome can complete interactions with web pages, including parsing/rendering HTML or CSS and running JavaScript. Since the release of Chrome M112, we've seen a significant increase in Speedometer 2.1 scores on Android devices [1]. In fact, on many devices, scores more than doubled, with the newest Snapdragon® 8 Elite Mobile Platform setting new records for Speedometer performance on mobile devices! These huge accomplishments are a testament to the work not only of the Chrome and Android teams, but also our silicon and SoC partners. Since Chrome M112, Speedometer 2.1 scores have more than doubled on many Android devices. [1] How Did We Do It? The improvements resulted from several changes, including: Build optimizations: We've made a number of changes to the way Chrome is built, which has resulted in faster code execution tuned to modern premium Android devices and SoCs. V8 and Blink improvements: Many improvements to the JavaScript engine (V8) and the rendering engine (Blink) have further boosted performance. Scheduling, OS and SoCs: We worked closely with Android partners to optimize the way Chrome interacts with the operating system and its thread ## How Chrome achieved the highest score ever on Speedometer 3 DevFeed: [How Chrome achieved the highest score ever on Speedometer 3]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-06-06T16:15:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [web applications]() Tags: [apple](), [benchmark](), [benchmarking](), [browser](), [chrome](), [dedupe](), [google](), [intel](), [memory](), [microsoft](), [mozilla](), [none](), [optimization](), [performance](), [the-fast-and-the-curious](), [web-applications]() ### AI overview Chrome describes workload-focused optimizations that increased its Speedometer 3 score by 72% since May 2022. The work targets browser operations including string parsing, stylesheet deduplication, path drawing, form creation, selector handling, DOM parsing, and font rendering. ### Source excerpt Today's The Fast and the Curious post explores how Chrome achieved the highest score on the new Speedometer 3.0, an upgraded browser benchmarking tool to optimize the performance of Web applications. Try out Chrome today! Speedometer 3.0 is a recently published benchmark for measuring browser performance that was created as an industry collaboration between companies like Google, Apple, Mozilla, Intel, and Microsoft. This benchmark helped us identify areas in which we could optimize Chrome to deliver a faster browser experience to all our users. Here's a closer look at how we further optimized Chrome to achieve the highest score ever Speedometer 3, by carefully tracking its recent performance over time as the updated benchmark was being developed. Since the inception of Speedometer 3 in May 2022, we've driven a 72% increase in Chrome's Speedometer score - translating into performance gains for our users: Optimizing workloads By looking at the workloads in Speedometer and in which functions Chrome was spending the most time, we were able to make targeted optimizations to those functions that each drove an increase in Chrome's score. For example, the SpaceSplitString function is used heavily to turn space-separated strings such as those in "class='foo bar' " into a list representation. In this function we removed some unnecessary bound checks. When we detect that there are duplicated stylesheets, we dedupe them and reference a single stylesheet instance. We made an optimization to reduce the cost of drawing paths and arcs by tuning memory allocations. When creating form editors we detected some unnecessary processing that occurs when form elements are created. Within querySelector, we were able to detect what selector was commonly used and create a hot-path for that. We previously shared how we optimized innerHTML using specialized fast paths for parsing, an implementation that also made its way into WebKit. Some workloads in Speedometer 3 use DOMParser so we extended ## Introducing Shared Memory Versioning to improve slow interactions DevFeed: [Introducing Shared Memory Versioning to improve slow interactions]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-06-03T17:24:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [real user monitoring](), [Processes]() Tags: [browser](), [chrome](), [javascript](), [memory](), [metrics](), [none](), [performance](), [privacy](), [process](), [the-fast-and-the-curious](), [traces](), [web-platform]() ### AI overview The article describes Chrome's use of field data and anonymized Perfetto traces to investigate slow web interactions. It identifies redundant synchronous cookie reads from the network service as a source of contention and introduces shared memory versioning as the stated improvement. ### Source excerpt On the Chrome team, we believe it's not sufficient to be fast most of the time, we have to be fast all of the time. Today's The Fast and the Curious post explores how we contributed to Core Web Vitals by surveying the field data of Chrome responding to user interactions across all websites, ultimately improving performance of the web. As billions of people turn to the web to get things done every day, the browser becomes more responsible for hosting a multitude of apps at once, resource contention becomes a challenge. The multi-process Chrome browser contends for multiple resources: CPU and memory of course, but also its own queues of work between its internal services (in this article, the network service). This is why we've been focused on identifying and fixing slow interactions from Chrome users' field data, which is the authoritative source when it comes to real user experiences. We gather this field data by recording anonymized Perfetto traces on Chrome Canary, and report them using a privacy-preserving filter. When looking at field data of slow interactions, one particular cause caught our attention: recurring synchronous calls to fetch the current site's cookies from the network service. Let's dive into some history. Cookies under an evolving web Cookies have been part of the web platform since the very beginning. They are commonly created like this: document.cookie = "user=Alice;color=blue" And later retrieved like this: // Assuming a `getCookie` helper method: getCookie("user", document.cookie) Its implementation was simple in single-process browsers, which kept the cookie jar in memory. Over time, browsers became multi-process, and the process hosting the cookie jar became responsible for answering more and more queries. Because the Web Spec requires Javascript to fetch cookies synchronously, however, answering each document.cookie query is a blocking operation. The operation itself is very fast, so this approach was generally fine, but under heavy load s ## Speedometer 3: Building a benchmark that represents the web DevFeed: [Speedometer 3: Building a benchmark that represents the web]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2024-03-11T16:00:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Benchmark](), [benchmarking](), [Latency](), [web applications](), [browsers](), [WebKit](), [V8]() Tags: [benchmark](), [benchmarking](), [benchmarks](), [browsers](), [collaboration](), [governance](), [none](), [optimization](), [performance](), [the-fast-and-the-curious](), [user-experience](), [web](), [web-applications](), [web-performance](), [workflows]() ### AI overview This article announces Speedometer 3.0, an updated browser benchmark designed to represent modern web applications. Developed through collaboration among major browser-engine teams, it improves score calculation and detail while adding more diverse workloads to guide browser performance optimization and better reflect user experiences. ### Source excerpt Today's The Fast and the Curious post covers the release of Speedometer 3.0 an upgraded browser benchmarking tool to optimize the performance of Web applications. In collaboration with major web browser engines, Blink/V8, Gecko/SpiderMonkey, and WebKit/JavaScriptCore, we're excited to release Speedometer 3.0. Benchmarks, like Speedometer, are tools that can help browser vendors find opportunities to improve performance. Ideally, they simulate functionality that users encounter on typical websites, to ensure browsers can optimize areas that are beneficial to users. Let's dig into the new changes in Speedometer 3.0. Applying a multi-stakeholder governance model Since its initial release in 2014 by the WebKit team, browser vendors have successfully used Speedometer to optimize their engines and improve user experiences on the web. Speedometer 2.0, a result of a collaboration between Apple and Chrome, followed in 2018, and it included an updated set of workloads that were more representative of the modern web at that time. The web has changed a lot since 2018, and so has Speedometer in its latest release, Speedometer 3. This work has been based on a joint multi-stakeholder governance model to share work, and build a collaborative understanding of performance on the web to help drive browser performance in ways that help users. The goal of this collaborative project is to create a shared understanding of web performance so that improvements can be made to enhance the user experience. Together, we were able to to improve how Speedometer captures and calculates scores, show more detailed results and introduce an even wider variety of workloads. This cross-browser collaboration introduced more diverse perspectives that enabled clearer insights into a broader set of web users and workflows, ensuring the newest version of Speedometer will help make the web better for everyone, regardless of which browser they use. Why is building workloads challenging? Building a reliable ben ## How Core Web Vitals saved users 10,000 years of waiting for web pages to load DevFeed: [How Core Web Vitals saved users 10,000 years of waiting for web pages to load]() Original publisher: [Read original article]() Author: Chromium Blog (noreply@blogger.com) Published: 2023-11-07T17:03:00Z Content type: article Language: en Sources: [Chromium Blog]() Topics: [Core Web Vitals](), [Chrome](), [Web](), [Google](), [User Experience](), [Google Search]() Tags: [chrome](), [core-web-vitals](), [ecosystem](), [google](), [google-search](), [performance](), [the-fast-and-the-curious](), [user-experience](), [web](), [web-performance]() ### AI overview This article explains how Core Web Vitals helped improve web performance for Chrome users on desktop and Android, reportedly saving more than 10,000 years of page-loading time in 2023. It describes how shared metrics, developer guidance, and collaboration across Chrome, Search, and the web ecosystem contributed to faster, more responsive pages. ### Source excerpt Today's The Fast and the Curious post explores how Core Web Vitals saved Chrome users more than 10,000 Years of waiting for web pages to load in 2023 (across Chrome desktop and Android) by quantifying the experience of sites and identifying opportunities to make improvements. In 2020, we introduced Web Vitals - essential quality signals for webpages to ensure a better user experience. Since then, there has been a massive leap in web performance made possible by our work on Core Web Vitals (CWV) and its broader impact on the web. Today, over 40% of sites pass all of the CWV metrics, leading to pages that load and respond to interactions more quickly. Here's a closer look at the journey to help improve the performance for sites and some specific work done in the browser and the ecosystem to enable this achievement. Chrome's Quest for Speed The very essence of the web lies in its ability to provide information and services efficiently and rapidly. This principle is at the heart of Google's business and drives our work on Chrome. However, we noticed an issue with sites over a long time horizon. Even if slow sites improved their performance for a while, it would often decline over time. No matter how fast Google Search might be, the user experience would be subpar if the pages found were slow to load. We could not help these sites improve their performance directly, but we wanted users to have a great experience when they moved from Google Search to the individual sites. To tackle the challenge of improving the user experience while simultaneously providing unified guidance to developers, teams from Search and Chrome collaborated to address the issue of slow web pages. Defining the Fast Web We examined millions of pages to define a public standard for a fast, user-friendly web page (initially published in The Science Behind Web Vitals). We published our specifications and data to the open ecosystem and took note of the feedback we received. The introduction of CWV metric