Speed has been one of Chrome’s four core principles since the browser was first introduced a decade ago. We’ve always wanted Web developers to be able to provide users with a fast, great Web experience. As Chrome marks its 10th anniversary, we thought it would be interesting to look back at the efforts we’ve made to speed up over the past decade and what we’re trying to do next.
Multiple browser components dedicated to speed up
V8 is a JavaScript and WebAssembly engine for Chrome. With the rapid increase in the number of JavaScript scripts used on web pages, a high-speed engine capable of handling these JavaScript scripts becomes a very important foundation. Over the years, we developed a new JavaScript execution pipeline for V8, enabling Ignition (a new interpreter) and TurboFan (an optimized compiler). These actions have improved our performance on speed benchmarks by 5-10%. Script Streaming allows JavaScript scripts to be parsed in a background thread as they begin to download, which can increase page loading speed by up to 10%. The background compilation process that was added later reduced the compilation time of the main thread by up to 20%.
Our work on the Orinoco project enabled concurrent garbage collection, freeing up the main thread while reducing jank. Over time, we’ve also shifted our focus to actual JavaScript performance, which has helped us double the runtime performance of React and increase the performance of libraries like Vue, Preact, and Angular by up to 40%.
Since the original V8 commit went live, parallel, concurrent, incremental garbage collection has been reduced to one percent of jank-induced garbage collection. We also implemented WebAssembly, allowing developers to run non-javascript code on the Web with predictable performance, and enabled the Liftoff baseline compiler to ensure fast startup times for WASM applications. These new components are the latest in a decade of efforts to improve V8 performance, resulting in more than a 20-fold improvement in performance.
The chart above shows the scores of Chrome releases for the V8 platform in recent years. The V8 platform is the predecessor of the old Octane benchmark, and we use it in this chart because, unlike Octane, the V8 platform runs in all versions of Chrome, including the most recent test version.
Chrome also plays a key role in helping to evolve and update network protocols and transport layers with SPDY, HTTP/2, and QUIC. SPDY was designed to overcome the limitations of HTTP/1.1 and became the basis for HTTP/2, which is now supported by all modern browsers. At the same time, the team was actively iterating on A QUIC designed to better improve latency and user experience, and behind the QUIC was an active engineering task Force (ITEF) effort. The effect of QUIC is evident on video sites like YouTube, where users report a 30 percent reduction in re-caching rates when watching videos with The help of QUIC.
Next is Chrome’s rendering Pipeline. This component is used to ensure that the web page is responsive to the user and displayed at 60 frames per second. In order to display content at 60fps, Chrome must render each frame in 16 milliseconds. This includes JavaScript script execution, styling, cascading layout, drawing, and pushing pixels to the user’s screen. The less Chrome is used in those 16 milliseconds, the more time developers have to make the user experience better. Our implementation of the render pipeline covers how optimization identifies elements that need to be redrawn on a page and better tracks sets of visually non-overlapping elements. This process reduces the time to draw a new frame image to the screen by up to 35%.
In 2015, the Chrome team proposed a user-centric performance model called RAIL. We recently updated it.
In terms of memory consumption, between Chrome versions 63 and 66, memory usage for renderer processing increased by approximately 20% to 30%. We want to continue exploring rail-based build approaches with site isolation in place. The use of Ignition and TurboFan reduced the V8’s overall memory footprint by 5% to 10% across all v8-supported devices and platforms. This year, some research found that 7% of sites on the Internet were affected by memory leaks, which we have fully fixed. The components used to speed up Chrome include DOM, CSS, and storage systems such as IndexedDB. If you want to learn more about what we’re doing to improve performance, check out the Chromium blog.
Give Web developers more ability to measure and optimize Web pages
Knowing where to start improving your site can be a tedious process. To help, we explored several tools for understanding the lab signals and real-world experiences experienced by users. Over the years, the Chrome DevTools performance panel has become a visual way to see how web pages are presented in a lab environment. To continue to reduce conflict and find potential for performance improvement on your site, we subsequently committed to Lighthouse, a tool for analyzing website quality that gives you clear metrics for site performance and specific guidelines for improving your user experience. Lighthouse can be accessed directly from DevTools Audits panels, run from the command line, or integrated with other development products such as WebPageTest.
Running Lighthouse in the Chrome DevTools Audits panel
To complement the experimental data provided by Lighthouse, we released the Chrome User Experience Report to provide developers with data on the real user experience of the people who use the product, such as first time content drawing and first input lag. Developers can now generate their own personalized website performance reports while keeping track of the progress of millions of sources through the CrUX dashboard.
We also introduced some Web platform features to help developers optimize their site load performance. Resource Hints and <link ref=preload> let developers tell the browser which key resources need to be loaded early. Chrome was one of the first browsers to implement byte-saving solutions such as Brotli for compression, WOFF2 for small Web fonts, and WebP for images.
We are pleased to see an increasing number of browsers supporting these features. Chrome implements Service Workers, eliminating offline caching and network elasticity to support repeated visits to web pages. We are also pleased to see that this feature is now supported by most modern browsers.
In fact, Google Search has applied the Servier Worker and navigation preload to conditional caching for repeated searches. This results in a two-fold improvement in page load time for repeated visits.
Looking to the future, we’re also excited about emerging standards such as native images and lazy loading for embedded frames, and image formats such as AV1 to help efficiently deliver content to users.
Enjoy the Web better with Chrome in your data planning
The number of web pages has grown at an unprecedented rate in the past decade, but many users are new to the Web, and the traffic can be costly or slow for them. For that reason, Chrome has introduced data-conscious features like Data Saver in recent years. The Data Saver intelligently optimizes web pages and saves up to 92% of your web traffic.
We’re also exploring new ways to save data. For those with the slowest connections, we’ve developed Chrome for Android to allow the smart Web optimizer to display the necessary content as early as possible. These page conversion loads are very fast compared to the entire page load, and we are constantly improving our accuracy, coverage, and performance.
We are also trying to provide some support and assistance to users with limited data or network access. For example, we’ve added a native lazy loading mechanism to Chrome, as well as an option for users to stop other requests from a page if they’re using a lot of data.
We’re just getting started
Taken together, these changes help developers and businesses deliver useful content to their users faster. We know there’s still a lot of work to be done, and we’ll see more improvements and improvements in page loading performance over the next decade.
Open Source China
https://www.oschina.net/translate/10-years-of-speed-in-chrome