How to use Chrome Dev Tools to analyze page performance (front-end performance optimization)

background

We often use Chrome Dev Tools for development and debugging, but few know how to use it to analyze page performance. In this article, I will explain in detail how to use Chrome Dev Tools for page performance analysis and how to interpret performance report data.

Analysis panel introduction

The above picture is a screenshot of Chrome Dev Tools. I think the functions of the modules circled in the picture are mainly used for quick analysis of page performance. Here is a brief introduction:

• Network: The various resource requests on the page. Here you can see the resource name, status, protocol used (http1/http2/quic...), resource type, resource size, resource timeline, etc.
• Performance: Flame chart of various performance indicators of the page, where you can see white screen time, FPS, resource loading timeline, longtask, memory change curve and other information
• Memory: can record the page memory status at a certain moment, generally used to analyze memory leaks
• JavaScript Profiler: It can record the time consumption of functions, making it easier to find functions that consume more time
• Layers: Displays the layers in the page

Analysis Steps

First of all, when analyzing, we recommend opening the page in incognito mode to eliminate the impact of factors such as plug-ins on page performance. Then, we uncheck the page cache to test the disable cache situation, and then adjust the network conditions. When we use a computer to open a page, we are usually connected to wifi, etc. To test the performance of the page more realistically, it is better to adjust the network to 3G, etc., as shown in the figure:

After the adjustment, we switch to the Performance panel. Here are some buttons to explain their functions:

The above picture, from left to right, represents:

• Manually start recording, and need to be manually ended after starting
• Automatically restart the page and record the entire page loading process. This is the most commonly used one. Generally, when analyzing page performance, just click this.
• Clear performance recording records
• Upload page performance recording data
• Download page performance recording data
• Select the performance records to display. You may have performed multiple analyses. You can switch here to see the results of each analysis.
• Whether to capture screenshots of the page loading process, this is usually checked
• Whether to record memory changes, this is usually checked
• Garbage collection, click to perform garbage collection

Here, I take a page of JD.com as an example, check the disable cache, and use Fast 3G network to illustrate how to understand the performance results and find optimization points.

Analyze from the network panel

Let's take a look at the Network panel to see what information is available. As shown in the following figure:

As can be seen from the figure, some performance optimization methods on the page are:

• The page goes straight out, enter https://wq.jd.com/wxportal/index_v6 , the document loaded back by the page is a rendered HTML page
• Image optimization, deployment under different CDN domain names, use webp/dpg and other format images, image cutting, etc.
• Some of the http protocols use http2, multiplexing, to speed up resource loading
• Small logo is processed using base42
• Load on demand, the menu loads the icons of the first screen first, and then loads the icons of the second screen when sliding to the second screen

From the pictures, I think some performance optimization methods that can also be considered are:

• The size of the html is 138kb, and the content download time is more than 700 milliseconds. I think the page can be split up and the content that does not take up one or two screens can be loaded separately.
• TTFB (Time To First Byte) is over 500 milliseconds, which means the waiting time before downloading the first byte is too long. However, this is mainly affected by the user's network conditions, and there is not much that can be done about it. Such as DNS resolution optimization, reducing backend service processing time, etc.
• Merge Sprite images. The icons in the menu categories below the large carousel can be grouped together using a Sprite image.
• For the top carousel, when loading for the first time, you can load the first frame of the image first, and delay the next few frames.
• If there are many pictures, use http2 protocol if possible.

Analyze from the performance panel

Switch to the Performance panel, click on the automatic page restart, and record the entire page loading process, and then analyze the results~​

Network&&White Screen

The performance panel has many, many parameters, and we will look at some of the more common ones. First, look at the white screen time and network loading status, as shown below:

In the above picture, we can see several pieces of information:

• The white screen time for this page loading is about 1000 ms
• The FPS curve is not marked in red. If there are many red lines, it means that the page has a lot of rendering lags.
• Judging from the network resource loading situation, the images do not enable http2, so the number of images that can be loaded at the same time is limited, and the images that are not loaded have a waiting process
• The loading time of resources can also be seen. For example, the background image of the carousel takes nearly 700 milliseconds to load, which is a bit long.

In addition, we can check whether there is a blank period in resource loading. Although there is no blank period in the above figure, if there is a blank period between resource loading, it means that the idle time of resource loading is not fully utilized and it can be adjusted.

Flame graph

The flame graph is mainly in the Main panel. It is the panel we most often use to analyze the time consumption of specific functions. Let's take a look at it, as shown in the figure:

First, there will be many tasks in the panel. If it is a time-consuming task, its upper right corner will be marked in red (not in the picture, which means that the logical processing of the first screen of the page is well distributed). At this time, we can select the task marked in red (just select one here), and then zoom in (select and slide the mouse to zoom in) to see its specific time-consuming point.

After zooming in, you can see what operations are being performed and how much time each function takes. The code here is compressed, and you can see the compressed function names. Then we click on a function, and at the bottom of the panel, the code information will appear, including which function it is, how much time it takes, which line of which file, etc. In this way, we can easily locate the time-consuming function.

You can also switch tabs horizontally to view its call stack and other information, making it easier to find the corresponding code. You can try it~

Timeline & Memory Status

In the Timings area, we can see some key times for this loading, which are:

• FCP: First Contentful Paint
• LCP: Largest Contentful Paint
• FMP: First Meaningful Paint
• DCL: DOMContentLoaded Event
• L: Onload Event

We can select the area (select the area from the white screen to the area with content, representing the page loading process this time), and compare it with the time above. The screenshot is as follows:

In addition, we can see the memory usage in the page, such as JS Heap. If the curve keeps growing, it means there is a memory leak. As can be seen from the figure, the memory curve has not dropped for a long time. There is a possibility of memory leak. The memory is released after Onload. For more causes and analysis methods of memory leaks, please refer to my article "Analysis of Chrome browser garbage collection mechanism and memory leaks"

At the bottom is a summary of the time consumption of the page. If the Scripting time is too long, it means that js executes too much logic, and you can consider optimizing js. If the rendering time is too long, consider optimizing the rendering process. If there is too much idle time, you can consider making full use of it, such as putting some reporting operations into the idle time of the page and then reporting.

Other panels

The above is some of the information that can be viewed in the performance panel. In addition, we can use the Layers panel to view the 3D view of the page layering. In the Rendering panel (click more tools->Rendering to open it), check Layer Bordersk to see the composite layer and RenderLayer area, which can help analyze animation jams, whether to turn on GPU acceleration, etc. The Memory panel and JavaScript Profiler panel are mainly used to analyze memory leaks. I won’t talk about them here. You can read my other article "Analysis of Chrome browser garbage collection mechanism and memory leaks"

Analyze with Audits tool

Audits is actually LightHouse, which is an open source automated testing tool from Google. It evaluates and analyzes web pages through a series of rules and finally gives an evaluation report. Its panel looks like this:

Overall situation

Audits mainly score web pages based on five aspects, of course you can also remove certain aspects of the evaluation. After selecting the device, assessment aspects, network conditions and other options, click Run Audits and we will get a report.

The above figure is an overall report. It can be seen that the performance of this page is not up to standard. Of course, a single test cannot explain anything, it can only serve as a reference. Let's look at its performance indicators:

• First Contentful Paint: The content is painted for the first time.
• First Meaningful Paint: This can be simply understood as the time it takes for users to see the main content of a web page. The lower the score, the faster the page displays its main content. In the example in the figure, the first effective drawing time of the web page is 2.5s.
• Speed ​​Index: The speed index is a page loading performance indicator that shows you how quickly the page content is apparently filled, the lower the score for this metric, the better.
• First CPU Idle: First CPU idle time
• Time to Interactive: The time required for most of the network resources in the page to finish loading and the CPU to be idle for a long time. At this time, it can be expected that the CPU is very idle and can handle user interaction operations in a timely manner.
• Max Potential First Input Delay: Maximum input delay time. Input responsiveness plays a key role in how users perceive the performance of your application. The application has 100 milliseconds to respond to user input. If it takes longer than this, users will perceive the app as unresponsive.

For these times, you can click the red box in the picture to switch the display mode. The corresponding time explanation will be attached, and you can click Learn more to view the detailed indicator introduction. In the document, each indicator is clearly divided into three parts: why this review is important; how to pass this review; how to achieve this review;

Interpretation of performance indicator optimization suggestions

Performance recommendations are mainly divided into three categories: Opportunities (optimizable items), manual diagnosis items, and approved review items. The example is as follows:

Each item in the figure can be expanded to see a detailed explanation, including:

There are 2 suggestions for optimization:

• Delays will block rendering of resource loading, here is a navfoot.6bf68af7.css
• Delay the loading of images outside the viewport. Here are the images that are not necessary to load (which is consistent with the optimization suggestions I mentioned above, haha)

The content in this item refers to some points that LightHouse has discovered that can be directly optimized. You can optimize accordingly.

There are 6 suggestions for manual diagnosis items:

• Minimize main thread work
• Reduce JavaScript execution time
• Avoid DOM being too large
• Cache some static resources through effective caching strategies
• Avoid chaining critical requests
• Keep request count and transfer size low

These items mean that LightHouse cannot decide for you whether the current situation is good or bad, but the details are listed and you can manually check the situation of each item.

Passed review items

Listed here are the good points. There are 16 examples in this article. However, even if they are done well, it is still worth our careful look, because like all entries, each entry here also has a showmore, and we can click in to carefully learn the knowledge and principles behind it!

Accessibility

Accessibility refers to the experience for users who may be outside the scope of "normal" users, who access or interact with your web pages in a different way than you expect. The examples in this article suggest the following figure:

The Accessibility category tests the ability of screen readers and other assistive technologies to work properly with the page. For example: use attributes according to elements, whether tags are used in a standardized manner, whether the img tag lacks an alt attribute, recognizable element naming, etc. We will not discuss this item in detail, but we still recommend that you modify the web page according to the audit recommendations.

For other items, the best practices of the examples in this article are highly rated, but the examples do not support PWA and do not need to consider SEO, so I will not elaborate on them here. If you have corresponding needs, you can take a look at them in detail.

Summarize

Finally, to sum up, we use Chrome Dev Tools to analyze page performance and have the following indicators for reference:

• Analyze from the network panel
• Analyze from the performance panel
• Analyze memory leaks from the Memory panel, etc.
• Analyze with Audits tool

These analysis methods are described in detail in this article. You can take a serious look~

This concludes this article on the steps to use Chrome Dev Tools for page performance analysis (front-end performance optimization). For more relevant Chrome Dev Tools page performance content, please search for previous articles on 123WORDPRESS.COM or continue to browse the related articles below. I hope everyone will support 123WORDPRESS.COM in the future!