1. Background
We often use Chrome Dev Tools for development and debugging, but few know how to use it to analyze page performance. I will explain in detail how to use Chrome Dev Tools to analyze page performance and how to interpret performance report data.
2. Introduction to analysis panel
The picture above is a screenshot of Chrome Dev Tools. Among them, I think the functions of several modules circled in the picture that can be used for quick analysis of page performance are briefly introduced here:
- Network: 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 graph of various performance indicators of the page. Here you can see information such as white screen time, FPS, resource loading timeline, longtask, memory change curve, etc.
- Memory: can record the page memory status at a certain moment, generally used to analyze memory leaks
- JavaScript Profiler: can record the time consumption of functions to facilitate the identification of functions that take more time
- Layers: Shows the layering in the page
3. Analysis steps description
First of all, when we analyze, we recommend using incognito mode to open the page to eliminate the impact of some plug-ins and other factors on page performance. Then, we uncheck the page cache, test the disable cache, and adjust the network conditions. When we open the page on the computer, we usually connect it to wifi. To test the performance of the page more realistically, we should It will be better if the network is adjusted to 3G, as shown in the figure:
After the adjustment, we switch to the Performance panel. Here we first explain the functions of some buttons:
The picture above, from left to right, represents:
- Start recording manually and need to end it manually after starting
- Automatically restart the page and record the entire page loading process. This is the most commonly used. Generally, it is enough to click this when analyzing page performance.
- Clear performance recording history
- Upload page performance recorded data
- Download page performance recorded data
- Select the performance records to display. You may have performed multiple analyses, and you can switch here to view each result.
- Whether to capture screenshots of the page loading process, this generally needs to be checked
- Whether to record memory changes, this generally needs to be checked
- Garbage collection, click to perform a garbage collection
Here, I will take a page on JD.com as an example, check disable cache, and the network condition is Fast 3G to explain how to understand the performance results and find optimization points.
4. Analysis from the network panel
Let's take a look at the network panel and see what information is available. As shown below:
As can be seen from the figure, some performance optimization methods in the page include:
- The page is directly loaded, input
https://wq.jd.com/wxportal/index_v6, and the document returned after the page is loaded is a rendered html page. - Image optimization, deployed under different CDN domain names, using webp/dpg and other format images, image cutting, etc.
- Part of the http protocol uses http2, multiplexing, and speeding up resource loading.
- Small logos are processed using base42
- Load on demand, the menu first loads the icons on the first screen, and then loads the icons on the second screen when sliding to the second screen
From the picture, I personally think that some performance optimization methods that can be considered include:
- The size of html is 138kb, and the content download time is more than 700 milliseconds. It feels like the page can be split, and the content on the first and second screens is loaded separately.
- TTFB (Time To First Byte) is more than 500 milliseconds. It takes too long to wait before downloading the first byte. However, this is mainly affected by the user's network conditions and there is relatively little that can be done. Such as DNS resolution optimization, reducing back-end service processing time, etc.
- Merge sprite images. The icons there are classified in the menu below the large carousel image. You can use a sprite image to collect these icons.
- When loading the top carousel image for the first time, you can load the first frame of the image first and delay the following frames.
- There are many pictures. If possible, use the http2 protocol.
5. Analysis from the performance panel
Switch to the Performance panel, click to automatically restart the page, and record the entire page loading process, and then analyze the results~
Network&&white screen
There are many parameters in the performance panel. We are going to look at some of the more common ones. First, look at the white screen time and network loading status, as shown below:
In the picture above, we can see some information:
- The white screen time for this page loading is about 1000 ms.
- The FPS curve is not marked in red. If there are a lot of red marks, it means that the page has a lot of rendering lags.
- Judging from the loading of network resources, http2 is not enabled for images, so the number of images that can be loaded at the same time is limited, and there is a waiting process for images that are not loaded.
- You can also see the loading time of resources. For example, the background image of the carousel took 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 picture, 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, mainly in the Main panel, is the panel we most often look at when analyzing the time consumption of specific functions. Let's take a look, as shown in the figure:
First of all, there will be a lot of Tasks in the panel. If it is a long-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 allocated). At this time, we can select the one marked in red. Task (just select one here), and then zoom in (select it, slide the mouse to zoom in) to see its specific time-consuming point.
After zooming in, you can see what operations are being done and which functions take how much time. The code here is compressed, and what you see is the compressed function name. Then we click on a function, and at the bottom of the panel, the code information will appear, which function it is, how much it takes, and which line it is on in which file. In this way, we can easily locate the time-consuming function.
You can also switch tabs horizontally to see its call stack and other conditions, making it easier to find the corresponding code. Specifically, you can try it~
Timeline&&memory status
In the Timings area, we can see some key times of this loading, including:
- FCP: First Contentful Paint
- LCP: Largest Contentful Paint
- FMP: First Meaningful Paint
- DCL: DOMContentLoaded Event
- L: Onload Event
We can make a selection (select the area from the white screen to the area with content, which represents the page loading process this time), and you can 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 (heap). If the curve keeps growing, it means there is a memory leak. As can be seen from the figure, for a long time, the memory curve is If there is no decrease, there is a possibility of memory leak here. The memory is released only after Onload.
At the bottom is an overview of the page's time consumption. If the scripting time is too long, it means that js executes too much logic. You can consider optimizing js. If the rendering time is too long, consider optimizing the rendering process. If there is too much idle time, then You can consider making full use of it, such as putting some reporting operations into the idle time of the page before reporting.
Other panels
The above is some 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 situation, the Rendering panel (click more tools->Rendering to open), check Layer Bordersk to see the composite layer and RenderLayer area, which can help analyze animation lags , whether to enable GPU acceleration and other issues, and the Memory panel and JavaScript Profiler panel are mainly used to analyze memory leaks, so I won’t go into them here.
6. Analysis with Audits tool
Audits is actually LightHouse. LightHouse is an automated testing tool open source by 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 scores web pages from 5 aspects. Of course, you can also eliminate certain aspects of evaluation. After selecting the equipment, assessment aspects, network conditions and other options, click Run Audits and we will get a report.
The picture above 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: Content begins to be painted for the first time.
- First Meaningful Paint: It can be simply understood as the time it takes for users to see the main content of the 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.5 seconds.
- Speed Index: The Speed Index is a page loading performance metric that shows you how quickly the page content is visibly filled. The lower the score for this metric, the better.
- First CPU Idle: First CPU idle time
- Time to Interactive: Interactive time, the time required for most network resources in the page to finish loading and the CPU to be idle for a long period of 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: The 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 this time is exceeded, users will perceive the app as unresponsive.
For these times, you can click the red box in the picture to switch the display mode, and the corresponding time explanation will be attached. Then you can click Learn more to view the detailed indicator introduction. In the document, each indicator will be clearly divided into three parts: why this review is important; how to pass this review; how to achieve this review;
7. Interpretation of performance index optimization suggestions
Performance suggestions are mainly divided into three categories: Opportunities, optimizable items, manual diagnostic items, and passed review items. The example this time is as follows:
Each item in the figure can be expanded to see a detailed explanation, including:
There are 2 suggestions for optimization items:
- Delay will block rendering of resource loading, here is a navfoot.6bf68af7.css
- Delay the loading of images outside the viewport. Here is a list of unnecessary loading images (consistent with the optimization suggestions I mentioned above, haha)
The content in this item refers to some points discovered by LightHouse that can be directly optimized. You can optimize accordingly.
There are 6 suggestions for manual diagnostic items:
- Minimize main thread work
- Reduce JavaScript execution time
- Avoid DOM being too large
- Cache some static resources with an effective caching strategy
- Avoid linking critical requests
- Keep request numbers low and transfer sizes small
These items mean that LightHouse cannot decide for you whether the current situation is good or bad, but it lists the details and allows you to manually check the status of each item.
Passed review items
What is listed here are all things that have been done well. There are 16 examples in this article. However, even if they are done well, it is still worth going in and taking a closer look, because like all items, each item here also has a showmore. We can click Go in and carefully study the knowledge and principles behind it!
AccessibilityAccessibility
Accessibility refers to the experience of users who may be outside the scope of "normal" users. They access or interact with your webpage in a different way than you expect. Examples in this article suggest the following:
The Accessibility category tests the ability of screen readers and other assistive technologies to work properly on the page. For example: use attributes by element, whether the use of tags is standardized, whether the img tag lacks alt attributes, identifiable element naming, etc. We will not go into detail on this item, but we still recommend that you modify the web page according to the audit recommendations.
For several other items, the examples in this article have very high best practice scores. However, the examples do not support PWA and do not need to consider SEO. I will not go into details here. If you have corresponding needs, you can take a look at them in detail.
Summarize
Finally, to summarize, we use Chrome Dev Tools to analyze page performance and have the following indicators for reference:
- Analysis from network panel
- Analysis from performance panel
- Analyze memory leaks from the Memory panel, etc.
- Analyze with Audits tool