How Chrome Became the Highest Scoring Browser on Speedometer, Ever

Tuesday, March 15, 2022

Last week we released a blog post about our improvements in Chrome speed over the past year culminating with the M99 release of Chrome. We wanted to follow up by going in depth on how we achieved this milestone in browser performance.

Since the launch of Chrome in 2008, one of our core principles has been to build the fastest browser, whether you're on your phone or laptop. We have never strayed from our performance mission, and are always analyzing and optimizing every part of Chrome. We're proud to announce that Chrome scores over 300 on Apple’s Speedometer 2.0 benchmark suite on the M1 MacBook, the highest score we’ve ever seen. In this The Fast and the Curious post we'll go behind the scenes to share all the work that went into making Chrome blazingly fast.

“If you can’t measure it you can’t improve it” – this sentiment has driven a large part of our work to improve Chrome’s performance since the early days. For measuring browser performance, there has been a long history of various benchmarks that aim to provide test workloads for browsers to track their performance. Making these benchmarks both reflective of the real and ever changing world, while also being consistent, is a challenge. Chrome uses a combination of internal benchmarking infrastructure and public, industry-standard benchmarks, to continuously measure Chrome’s performance. For comparing browsers’ JavaScript performance, Apple’s Speedometer 2.0 benchmark is the most reflective of the real world, and most broadly used today.

We’ve been tracking our performance on Speedometer 2.0 ever since it came out:

Beginning with the M87 release, Chrome shipped on the M1 based Mac and began measuring the speed of Chrome on the new CPU reflected in the red line above.

Since 2015, we’ve been measuring Chrome’s Speedometer scores on a 13-inch MacBook. In the graph above, you can see just some of the many projects that have helped make a dramatic improvement in performance. You can learn about fast lookups, the Ignition + TurboFan compilers, blazingly fast parsing, faster JS calls, Spectre, Pointer Compression, Short builtins, Sparkplug and much more on V8.dev. You’ll notice some projects actually decrease our Speedometer score, as building an entire browser is about managing trade offs. For example, with pointer compression, we were willing to take a small performance hit for the large memory savings it provided. Similarly, when the Spectre CPU exploit hit, we traded off performance to help guarantee the safety of our users.

The result of years of work has been an 83% improvement in Speedometer score, a dramatic improvement we are happy to deliver to our users. With Apple’s introduction of the M1 CPU, combined with Sparkplug and LTO+PGO, Chrome now scores over 300 - the highest score any browser has ever achieved \o/.

We are excited to achieve this milestone in performance and look forward to delivering even more performance improvements with each release. Stay tuned to this blog to stay up to date on all things speed.

Posted by Thomas Nattestad, Chrome Product Manager

Footnote:Data source for M1 MacBook statistics: Speedometer 2.0 comparing Chrome 99.0.4812.0 --enable-features=CanvasOopRasterization --use-cmd-decoder=passthrough vs. Safari 15.2 17612.3.6.1.6 on a MacBook Pro (14", 2021), Apple M1 Max, 10 cores (8 performance, 2 efficiency), 32 GPU cores, 64gb device.

A new speed milestone for Chrome

Monday, March 7, 2022

Everyday, billions of people around the world turn to Chrome to get things done quickly on their devices, whether shopping for a new pair of headphones or pulling together a sales report for work. Nothing is more frustrating than having a slow experience while browsing the web. That’s why Chrome has always been focused on building the fastest possible browser since its launch in 2008, without compromising on feature functionality or security. In our first The Fast and the Curious post of 2022, we are thrilled to celebrate how in the M99 release of Chrome we were able to substantially increase the speed of Chrome across all major platforms.
SpeedometerThinLTO

Two of the other recent major contributors to Chrome’s speed are the V8 Sparkplug compiler and short builtin calls. Sparkplug is a new mid-tier JavaScript compiler for V8 that generates efficient code with low compilation overhead. Short builtin calls are used by the V8 JavaScript engine to optimize the placement of generated code inside the device’s memory. This technique boosts performance by avoiding indirect jumps when calling functions and makes a substantial difference on Apple M1-based Macs.

Chrome continues to get faster on Android as well. Loading a page now takes 15% less time, thanks to prioritizing critical navigation moments on the browser user interface thread. Last year we also reduced startup time for Chrome on Android by 13% using Freeze-Dried Tabs. This approach conserves resources across the board by using a lightweight version of tabs on load, while the actual tab loads in the background. Finally, we were able to improve speed and memory usage using Isolated Splits, which improved startup time by preloading the majority of the browser process code on a background thread.

We know that benchmarks are just one of many ways of measuring the speed of a browser. At the end of the day, what matters most is that Chrome is actually faster and more efficient in everyday usage, so we’ll continue to invest in innovative performance improvements that push the envelope of what’s possible in modern computing.

Posted by Max Christoff, Senior Director, Chrome Engineering

Data source for Mac statistics: Speedometer 2.0 comparing Chrome 99.0.4812.0 --enable-features=CanvasOopRasterization --use-cmd-decoder=passthrough vs. Safari 15.2 17612.3.6.1.6 on a MacBook Pro (14", 2021), Apple M1 Max, 10 cores (8 performance, 2 efficiency), 32 GPU cores, 64gb device connected to power.

Data source for Android statistics: Real-world data anonymously aggregated from Chrome clients.

Chrome on Windows performance improvements and the journey of Native Window Occlusion

Thursday, December 9, 2021

Whether you prefer organizing your browser with tab groups, naming your windows, tab search, or another method, you have lots of features that help you get to the tabs you want. In this The Fast and the Curious post, we describe how we use what windows are visible to you to optimize Chrome, leading to 25.8% faster start up and 4.5% fewer crashes.

Background

For several years, to improve the user experience, Chrome has lowered the priority of background tabs[1]. For example, JavaScript is throttled in background tabs, and these tabs don’t render web content. This reduces CPU, GPU and memory usage, which leaves more memory, CPU and GPU for foreground tabs that the user actually sees. However, the logic was limited to tabs that weren't focused in their window, or windows that were minimized or otherwise moved offscreen.

Through experiments, we found that nearly 20% of Chrome windows are completely covered by other windows, i.e., occluded. If these occluded windows were treated like background tabs, our hypothesis was that we would see significant performance benefits. So, around three years ago, we started working on a project to track the occlusion state of each Chrome window in real time, and lower the priority of tabs in occluded windows. We called this project Native Window Occlusion, because we had to know about the location of native, non-Chrome windows on the user’s screen. (The location information is discarded immediately after it is used in the occlusion calculation.)

Calculating Native Window Occlusion

The Windows OS doesn’t provide a direct way to find out if a window is completely covered by other windows, so Chrome has to figure it out on its own. If we only had to worry about other Chrome windows, this would be simple because we know where Chrome windows are, but we have to consider all the non-Chrome windows a user might have open, and know about anything that happens that might change whether Chrome windows are occluded or not.

There are two main pieces to keeping track of which Chrome windows are occluded. The first is the occlusion calculation, which consists of iterating over the open windows on the desktop, in z-order (front to back) and seeing if the windows in front of a Chrome window completely cover it. The second piece is deciding when to do the occlusion calculation.

Calculating Occlusion

In theory, figuring out which windows are occluded is fairly simple. In practice, however, there are lots of complications, such as multi-monitor setups, virtual desktops, non-opaque windows, and even cloaked windows(!). This needs to be done with great care, because if we decide that a window is occluded when in fact it is visible to the user, then the area where the user expects to see web contents will be white. We also don’t want to block the UI thread while doing the occlusion calculation, because that could reduce the responsiveness of Chrome and degrade the user experience. So, we compute occlusion on a separate thread, as follows:

Ignore minimized windows, since they’re not visible.
Mark Chrome windows on a different virtual desktop as occluded.
Compute the virtual screen rectangle, which combines the display monitors. This is the unoccluded screen rectangle.
Iterate over the open windows on the desktop from front to back, ignoring invisible windows, transparent windows, floating windows (windows with style WS_EX_TOOLBAR), cloaked windows, windows on other virtual desktops, non-rectangular windows[2], etc. Ignoring these kinds of windows may cause some occluded windows to be considered visible (false negatives) but importantly it won’t lead to treating visible windows as occluded (false positives). For each window:

Subtract the window's area from the unoccluded screen rectangle.
If the window is a Chrome window, check if its area overlapped with the unoccluded area. If it didn’t, that means the Chrome window is completely covered by previous windows, so it is occluded.

Keep iterating until all Chrome windows are captured.
At this point, any Chrome window that we haven’t marked occluded is visible, and we’re done computing occlusion. Whew! Now we post a task to the UI thread to update the visibility of the Chrome windows.
This is all done without synchronization locks, so the occlusion calculation has minimal effect on the UI thread, e.g., it will not ever block the UI thread and degrade the user experience.

For more detailed implementation information, see the documentation.

Deciding When to Calculate Occlusion

We don’t want to continuously calculate occlusion because it would degrade the performance of Chrome, so we need to know when a window might become visible or occluded. Fortunately, Windows lets you track various system events, like windows moving or getting resized/maximized/minimized. The occlusion-calculation thread tells Windows that it wants to track those events, and when notified of an event, it examines the event to decide whether to do a new occlusion calculation. Because we may get several events in a very short time, we don’t calculate occlusion more than once every 16 milliseconds, which corresponds to the time a single frame is displayed, assuming a frame rate of 60 frames per second (fps).

Some of the events we listen for are windows getting activated or deactivated, windows moving or resizing, the user locking or unlocking the screen, turning off the monitor, etc. We don’t want to calculate occlusion more than necessary, but we don’t want to miss an event that causes a window to become visible, because if we do, the user will see a white area where their web contents should be. It’s a delicate balance[3].

The events we listen for are focused on whether a Chrome window is occluded. For example, moving the mouse generates a lot of events, and cursors generate an event for every blink, so we ignore events that aren’t for window objects. We also ignore events for most popup windows, so that tooltips getting shown doesn’t trigger an occlusion calculation.

The occlusion thread tells Windows that it wants to know about various Windows events. The UI thread tells Windows that it wants to know when there are major state changes, e.g., the monitor is powered off, or the user locks the screen.

Results

This feature was developed behind an experiment to measure its effect and rolled out to 100% of Chrome Windows users in October 2020 as part of the M86 release. Our metrics show significant performance benefits with the feature turned on:

8.5% to 25.8% faster startup
3.1% reduction in GPU memory usage
20.4% fewer renderer frames drawn overall
4.5% fewer clients experiencing renderer crashes
3.0% improvement in first input delay
6.7% improvement in first contentful paint and largest contentful paint

A reason for the startup and first-contentful-paint improvements is when Chrome restores two or more full-screen windows when starting up, one of the windows is likely to be occluded. Chrome will now skip much of the work for that window, thus saving resources for the more important foreground window.

Posted by David Bienvenu, Chrome Developer

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.[1] Note that certain tabs are exempt from having their priority lowered, e.g., tabs playing audio or video.[2] Non-rectangular windows complicate the calculations and were thought to be rare, but it turns out non-rectangular windows are common on Windows 7, due to some quirks of the default Windows 7 theme.[3] When this was initially launched, we quickly discovered that Citrix users were getting white windows whenever another user locked their screen, due to Windows sending us session changed notifications for sessions that were not the current session. For the details, look here.

Faster Chrome - Let The Compiler do the work

Wednesday, December 1, 2021

Chrome is fast, but there's always room for improvement. Often, that's achieved by carefully crafting the algorithms that make up Chrome. But there's a lot of Chrome, so why not let computers do at least some part of our work? In this installment of The Fast And the Curious, we'll show you several changes in how we build Chrome to achieve a 25.8% higher score on Speedometer on Windows and a 22.0% increase in browser responsiveness.

Why speed?

So why do we care about performance benchmarks? It's not a simple "higher numbers is better" chasing of achievements - performance was so important to Chrome that we embedded in our core principles, the "4Ss" - Speed, Security, Stability, Simplicity. And speed matters because we want a browser that responds quickly. Speed matters so much because we want to build a faster and more responsive browser. And by improving the speed of the browser, there's the additional benefit of maximizing battery use, so you don't have to charge your laptop/devices as often.

Speed? Size? Something Else?

Let's look at a typical optimization.

int foo();

int fiver(int num) {

for(int j = 0; j < 5; j++)

num = num + foo();

return num;

}

The compiler can either compile this as a loop (smaller), or turn it into five additions in a row (faster, but bigger)

You save the cost of checking the end of the loop and incrementing a variable every time through the loop. But in exchange, you now have many repeated calls to foo(). If foo() is called a lot, that is a lot of space.

And while speed matters a lot, we also care about binary size. (Yes, we see your memes!) And that tradeoff - exchanging speed for memory, and vice versa, holds for a lot of compiler optimizations.

So how do you decide if the cost is worth it? One good way is to optimize for speed in areas that are run often, because your speed wins accumulate each time you run a function. You could just guess at what you inline (your compiler can do this, it's called "a heuristic", it's an educated guess), and then measure speed and code size.

The result: Likely faster. Likely larger. Is that good?

Ask any engineer a question like that, and they will answer “It depends”. So, how do you get an answer?

The More You Know… (profiling & PGO)

The best way to make a decision is with data. We collect data based on what gets run a lot, and what gets run a little. We do that for several different scenarios, because our users do lots of different things with Chrome and want them to be fast.

Our goal is collecting performance data in various scenarios, and using that to guide the compiler. There are 3 steps needed:

Instrument for profiling
Run that instrumented executable in various scenarios
Use the resulting performance profile to guide the compiler.

But we can do more (ThinLTO)

That's a good start, but we can do better. Let's look at inlining - the compiler takes the code of a called function and inserts all of it at the callsite.

inline int foo() { return 3; };

int fiver_inline(int num) {

for(int j = 0; j < 5; j++)

num = num + foo();

return num;

}

When the compiler inlines foo(), it turns into

int fiver_inline(int num) {

for(int j = 0; j < 5; j++)

num = num + 3;

return num;

}

Not bad - saves us the function call and all the setup that goes with having a function. But the compiler can in fact even do better - because now all the information is in one place. The compiler can apply that knowledge and deduce that fiver_inline() adds the number three and does so 5 times - and so the entire code is boiled down to

return num + 15;

Which is awesome! But the compiler can only do this if the source code for foo() and the location where it is called are in the same source file - otherwise, the compiler does not know what to inline. (That's the fiver() example). A trivial way around that is to combine all the source files into one giant source file and compile and link that in one go.

There's just one downside - that approach needs to generate all of the machine code for Chrome, all the time. Change one line in one file, compile all of Chrome. And there's a lot of Chrome. It also effectively disables caching build results and so makes remote compilation much less useful. (And we rely a lot on remote compilation & caching so we can quickly build new versions of Chrome.)

So, back to the drawing board. The core insight is that each source file only needs to include a few functions - it doesn't need to see every single other file. All that's needed is "cleverly" mixing the right inline functions into the right source files.

Now we're back to compiling individual source files. Distributed/cached compilation works again, small changes don't cause a full rebuild, and since "ThinLTO" does just inline a few functions, and it is relatively little overhead.

Of course, the question of "which functions should ThinLTO inline?" still needs to be answered. And the answer is still "the ones that are small and called a lot". Hey, we know those already - from the profiles we generated for Profile Guided Optimization (PGO). Talk about lucky coincidences!

But wait, there's more! (Callgraph Sorting)

We've done a lot for inlined function calls. Is there anything we can do to speed up functions that haven't been inlined, too? Turns out there is.

One important factor is that the CPU doesn't fetch data byte by byte, but in chunks. And so, if we could ensure that a chunk of data doesn't just contain the function we need right now, but ideally also the ones that we'll need next, we could ensure that we have to go out and get chunks of data less often.

In other words, we want functions that are called right after the other to live next to each other in memory also ("code locality"). And we already know which functions are called close to each other - because we ran our profiling and stored performance profiles for PGO.

We can then use that information to ensure that the right functions are next to each other when we link.

I.e.

g.c

extern int f1();

extern int f2();

extern int f3();

int g() {

f1();

for(..) {

f3();

}

f1();

f2();

}

could be interpreted as "g() calls f3() a lot - so keep that one really close. f1() is called twice, so… somewhat close. And if we can squeeze in f2, even better". The calling sequence is a "call graph", and so this sorting process is called "call graph sorting".

Just changing the order of functions in memory might not sound like a lot, but it leads to ~3% performance improvement. And to know which functions calls which other ones a lot… yep. You guessed it. Our profiles from the PGO work pay off again.

One more thing.

It turns out that the compiler can make even more use of that profile data for PGO. (Not a surprise - once you know where the slow spots are, exactly, you can do a lot to improve!). To make use of that, and enable further improvements, LLVM has something called the "new pass manager". In a nutshell, it's a new way to run optimizations within LLVM, and it helps a lot with PGO. For much more detail, I'd suggest reading the LLVM blog post.

Turning that on leads to another ~3% performance increase, and ~9MB size reduction.

Why Now?

Good question. One part of that is that PGO & profiling unlock an entire new set of optimizations, as you've seen above. It makes sense to do that all in one go.

The other reason is our toolchain. We used to have a colorful mix of different technologies for compilers and linkers on different platforms.

And since this work requires changes to compilers and linkers, that would mean changing the build - and testing it - across 5 compilers and 4 linkers. But, thankfully, we've simplified our toolchain (Simplicity - another one of the 4S's!). To be able to do this, we worked with the LLVM community to make clang a great Windows compiler, in addition to partnering with the LLVM community to create new ELF (Linux), COFF (Windows), and Mach-O (macOS, iOS) linkers.

And suddenly, it's only a single toolchain to fix. (Almost. LTO for lld on MacOS is being worked on).

Sometimes, the best way to get more speed is not to change the code you wrote, but to change the way you build the software.

Posted by Rachel Blum, Engineering Director, Chrome Desktop
Data source for all statistics: Speedometer 2.0.

Partitioning Chrome's Code for Faster Launch Times on Android

Tuesday, November 16, 2021

Mobile devices are generally more resource constrained than laptops or desktops. Optimizing Chrome’s resource usage is critical to give mobile users a faster Chrome experience. As we’ve added features to Chrome on Android, the amount of Java code packaged in the app has continued to grow. In this The Fast and the Curious post we show how our team improved the speed and memory usage of Chrome on Android with Isolated Splits. With these improvements, Chrome on Android now uses 5-7% less memory, and starts and loads pages even faster than before.

The Problem

For Android apps (including Chrome on Android), compiled Java code is stored in .dex files. The user's experience in Chrome on Android is particularly sensitive to increases in .dex size due to its multi-process architecture. On Android, Chrome will generally have 3+ processes running at all times: the browser process, the GPU process, and one or more renderer processes. The vast majority of Chrome’s Java code is used only in the browser process, but the performance and memory cost of loading the code is paid by all processes.

Bundles and Feature Modules

Ideally, we would load the smallest chunk of Java necessary for a process to run. We can get close to this by using Android App Bundles and splitting code into feature modules. Feature modules allow splitting code, resources, and assets into distinct APKs installed alongside the base APK, either on-demand or during app install.

Now, it seems like we have exactly what we want: a feature module could be created for the browser process code, which could be loaded when needed. However, this is not how Android loads feature modules. By default, all installed feature modules are loaded on startup. For an app with a base module and three feature modules “a”, “b”, and “c”, this gives us an Android Context with a ClassLoader that looks something like this:

Having a small minimum set of installed modules that are all immediately loaded at startup is beneficial in some situations. For example, if an app has a large feature that is needed only for a subset of users, the app could avoid installing it entirely for users who don't need it. However, for more commonly used features, having to download a feature at runtime can introduce user friction -- for example, additional latency or challenges if mobile data is unavailable. Ideally we'd be able to have all of our standard modules installed ahead of time, but loaded only when they're actually needed.

Isolated Splits to the Rescue

A few days of spelunking in the Android source code led us to the android:isolatedSplits attribute. If this is set to “true”, each installed split APK will not be loaded during start-up, and instead must be loaded explicitly. This is exactly what we want to allow our processes to use less resources! The ClassLoader illustrated above now looks like this:

In Chrome’s case, the small amount of code needed in the renderer and GPU processes can be kept in the base module, and the browser code and other expensive features can be split into feature modules to be loaded when needed. Using this method, we were able to reduce the .dex size loaded in child processes by 75% to ~2.5MB, making them start faster and use less memory.

This architecture also enabled optimizations for the browser process. We were able to improve startup time by preloading the majority of the browser process code on a background thread while the Application initializes leading to a 7.6% faster load time. By the time an Activity or other component which needed the browser code was launched, it would already be loaded. By optimizing how features are allocated into feature modules, features can be loaded on-demand which saves the memory and loading cost until the feature is used.

Results

Since Chrome shipped with isolated splits in M89 we now have several months of data from the field, and are pleased to share significant improvements in memory usage, startup time, page load speed, and stability for all Chrome on Android users running Android Oreo or later:

Median total memory usage improved by 5.2%
Median renderer process memory usage improved by 7.9%
Median GPU process memory usage improved by 7.6%
Median browser process memory usage improved by 1.2%
95th percentile startup time improved by 7.6%
95th percentile page load speed improved by 2.3%
Large improvements in both browser crash rate and renderer hang rate

Posted by Clark Duvall, Chrome Software Engineer

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.

Searching, browsing, and shutdown Chrome performance improvements

Monday, November 1, 2021

Chrome has long-term investments in performance improvement across many projects and we are pleased to share improvements across speed, memory, and unexpected hangs in today’s The Fast and the Curious series post. One in six searches is now as fast as a blink of an eye, Chrome OS browsing now uses up to 20% less memory thanks to our PartitionAlloc investment, and we’ve resolved some thorny Chrome OS and Windows shutdown experiences.OmniboxYou’ve probably noticed that potential queries are suggested to you as you type when you’re searching the web using Chrome’s omnibox (as long as the “Autocomplete searches and URLs” feature is turned on in Chrome settings.) This makes searching for information faster and easier, as you don’t have to type in the entire search query -- once you’ve entered enough text for the suggestion to be the one you want, you can quickly select it.

Searching in Chrome is now even faster, as search results are prefetched if a suggested query is very likely to be selected. This means that you see the search results more quickly, as they’ve been fetched from the web server before you even select the query. In fact, our experiments found that search results are now 4X more likely to be shown within 500 ms!

Currently, this only happens if Google Search is your default search engine. However, other search providers can trigger this feature by adding information to the query suggestions sent from their servers to Chrome, as described in this article.

Chrome OS PartitionAlloc

Chrome’s new memory allocator, PartitionAlloc, rolled out on Android and Windows in M89, bringing improved memory usage [up to 22% savings] and performance [up to 9% faster responsiveness]. Since then, we have also implemented PartitionAlloc on Linux in M92 and Chrome OS in M93. We are now pleased to announce that M93 field data from Chrome OS shows a total memory footprint reduction of 15% in addition to a 20% browser process memory reduction, improving the Chromebook browsing experience for both single and multi-tabs.

Resolving the #1 shutdown hang

Often software engineers add a cache to a system with the goal of improving performance. But a frequent corollary of caching is that the cache may introduce other problems (code complexity, stability, memory consumption, data consistency), and may even make performance worse. In this case, a local cache was added years ago to Chrome's history system with the goal of making startup faster. The premise at the time, which seemed to bear out in lab testing, was that caching Chrome's internal in-memory history index would be faster than reindexing the history at each startup.

Thanks to our continuing systematic investigation into real-world performance using crash data in conjunction with anonymized performance metrics, we uncovered that not only did this cache add code complexity and unnecessary memory usage, but it was also our top contributor to shutdown hangs in the browser. This is because on some OSes, background priority threads can be starved of I/O indefinitely while there is any other I/O happening elsewhere on the system. Moreover, the performance benefits to our users were minimal, based on analysis of field data. We've now removed the cache and resolved our top shutdown hang. This was a great illustration of the principle that caching is not always the answer!

Stay tuned for many more performance improvements to come!

Posted by Yana Yushkina, Product Manager, Chrome Browser

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.

RenderingNG: an architecture that makes and keeps Chrome fast for the long term

Wednesday, October 6, 2021

Our continual investments in the performance of Chrome have led to significant improvements in battery life, memory, and the speed of the web. This post in The Fast & the Curious series highlights the rendering journey of Chrome over the past eight years, a journey that has led to a browser that is better across the board. For example, Chrome 94, as compared with Chrome 93:

is up to 8% more responsive on real pages,

saves more than 1400 years of CPU time per day, and

improves battery life by up to 0.5%

In addition, recent versions of Chrome are much better than those of years past with:

150% or more faster graphics rendering, and

greater reliability, due to a 6x reduction in GPU driver crashes on problematic hardware

IntroductionRenderingNG

RenderingNGcoming to a conclusion

The pyramid of success

Performance

GPU & multi-core

A great way Chrome can render content faster is to take advantage of the multi-core CPUs and advanced GPUs present in today’s devices. Multi-core means we can do multiple kinds of work in parallel. For example, Chrome parallelizes running JavaScript, scrolling a web page, decoding an image or video, and rastering new content that will be on-screen soon. GPUs enable even more parallelization by rastering every pixel on-screen, rather than one-at-a-time, yielding a large speedup.

Earlier generations of browsers were not built to natively support these technologies, because at the time GPUs and multi-core computers were not widespread. It turned out that bolting on highly parallel features was extremely challenging, requiring the team to re-architect the entire Chrome rendering pipeline over time. This re-architecture is RenderingNG.

Scaling up and scaling down

To avoid exhausting available resources and potentially diminishing the user experience of the web, browsers must be respectful of efficiency. They should not slow down your ability to interact with your computer or phone, or keep you from multitasking between the browser and other apps. Likewise, browsers also need to maximize battery life of your phone and laptop, and prevent the device itself from getting too hot (here’s looking at you, CPU cooling fans!). And finally, the browser must always be smooth and responsive to the user.

This means that the browser needs to be able to scale up and down its use of the GPU and multi-threading to balance multitasking, battery, and device temperature. As one example of scaling up, it’s important that scrolling happen in parallel with JavaScript on all devices; otherwise the browser will have poor user responsiveness. On the other hand, there are times when the browser must scale down because battery life may be considered more important than maximum use of GPU and CPU resources to make rendering faster.

It turns out to be challenging to be able to scale up and scale down seamlessly, and in a way that doesn’t break web content or make the browser unresponsive in key situations. RenderingNG applies novel technologies throughout the stack to make this work, including a complete rewrite of how compositing works, enabling the flexible use of GPU or CPU computations for arbitrary pieces of web pages, in order to pick the right fit for each web page and device.

Performance isolation

The third key technique is performance isolation. Performance isolation is what allows you to have a nice experience reading your email while music and video is playing in the background: your computer and operating system (OS) architecture makes sure that they all share the CPU fairly and smoothly. (This feature has been around for native apps for so long, we just take it for granted, but it wasn’t always that way!)

Browsers already have good isolation from other apps on your computer (thanks to the OS), but within a web page, it can be difficult to isolate all the pieces, such as iframes for ads and other embedded content, video and audio, animations, scrolling, JavaScript, and various other browser tasks. In earlier eras of the web, it was a huge achievement to simply make all these features work at all. Now the bar has been raised, and they need to fit together seamlessly in order to create a reliably fast user experience on the web.

RenderingNG’s architecture implements performance isolation for all of these features.

Reliability

Most of our work has been focused on reliability of the user experience. This is especially true when rewriting the entire rendering stack of a web browser--a huge and potentially risky undertaking.

We did this with four key techniques:

Comprehensive testing, such as a huge battery of Web Platform Tests,
Measuring progress in reliability, through metrics that track performance & quality, and committed goals such as Compat2021,
Listening to and acting on bug reports and feedback,
Good software design patterns.

Compat2021 improvements over time

Extensibility

Finally, we always have one eye toward what web apps will need now and in the future to unlock better and better experiences for users. These apps are always pushing at the boundary of what is possible to do well on the web, and sometimes beyond. When they go beyond what current web APIs or architectures were designed for, the web app may still work, but it’ll sometimes be slower and more cumbersome to use---and more taxing on your computer than necessary. We are filling these gaps with new APIs that allow web apps to continue doing all these things, but in a way that is much easier to implement performantly.

Extensibility has been part of the design of RenderingNG from the beginning, and is a big reason why the system is clean and modular.

Results

The first RenderingNG performance optimization shipped in 2015. Below we’ve highlighted a few of the many subsequent performance improvements since then.

CompositeAfterPaint: faster and more responsive on all pages [1]

In the M94 release, we will ship CompositeAfterPaint, a new compositing subsystem that allows for arbitrary scaling up and down of GPU use for web app content. Even better, due to more efficient, purpose-built algorithms in this subsystem, CompositeAfterPaint will substantially improve:

Scroll latency by up to 8%
Responsiveness by up to 3%
Peak rendering speed by up to 3%
GPU memory use by more than 3%
CPU time spent rendering and interacting with tabs, resulting in a savings of more than 1400 years of CPU time per day
Battery life by up to 0.5%

GPU Raster: dramatically faster than before [2]

When it shipped on Mac in 2016, GPU raster resulted in a 37% improvement on the overall MotionMark benchmark, and 150% on HTML categories. We subsequently brought similar wins to all other platforms and content types, concluding in 2020. In 2021 we shipped improvements focused on further GPU acceleration for 2D Canvas rendering, with up to a 1000% improvement in the Path rendering test, and a 130% improvement overall on the MotionMark 1.2 benchmark, as measured on an Apple M1 Mac.

Out-of-process Raster: much-improved reliability [1]

Out-of-process raster shipped on Android in 2018. This reduced the crash rate for problematic GPU drivers by 6x, bringing reliability in line with other drivers.

Learn more

If you’d like to learn more about RenderingNG, head over to the Chrome Developers Blog, where we are publishing a whole series about the project, with more to come over time.

Thanks for reading!

Posted by Chris Harrelson, Lead Rendering Software Engineer

[1] Data source: Real-world data anonymously aggregated from Chrome clients.
[2] Data source: MotionMark.

Faster and more efficient phishing detection in M92

Tuesday, July 20, 2021

Keeping Chrome users safe as they browse the web is crucially important to Chrome; in fact, security has always been one of our four core principles. In some cases, security can come at the expense of performance. In our next post in The Fast and the Curious series, we are excited to share how improvements to our phishing detection algorithms keeps users safe online. With these improvements, phishing detection is now 50 times faster and drains less battery.Phishing detection

What you will see if a phishing attempt is detected

To preserve your privacy, by default Chrome's Safe Browsing mode never sends any images outside the browser. While this is great for privacy, it means that your machine has to do all the work to analyze the image.

Image processing can often generate heavy workloads because analyzing the image requires an evaluation of each pixel in what is commonly known as a “pixel loop.” Some modern monitors display upwards of 14 million pixels, so even simple operations on each of those pixels can add up to a lot of CPU use! For phishing detection, the operation that takes place on each pixel is the counting of its basic colors.

Here is what this looks like. The counts are stored in an associative data structure called a hashmap. For each pixel, we extract its RGB color values and store the counts in one of 3 different hashmaps -- one for each color.

Making it more efficient

Adding one item to a hashmap is fast, but we have to do this for millions of pixels. We try to avoid reducing the number of pixels to avoid compromising the quality of the analysis. However, the computation itself can be improved.

Our improvements to the pipeline look like this:

The code now avoids keeping track of RGB channels in three different hashmaps and instead uses only one to index by color. Three times less counting!
Consecutive pixels are summed before being counted in the hashmap. For a site with a uniform background color, this can reduce the hashmap overhead to almost nothing.

Here is what the counting of the colors looks like now. Notice how there are significantly fewer operations on the hashmap:

How much faster did this get?

Starting with M92, Chrome now executes image-based phishing classification up to 50 times faster at the 50th percentile and 2.5 times faster at the 99th percentile. On average, users will get their phishing classification results after 100 milliseconds, instead of 1.8 seconds.

This benefits you in two ways as you use Chrome. First and foremost, using less CPU time to achieve the same work improves general performance. Less CPU time means less battery drain and less time with spinning fans.
Second, getting the results faster means Chrome can warn you earlier. The optimization brought the percentage of requests that took more than 5 seconds to process from 16.25% to less than 1.6%. This speed improvement makes a real difference in security - especially when it comes to stopping you from entering your password in a malicious site!
Overall, these changes achieve a reduction of almost 1.2% of the total CPU time used by all Chrome renderer processes and utility processes.
At Chrome’s scale, even minor algorithm improvements can result in major energy efficiency gains in aggregate. Here’s to many more centuries of CPU time saved!

Stay tuned for many more performance improvements to come!

Posted by Olivier Li Shing Tat-Dupuis, Chrome Developer

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.

Chrome is up to 23% faster in M91 and saves over 17 years of CPU time daily

Thursday, May 27, 2021

Since the launch of Chrome in 2008, speed has been one of the 4 core principles that shape the work we do to deliver a highly performant browser. The V8 JavaScript compiler is a critical part of delivering maximum speed for the JavaScript that’s shipped on practically every web page. In our next post in The Fast and the Curious series, we are excited to share how improvements to the V8 engine are delivering up to 23% faster performance.

An important component of delivering a fast browser is fast JavaScript execution. In Chrome, that job is done by the V8 engine which executes over 78 years worth of JavaScript code on a daily basis. In M91 Chrome is now up to 23% faster with the launch of a new Sparkplug compiler and short builtin calls, saving over 17 years of our users' CPU time each day! Sparkplug is a new JavaScript compiler that fills the gap between needing to start executing quickly and optimizing the code for maximum performance. Short builtin calls optimize where in memory we put generated code to avoid indirect jumps when calling functions.

Sparkplug

The V8 engine has multiple compilers which can make different tradeoffs throughout the various phases of executing JavaScript. Three years ago, we launched a new two-tier compiler system consisting of Ignition and Turbofan. Ignition is a bytecode interpreter whose job is to start executing the JavaScript with as little delay as possible. Turbofan is the optimizing compiler that generates high-performance machine code based on information gathered during JavaScript execution; as a result, it starts up more slowly than Ignition’s bytecode compiler. Sparkplug strikes a balance between Ignition and Turbofan in that it does generate native machine code but does not depend on information gathered while executing the JavaScript code. This lets it start executing quickly while still generating relatively fast code. For a complete technical deep dive into what it took to make this new engine, please see our V8 blog post.

Short builtins

Short builtins is a mechanism by which the V8 engine optimizes the location in memory of generated code. When V8 generates CPU-specific code from JavaScript, it lays that code out in memory. This generated code will frequently call builtin functions, which are small snippets of code for handling common routines --everything from basic operations like adding two variables, to full-fledged functions in the JavaScript standard library. For some CPUs, calling functions that are further away from your generated code can cause CPU-internal optimizations (such as branch prediction logic) to fail. The fix for this is to copy the builtin functions into the same memory region as the generated code. This change is especially impactful for the new Apple M1 chip. Please see our V8 blog post to learn more about the impact across platforms of this feature.

Stay turned for many more performance improvements to come!

Posted by Thomas Nattestad, Chrome Product Manager

Data source for all statistics: Speedometer 2.0.

Digging for performance gold: finding hidden performance wins

Thursday, April 22, 2021

We are fortunate that so many people choose Chrome as their browser to get things done, which is why we are continually investing in making Chrome more performant. But with software as complex as Chrome, there is a lot of performance left hidden in areas we aren’t actively working on. In our latest post in the The Fast and the Curious series, we investigate how to diagnose, find, and fix performance problems that normally go undetected.The 1%

Approach

As engineers, our training in optimization is to focus on improving the algorithmic performance of the components we own. The last 3 years of analyzing the immensely complex codebase of Chrome however have taught us that the real issue is often cross-cutting: multiple unrelated features’ long-tail performance issues, sharing the same systemic root cause(s). Applying local expertise and optimization is likely to miss the global optimum. It is necessary to disregard our initial intuition and assume ignorance, forcing us to dig beyond what is immediately apparent and find the underlying root cause by relentlessly exposing what we don’t know.

Chasing Invisible Bugs

How do we find bugs that are unforeseen, unreproducible, unowned, and essentially invisible?

First, define a scenario. For this work, we focus on user-visible Jank, which we measure in the field as a way to systematically identify moments where Chrome feels slow.

Second, gather high actionability bug reports in the field. For this we rely on Chrome’s BackgroundTracing infrastructure to generate what we call Slow Reports. A subset of Canary users who have opted in to sharing anonymized metrics have circular-buffer tracing enabled to examine specific scenarios. If a preconfigured threshold on a metric of interest is hit, the trace buffer is captured, anonymized, and uploaded to Google servers.

Such a bug report might look like this:

chrome://tracing view of a 2 seconds Jank on AutocompleteController::UpdateResult() on an otherwise healthy machine

We have a culprit! Let’s optimize AutocompleteController? No! We don’t know why yet: keep assuming ignorance!

By augmenting BackgroundTracing with stack sampling, we were able to find a recurring stack under stalled AutoComplete events:
RegEnumValueW

RegEnumValueWStub

base::win::RegistryValueIterator::Read()

gfx::`anonymous namespace\'::CachedFontLinkSettings::GetLinkedFonts

gfx::internal::LinkedFontsIterator::GetLinkedFonts()

gfx::internal::LinkedFontsIterator::NextFont(gfx::Font *)

gfx::GetFallbackFonts(gfx::Font const &)

gfx::RenderTextHarfBuzz::ShapeRuns(...)

gfx::RenderTextHarfBuzz::ItemizeAndShapeText(...)

gfx::RenderTextHarfBuzz::EnsureLayoutRunList()

gfx::RenderTextHarfBuzz::EnsureLayout()

gfx::RenderTextHarfBuzz::GetStringSizeF()

gfx::RenderTextHarfBuzz::GetStringSize()

OmniboxTextView::CalculatePreferredSize()

OmniboxTextView::ReapplyStyling()

OmniboxTextView::SetText...)

OmniboxResultView::Invalidate()

OmniboxResultView::SetMatch(AutocompleteMatch const &)

OmniboxPopupContentsView::UpdatePopupAppearance()

OmniboxPopupModel::OnResultChanged()

OmniboxEditModel::OnCurrentMatchChanged()

OmniboxController::OnResultChanged(bool)

AutocompleteController::UpdateResult(bool,bool)

AutocompleteController::Start(AutocompleteInput const &)

(...)

Ah ha! Autocomplete is not at fault. Time to optimize GetFallbackFonts()?! But wait… Why is GetFallbackFonts() even called in the first place?

And before we figure that out, how do we know this is the #1 root cause of our overall long-tail performance issue? We’ve only looked at one trace so far after all...

The Measurement Conundrum

The metrics tell us how many users are affected and how bad it is, but they do not highlight the root cause.

Slow Reports tell us what the problem is for a specific user but not how many users are affected. And while we can query our corpus of Slow Report traces, it comes with inherent biases that make it impossible to correlate 1:1 with metrics. For instance, because Chrome only reports the first instance of bad performance per-session and only for users of the Canary/Dev channel, there’s both a startup and a population bias.

This is the measurement conundrum. The more actionability (data) a tool provides, the fewer scenarios it captures and the more bias it incurs. Depth vs. breadth.

Tools that attempt to do both sit somewhere in the middle, where they use aggregation over a large dataset and risk showing aggregate results based on flawed input (e.g. circular buffer tracing having dropped the interesting portion and contributing to a biased aggregate).

Thus we scientifically opted for the least engineering-minded option: open a bunch of Slow Report traces manually. This gave us the most actionability over a top-level issue we’d already quantified.

After opening dozens of traces it turned out that a great majority showed variations of the aforementioned fonts issue. While this didn’t give us a precise #users-affected, it was enough for us to believe it was the main cause of user pain seen in the metrics.

Fallback Fonts

We dug into why GetFallbackFonts() had to be called in the first place. In the example above, the caller is trying to determine the size in pixels of a Unicode string rendered by a given font.

If a substring within it is from a Unicode Block that can’t be rendered by the given font, GetFallbackFont() is used to request the system recommended fallback font for it. If that fails, GetFallbackFonts() is invoked to try all the linked fonts and determine the one that can best render it; that second fallback is much slower.

GetFallbackFont() should never fail, but in practice it’s not that simple. The reliable way to do this on Windows is to query DirectWrite; however, DirectWrite was added in Windows 7, when Chrome still supported Windows XP. Therefore the GetFallbackFont() logic was forced to stick to a less reliable heuristic using Uniscribe+GDI in order to work on both versions of the OS. Since things worked most of the time, no one noticed that this could have been cleaned up when Chrome later dropped support for Windows XP. With new tooling to investigate long-tail performance, this turned out to be the number one cause of jank (unnecessarily invoking GetFallbackFonts()).

We fixed that, reducing the amount of calls to GetFallbackFonts() by 4x.

Still not zero though, and still seeing instances of the aforementioned AutoComplete issue in our Slow Reports. Keep digging. DirectWrite’s GetFallbackFont() failing was unexpected, but since Slow Reports are anonymized, no user-generated strings can be uploaded -- and therefore, finding which codepoints were problematic was tricky. We teamed up with our privacy experts to instrument Unicode Block and Script of text blocks going through HarfBuzz so that we could ensure no leakage of Personally Identifiable Information.

The Emoji Saga

With this new recording enabled, the next wave of Slow Reports came back. The vast majority of reports indicated that font fallback was failing when DirectWrite was being asked to find a font for a codepoint (Unicode character) in Miscellaneous Symbols and Pictographs. We wrote a local script trying all codepoints in that Unicode Block and quickly found out which ones could be problematic: U+1F3FB - U+1F3FF are modifiers added in Unicode 8.0 and are meaningful only when paired with another codepoint. For instance, U+1F9D7 (🧗) when paired with U+1F3FF is 🧗🏿. No font can render U+1F3FF on its own, and font fallback would correctly error out after scanning all linked fonts when asked to find one. The bug was in the browser-side Unicode segmentation logic which incorrectly broke down these two codepoints and asked DirectWrite to render them separately instead of keeping them as a single grapheme.

But wait, doesn’t Chrome support modern Unicode..?! Indeed, it does, in Blink which renders the web content. But the browser-side logic was not updated to support modern emojis (with modifiers) because it didn’t use to draw emojis at all. It’s only when the browser UI (tab strip, bookmark bar, omnibox, etc.) was modernized to support Unicode circa 2018 that the legacy segmentation logic became an (invisible) problem.

On top of that, the caching logic did not cache on error, so trying to render a modifier on its own caused a massive jank, every time, for users with a lot of fonts installed. Ironically, this cache had been added to amortize the cost of this misunderstood bottleneck when Unicode support was first added to browser UI. Diving deeper into the underlying implementation of our fonts logic, rather than stopping at the layer of the fonts APIs, not only fixed a major performance issue but also resulted in a correctness fix for other emojis. For instance, 🏳️‍🌈 is encoded as U+1F3F3( 🏳️) + U+1F308 (🌈); before the itemization fix, browser UI would incorrectly render this grapheme as 🏳️🌈.

And the journey continues...

Our journey keeps going into various components of Chrome but it always follows the same basic playbook: assume ignorance and relentlessly investigate unforeseen, unreproducible, and unowned bugs. And while stack ranking issues is nigh impossible (see: measurement conundrum), fixing the top 5 findings from any given tool and zooming in on the long tail has always addressed the majority of the user pain in practice.

Using this approach, we have reduced user-visible jank by a factor of 10X over the last 2.5 years and improved long-tail performance of many features caught in the cross-fire.

99th percentile of # of unresponsive 100ms intervals over a 30 seconds sample

Posted by Gabriel Charette 🤸🏼 and Etienne Bergeron 🕵🏻, Chrome Software Engineers

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.

Chromium Blog

How Chrome Became the Highest Scoring Browser on Speedometer, Ever

A new speed milestone for Chrome

Chrome on Windows performance improvements and the journey of Native Window Occlusion

Faster Chrome - Let The Compiler do the work

Partitioning Chrome's Code for Faster Launch Times on Android

Searching, browsing, and shutdown Chrome performance improvements

RenderingNG: an architecture that makes and keeps Chrome fast for the long term

Faster and more efficient phishing detection in M92

Chrome is up to 23% faster in M91 and saves over 17 years of CPU time daily

Digging for performance gold: finding hidden performance wins

Labels

Archive

Feed

May	JUN	Jul
	06
2021	2022	2023