Author: basinwang, Tencent PCG front-end development engineer
Large-scale projects are prone to encounter performance problems. Generally speaking, when we encounter performance bottlenecks, we will start to analyze accordingly. The direction of analysis is not only related to the characteristics of the business itself, but also common tools to find problems. This article mainly introduces how front-end performance analysis can go~
Front-end performance analysis tools (Chrome DevTools)
Generally speaking, the performance analysis of the front-end can usually be carried out from two perspectives of time and space :
Time : Common time-consuming, such as page load time, rendering time, network time, script execution time, etc.
Space : Resource occupation, including CPU occupation, memory occupation, local cache occupation, etc.
So, let's take a look at what common tools can be borrowed and used. Since our web pages basically run in the browser, most of the tools are basically provided by the browser itself, and the preferred tool is naturally Chrome DevTools . In this article, we also mainly focus on Chrome DevTools to explain.
Lighthouse
The predecessor of Lighthouse was Audits in the Chrome DevTools panel. In versions prior to Chrome 60, this panel only contained two measurement categories: network usage and page performance. Starting with Chrome 60, the Audits panel has been replaced by the integrated version of Lighthouse. In the latest version of Chrome, you need to install the Lighthouse extension separately to use it, or you can use it through a script.
Architecture
The following are the components of Lighthouse:
Driver: Interface to interact with Chrome Debugging Protocol
Collectors (Gatherers): Use the driver to collect page information, the output of the collector is called Artifact
Audits: Taking Artifact as input, the auditor will run tests on it, and then assign pass/fail/score results
Report: Group the results of the review into user-oriented reports (such as best practices), apply a weighted sum to the part, and then get a score
The main function
Lighthouse will run web pages under a series of tests, such as devices of different sizes and different network speeds. It also checks the page for consistency with accessibility guidelines, such as color contrast and ARIA best practices.
In a relatively short period of time, Lighthouse can give such a report (the report can be generated as JSON or HTML):
This report analyzes pages from five aspects: performance , accessibility , best practices , search engine optimization and PWA . For performance, some common time-consuming statistics will be given. In addition, some detailed optimization directions will be given.
If you want a more comprehensive evaluation of your website in a short time, you can use Lighthouse to run the score and determine the general optimization direction.
Performance panel
The Performance panel also has a predecessor called Timeline . This panel is used to record and analyze runtime performance , which is the performance of the page when it is running (not when it is loaded).
Steps for usage
The Performance panel has many functions, and the specific analysis can be discussed separately. Here we briefly talk about the steps used:
Open Chrome in incognito mode. Incognito mode ensures that Chrome runs in a clean state. For example, browser extensions may have an impact in performance evaluation.
In DevTools, click the "Performance" tab and perform some basic configuration (for more information, refer to the official instructions ).
Follow the prompts and click Record to start recording. After completing the corresponding operation, click Stop.
When the page is running, DevTools captures performance metrics. After stopping the recording, DevTools processes the data and then displays the results on the Performance panel.
The main function
There are a lot of articles on how to use Performance, and you can find it by searching the Internet. Generally speaking, the following functions are mainly used:
Check the FPS chart : When you see a red bar above the FPS, it means that the frame rate has dropped too low, which may harm the user experience. Generally, the higher the green bar, the higher the FPS
View the CPU chart : The CPU chart is below the FPS chart. The color of the CPU chart corresponds to the Summary tab at the bottom of the performance board
Check the flame graph : The flame graph visually shows the internal CPU analysis. The horizontal axis is time, the vertical axis is the call pointer, and the top function of the call stack is at the bottom. After the JS analyzer is enabled, the flame graph will display each JavaScript function called, which can be used to analyze specific functions
Check Buttom-up : This view can see that certain functions have the greatest impact on performance, and can check the call path of these functions
For details on how to locate certain performance bottlenecks, you can refer to the official document series , which will not be introduced in detail here.
Performance Monitor
After opening the Chrome console, press the key combination ctrl + p(Mac shortcut key is command + p), enter > Show Performance Monitor, and you can open the Performance Monitor. The main monitoring indicators include:
CPU usage: CPU occupancy rate
JS head size: JS memory usage size
DOM Nodes: The number of DOM nodes mounted in the memory
JS event listeners: the number of event listeners
...: Others, etc.
In most cases, when we are performing performance optimization, some of the above tools are sufficient to determine the general optimization direction. More details and cases will not be detailed here.
Front-end performance monitoring
In addition to specific performance analysis and positioning, we often need to monitor business performance. Front-end performance monitoring includes two methods: Synthetic Monitoring (SYN) and Real User Monitoring (RUM).
Synthetic monitoring
Synthetic monitoring is to submit a page for performance audit in a simulation scenario, run your page through a series of tools and rules, extract some performance indicators, and get an audit report. For example, the Lighthouse described above is synthetic monitoring.
There are not many usage scenarios for synthetic monitoring, and it may generally appear in the process of development and testing, such as combining pipeline running performance reports, analyzing some simple tasks running locally when locating performance problems, etc. The advantages of this approach are obvious:
Ability to collect richer data indicators, such as data obtained in combination with Chrome Debugging Protocol
More mature solutions and tools, low cost
Does not affect the performance experience of real users
Real user monitoring
Real user monitoring means that users visit on our page, and various performance indicators will be generated after the visit. At the end of the user's visit, we upload these performance indicators to our log server for data extraction, cleaning and processing, and finally a process of displaying on our monitoring platform.
When we talk about front-end monitoring, most of them include real user monitoring. Some common performance monitoring includes loading time, DOM rendering time, interface time-consuming statistics, etc. For the page loading process, you can see that it is defined as many stages:
What we have to do is to do the management, calculation, collection, and reporting where we can. This process often requires the use of Performance Timeline API. Send the required data to the server, and then process the data, and finally monitor it through visualization and other methods. Therefore, real user monitoring often needs to be built in conjunction with the front-end architecture design of the business itself, and its advantages are easier to understand:
Completely restore the real scene, minus the simulation cost
The data sample is enough to smooth out individual differences
The collected data can be used for analysis and optimization of more scenarios
Compared with synthetic monitoring, real user monitoring cannot get more performance analysis data in some scenarios (for example, where the CPU is occupied and the memory is high), so it is used as an optimization effect in more cases. In these cases, specific analysis and positioning may still have to rely on synthetic monitoring.
However, real user monitoring also has its own advantages. For example, TCP and DNS connections are too time-consuming, and some running time-consuming problems in various environments are difficult to find in synthetic monitoring.
Performance analysis automation
In the development process, we often need to perform performance analysis. The performance analysis of the front-end is not low cost to get started. In addition to the basic page load time-consuming and network time-consuming, more specific positioning often needs to be analyzed in combination with the Performance panel, FPS, CPU, and flame graph introduced earlier.
If this area wants to be developed in the direction of automation, what can we do?
Use Lighthouse
I also introduced Lighthouse earlier, which provides a script to use. Therefore, we can run scripts for automated tasks, use Lighthouse to run analysis reports, and compare past data to perform performance regression in scenarios such as functional changes and performance optimization.
The advantage of using Lighthouse is that the development cost is low. You only need to adjust and obtain some data you need according to the official configuration , and you can quickly access the more comprehensive performance analysis capabilities of Lighthouse.
However, because Lighthouse is also based on CDP (Chrome DevTools Protocol), in addition to reducing the cost of implementation, some of the capabilities that CDP lacks will also be missing.
Chrome DevTools Protocol
The Chrome DevTools Protocol allows third parties to detect, inspect, debug, and analyze Chrome-based web applications. With this agreement, we can develop our own tools to obtain Chrome data.
Understanding the Chrome DevTools protocol
Chrome DevTools protocol is based on WebSocket, which uses WebSocket to establish a fast data channel connecting DevTools and the browser kernel.
The Chrome DevTools we use is actually a web application. When we use DevTools, the browser kernel Chromium itself will serve as a server, and the browser debugging tool interface we see communicates with Chromium through Websocket. The establishment process is as follows:
DevTools will serve as a web application and Chromium will provide the connection as a server.
Extract HTML, JavaScript and CSS files via HTTP.
After the resource is loaded, DevTools will establish a Websocket connection with the browser and start exchanging JSON messages.
Similarly, when we use DevTools to remotely debug real-time content on an Android device from a Windows, Mac, or Linux computer, this protocol is used. When Chromium starts with a --remote-debugging-port=0flag, it will start the Chrome DevTools protocol server.
Chrome DevTools protocol domain division
The Chrome DevTools protocol has APIs for interacting with many different parts of the browser, such as pages, service workers, and extensions. The protocol divides different operations into different domains, and each domain is responsible for different functional modules. For example DOM, Debugger, Network, Consoleand Performancethe like, can be understood as DevTools different functional modules.
Using this protocol we can:
The Runtime data acquired JS, such as the commonly used
window.performanceandwindow.chrome.loadTimes()the likeAcquisition
NetworkandPerformancedata for automatic performance analysisUsing Puppeteer 's CDPSession , the protocol communication with the browser will become easier
Performance related domains
This article talks about performance analysis, so here we only focus on the domains related to performance.
1. Performance. The runtime performance indicators Performancethat Performance.getMetrics()can be obtained from the domain include:
Timestamp: The timestamp of the measurement sample takenDocuments: The number of documents on the pageFrames: The number of frames in the pageJSEventListeners: The number of events in the pageNodes: The number of DOM nodes in the pageLayoutCount: Total number of all or part of the page layoutRecalcStyleCount: Total number of page style recalculationsLayoutDuration: The combined duration of all page layoutsRecalcStyleDuration: The total duration of all page style recalculationsScriptDuration: Duration of JavaScript executionTaskDuration: The combined duration of all tasks performed by the browserJSHeapUsedSize: JavaScript stack size usedJSHeapTotalSize: Total size of JavaScript stack
2. Tracing. TracingDomain can get DevTools performance tracking of page load. You can use Tracing.startand Tracing.stopcreate trace files that can be opened in Chrome DevTools or the timeline viewer.
We can see that the generated JSON file looks like this:
Such a JSON file, we can throw it into the DevTools Timeline Viewer , and you can see the corresponding timeline and flame graph:
3. Runtime. RuntimeThe domain exposes the JavaScript runtime through remote evaluation and mirroring objects. You can measure JavaScript memory leaks by Runtime.getHeapUsageobtaining the usage of the JavaScript stack, by Runtime.evaluatecalculating the expression of the global object, by Runtime.queryObjectsiterating the JavaScript stack and finding all objects with a given prototype (which can be used to calculate all objects with the same prototype somewhere in the prototype chain) ).
In addition to the above, there are Networkalso network-related performance that can be analyzed, and other data analysis that may involve DOM nodes, JS execution, etc., and more may need to be studied by yourself.
Automated performance analysis
By using the Chrome DevTools protocol, we can obtain a lot of data provided by DevTools, including network data, performance data, and runtime data.
Regarding how to use this protocol, many great gods have already encapsulated libraries in different languages for this protocol, including Node.js, Python, Java, etc., which can be found in the awesome-chrome-devtools project as needed .
As for what kind of data we can get and what degree of automation can be achieved, I won't talk about it in this article. I will open an article later in detail.
reference
Front-end performance analysis tool-Chrome performance analysis & performance monitor
How does Ant Financial achieve the ultimate in front-end performance monitoring?
Chrome devtools protocol-introduction to web performance automation practice
Tencent Global Digital Ecology Conference is coming!
Scan the QR code below the poster to make an appointment