Chromium Blog: abril 2017

Next steps toward more connection security

jueves, 27 de abril de 2017

began our questIncognito mode

Treatment of HTTP pages in Chrome 62Our planchange in Chrome 56

Treatment of HTTP pages with user-entered data in Chrome 62alleasier and cheaper than ever beforeset-up guidesPosted by Emily Schechter, Chrome Security Team

Real-world JavaScript performance

miércoles, 12 de abril de 2017

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

Scroll anchoring for web developers

martes, 11 de abril de 2017

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”

Chromium Blog

Next steps toward more connection security

Real-world JavaScript performance

Scroll anchoring for web developers

Etiquetas

Archive

Feed