There are many well-established theories and methods for front-end performance optimization, such as Yahoo! Performance Rules (Best Practices for Speeding Up Your Web Site), Google PageSpeed Insights Rules ( https://developers.google.com/speed/docs/insights/rules ). The same principles remain true, and performance optimization guidelines such as these can be mapped to different stages of the Browser Processing Model.
For details, you can view " Front-end Performance Monitoring: window.performance attribute analysis "
Obviously, most of these indicators are non-visual indicators (Non-Visual Metrics), which are conventional indicators for experience optimization and are inescapable key factors in experience and performance optimization. However, they are not sensory indicators and cannot completely Measure the user's sensory performance (Perceptual Performance).
The so-called sensory performance is the performance that users intuitively perceive. User experience is a very subjective judgment. So how to measure and count perceived performance? Usually we evaluate and measure user perception through user research analysis (eye trackers, user communication, user feedback, survey questionnaires, expert evaluations). But sensory performance is different from user experience. Is there a way to quantify and measure it? After some research and understanding, the author found that sensory performance can be measured, analyzed and benchmarked in a certain way, because the perception of performance is more reflected in visual changes, so we can measure sensory performance through some visual indicators:
-
First Paint Time/First Non-Blank Paint: The time of the first rendering
-
First Contentful Paint Time: The first rendering time of content elements in the document
-
First Meaningful Paint Time: represents the first meaningful rendering time
-
First Interactive Time: first interactive time
-
Consistently Interactive Time: Continuously interactive time
-
Fisrt Visual Change: The point in time when the first visual change occurs
-
Last Visual Change: The time point when the last visual change occurred
-
Speed Index: Visual speed——Mean Pixel-Histogram Difference
-
Perceptual Speed Index: Visual speed - Structural Similarity Image Metric algorithm, statistical results are closer to the user's real feelings
Performance optimization analysis tools
When it comes to performance optimization analysis tools, we have many choices during the development stage (such as Chrome's own Dev Tools, the veteran YSlow, and Google's PageSpeed Insights). The author here strongly recommends Lighthouse.
PageSpeed Insights also integrated Lighthouse ratings into PageSpeed Insights in a revision in 2018!
Comparing the two, after the integration, PageSpeed Insights mainly adds more visual report presentation parts, and you can choose the language to view the optimization plan after analysis; while Lighthouse has multiple channels to view the detection results. .
Introduce the usage and differences of these three tools:
-
Google DevTools
-
Google Extensions Lighthouse
-
Web.dev
Google DevTools
There is a very useful DevTools in the Google Chrome browser. After Chrome version 60, DevTools added a new panel, Audits, which is based on Lighthouse. We only need to open DevTools and execute Run audits in the Audits panel to start scoring.
The advantage of using this method is that it can detect some web pages that are not actually installed on the server. For example, if you want to adjust SEO on the test machine, or websites that are opened in local mode, you can also use this method to score.
Web.dev
Web.dev is also developed by Google based on Lighthouse. It is basically the same as PageSpeed Insights and Lighthouse. The difference is that its evaluation is based on impact (Impact). You can start optimizing from the more important projects more intuitively. . In addition, it will be slightly more convenient when downloading reports.
What's Lighthouse
Lighthouse is an open source tool developed by Google that provides a comprehensive set of tests to evaluate web page quality , including loading performance, accessibility, best practices and PWA.
Official introduction: https://developers.google.com/web/tools/lighthouse
Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO and more.
You can run Lighthouse in Chrome DevTools, from the command line, or as a Node module. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.
In versions after chrome 60, Lighthouse is already built into DevTool.
Open source library: GitHub - GoogleChrome/lighthouse: Automated auditing, performance metrics, and best practices for the web. This is how it introduces itself:
Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.
Lighthouse's goal is "Do Better Web" and is designed to help web developers improve their existing web applications. By running a suite of tests, developers can discover new Web platform APIs, become aware of performance pitfalls, and learn (new) best practices. In other words, let developers do better at web development.
lighthouse architecture diagram
lighthouse/architecture.md at main · GoogleChrome/lighthouse · GitHub (recommended to open and take a look)
Lighthouse source code structure
——
├─assets
├─build
├─clients // Display logic in the browser
│ └─extension // extension
├─docs // Documentation
├─lighthouse-cli // command line tool
│ ├─commands // commands
│ └─test
├─lighthouse-core // core logic
│ ├─audits
│ ├─computed
│ │ └─metrics
│ ├─config
│ ├─gather
│ │ ├─connections
│ │ └─gatherers
│ ├─lib // tool library
│ ├─report // report generator
│ │ └─html
│ │ └─renderer
│ └─test // test case
├─lighthouse-logger // Log collection
├─lighthouse-viewer // Report rendering tool
└─types // type file
Lighthouse overall calling relationship
Lighthouse-core internal module dependencies
In fact, I think the official documentation is pretty good, and it doesn’t seem like a problem at all to use the documentation.
There is no need to say more here. But I have to look at the principle of this. At the moment, I don’t have the time to understand it in depth...
Reference article:
[Performance Optimization] Performance Measurement Tool-LightHouse [Performance Optimization] Performance Measurement Tool-LightHouse - Zhihu
Measurement and optimization practice of front-end sensory performance Measurement and optimization practice of front-end sensory performance - Zhihu
Lighthouse, PageSpeed Insights & Web.dev, must-know assessment tools for network optimization. Lighthouse, PageSpeed Insights & Web.dev, must-know assessment tools for network optimization |
When reprinting the article " Performance Measurement Tool-DevTools/PageSpeed/LightHouse " on this site , please indicate the source: Performance Measurement Tool-DevTools/PageSpeed/LightHouse - Front-end Performance Optimization - Zhou Junjun's personal website