The original address: developer.chrome.com/blog/render…

The author is Chris Harrelson, who is the project lead for rendering (converting HTML and CSS into pixels) in Blink. For eight years, I’ve been digging deep into rendering performance on the Web, and my personal goal is to deliver a great user experience on the Web as quickly, easily, and reliably as I can. I’m happy to tell you about the work we’ve been doing during that time to build a new, cutting-edge Chromium rendering engine architecture. Great loving efforts have been made to achieve this goal and I hope you enjoy hearing about it!

By 2021, we will have essentially completed the process of designing, building and delivering the architecture. Let’s call it RenderingNG, because it is truly the next generation of rendering architecture, vastly surpassing the previous architecture. RenderingNG has been in the works for at least eight years and represents the collective work of many dedicated Chromium developers. It unleashes tremendous potential for the next generation of fast, smooth, reliable, responsive, and interactive Web content. I believe this is also a baseline that defines a new minimum standard for all Web rendering engines that developers can rely on.

​

This blog post is the first in a series in which we explain what we built, why we built it, and how it works. In the first article, I will start with:

  • Our Polaris target.
  • Pyramid of Success: the principles that guide our work, and examples of these principles in practice.
  • Features and functionality implemented by RenderingNG.
  • A high-level overview of RenderingNG’s main project components.

The north star

The north Star goal driving RenderingNG is that the richness of the browser engine implementation and its rendering API should not be a limiting factor in the web user experience.

You don’t have to worry about browser errors that will cause functionality to be unreliable or spoil your site’s presentation.

There should be no mysterious performance cliff. Also, you don’t need to address the missing built-in functionality.

It should work.

I believe RenderingNG is a big step towards this Polaris goal. Before RenderingNG, we could (and did) add rendering features and improve performance, but trying to make these features reliable for developers, and there were a number of performance cliffs. Now we have an architecture that systematically addresses many of these issues, and also unlocks advanced functionality that was previously considered unfeasible. It:

  • With rock-solid core functionality across different platforms, devices, and operating system combinations.
  • Predictable and reliable performance.
  • Maximize hardware functionality (kernel, GPU, screen resolution, refresh rate, low-level raster apis).
  • Only the work required to display visible content is performed.
  • Built-in support for common visual design, animation, and interaction design patterns.
  • Provides developer apis to easily manage rendering costs.
  • Provides a render pipeline extension point for developer add-ons.
  • Optimize all content – HTML, CSS, 2D canvas, 3D canvas, images, video, and fonts.

Comparison with other browser rendering engines

Gecko and Webkit have also implemented most of the same architectural features described in these blog posts, and in some cases even added them before Chromium. This is great! While any browser becoming faster and more reliable is something to celebrate and have a real impact, the ultimate goal is to raise the baseline of all browsers so that developers can rely on it.

Pyramid of success

My philosophy is that success is achieved first by reliability, then by scalable performance, and finally by scalability as a result.

​

Like a real life pyramid, each level provides the necessary solid foundation for the level above.

reliability

​

If we want a rich and complex user experience, we first need a rock-solid platform. Core functions and foundations must work properly and continue to work over time. Just as important, these features are well combined and have no weird edge behavior or errors.

​

Therefore, reliability is the most important part of RenderingNG. Reliability is the result of good testing, quality feedback loops, metrics, and software design patterns.

To illustrate how important I think reliability is, we’ve spent the better part of the last eight years working on it. First, we built an in-depth understanding of the system — learning from defect reports and fixing them, conducting comprehensive testing, understanding the site’s performance requirements and Chromium performance limitations. We then carefully and progressively designed and rolled out key design patterns and data structures. Only then were we ready to add true next-generation primitives for responsive design, extensibility, and rendering customization.

​

That’s not to say that Chromium hasn’t improved over that time. In fact, the opposite is true! Those years have seen steady and sustained growth in reliability and performance as we gradually refactor and roll out each improvement.

Tests and indicators

Over the past eight years, we have added tens of thousands of unit, performance, and integration tests. In addition, we have developed comprehensive metrics to measure many aspects of how Well Chromium rendering performs in local testing, performance benchmarking, and using real users and devices on real sites.

But no matter how good RenderingNG (or any other browser’s rendering engine, for that matter) is, it’s still not easy to develop for the Web if there are a lot of bugs or behavioral differences between browsers. To solve this problem, we also made maximum use of Web platform testing. Each of these tests validated the usage patterns of the web platform that all browsers should pass. We also closely monitor metrics to pass more tests and improve core compatibility over time.

Web platform testing is a collaborative effort. For example, Chromium engineers only added about 10% of the total NUMBER of WPT tests for CSS features; Other browser vendors, independent contributors, and specification authors contributed the remainder. It takes a village to build an interoperable network!

​