[go: up one dir, main page]

In January, we began our quest to improve how Chrome communicates the connection security of HTTP pages. Chrome now marks HTTP pages as “Not secure” if they have password or credit card fields. Beginning in October 2017, Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.
Treatment of HTTP pages in Chrome 62

Our plan to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the change in Chrome 56, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we’re ready to take the next steps.

Passwords and credit cards are not the only types of data that should be private. Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the “Not secure” warning when users type data into HTTP sites.

Treatment of HTTP pages with user-entered data in Chrome 62

When users browse Chrome with Incognito mode, they likely have increased expectations of privacy. However, HTTP browsing is not private to others on the network, so in version 62 Chrome will also warn users when visiting an HTTP page in Incognito mode.

Eventually, we plan to show the “Not secure” warning for all HTTP pages, even outside Incognito mode. We will publish updates as we approach future releases, but don’t wait to get started moving to HTTPS! HTTPS is easier and cheaper than ever before, and it enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.

Posted by Emily Schechter, Chrome Security Team

The V8 JavaScript engine is a cornerstone of fast browsing in Chrome. Over the course of the past year, the V8 team has developed a new method for measuring performance against snapshots of real web pages. Using insights from real-world measurements, the V8 team improved the speed of the average page load in Chrome by 10-20% over the course of the past year.


Historically, JavaScript engines such as V8 used benchmarks like Octane to improve the “peak” performance of JavaScript, or the performance of CPU-intensive script in hot loops. At the beginning of last year, the V8 team started to measure performance with higher fidelity by instrumenting snapshots of popular web pages such as Reddit, Twitter, Facebook, and Wikipedia. This analysis revealed that while peak performance benefits certain types of large web applications, browsing typical websites relies more on “startup” performance, or the speed it takes to start running script. Using insights gleaned from this real-world performance data, the V8 team implemented optimizations which improved mean page load between Chrome 49 and Chrome 56 by 10-20%, depending on CPU architecture.


The web page snapshots also enabled analysis of the differences between various benchmarks and real web workloads. Although no benchmark can be a representative proxy for all sites, the Speedometer benchmark is an approximation of many sites due to its inclusion of real web frameworks including React, Angular, Ember, and jQuery. This similarity can be seen in the startup optimizations above, which also yielded a 25-35% improvement in Chrome’s Speedometer score. Conversely, comparing page snapshots to Octane revealed that Octane was a poor approximation of most websites. Given the plateau of Octane scores across web browsers and the over-optimization of peak performance, we decided to retire the benchmark as a general-purpose measure of real-world JavaScript performance.

V8 performance optimizations improved Chrome's Speedometer score by 25-35% over the past year


Going forward, we plan to ship more JavaScript performance improvements for new patterns of script appearing on the web, including modern libraries, frameworks, and ES2015+ language features. By measuring real-world websites rather than traditional benchmarks, we can better optimize JavaScript patterns that matter most to users and developers. Stay tuned for updates about our new engine architecture, designed for real-world performance.


Posted by Seth Thompson, V8 Track Commentator

One of the strengths of the web is progressive loading, which means that there is no install step and users can start consuming content almost immediately while the site keeps loading. But progressive loading can also result in annoyances, such as an unexpected page jump when offscreen content loads and pushes down what’s currently on the screen. This can be even worse on mobile devices, since smaller screens mean more content is offscreen and page jumps are more likely.
Since its early days, Chrome has taken a stand against bad or abusive content. For instance, Safe Browsing warns users before they visit malicious websites, and visual indicators on tabs allow our users to quickly track down the source of unexpected noise. Similar to other features designed to protect our users from bad experiences, starting in version 56 Chrome prevents these unexpected page jumps with a new feature called scroll anchoring. This feature works by locking the scroll position on an on-screen element to keep our users in the same spot even as offscreen content continues to load.
Side by side comparison of a web page with scroll anchoring disabled (left) and enabled (right).

Due to the expressiveness of the web, there might be some content for which scroll anchoring is either unwanted or misbehaving. For this reason, this feature ships alongside the ”overflow-anchor” CSS property to override the functionality. To further minimize potential issues, scroll anchoring is disabled on complex interactive layouts via suppression triggers, and on back/forward navigations to allow for scroll restoration.

Today, scroll anchoring is preventing about three page jumps per page-view, but with your help it could be even better. Get involved by participating in the scroll anchoring Web Platform Incubator Community Group, submitting feedback via g.co/reportbadreflow, and designing your websites or services with a no-reflow mindset.


Posted by Steve Kobes, “The Unbouncer”