Chromium Blog
News and developments from the open source browser project
10 years of Speed in Chrome
Tuesday, September 11, 2018
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 o
ptimizing 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
Octane: the JavaScript benchmark suite for the modern web
Tuesday, August 21, 2012
The web is evolving and so should the JavaScript benchmarks that measure its performance. Today, we are releasing
Octane
, a JavaScript benchmark suite that aims to measure a browser’s performance when running the complex and demanding web applications that users interact with daily.
Most of the existing JavaScript benchmarks run artificial tests that were created on an ad-hoc basis to stress a specific JavaScript feature. Octane breaks with this tradition and extends the former V8 Benchmark Suite with 5 new benchmarks created from full, unaltered [1], well-known web applications and libraries. A high score in the new benchmarks directly translates to better and smoother performance in similar web applications.
Here is an overview of the new tests:
Box2DWeb
runs a JavaScript port of a popular
2D physics engine
that is behind many well-known simulations and web games.
Mandreel
puts a JavaScript port of the 3D Bullet Engine to the test with a twist: The original C++ source code for the engine is translated to JavaScript by Onan Games’
Mandreel
compiler, which is also used in countless web-based games.
Pdf.js
is based on
Mozilla’s PDF reader
and shows how Javascript applications can replace complex native browser plug-ins. It measures how fast the browser decodes a sample PDF document.
GB Emulator
is derived from an
open source emulator
of a famous game console running a 3D demo.
CodeLoad
measures how quickly a JavaScript engine can bootstrap commonly used JavaScript libraries and start executing code in them. The source for this test is derived from open source libraries (
Closure
,
jQuery
).
Besides an expanded
set of benchmarks
, Octane also has an interface that makes it easier to read and that adapts automatically to tablet and mobile screens.
You can try out
Octane
yourself, browse the
source code
, or read more about each benchmark at the
Octane site
. Still have some questions? Have a look at the
FAQ page
.
[1]
Beside glue logic and emulation of canvas / DOM interaction where necessary.
Posted by Stefano Cazzulani, Product Manager
Better code optimization decisions for V8
Tuesday, May 1, 2012
As of current dev and beta channel releases, V8 uses a new algorithm based on counters to decide which functions to optimize. This greatly increases performance for small JavaScript programs. For example, on the SunSpider benchmark, which focuses on extremely short-running tests, V8's speed improved by about 25%.
When executing JavaScript, V8 at first compiles it to machine code with a very fast compiler that doesn't optimize the code it produces. V8 has a second,
optimizing compiler
that generates much faster machine code, but takes much more time to do so, so it has to be used selectively. That's why V8 must try to predict which functions will benefit most from optimization, and carefully decide when to optimize them.
In the past, V8 stopped once every millisecond to look at currently running functions, and eventually optimized them. For long-running programs, this worked great, but short-running programs often finished before they could benefit much from the optimizing compiler -- a single millisecond can be a long time to wait before optimizing! In addition, V8 often made different optimization decisions each time a JavaScript program ran, sometimes overlooking small but performance-critical functions.
The new version of V8 makes earlier and more repeatable optimization decisions by analyzing the running program in more detail. It uses counters to keep track of how often JavaScript functions are called and loops are executed in a program, approximating the time spent inside each function. That way V8 is able to quickly gather fine-grained information about performance bottlenecks in a JavaScript program, and to make sure that the optimizing compiler's efforts are spent on those functions that deserve it most.
The new algorithm is contained in the current beta channel releases -- go
give it a spin
now!
Posted by Jakob Kummerow, Software Engineer
V8 Benchmark Suite extended with physics simulation
Thursday, March 15, 2012
Today we are releasing version 7 of the
V8 Benchmark Suite
. This new version adds
Oliver Hunt’s
2D
Navier-Stokes
fluid dynamic simulation, which stresses intense double array computations. These complex double array computations are today common in games, graphic and scientific applications.
The new test shows the recent improvements V8 has made in handling advanced physics computations: the current
Chrome 18
(today in beta) delivers a 5% score improvement compared to the current Chrome 17.
Chrome 19
(today in canary), where the full set of improvements is being released, delivers a whopping 25% score improvement compared to Chrome 17.
With these additions, the V8 Benchmark Suite is now a more comprehensive collection of eight tests, including OS kernel simulation, crypto and string operations, memory management stress-tests, and as of today, double array computations.
We plan to keep updating the suite by adding more tests. These updates are a reflection of Chrome’s commitment to keep pushing the boundaries of speed, optimizing the engine for today’s more demanding web apps.
Posted by Stefano Cazzulani, Product Manager
A game changer for interactive performance.
Monday, November 21, 2011
Today we are announcing the release of Chrome’s new
incremental garbage collector
(GC) which dramatically improves interactive performance of web apps and HTML5 games.
The V8 project has made
huge progress
improving
peak performance
of web apps. With the advent of technologies like
WebGL
we’re seeing the emergence of highly interactive and graphically intensive apps, such as the
new version of Google Maps
,
new games
and
demos
. But with these new uses comes a need for better
interactive performance
in JavaScript.
Avoiding pauses is vital to achieving good interactive performance. Previously, garbage collection pause times depended on the amount of memory used. Therefore, large interactive apps were impacted by pauses that caused hiccuping. V8’s new GC reduces pause times dramatically while maintaining great peak performance and memory use.
To evaluate the new GC, we took the most memory intensive peak performance test from the V8 Benchmark Suite and used it to make a
stress test
for interactive performance. In our testing the maximum time to render a frame including pause time is reduced from 272ms to 50ms.
The new GC in Chrome improves interactive performance and opens up new possibilities for the interactive web. If you are developing highly interactive web apps or games, please try it out and share your experiences. It is available now on the
dev channel
.
Posted by Vyacheslav Egorov and Erik Corry, Software Engineers
Updating JavaScript Benchmarks for Modern Browsers
Wednesday, May 4, 2011
Benchmarks are incredibly important for influencing the direction of JavaScript engines. Over the past two years, JavaScript has gotten dramatically faster across all major browsers, particularly in areas that popular benchmarks measure. As it turns out, browser developers are a competitive bunch. However, as JS engines get faster, benchmarks must evolve in order to keep pushing them in the right direction.
We’ve been constantly updating our
V8 benchmark suite
to force us to get faster in areas that are important to web developers. We’ve fixed bugs and added new tests for
regular expressions
and
memory management
. We’re very focused on JavaScript performance, so we scrutinize our benchmark carefully to make sure that it’s as useful a measuring stick as possible.
The two other widely cited JS benchmarks are
SunSpider
from Apple, and
Kraken
, a new benchmark from Mozilla.
SunSpider was one of the first suites of tests, first appearing in 2007. It’s done a lot to help improve JS engines, but many of the tests in the suite are less relevant to the web in 2011. Even for the more relevant tests, JavaScript has gotten so fast that many finish in only a few milliseconds. This just isn’t long enough to figure out which engine is faster--a golf cart and a Tesla will finish a 10-foot race in nearly the same time.
To make the benchmark more meaningful, we’ve experimented by making the race longer by running each of the tests in SunSpider 50 times consecutively. While repeating a trivial test many times isn’t a great solution, it does provide an opportunity for some optimization. With this change, the results begin to reflect Chrome’s true performance. It’s more than 30% faster on the SunSpider suite overall and up to 4x faster on some of the individual tests.
Kraken, a more modern benchmark, is in better shape. Unfortunately, the
canonical
version of the benchmark has not been updated to reflect all the latest changes which address at least
one important bug
. As a result, the benchmark is less useful and has even (mis)led us to spend time making some
irrelevant optimizations
in Chrome. To help us focus on the right things, we’re now testing the latest version of Kraken built directly from Mozilla’s source code repository.
We’re posting a
modified version of SunSpider
and the
latest version of Kraken
to make it easy to run the benchmarks in your own browser and compare results.
Posted by Mike Belshe, Software Engineer
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
Archive
2024
Aug
Jun
May
Apr
Mar
Feb
2023
Nov
Oct
Sep
Aug
Jun
May
Apr
Feb
2022
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
