Chromium Blog: 10 years of Speed in Chrome

Chromium Blog

News and developments from the open source browser project

* { line-height: 1.38 !important; white-space: initial !important; } ul { font-size: 11pt !important; } li { line-height: 1.38 !important; } img { margin-bottom: 0 !important; } i { text-align: center !important; } Speed has been one of Chrome’s four core principles, since it was first launched ten years ago. We’ve always wanted to enable web developers to provide users with fast, engaging web experiences. On Chrome’s 10th birthday, we thought it would be fun to look at what we’ve done to improve speed over the years and what we’re doing next.

Many components in the browser contribute to speed V8 is Chrome’s JavaScript and WebAssembly engine. With web pages using an increasing amount of JavaScript, a fast engine to handle it is an important cornerstone. Over the years, we worked on a new JavaScript execution pipeline for V8, launching Ignition (a new interpreter) and TurboFan (an optimizing compiler). These allowed us to improve performance on the Speedometer benchmark by 5-10%. Script streaming enabled us to parse JavaScript on a background thread as soon as it began downloading, improving page loads by up to 10%. We then added background compilation reducing main-thread compile time by up to 20%.

Our work on project Orinoco enabled concurrent garbage collection, freeing up the main thread and reducing jank. Over time, we also shifted to focusing on real-world JavaScript performance, helping us double the performance of the React.js runtime and improve performance for libraries like Vue.js, Preact, and Angular up to 40%. Parallel, concurrent, and incremental garbage collection reduced garbage collection induced jank by 100× since the initial V8 commit. We also implemented WebAssembly, enabling developers to run non-JavaScript code on the web with predictable performance, and launched the Liftoff baseline compiler to ensure fast startup times of WASM apps. These new components are just the latest in a 10-year effort that has improved V8's performance release-to-release for an improvement of 20x over the years.

V8 Bench scores for a range of Chrome releases over the years. V8 Bench is the predecessor to the old Octane benchmark. We've used it for this chart because unlike Octane, it can run in all Chrome versions, including the initial Chrome Beta.

Chrome has also played a key role in helping evolve network protocols and transport layers through SPDY, HTTP/2 and QUIC. SPDY aimed to address limitations of HTTP/1.1 and became the foundation of HTTP/2 protocol, which is now supported by all modern browsers. In parallel, the team has been actively iterating on QUIC, which aims to further improve latency and user experience and now has an active IETF effort behind it. QUIC’s benefits are noticeable for video services like YouTube. Users reported 30% fewer rebuffers when watching videos over QUIC.

Next up is Chrome's rendering pipeline. This is responsible for ensuring webpages are responsive to users and display at 60 frames per second (fps). To display content at 60fps, Chrome has 16ms to render each frame. This includes JavaScript execution, style, layout, paint and pushing pixels to the user's screen. Of this 16ms, the less Chrome uses, the more web developers have to delight their users. Improvements to our rendering pipeline have included optimizing how we identify which elements in a page need to be redrawn and better tracking visually non-overlapping sets. This reduced the time to paint new frames to the screen by up to 35%.

In 2015, a user-centric performance model called RAIL was introduced by the Chrome team. We recently updated it.
What about memory consumption? Between Chrome 63 and 66, a ~20-30% improvement in renderer process memory usage was observed. We hope to continue exploring ways to build on this now that site-isolation has landed. Ignition and TurboFan reduced V8's overall memory footprint, slimming it down by 5-10% on all devices and platforms supported by V8. Some sleuthing this year also discovered memory leaks impacting 7% of sites on the web, which we’ve now fully fixed. Many components contribute to Chrome’s speed including the DOM, CSS and storage systems like IndexedDB. To learn more about our improvements to performance, continue keeping an eye on the Chromium Blog.

Give web developers more power to measure and optimize their web pages
Understanding where to start with improving your site can be a tedious process. To help, we explored several tools for understanding the lab signals and real-world experience felt by your users. Over the years, the Chrome DevTools Performance panel became a powerful way to visualize the play-by-play breakdown of how web pages were displayed in a lab setting. To continue lowering the friction for finding performance opportunities sites had, we then worked on Lighthouse - a tool for analyzing the quality of your website, giving you clear measurements of your site’s performance and specific guidance for improving your users’ experience. Lighthouse can be accessed directly from inside the DevTools Audits panel, run from the command-line, or integrated with other development products like WebPageTest.

Lighthouse running in the Chrome DevTools Audits panel
To complement the lab data provided by Lighthouse, we released the Chrome User Experience Report to help developers get access to field metrics for the experience their users feel in the real-world, such as First Contentful Paint and First Input Delay. Now, developers can build out their own custom site performance reports and track progress over millions of origins using the CrUX Dashboard.

We also introduced a number of Web Platform capabilities to help developers optimize the loading of their sites. We shipped Resource Hints and <link rel=preload> to allow developers to inform the browser what resources are critical to load early on. Chrome was one of the first browsers to implement support for byte-saving approaches like Brotli for compression, WOFF2 for smaller web fonts and WebP support for images.
We’ve been excited to see an increasing number of browsers support these features over time. Chrome implemented Service Workers, enabling offline caching & network resilience for repeat visits to pages. We’re delighted to see broad modern browser support for the feature.

In fact, Google Search now uses Service Worker and navigation preload for opportunistic caching on repeat searches. This led to a 2x improvement in page load times for repeat visits.
As we look to the future, we are also excited about the potential that emerging standards like native lazy-loading for images & iframes, and image formats like AV1 have to help deliver content to users efficiently.

Enjoy more of the web on your data-plan with Chrome

Over the last 10 years, the size of web pages has been ever-increasing, but for many users coming online for the first time, data can be prohibitively expensive or painfully slow. To help, Chrome released data-conscious features over the years like Chrome’s Data Saver. Data Saver intelligently optimizes pages, saving up to 92% on data consumption.

Going ahead, we are exploring new ways to help you save data. For users on the slowest connections, we've been working on Chrome for Android, allowing for smarter page optimizations to show essential content earlier. These page transformations load far faster than the full page, and we're continuing to improve our fidelity, coverage, and performance.

We've also been experimenting with putting guardrails in place for users who are data- or network- constrained. For example, we're exploring bringing native lazy-loading to Chrome, as well as providing users the option to stop additional requests from a page when it uses a lot of data.

We’re just getting started...

Together, these changes help developers and businesses deliver useful content to their users sooner. We know there’s still work to be done. Here’s to offering improvements to page load performance over another 10 years!

Posted by Addy Osmani, JavaScript Janitor

Google

Labels

$200K 1
10th birthday 4
abusive ads 1
abusive notifications 2
accessibility 3
ad blockers 1
ad blocking 2
advanced capabilities 1
android 2
anti abuse 1
anti-deception 1
background periodic sync 1
badging 1
benchmarks 1
beta 83
better ads standards 1
billing 1
birthday 4
blink 2
browser 2
browser interoperability 1
bundles 1
capabilities 6
capable web 1
cds 1
cds18 2
cds2018 1
chrome 35
chrome 81 1
chrome 83 2
chrome 84 2
chrome ads 1
chrome apps 5
Chrome dev 1
chrome dev summit 1
chrome dev summit 2018 1
chrome dev summit 2019 1
chrome developer 1
Chrome Developer Center 1
chrome developer summit 1
chrome devtools 1
Chrome extension 1
chrome extensions 3
Chrome Frame 1
Chrome lite 1
Chrome on Android 2
chrome on ios 1
Chrome on Mac 1
Chrome OS 1
chrome privacy 4
chrome releases 1
chrome security 10
chrome web store 32
chromedevtools 1
chromeframe 3
chromeos 4
chromeos.dev 1
chromium 9
cloud print 1
coalition 1
coalition for better ads 1
contact picker 1
content indexing 1
cookies 1
core web vitals 2
csrf 1
css 1
cumulative layout shift 1
custom tabs 1
dart 8
dashboard 1
Data Saver 3
Data saver desktop extension 1
day 2 1
deceptive installation 1
declarative net request api 1
design 2
developer dashboard 1
Developer Program Policy 2
developer website 1
devtools 13
digital event 1
discoverability 1
DNS-over-HTTPS 4
DoH 4
emoji 1
emscriptem 1
enterprise 1
extensions 27
Fast badging 1
faster web 1
features 1
feedback 2
field data 1
first input delay 1
Follow 1
fonts 1
form controls 1
frameworks 1
fugu 2
fund 1
funding 1
gdd 1
google earth 1
google event 1
google io 2019 1
google web developer 1
googlechrome 12
harmful ads 1
html5 11
HTTP/3 1
HTTPS 4
iframes 1
images 1
incognito 1
insecure forms 1
intent to explain 1
ios 1
ios Chrome 1
issue tracker 3
jank 1
javascript 5
lab data 1
labelling 1
largest contentful paint 1
launch 1
lazy-loading 1
lighthouse 2
linux 2
Lite Mode 2
Lite pages 1
loading interventions 1
loading optimizations 1
lock icon 1
long-tail 1
mac 1
manifest v3 2
metrics 2
microsoft edge 1
mixed forms 1
mobile 2
na 1
native client 8
native file system 1
New Features 5
notifications 1
octane 1
open web 4
origin trials 2
pagespeed insights 1
pagespeedinsights 1
passwords 1
payment handler 1
payment request 1
payments 2
performance 20
performance tools 1
permission UI 1
permissions 1
play store 1
portals 3
prefetching 1
privacy 2
privacy sandbox 4
private prefetch proxy 1
profile guided optimization 1
progressive web apps 2
Project Strobe 1
protection 1
pwa 1
QUIC 1
quieter permissions 1
releases 3
removals 1
rlz 1
root program 1
safe browsing 2
Secure DNS 2
security 36
site isolation 1
slow loading 1
sms receiver 1
spam policy 1
spdy 2
spectre 1
speed 4
ssl 2
store listing 1
strobe 2
subscription pages 1
suspicious site reporter extension 1
TCP 1
the fast and the curious 23
TLS 1
tools 1
tracing 1
transparency 1
trusted web activities 1
twa 2
user agent string 1
user data policy 1
v8 6
video 2
wasm 1
web 1
web apps 1
web assembly 2
web developers 1
web intents 1
web packaging 1
web payments 1
web platform 1
web request api 1
web vitals 1
web.dev 1
web.dev live 1
webapi 1
webassembly 1
webaudio 3
webgl 7
webkit 5
WebM 1
webmaster 1
webp 5
webrtc 6
websockets 5
webtiming 1
writable-files 1
yerba beuna center for the arts 1

Feed

Give us feedback in our Product Forums.

Google
Privacy
Terms

Chromium Blog

10 years of Speed in Chrome

Labels

Archive

Feed