There are three levels of views in improving browser performance,
From the architecture-level perspective, servicification is the goal. It is the foundation of the next two levels.
We had talked about the servicification in the first part of this browser mechanism series. The Chromium browser team has been working on migrating from the old architecture to the new one. The process of migration takes years.
In the process-level, we will see more tasks are unloaded from the main thread in the renderer process. Tasks running in an off-main thread won’t block user interactions and ensure the smooth browsing experience.
On top of the process, the last one is the task-level. Developers try to improve algorithms in each rendering phase, such as layout computation.
Process-level: from the main to off-main thread
The main thread in the renderer process is always a handful.
It takes responsibility for all heavy-lifting tasks from DOM parsing and layout calculation to page events and user inputs. Its goal is delivering an updated bitmap on our display in a timely fashion.
To achieve a better performance, engineers start moving tasks used to run in the main thread to off-main threads.
The idea here is to free up the main thread as much as possible. With more tasks managed outside of the main thread, the browser can achieve more by doing less.
The off-main-thread idea is not new. Firefox team implemented off-main-thread paint in 2017. Instead of using the compositor thread, a new paint thread is added to run the painting phase. Chromium is probably to follow in 2020.
Many proposals are in draft, and some have been under development for a while. Scroll-link animation is one of them.
Scroll-linked animation
What’s a scroll-linked animation? The animation responses to your scrolling behavior. When you scroll down, the animation goes forward; it goes back when you scroll up.
In recent years, we see an increasing number of websites use scroll-linked animation to enhance user experience and storytelling, such as Tomato Can Blues.
We mention that CSS animation is fast. However, scroll-linked animation is JavaScript based. Usually, it is a composite of two parts.
- We listen to the scrolling event and then apply the scrolling offset value to transform elements accordingly.
- The rendering process receives the transform update, and the compositor thread starts to deliver the animation immediately.
These two steps repeat whenever a user scrolls the page.
The transform is a fast-path property. Therefore, the second step is composite-only rendering. It proceeds fast.
However, the JavaScript part in the first part still runs on the main thread.
Moreover, the main thread scroll offset is behind. Using it to animate elements on the page always feel laggy.
Taking the challenge, the team plans to move the scroll-linked animation to an off-main thread with a new Web Animation API.
The implement proposes a new concept — a scrolling timeline. When you scroll, this behavior initializes the start of the timeline. By scrolling down, the timeline goes forward, while it goes back when you scroll up. Yes, you can have a time travel backward in the scrolling timeline.
What are the benefits? Smoother animation provides us an immersive reading experience. Meanwhile, we, as web developers, have a new tool to do a better job.
The team is working toward publishing First Public Working Draft in 2020.
Besides the scroll-linked animation, the scrollbar scrolling will be moved to the compositor thread, which is currently happening on the main thread in Chromium. The team aims to implement it in March this year.
Another feature worth mentioning is the off-main thread CSS paint.
The best part? We can paint a dinosaur on a screen by a little CSS `background-image: paint(dino)`. Moreover, we can animate the painted element on the compositor thread. Xida Chen has a 5-minute talk on BlinkOn sharing some sample codes.
Task-level: a new layout computation — LayoutNG
LayoutNG is the next generation layout engine in Chromium. The team hopes to build the foundation of the browser for the next decade.
A layout engine is basically an algorithm to compute the layout tree in the layout phase.
We had been using the “float” as our website layout tool since 2000 before the “display: flex” came out in 2013. Then all browsers support “display: grid” in 2017, completing the layout tool on the web.
In 2018, W3C First Public Working Draft of CSS Layout API was published. What does the API do? It empowers developers to invent new CSS layouts. We will see more layout options coming to the web at a faster pace. The future layouts are not merely “display: float” and “position: absolute” anymore.
What is the challenge? With the current browser layout algorithm, adding any new layout options complicates the layout tree generation dramatically.
This challenge leads to the birth of the LayoutNG project.
The project is focusing on fragmentation and CSS custom layout scalability, along with whole lots of performance improvement. LayoutNG Design Doc is an information design document with a straightforward explanation.
At the end of 2019, the team shipped the “big first bit” in Chromium, reducing paint time by about 5%. The whole part will be implemented progressively in 2020 and the future.
What’s the takeaway?
The improvements are happening on three levels in our browser:
- The architecture-level improvement focuses on servicification.
- The process-level enhancements free up the main thread in the renderer process.
- The task-level developments introduce new algorithms on rendering phases.
The browser is evolving, but I don’t expect to see its mechanism (the navigation and the rendering) changes dramatically in the next decade.
References
LayoutNG
Scroll-linked Animation
Off main thread CSS paint
Compositor threaded scrollbar scrolling
Main thread scheduling APIs
Prefetch
