Chromium Blog: 1月 2017

Open-sourcing Chrome on iOS!

2017年1月31日火曜日

Historically, the code for Chrome for iOS was kept separate from the rest of the Chromium project due to the additional complexity required for the platform. After years of careful refactoring, all of this code is rejoining Chromium and being moved into the open-source repository.

Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine. For Chromium, this means supporting both WebKit as well as Blink, Chrome's rendering engine for other platforms. That created some extra complexities which we wanted to avoid placing in the Chromium code base.

Given Chrome's commitment to open-source code, we've spent a lot of time over the past several years making the changes required to upstream the code for Chrome for iOS into Chromium. Today, that upstreaming is complete, and developers can compile the iOS version of Chromium like they can for other versions of Chromium. Development speed is also faster now that all of the tests for Chrome for iOS are available to the entire Chromium community and automatically run any time that code is checked in.

We value the open source community and all of our contributors, and we're glad that Chrome for iOS can finally join in. Posted by Rohit Rao, Upstream Angler

Performance improvements in Chrome's rendering pipeline

2017年1月30日月曜日

Speed is one of Chrome’s four core principles, enabling web developers to provide users with faster, more engaging web experiences. While many components in the browser contribute to overall speed, the rendering pipeline is primarily responsible for ensuring websites display at 60 frames per second (fps), which feels fast and responsive to users. Over the last few months we’ve rolled out several performance improvements to Chrome’s rendering pipeline, making it even smarter about the work it completes. Chrome now more intelligently skips redundant tasks, chooses optimal rendering algorithms, and better utilizes system hardware, causing websites to load faster, run smoother, and use less power.

In order to display content at 60fps, Chrome has only 16ms to render each frame, including JavaScript execution, style, layout, painting, and pushing the resulting pixels to the user’s screen. Of that 16ms time budget, the less Chrome uses, the more time web developers have to run scripts, load content, and delight their users. Many of our recent improvements to the rendering pipeline focus on reducing the per-frame workload, rather than simply improving Chrome’s raw speed.

For example, when Chrome is preparing to paint pixels to the screen, it must first identify which elements on the page need to be redrawn and which can be copied from the previous frame’s cache. On highly dynamic pages with frequent DOM changes, this performance cost can add up quickly. To simplify this task, Chrome now tracks the draw commands generated for each element and can identify visually non-overlapping subsets. If one of these subsets hasn’t been modified, the entire block can be copied directly from the cache without any additional work. This optimization reduces the time it takes to paint a new frame to the screen by up to 35%.

Chrome also groups the pixels into tiles to enable smaller and faster updates to the screen. Previously, Chrome would redraw any of these tiles that had been modified by a DOM update, but this is only optimal if the majority of a tile’s area needs to be redrawn. If only a few pixels have changed, it’s faster to copy the entire tile from the previous frame and then update the new pixels. Chrome can now intelligently choose the redraw pipeline that will be faster, reducing tile redraw time by up to 40%.

Any update to the screen, such as the input cursor blinking, would previously require the whole tile to be re-rendered (left). When only a few pixels have changed, Chrome can now redraw only the modified region (right).

In addition to intelligently optimizing its workload, Chrome is now better at choosing how it completes that work given the underlying hardware. While video and canvas elements have been GPU accelerated for a long time, Chrome is constantly getting better at utilizing the GPU for more challenging rendering tasks. On Android, Mac, and Windows, Chrome now better utilizes GPU acceleration for complex site content rendering. This improves animation performance, input latency, and scroll smoothness for modern SVG and HTML5 pages.

There are many different dimensions to speed, and we’re committed to continually improving Chrome’s performance and enabling developers to optimize their user experience to hit 60fps. The rendering pipeline is only one piece of the puzzle, and we’ve got a lot more coming. Stay tuned as we continue taking deep dives into performance and steadily make the web faster and more responsive for all Chrome users. Posted by Chris Harrelson, Painting Professional

Reload, reloaded: faster and leaner page reloads

2017年1月26日木曜日

Reload has long been a staple feature of web browsers and kept its original behavior throughout the years, despite the changing landscape of web platform innovations, connectivity, and content consumption patterns. When reloading a page, browsers will check with the web server if cached resources are still usable, a process known as validation. This typically results in hundreds of network requests per page issued to dozens of domains. On mobile devices, the high latency and transient nature of mobile connections mean that this behavior can produce serious performance issues. In the latest version of Chrome, changes to page reload behavior produce reloads that are 28% faster and result in 60% fewer validation requests.

Users typically reload either because a page is broken or the content seems stale. The existing reload behavior usually solves broken pages, but stale content is inefficiently addressed by a regular reload, especially on mobile. This feature was originally designed in times when broken pages were quite common, so it was reasonable to address both use cases at once. However, this original concern has now become far less relevant as the quality of web pages has increased. To improve the stale content use case, Chrome now has a simplified reload behavior to only validate the main resource and continue with a regular page load. This new behavior maximizes the reuse of cached resources and results in lower latency, power consumption, and data usage.

Despite being a relatively minor change, the new behavior makes reloads up to 28% faster and consume less bandwidth and power. Furthermore, Facebook contacted us with data showing that Chrome was sending validation requests at three times the rate of other browsers. Thanks to the new reload behavior and some related changes, Facebook now reports 28% faster page reloads and 60% less validation requests from Chrome.

We hope this faster reload will come in handy whenever you want to get the latest content on your favorite website or quickly recover from a flaky connection in the subway.

Posted by Takashi Toyoshima, “Reloader Sensei”

Chromium Blog

Open-sourcing Chrome on iOS!

Performance improvements in Chrome's rendering pipeline

Reload, reloaded: faster and leaner page reloads

ラベル

Archive

Feed