Starting in version 90, Chrome’s address bar will use https:// by default, improving privacy and even loading speed for users visiting websites that support HTTPS. Chrome users who navigate to websites by manually typing a URL often don’t include “http://” or “https://”. For example, users often type “example.com” instead of “https://example.com” in the address bar. In this case, if it was a user’s first visit to a website, Chrome would previously choose http:// as the default protocol^{1. This was a practical default in the past, when much of the web did not support HTTPS.}

Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol^{2. HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.}

HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default.

¹ One notable exception to this is any site in the HSTS preload list, which Chrome will always default to HTTPS.
² IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP.

Posted by Shweta Panditrao and Mustafa Emre Acer, Chrome team

Improving memory management

In Chrome M89, we’re seeing significant memory savings on Windows--up to 22% in the browser process, 8% in the renderer, and 3% in the GPU. Even more than that, we’ve improved browser responsiveness by up to 9%. We’ve achieved this by using PartitionAlloc, our own advanced memory allocator, which is optimized for low allocation latency, space efficiency, and security. For some time now, PartitionAlloc has been used extensively within Blink, our renderer codebase. Starting in M89, we’ve upgraded Chrome on Android and 64-bit Windows to use PartitionAlloc everywhere (by intercepting malloc).

In addition to improving how we allocate memory, Chrome is now smarter about using (and discarding) memory. Chrome now reclaims up to 100MiB per tab, which is more than 20% on some popular sites, by discarding memory that the foreground tab is not actively using, such as big images you’ve scrolled off screen. Chrome is also shrinking its memory footprint in background tabs on macOS, something we’ve been doing on other platforms for a while. We’re seeing up to 8% memory savings, which is more than 1GiB in some cases!

Finally, with more data from the field on tab throttling, we’re seeing up to 65% improvement on Apple Energy Impact score for tabs in the background, keeping your Mac cooler and those fans quiet.

Build, packaging, and runtime improvements

Focusing on Chrome for Android, we have a uniquely challenging job of building a great browser for every single variant of Android device. In this release we’re taking advantage of some packaging and runtime optimizations to deliver better performance in the Chrome that is in your pocket.

Some new Play and Android capabilities allowed us to repackage Chrome on Android, and we’re seeing fewer crashes due to resource exhaustion, a 5% improvement in memory usage, 7.5% faster startup times, and up to 2% faster page loads. Android App Bundles allow the Play Store to generate optimized APKs for each user’s device configuration, and allows packaging code and resources in split APKs, which are installed alongside the base APK. And an Android O feature, isolatedSplits, allows these feature splits to be loaded on demand, reducing Chrome’s overall startup cost.

For those of you who picked up the latest Android devices (Android Q+ and 8GB+ of RAM), we’ve rebuilt Chrome as a 64-bit binary, giving you a more stable Chrome that is up to 8.5% faster to load pages and 28% smoother when it comes to scrolling and input latency.

Finally, we’ve built a way for Chrome on Android to start up 13% faster: Freeze-Dried Tabs. Chrome now saves a lightweight version of your tabs that are similar in size to a screenshot, but support scrolling, zooming, and tapping on links. We use these Freeze-Dried Tabs at startup while the actual tab loads in the background, getting you to your pages faster. See it in action below:

Our teams are always working hard to bring you the fastest and most powerful browser on every one of your devices. We’re very excited to bring you these performance improvements and have much more to come, so stay tuned.

Posted by Mark Chang, Chrome Product Manager

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.