Good day, I recently solved the problem of slowing down scrolling on the Mail.Ru Mail pages. Especially this problem was noticeable on retina-displays. After a simple analysis, I came to the conclusion that one of the main problems is slow page rendering.

In this article, I’ll tell you how you can use the Skia Debugger tool included in the Chrome toolkit for step-by-step analysis of the page rendering process, as well as how it can be used to get data on how long it takes to draw each element.

Like many such optimization problems, this problem can be solved in many ways. I took up the optimization of rendering, as it took a significant amount of time. Thus, I could quickly get a performance boost and, accordingly, improve the smoothness of the scroll by speeding up the rendering.
')


In the beginning, I decided to see how long it takes to render the page. To do this, you can use the devtools “Enable continuos page repainting” setting. This option causes the browser to constantly redraw the page without any user action. In this mode, the panel also displays the page rendering time. About this and other features devtools perfectly described in this article, so I will not focus on it. Let me just say that after taking measurements, it turned out that the analyzed page on the retine is rendered for about 100 milliseconds , which creates a slowdown when the page is scrolled. The data that I can see when recording the timing in devtools was not very informative, since it contained only the time to render the whole page, and I had to find the culprit of the problems.

Therefore, I began to search for which component of the browser is responsible for rendering, and which logs will be able to help me understand what is slowing down. I started by studying this article and the Chromium architecture , which is available in the public domain and is not conceptually different from the Chrome architecture.

In these articles I was interested in what component is responsible for rendering and what logs it provides. From the chapters describing the graphic components, I learned that basically all the work lies with the Skia library. To my joy, the Skia Debugger debugger was developed for it, which, judging by the screenshots on the project site, was necessary for me. But, unfortunately, installing it was a nontrivial task for me (it was necessary to build the debugger itself and rebuild Chrome).

Searching some more, I found a link to this video. From it, I learned that this debugger was built into Chrome Canary , and you can use it by running the browser with the --enable-skia-benchmarking option, on a Mac you can do this with the following command:
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-skia-benchmarking

Starting the browser with this parameter, go to chrome: // tracing . You should see the following tab:



Open another tab with the page that we want to analyze. In my case, it was the mailing list page. Go back to the chrome: // tracing tab and click Record, the popup should open. In it you need to select the item “Frame Viewer” from the list and click on Record. After that, the recording will begin, and you can perform any actions on the analyzed tab, I recommend keeping open no more than one tab, since the recording buffer is very limited, and a relatively small piece of data fits into it.

Once you have completed the actions you are interested in, go back to the tracing tab and click Stop. After that, you will construct a diagram containing information about what happened in the system during recording. All data is grouped by browser processes. I am interested in the process with a list of messages, it is easy to find by the title. In this process, we look at the section ss :: Picture, in which the circles display the final images rendered by the browser.



Find among them one that contains the entire page. Now a window with a picture of the page is displayed at the bottom of the screen. In the upper right corner, a diagram is displayed that shows how much total time each drawing function takes. On the left, the timeline is displayed with the sequence of drawing the page elements and the time spent on each of them.



Scrolling through the timeline, I found that the main culprit of such a long page rendering is the container of the list of messages with a shadow. This element takes about 45% of the total page rendering time.



After I replaced box-shadow with a regular border and re-recorded the page, I saw that the amount of time for drawing had decreased from 45% to 6.5%, and also that another Skia function was used now.



Acceleration of rendering was also confirmed after viewing the optimized page in the “Enable continuos page repainting” mode.

To many, it may seem that the problem with box-shadow was obvious, and it could be found by simply changing the styles on the pages through devtools. But in this article I wanted to talk about how to use alternative tools. How can they be used to understand the sequence in which elements are drawn on a page and how long it takes.

This tool has a lot of great opportunities that I did not describe in the article, because they are beautifully described in the video I mentioned earlier.

Understanding the processes occurring in the browser is a very important knowledge that is necessary for the effective optimization of web applications. But optimization also requires tools that will allow us to measure the acceleration that this or that optimization has given, as well as to understand the cause of the problem.

"If we are talking about performance, there can be no" probably. " Without measuring performance, you just won’t be able to find out if your changes helped or hurt the program. ”
Steve McConel "Perfect Code" 2nd. edition, p. 579 "Code Optimization Strategies"

Determining the most difficult to draw elements is an important step in optimizing a web application. The knowledge gained about new features in Chrome will help not only to debug and find the bottlenecks of rendering, but also to understand how any of the components of the page affect the whole process of rendering the stream as a whole. I will try to tell about other features of this tool in the following articles.

Links

• Draft with description of Skia Debugger implementation in chrome: // tracing
• A document describing the architecture of drawing graphics in Chromium
• Chrome Conceptual Architecture (2009)
• Skia project repository