Chromium Blog: speed

The Wayback Machine - https://web.archive.org/web/20210205070103/https://blog.chromium.org/search/label/speed

Chrome just got faster with Profile Guided Optimization

Tuesday, August 25, 2020

From the very beginning, we built Chrome to be the fastest browser possible. The faster Chrome is, the faster you find the information you want or finish the task you need to do. With M85, users will find a noticeably faster Chrome, thanks to our two latest improvements: Profile Guided Optimization, which delivers up to 10% faster page loads; and Tab Throttling, which helps reduce the impact of idle background tabs, coming to the Beta channel.

Profile Guided Optimization

Simplified, Profile Guided Optimization (PGO) is a compiler optimization technique where the most performance-critical parts of the code can run faster. Because PGO uses real usage scenarios that match the workflows of Chrome users around the world, the most common tasks get prioritized and made faster. It is rolling out with Chrome M85 on Mac and Windows.

PGO was initially introduced in M53 for Chrome on Windows using Microsoft Visual C++ (MSVC), our previous build environment. In M85, we are rolling out PGO on Mac and Windows using Clang. Our testing consistently shows pages loading up to 10% faster at the median, and even greater speed improvements when your CPU is tasked with running many tabs or programs.

Platform	Browser Responsiveness*	First Contentful Paint**	Speedometer 2.0
Mac	3.9% faster	2.3% faster	7.7% faster
Windows	7.3% faster	3.5% faster	11.4% faster

Tab throttling coming to Beta

We know you need a lot of tabs to do your work, and with tab throttling - now rolling out on Beta channel - Chrome will give more resources to the tabs you’re using by taking them back from tabs that have been in the background for a long time. We see improvements not only in loading speed but also battery and memory savings. Watch this space for more on that work when it is broadly available!

Chrome's performance - speed and usage of resources like power, memory, or CPU - has always been top of mind. We have a dedicated engineering team that has been consistently (and quietly) making improvements so Chrome runs faster and smoother on all devices, operating systems, and internet conditions. No matter if you are a heavy tab user on your Windows laptop, or need a lightweight app experience on your Android phone, we are working hard to use your device resources most efficiently.

Posted by Max Christoff, Engineering Director, Chrome

*How fast your browser responds to user input (real world data anonymously aggregated from Chrome pre-stable channels)

** The time it takes the first text or image to be displayed upon loading a page (real world data anonymously aggregated from Chrome pre-stable channels)

The Science Behind Web Vitals

Thursday, May 21, 2020

Web Vitals is an initiative by Google to help business owners, marketers and developers alike identify opportunities to improve user experiences. These signals are guided by extensive work by many researchers in the fields of human–computer interaction (HCI) and user experience (UX). But figuring out the right metrics and thresholds is not as simple as picking up a research paper and finding the answer. Journeys, not pages Imagine you’re walking through an unfamiliar city to get to an important appointment. You walk through various streets and city centers on your way. But here and there, loose paving stones make you trip, there are slow automatic doors you have to wait for to open, and unexpected construction detours lead you astray. All of these events interrupt your progress, increase stress and distract you from reaching your destination. People using the web are also on a journey, with each of their actions constituting one step in what would ideally be a continuous flow. And just like in the real world, they can be interrupted by delays, distracted from their tasks and led to make errors. These events, in turn, can lead to reduced satisfaction and abandonment of a site or the whole journey. In both cases, removing interruptions and obstacles is the key to a smooth journey and a satisfied user. So what trips users up on the web? Interruptions due to waiting The most common type of interruption web users experience is waiting for pages to load. For a developer, a page load is a discrete event and some delay might feel inevitable. However, a page load more often happens in the middle of a user's journey, as they learn about recent events in the news, research a new product or add items to a cart for purchase. So from the user's point of view, loading a particular page doesn't represent a natural break: they haven’t yet achieved their goal, which may make them less tolerant of delays.¹ This means pages need to load fast so the user's journey can flow smoothly. How fast is fast enough? In a way, that’s the wrong question. There’s no single magic number and there's three main reasons why. First, the answer depends on the outcome you consider, for instance abandonment, user satisfaction or task performance. Different studies focus on different outcomes and yield different results. Second, the effect of delays varies hugely depending on a user's personality, past experience and the urgency of their task.² For example, if you were to plot how many users stayed on a site as a function of the delay they experienced, you would not see a clean step from 100% to 0% after X seconds. You would instead see a smooth distribution that might look like this:

Chart showing the percent of users remaining decreasing as the delay increases

So we must ask: which point on this curve do we aim for? In other words, how much do we invest in speed on the one hand, and how many of our users will we lose on the other? Finally, the effect of delays varies depending on the context and situation. News sites, shopping sites and travel sites are often part of different kinds of user journeys, and the entire curve above might look different for each of them. Even within a context, site design and user behavior can change over time. Although this is more difficult than we may have hoped, a distribution of outcomes at different levels of performance still contains useful hints. In particular, the distribution reveals how many users we may lose (or are losing currently) at a given level of performance. In addition, the steepness of the curve at different points can tell you how much return you’ll get for optimising speed by a particular amount. These are important factors in your tradeoff decision, since your time as a designer or engineer is also valuable. So instead of looking for a single magic number, our goal is to find in the research useful ranges of values and reasonable guidelines. For example:

One study found that delays decreased satisfaction and intention to return. On unfamiliar sites, 2 seconds of delay was enough to cause most of the drop – familiar sites bottomed out after longer delays. On unfamiliar sites, task performance also suffered, with most of the drop observed with delays of up to 4 seconds.³

Another study involved navigating a nested menu on a web page. A range of delays, 3 seconds apart, was tested for loading each panel. Satisfaction dropped when increasing the delay from 0 to 3 seconds and again when going from 9 to 12 seconds. Intention to return also dropped with the 12-second delay. A 6-second delay was enough for some participants to remark on the site being slow.⁴

One study found that mobile web users didn’t tend to keep their attention on the screen for more than 4–8 seconds at a time.⁵ This would mean that if they avert their attention before your page has loaded, the time they’re looking away further delays how soon they finally see the page. So a 5-second load time might turn into a 10-second effective delay.

It’s been suggested that the speed of a system’s response should be comparable to the delays humans experience when they interact with one another. This has led to guidance that responses should take about 1–4 seconds.⁶

The empirical studies are drawn from data with high variability and gradual drop-offs rather than hard thresholds, and the others are based on predictions from theory. But collectively they suggest that it’s worth aiming to keep load times within a couple of seconds. The Largest Contentful Paint (LCP) metric measures when a page-to-page navigation appears complete to a user. We recommend sites aim to keep LCP under 2.5 seconds for 75% of their page loads. This recommendation is further informed by Chrome analysis of the web today and aims to be feasible for enough sites to attain in practice. For more details of that analysis, see Defining the Core Web Vitals metric thresholds. Interruptions and errors from instability Most web pages need to load several elements, and often these load progressively. This can actually be a good thing: if some content appears as early as possible, it may allow a user to start making progress towards their goal without waiting for everything to load. However, if the position of already-visible elements shifts as others load, this can negatively affect the user’s experience in two ways. One is that if an element they’re looking at suddenly moves, it will take their eyes at least a couple hundred milliseconds to find its new position.⁷ If it scrolled out of view, it will take much longer. This type of interruption slows the user journey and can be very frustrating. A more serious consequence is that unexpected layout shifts can lead to errors. If the user is trying to tap an element that then moves, they may end up tapping something else that moved into its original position. This is because the delay from perceiving the shift, deciding to abandon their action and then doing so can make it impossible for a human to respond appropriately. This could mean clicking a link or ad or "Buy Now" button unintentionally and significantly disrupting the user's intended journey. Cumulative Layout Shift (CLS) measures how frequent and severe unexpected layout shifts are on a page. Fewer shifts mean less chance for interruption and errors. We recommend sites aim for a CLS of less than 0.1 for 75% of page loads. Distraction and errors from low responsiveness While page loads represent the larger transitions in a user’s journey – like entering a building – the small steps also matter. When you’re walking, you don’t really want to be conscious of the mechanics of walking. Ideally, you actually forget that you’re walking and can focus on other things, like finding your way. But something like having a stone in your shoe will interfere with that concentration. Likewise, you don’t want users’ experience to suffer from frictions in their moment-to-moment interactions with your site. Here are some research insights relevant to achieving this:

One study found that a delay in visual feedback from touch screen buttons became perceivable when it was increased from 70ms to 100ms. When it was further increased from 100ms to 150ms, people also rated the quality of the buttons as significantly lower.⁸

One experiment showed that in an animation, the illusion that one event caused another started breaking when there was a delay of about 100ms.⁹ It’s been suggested that similarly, the illusion of direct manipulation in user interfaces will break down with delays longer than this.¹⁰ (This guidance was apparently also informed by an earlier best-guess recommendation that actions should have a visible effect within 100–200ms.¹¹)

Just as for LCP, there’s no “magic number”, only markers representing distributions. Some individuals are much more sensitive than others,¹² and shorter delays may be noticed when haptic or auditory feedback is involved.¹³ Aside from changing how the UI feels, delaying something people expect to be near-instantaneous can lead them to make errors. They may repeat an action because they think it didn’t work, and the second action can have an undesirable effect. For example, they may click an “add to cart” button twice and not realise that they’re now buying two items. The responsiveness related to these experiences is measured by First Input Delay (FID), and we recommend sites aim to keep FID under 100 milliseconds for 75% of page loads. Impact We analyzed millions of page impressions to understand how these metrics and thresholds affect users. We found that when a site meets the above thresholds, users are 24% less likely to abandon page loads (by leaving the page before any content has been painted). We also looked specifically at news and shopping sites, sites whose businesses depend on traffic and task completion, and found similar numbers: 22% less abandonment for news sites and 24% less abandonment for shopping sites. There are few interventions that can show this level of improvement for online businesses, and results like these are part of the reason we and our ecosystem partners prioritize the Web Vitals metrics. Providing a smooth journey for users is one of the most effective ways to grow online traffic and web-based businesses. We hope the Web Vitals metrics and thresholds will provide publishers, developers and business owners with clear and actionable ways to make their sites part of fast, interruption-free journeys for more users. Amar Sagoo, Staff Interaction Designer
Annie Sullivan, Software Engineer
Vivek Sekhar, Product Manager ¹ Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
² Shneiderman, B. (1984). Response Time and Display Rate in Human Performance with Computers. ACM Computing Surveys (CSUR), 16(3), 265–285.
³ Galletta, D. F., Henry, R., McCoy, S. & Polak, P. (2004). Web Site Delays: How Tolerant are Users? Journal of the Association for Information Systems, 5(1), 1.
⁴ Hoxmeier, J. A. & DiCesare, C. (2000). System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications. AMCIS 2000 Proceedings, 347.
⁵ Oulasvirta, A., Tamminen, S., Roto, V. & Kuorelahti, J. (2005). Interaction in 4-Second Bursts: The Fragmented Nature of Attentional Resources in Mobile HCI. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 919–928).
⁶ Card, S. K., Robertson, G. G., & Mackinlay, J. D. (1991). The information visualizer, an information workspace. In Proceedings of the SIGCHI Conference on Human factors in computing systems (pp. 181-186).
Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
⁷ Purves D., Augustine G. J., Fitzpatrick D., et al. (2001). Types of Eye Movements and Their Functions. Neuroscience (2nd edition).
⁸ Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.
⁹ Card, S. K. (Ed.). (2018). The psychology of human-computer interaction. Crc Press.
¹⁰ Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
¹¹ Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
¹² Jota, R., Ng, A., Dietz, P., & Wigdor, D. (2013, April). How fast is fast enough? a study of the effects of latency in direct-touch pointing tasks. In Proceedings of the sigchi conference on human factors in computing systems (pp. 2291-2300).
¹³ Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.

10 years of Speed in Chrome

Tuesday, September 11, 2018

* { 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

Chromium Blog

Chrome just got faster with Profile Guided Optimization

The Science Behind Web Vitals

10 years of Speed in Chrome

Labels

Archive

Feed

Jan	FEB	Mar
	05
2020	2021	2022