Chromium Blog: 2023

Redesigning Chrome downloads, to keep you productive and safe online

Thursday, August 3, 2023

Main image of blog post that showcases the new download experience for Chrome on the right side of the Chrome Address bar.

With the latest release of Chrome for desktop we are introducing a redesign of the Chrome downloads experience to make it easier for you to interact with your recent downloads. Let's go behind the scenes and learn more about this redesign from Chrome Senior Product Manager Jasika Bawa.

What influenced your decision to redesign Chrome downloads?

Downloads are a core part of day to day web browsing, from getting the perfect cat themed background for your PC to saving a copy of your tax return. Over the years, we have listened to your feedback about the legacy Chrome downloads experience. We learned that while there was a lot about it that worked well for you, like strong support for core download journeys and built-in protection from potentially harmful files, it had its problems too. For example, it –

Occupied precious pixels at the bottom of the screen which squeezed the web content area, and was limited by screen width in how many files it could show at once
Didn't go away automatically, and only offered actions such as pause/resume and open in folder from a fixed overflow menu
Was no longer modern, interactive, and consistent with the look and feel of other browser UI or the browser ecosystem at large

All this made it clear that there was room for improvement for us to create a more intuitive experience for downloading in Chrome.

What does the redesign have to offer?

The new download tray is available to the right of the Chrome address bar and replaces the legacy downloads experience at the bottom of your screen. When a download is in progress, an animated ring helps you monitor it with a quick glance. The tray opens when you've finished downloading a file and automatically dismisses itself, making it easy to access quickly and allowing you to continue browsing uninterrupted.

GIF of the Chrome browser with the cursor clicking the “save” option of a web file. The download in progress icon appears with a progress ring around it. Once the file has finished downloading, the download tray opens automatically.

With the download tray, you can see a list of all your downloads from the past 24 hours in any browser window, not just the one in which you originally downloaded a file. The tray also offers in-line options to open the folder a download is in, cancel a download, retry a download should it fail for any reason, and pause/resume downloads.

GIF of the Chrome browser with the cursor opening the download tray to the right of the Chrome address bar. The download tray shows a file download in progress, and offers an in-line option to pause the download. The cursor clicks on the pause button, which turns into a play button. The cursor clicks on the play button to resume the download progress.

How will the new downloads experience help keep people safe online?

We always want to make sure you are safe when downloading files, so Chrome will continue to provide clear warning signs of potential malware or viruses to protect your device and accounts. In fact, the additional space and more flexible UI of the new Chrome downloads experience will give us the opportunity to provide even more context when Chrome protects you from a potentially malicious file, and enable us to build advanced deep scan options that we couldn't before. Be sure to watch the Google Security Blog for more details on these coming soon.

In addition to download warnings, the download tray being anchored next to the Chrome address bar helps create a clearer separation of trusted browser UI from web content, which was something we wanted to ensure with the redesign.

Image asset of Chrome browser with zoom in of download tray showing a notification that a dangerous file was blocked from being downloaded.

How did you think about making the transition to the new downloads experience easier?

It was important to us that all the functionality of the legacy Chrome downloads experience be made available in the new one. For example, you can still drag a downloaded file to another folder, program, or website, and perform actions like "Always open" from the new download tray. If you want a more detailed view of your downloads, you can continue to access this by selecting the "Show all downloads" option in the download tray, by clicking "Downloads" from the Chrome three dot menu, or by typing chrome://downloads in the Chrome address bar.

We also took feedback from our early experiments seriously, and used it to make changes like adjusting the frequency with which the download tray opens. You can even choose to have the tray not open automatically at all, in Chrome settings.

Image of the Downloads settings menu in Chrome browser when you can select the option to disable showing downloads when they're done.

Are there any steps developers need to take?

For developers, we'd like to highlight the opportunity to update any guidance or visuals you may have built to help guide users through their download journey. You may want to consider referencing the Download a file topic in the Google Chrome Help Center as a starting point.

For extension developers, it is worth noting changes to chrome.downloads extensions APIs in case you need to update your extensions – specifically, setShelfEnabled has been replaced by setUiOptions which lets you show or hide the new downloads experience.

We hope you'll enjoy this fresh coat of paint! We'll continue to build upon it in future releases to help you stay productive in Chrome while keeping you safe when downloading files from the web.

Posted by Joshua Cruz, Communications Manager

How Chrome achieved high scores on three browser benchmarks

Friday, June 2, 2023

Hero image for The Fast and the Curios series

Since the beginning of Chrome, benchmarks have been a key way by which we drive performance optimizations that benefit users. The most relevant web benchmarks today are Speedometer, MotionMark, and Jetstream. Over the last year Chrome has invested in optimizing against these specific benchmarks and has just achieved our highest scores across all three. These gains were achieved through a combination of large projects and small improvements. In today’s The Fast and the Curious post, we want to share just some of the ways we drove these improvements in Chrome. Announcing our brand new mid-tier compiler: Maglev We’re bringing a new mid-tier compiler to Chrome. Maglev is a just-in-time compiler that can quickly generate performant machine code for all relevant functions within the first one-hundredth of a second. It reduces overall CPU time to compile code while also saving battery life. Our measurements show Maglev has provided a 7.5 percent improvement on Jetstream and a 5 percent improvement in Speedometer. Maglev will start rolling out in Chrome version 114, which begins release on June 5.Speedometer Speedometer measures the responsiveness of websites by putting various JavaScript UI frameworks through their paces. Just over a year ago we shared details about how we increased our score from 100 to over 300 from Chrome version 40 to version 101. Since then, across 13 Chrome releases, we’ve achieved our new highest Speedometer score of 491. In addition to Maglev, the V8 team has achieved this score through both small adjustments, such as optimized function calls, and major, multi-quarter projects. A speedometer visual shows a 491 score for the Speedometer browser benchmark, which measures the responsiveness of websites. This is up from a score of 330 in the past year for Chrome.

A speedometer visual shows a 491 score for the Speedometer browser benchmark, which measures the responsiveness of websites. This is up from a score of 330 in the past year for Chrome.

Chrome 116.0.5803.2 running on an M2 Macbook Air with Maglev enabled

MotionMarkMotionMark is designed to test how much browser graphics systems can render at high frame rates. Chrome’s graphics and rendering teams have tracked over 20 optimizations since the start of the year, and more than half are available today. Together, these optimizations have almost tripled performance. Some highlights include improvements to Canvas performance, profile-guided optimization, GPU task scheduling, and layer compositing. We also created a novel algorithm for dynamic multisample anti-aliasing and out-of-process 2D canvas rasterization for improved parallelism. A speedometer visual shows a 4821.30 score for the MotionMark browser benchmark, which tests browser graphics systems. This marks a nearly 3X improvement in the last year for Chrome.

A speedometer visual shows a 4821.30 score for the MotionMark browser benchmark, which tests browser graphics systems. This marks a nearly 3X improvement in the last year for Chrome.

Chrome M115.0.5773.4 running on a 13” M2 Macbook Pro

Jetstream JetStream is a JavaScript and WebAssembly benchmark suite focused on advanced web applications. Many of the updates that we made for Speedometer also drove significant improvements on Jetstream as we optimized the V8 engine. In addition to these enhancements, Maglev drove the biggest gains in this benchmark. A speedometer visual shows a 330.939 score for the Jetstream2 browser benchmark, which focuses on advanced web applications. This improvement is largely driven by Maglev, a new just-in-time compiler in Chrome.

A speedometer visual shows a 330.939 score for the Jetstream2 browser benchmark, which focuses on advanced web applications. This improvement is largely driven by Maglev, a new just-in-time compiler in Chrome.

Chrome 116.0.5803.2 running on an M2 Macbook Air with Maglev enabled

Looking ahead
Because we’re optimizing against these benchmarks, it’s essential that these improvements translate to real user benefits, which is why we’re investing, along with other browsers, in creating the next generation of benchmarks. This has been an ongoing collaboration, and we’re excited to turn our efforts toward this new target in the coming year.
We hope you all enjoy a faster Chrome!

Posted by Thomas Nattestad, Product Manager

An Update on the Lock Icon

Tuesday, May 2, 2023

Editor’s note: based on industry research (from Chrome and others), and the ubiquity of HTTPS, we will be replacing the lock icon in Chrome’s address bar with a new “tune” icon – both to emphasize that security should be the default state, and to make site settings more accessible. Read on to learn about this multi-year journey.

Browsers have shown a lock icon when a site loads over HTTPS since the early versions of Netscape in the 1990s. For the last decade, Chrome participated in a major initiative to increase HTTPS adoption on the web, and to help make the web secure by default. As late as 2013, only 14% of the Alexa Top 1M sites supported HTTPS. Today, however, HTTPS has become the norm and over 95% of page loads in Chrome on Windows are over a secure channel using HTTPS. This is great news for the ecosystem; it also creates an opportunity to re-evaluate how we signal security protections in the browser. In particular, the lock icon.

The lock icon is meant to indicate that the network connection is a secure channel between the browser and site and that the network connection cannot be tampered with or eavesdropped on by third parties, but it’s a remnant of an era where HTTPS was uncommon. HTTPS was originally so rare that at one point, Internet Explorer popped up an alert to users to notify them that the connection was secured by HTTPS, reminiscent of the “Everything’s Okay” alarm from The Simpsons. When HTTPS was rare, the lock icon drew attention to the additional protections provided by HTTPS. Today, this is no longer true, and HTTPS is the norm, not the exception, and we've been evolving Chrome accordingly.

For example: we know that the lock icon does not indicate website trustworthiness. We redesigned the lock icon in 2016 after our research showed that many users misunderstood what the icon conveyed. Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon. This misunderstanding is not harmless — nearly all phishing sites use HTTPS, and therefore also display the lock icon. Misunderstandings are so pervasive that many organizations, including the FBI, publish explicit guidance that the lock icon is not an indicator of website safety.

When shown Chrome UI in research studies, users would look at the padlock to evaluate the trustworthiness of a hypothetical ecommerce site. We showed the site controls to experiment participants. The overlaid heat-maps represent the click patterns of respondents who were asked to indicate any information which was perceived helpful in the scenario.

The lock icon is currently a helpful entry point into site controls in Chrome. In 2021, we shared that we were experimenting with replacing the lock icon in Chrome with a more security-neutral entry point to site controls. We continued to mark HTTP as insecure in the URL bar. Users in the experiment opened the site controls more, and they didn't express any confusion that can follow major UI changes.

Site controls currently accessible from the lock icon.

Based on these research results from ourselves and others, and the broader shift towards HTTPS, we will be replacing the lock icon in Chrome with a variant of the tune icon. We think the tune icon:

Does not imply "trustworthy"
Is more obviously clickable
Is commonly associated with settings or other controls

We plan to replace the lock icon with a variant of the tune icon, which is commonly used to indicate controls and settings.

Replacing the lock icon with a neutral indicator prevents the misunderstanding that the lock icon is associated with the trustworthiness of a page, and emphasizes that security should be the default state in Chrome. Our research has also shown that many users never understood that clicking the lock icon showed important information and controls. We think the new icon helps make permission controls and additional security information more accessible, while avoiding the misunderstandings that plague the lock icon.

The new icon is scheduled to launch in Chrome 117, which releases in early September 2023, as part of a general design refresh for desktop platforms. Chrome will continue to alert users when their connection is not secure. You can see the new tune icon now in Chrome Canary if you enable Chrome Refresh 2023 at chrome://flags#chrome-refresh-2023, but keep in mind this flag enables work that is still actively in-progress and under development, and does not represent a final product.

Same page controls, new icon. The lock continues to exist as a precisely scoped entry point to connection security information, but with a new top-level access point.

We’ll be replacing the lock icon on Android at the same time as the broader desktop change. On iOS, the lock icon is not tappable, so we will be removing it entirely. On all platforms, we will continue to mark plaintext HTTP as insecure.

As HTTPS has become the norm, replacing the lock icon has long been a goal both of Chrome and the broader security community. We’re excited that HTTPS adoption has grown so much over the years, and that we’re finally able to safely take this step, and continue to move towards a web that is secure-by-default.

- By David Adrian, Serena Chen, Joe DeBlasio, Emily Stark, and Emanuel von Zezschwitz, and the rest of Chrome Trusty Transport from the Chrome Security team

More ways we’re making Chrome faster

Thursday, April 13, 2023

From the beginning of Chrome, one of our 4 founding principles has been speed, and it remains a core principle that guides our work. Today’s The Fast and the Curious post shares how recent technical improvements to Chrome have helped us reach a new performance milestone on the Speedometer browser benchmark across platforms.

Speed is a critical factor in determining your experience while browsing the Web. The faster the browser, the more enjoyable your browsing experience will be. With the latest release of Chrome, we went deep under the hood of Chrome’s engine to look for every opportunity to increase the speed and efficiency, from improved caching to better memory management.

Improved HTML Parsing & optimizing specific features

We discovered some targeted optimizations for the highly used JS `Object.prototype.toString` and `Array.prototype.join`functions. We also implemented targeted improvements in CSS’s InterpolableColor.

`innerHTML` is a very common way of updating the DOM via JavaScript so we added specialized fast paths for parsing. To our happy surprise, it seems some of this work will also be benefitting WebKit, which will include it in their engine as well. Our goal is always to create a better web experience for all web users so we’re happy to see this work having expanded impact!

More efficient pointer compression & allocations in V8 & Oilpan

Pointer compression is used to save memory in both V8 and Oilpan (the garbage collector for DOM objects). We made optimizations to how we compress and decompress pointers, and we avoid compressing high-traffic fields. Given how frequently these operations are done, it has a wide spread impact on performance. We also moved frequently accessed objects like JavaScript’s `undefined` to the beginning of the memory bases, allowing them to be accessed using faster machine code.

The improved features and efficient pointer compression collectively gave us a 10% increase in Apple’s Speedometer 2.1 browser benchmark over the course of three months.

Getting the Most out of High-End Mobile Devices

Chrome on Android has always been optimized for a small footprint, but the Android ecosystem is diverse and contains devices with varying levels of capabilities. To maximize the performance of Chrome on high-end devices, we are now targeting them with a version of Chrome that uses compiler flags tuned for speed rather than binary size.

For capable devices, these versions of Chrome run the Speedometer 2.1 benchmark 30% faster.

Posted by Thomas Nattestad, Senior Product Manager, and Andrew Grieve, Software Engineer

How WebAssembly is accelerating new web functionality

Monday, April 3, 2023

WebAssembly is fundamentally changing how new developer capabilities and functionality can be created on the web. In order to maintain browser interoperability, new web capabilities need to go through a rigorous standardization process and cross browser implementations. Decades of major investment has pushed the browser functionality to astonishing heights, but this process can take time and the web doesn’t need to have every capability built in. After years of investing in lower level capabilities that act as building blocks for higher level functionality, we are seeing a new dawn of expanded functionality at a dramatically expanded pace.

WebAssembly

WebAssembly is a portable bytecode format compiled from other languages to offer maximized performance. By leveraging WebAssembly, developers can take libraries and functionality from other platforms and performantly bring them to the web, without requiring any reimplementation. WebAssembly also offers advanced computation primitives like parallelizable threads and Single Instruction Multiple Data (SIMD) that enable it to maximize the performance from the CPU.

With WebAssembly offering portability plus performant access to the CPU the web now has the necessary low level building blocks for a huge variety of new functionality to be built. All of this, of course, rests on the incredible foundation that is the full web platform—full of powerful capabilities, rendering methods, and much more.

Real world examples

We’ve dedicated a whole blog post to showcasing just a small proportion of the new functionality being made available thanks to WebAssembly.

Some of these examples are functionality that tried to go through the standard process but didn’t make it for a variety of reasons. Other examples are being actively standardized and implemented across browsers.

FFMPEG on Wasm is enabling web apps to work effectively with videos. WebCodecs is a standardized alternative that offers similar encoding and decoding support, but it hasn’t been shipped across browsers yet.
WebAssembly powers background blurring for VC calls in Google Meet and there is now a dedicated standards proposal for this functionality
Web SQL was standardized and even shipped in Chrome for many years but never adopted sufficiently across browsers. SQLite on Wasm will replace Web SQL which will eventually be removed from Chrome.
Universal Scene Descriptor (USD) is shipping in Safari but isn’t available in other browsers.

Advantages of this new development paradigm

Faster iteration speed

Because functionality doesn’t have to go through standards and get approval before shipping, iteration cycles go from taking years down to days or even hours. Approaches like Origin Trials help enable more experimentation but still require weeks or months for iterations. When you change the iteration rate of something, you fundamentally change the thing itself.

Some fields like machine learning are advancing so fast that it is incredibly hard for standards-based approaches to keep up. By the time one design has gone through standardization and cross browser implementation, the field has moved on to something new which would have to go through the whole process again.

That being said, standardization is still essential for many things (see disadvantages section below) and when feasible, standardizing should absolutely be attempted.

Immediate support across browsers

Because wasm is supported across browsers, the functionality built on top of it will work across all browsers immediately as well. Interop and cross browser implementation of features is the biggest pain point for developers and by moving functionality to these lower level primitives, we’ll remove much of this concern.

Improved security

Because this functionality is built on top of incredibly hardened security sandboxes, there is substantially improved security compared to natively implemented APIs. Flash for example was removed from the web in large part because it was just too difficult to harden the complex plugin sufficiently, but now it can be run in WebAssembly, eliminating almost all security concerns.

Disadvantages and limitations

As with any new solution to complex problems, WebAssembly is not without disadvantages and limitations. Some of these are inherent and some have some promising solutions.

This won’t replace JavaScript for most web development

WebAssembly won’t replace JavaScript or make it obsolete, but rather extend its capabilities.

WebAssembly in the browser is still entirely dependent on JavaScript and needs to interface through JavaScript to access other web functionality. Libraries and new functionality enabled by WebAssembly will be utilized through JavaScript APIs. While there are some proposals that could enable wasm to wasm module communication and direct interfacing with Web APIs, this is still in the early stages of development.

Bundle size of pages

By moving more logic and functionality into userland, the size of pages will increase as well. This is a large problem as lower bundle size is the most important thing for a good user experience. As a result, developers should think carefully before ballooning their bundle size with this functionality, and it may be more relevant for larger web apps than smaller ecommerce or blog sites. This has long been an issue for JavaScript-heavy frameworks and is something where more solutions could be possible to improve the situation.

Another potential mitigation here is to look at the popular functionality being shipped in userland and use that as an input about what functionality should be standardized to ship with the browser itself. By being battle-hardened in userland, browsers will have higher confidence and validation on what they should ship, dramatically simplifying the standards and implementation work. WebCodecs replacing wasm compiled FFMPEG or the handwriting recognition API to replace the wasm compiled option are perfect examples of this.

Device capability access

WebAssembly and other primitives are largely computation mechanisms and don't give any kind of root system access to the OS or device itself. Functionality like hardware access (USB or Bluetooth), screen or window management, input controls, file system, clipboard, and much more still require platform level APIs to access. Chromium’s Fugu project is specifically aiming to enable all of these cases for Chromium-based browsers, but implementations across other browsers would still be needed here.

Conclusion

WebAssembly is already enabling new functionality in the browser, but more than that it represents a fundamentally new approach to how functionality gets developed. The best way to improve a thing is to improve how you improve it and then basking in second order growth. As with any new paradigm there are advantages and disadvantages, but overall this is a powerful new approach for browsers and developers everywhere. I can’t wait to see what we all build together with it.

By Thomas Nattestad, Product Manager - WebAssembly

Jul	AUG	Sep
	07
2022	2023	2024

Chromium Blog

Redesigning Chrome downloads, to keep you productive and safe online

How Chrome achieved high scores on three browser benchmarks

An Update on the Lock Icon

More ways we’re making Chrome faster

How WebAssembly is accelerating new web functionality

Labels

Archive

Feed