This article was originally published at: github.com/bigo-fronte… Welcome to follow and reprint.
preface
Good or bad page performance directly affects user retention. For front-end developers, they should not judge by sensory experience, but need to understand the performance indicators of the page, and try to quantify these indicators, according to the quantitative indicators for targeted improvement, can truly achieve the optimization effect. General page performance indicators are:
- Bad time
- The first screen time
- User operable time
- Total page download time
- Network request time
- Memory usage, CPU usage, etc.
This article introduces the Performance API, Chrome’s Performace panel, and Lighthouse to show you how to use these tools to perform simple Performance checks and analysis on a page.
Performance API
One of html5’s new features is Performace, which returns information about the current page’s performance. It is part of the High Resolution Time API, It also integrates the Performance Timeline API, Navigation Timing API, User Timing API, and Resource Timing API.
This section describes how to use Timing indicators to analyze performance and obtain Timing indicators:
// Level 1 (deprecated soon)
window.performace.timing
// Level 2
window.performance.getEntriesByType("navigation") [0]
Copy the code
The following figure shows the processing model of Navigation Timing Level 1. The whole process is divided into 9 modules from the unloading of the old page from the current browser window to the completion of the loading of the new page: Unmount old documents, redirect/unload, application cache, DNS resolution, TCP handshake, HTTP request processing, HTTP response processing, DOM processing, document loading complete.
Navigation Timing Level 2, a new time line is given, the new time line will describe resource loading time with PerformanceResourceTiming object wrapped up.
Indicators show
indicators | instructions |
---|---|
navigationStart | Represents the Unix timestamp at the end of the uninstallation from the previous document. If there is no previous document, this value will be equal to fetchStart. |
unloadEventStart | Indicates the timestamp of previous web page unload (same domain as the current page), 0 if there is no previous web page unload or if the previous web page has a different domain from the current page. |
unloadEventEnd | Returns the timestamp at which the previous page’s Unload time bound callback function completed execution |
redirectStart | The time when the first HTTP redirect occurs. If there is no jump or the jump is not within the same domain name, 0 is returned. |
redirectEnd | The time when the last HTTP was completed. If there is no jump or the jump is not within the same domain name, 0 is returned. |
fetchStart | Returns the Unix millisecond timestamp when the browser is ready to read the document using an HTTP request. This event occurs before the web page queries the local cache. |
domainLookupStart | Returns the Unix millisecond timestamp from the start of the domain name query. If persistent connections are used, or the information is fetched from a local cache, the return value is the same as the value of the fetchStart attribute. |
domainLookupEnd | Returns the Unix millisecond timestamp at the end of the domain name query. If persistent connections are used, or the information is fetched from a local cache, the return value is the same as the value of the fetchStart attribute. |
connectStart | Returns the Unix millisecond timestamp when the HTTP request began to be sent to the server. If persistent Connection is used, the return value is equal to the value of the fetchStart attribute. |
connectEnd | Returns the Unix millisecond timestamp when the connection between the browser and the server was established. If a persistent connection is established, the return value is the same as the value of the fetchStart attribute. Connection establishment refers to the completion of all handshake and authentication processes. |
secureConnectionStart | Returns the Unix millisecond timestamp when the browser and server began the handshake for the secure link. If the current page does not require a secure connection, 0 is returned. |
requestStart | Returns the Unix millisecond timestamp when the browser makes an HTTP request to the server (or when it starts reading the local cache). |
responseStart | Returns the Unix millisecond timestamp when the browser receives the first byte from the server (or reads it from the local cache). |
responseEnd | Returns the Unix millisecond timestamp when the browser received (or read from the local cache) the last byte from the server (or closed if the HTTP connection has been closed before). |
domLoading | Returns the Unix millisecond timestamp when the DOM structure of the current web page starts parsing (that is, when the document. readyState property becomes “loading” and the corresponding readyStatechange event is triggered). |
domInteractive | Returns the Unix millisecond timestamp when the DOM structure of the current web page ends parsing and the embedded resource starts loading (that is, when the Document.readyState property changes to “interactive” and the corresponding readyStatechange event is triggered). |
domContentLoadedEventStart | Returns the Unix millisecond timestamp for the current web page when the DOMContentLoaded event occurs (that is, when the DOM structure is parsed and all scripts start running). |
domContentLoadedEventEnd | Returns the Unix millisecond timestamp when all scripts that need to be executed on the current page are completed. |
domComplete | Returns the Unix millisecond timestamp when the DOM structure of the current web page was generated (that is, when the Document.readyState property became “complete” and the corresponding readyStatechange event occurred). |
loadEventStart | The LOAD event is sent to the document, which is when the LOAD callback function starts executing. |
loadEventEnd | The time when the callback function of the load event completes execution. |
Calculation of key indicators
The following describes how to collect page performance statistics.
let times = {};
let timing = window.performance.timing;
Use navigation v2 HTTP: / / https://www.w3.org/TR/navigation-timing-2/ / / priority
if (typeof window.PerformanceNavigationTiming === 'function') {
timing = window.performance.getEntriesByType('navigation') [0] || timing;
}
// Redirection time
times.redirectTime = timing.redirectEnd - timing.redirectStart;
//DNS query takes time
times.dnsTime = timing.domainLookupEnd - timing.domainLookupStart;
//TTFB takes time to get the first byte
times.ttfbTime = timing.responseStart - timing.navigationStart;
// Query the cache data time
times.appcacheTime = timing.domainLookupStart - timing.fetchStart;
// The time to uninstall the page
times.unloadTime = timing.unloadEventEnd - timing.unloadEventStart;
// The TCP connection takes time
times.tcpTime = timing.connectEnd - timing.connectStart;
//request Request time
times.reqTime = timing.responseEnd - timing.responseStart;
// Parsing dom tree takes time
times.analysisTime = timing.domComplete - timing.domInteractive;
// Blank screen time
times.blankTime = (timing.domInteractive || timing.domLoading) - timing.fetchStart;
// First screen time
times.firstPaint = timing.domComplete - timing.fetchStart;
//domReadyTime
times.domReadyTime = timing.domContentLoadedEventEnd - timing.fetchStart;
Copy the code
Using The Performace API, you can report and statistics the page performance indicators on the user side, and optimize them according to the quantified data. Note that for SPA, if the front-end route changes, Performace data will not be updated. Therefore, if you need to collect statistics on sub-route indicators, you need to customize the report.
Chrome Performance panel
Performance is a developer tool provided by Chrome to record and analyze all the activities of our application at runtime. The data presented by it has the characteristics of real-time and multidimensional, which can help us locate performance problems well.
When using the Performance tool, it is best to open the page in traceless mode to avoid the impact of other Chrome plug-ins on page Performance.
The panel is divided into four parts:
Panel area | instructions |
---|---|
The control panel | Information captured during recording start, stop, and configure recording. |
The overview panel | An overview of page presentation (behavior). |
Flame panel | Visualize CPU stack information records. |
Statistical panel | Summarize data in the form of charts. |
The control panel
Enable recording, disable recording, and configure the content to be recorded during recording.
The overview panel
The summary area consists of three graphical records:
The data type | instructions |
---|---|
FPS | The higher the green column, the higher the FPS, and the red column indicates a possible stutter. |
CPU | Indicates which events are consuming CPU resources. |
NET | Blue represents HTML files, yellow represents Script files, purple represents Stylesheets files, green represents Media files, and gray represents other resources. |
Flame panel
- Analyze box selection areas from different perspectives. For example: Network, Frames, Interactions, Main, etc.
- On the Flame Chart panel you can see three lines. The blue line represents the DOMContentLoaded event, the green line represents the time to first Paint, and the red line represents the Load event.
Statistical panel
Statistics panel selection due to click to select different target statistics content is different.
- Summary panel: Summarizes the total browser load time.
color | meaning |
---|---|
blue | Loading, Loading |
yellow | Scripting, script |
purple | Rendering, the Rendering |
green | Painting, drawing |
Dark grey | Other, Other |
Light grey | Idle, Idle |
-
Bottom-up panel: Displays the elapsed time for each phase of the event.
-
Call Tree panel: View the Call stack of events.
-
Event Log panel: Event Log information.
Lighthouse
Lighthouse is a tool developed by Google for analyzing web applications and web pages, gathering modern performance metrics and providing insights into developer best practices. Provide Lighthouse with a site to review, which runs a series of tests against the page and then generates a report on the page’s performance.
Lighthouse is the main monitoring indicator
indicators | instructions |
---|---|
Performance | Page performance scores, including: First Contentful Paint, First Meaningful Paint, First CPU Idle, Time to Interaction Interactive, Speed Index, and Estimated Input Latency. |
PWA (Progressive Web App) | Verify all aspects of PWA performance. |
Accessibility | Monitor page accessibility and optimization recommendations. |
Best Practice | Does the page conform to best practices? |
Search Engine Optimization (SEO) | Is the page optimized for search engine results ranking? |
Lighthouse Score Calculation
- 0-49 (slow) : red
- 50-89 (average) : orange
- 90-100 (fast) : Green
Lighthouse used
- Use the Chrome extension
- Use LightHouse in the Chrome Debug panel
- Use LightHouse through the command line
Use the Charome plugin to extend
- Installation: chrome.google.com/webstore/de…
- Use: On the page where you want to collect metrics, click Generate Report.
Use LightHouse in the Chrome Debug panel
Open chrome’s control panel and select the Lighthose TAB to configure the report generation.
Use LightHouse through the command line
Installation:
npm install -g lighthouse
# or use yarn:
# yarn global add lighthouse
Copy the code
Use: Execute the Lighthouse URL to generate a report.
Bigo’s front-end build platform, Almond
Of course, you can also use the page performance analysis tool on bigo’s development platform Almond to perform one-click performance analysis on H5 pages. H5 can be launched only after it has been evaluated and all performance indexes meet the internal requirements. So far, there are more than 1800 review pages.
At present, Bigo front-end is developing rapidly, with a team size of more than 100 people, including NodeJS, small games, middle background, C-side business, front-end architecture and other technical directions. We have good practice in each direction. Welcome to join us, grow together, and build a more professional front-end team together.
conclusion
Using the Performace API, Chrome Performace, and Lighthouse tools, you can learn about the performance of a page in multiple dimensions, and obtain optimization suggestions, so that you can optimize the page accordingly.
Above, if there are mistakes, welcome to correct.
reference
Thoroughly understand front-end page performance monitoring in 10 minutes
Navigation Timing API
Front-end Performance Optimization Guide [6]- Web Performance Standards
Welcome everyone to leave a message to discuss, wish smooth work, happy life!
I’m bigO front. See you next time.