Lighthouse

Chrome provides Lighthouse (the old version was Audit) to judge the performance of our site, which runs a series of tests against the page and then generates a report on the page’s performance.

• It creates a benchmark for you to measure subsequent changes.
• It gives you workable hints as to which changes will have the most impact.

The Lighthouse panel

• Simulated throttling

Simulate the performance of a website in a poorly equipped environment

• Clear storage

Clear cached data to simulate a user’s first visit to the site

• Categories (generate a report on the performance of the options below) Disabling the options will speed up the review process slightly.

  • Performance
  • Progressive Web App (Progressive Web Application)
  • Best practices
  • Accessibility
  • SEO

• Device (Mobile option simulates Mobile viewport (has network speed limit), Desktop forbids analog Mobile viewport).

• Click Generate Report to Generate the audit report

The Performance report

Let’s take a look at how to use Performance to evaluate the Performance of our website. The Performance indicators are composed of the following 6 indicators

FCP (First Contentful Paint)

Measuring the time it takes from page loading to any part of the screen rendering page content, quick FCP helps convince the user that something is happening.

Largest Contentful Paint (LCP) :

Measures the time from the start of the page to the time when the largest block of text or image element appears on the screen. It can be used to determine when the main content of a page is rendered on the screen.

TTI (Time to Interactive):

Measures the time between the start of a page loading and the visual rendering when its initial script (if any) is loaded and can reliably and quickly respond to user input.

Total Blocking time (TBT) :

First Contentful Paint (FCP) + Time to Interactive (TTI) = Total blocking Time (TBT) where the main thread is blocked long enough to prevent input responses.

CLS (Cumulative Layout Shift) :

CLS is an important user-centric metric for measuring visual stability of users.

• Impact factors: Layout transformations of page content usually occur as a result of asynchronously loading resources or dynamically adding DOM elements to the page above existing content. The culprit could be an image or video of unknown size, displaying a larger or smaller font than its back-up, or a third-party AD or widget that dynamically resizes itself.

• Layout transformation: A layout transformation occurs only when an existing element changes its starting position. If a new element is added to the DOM or an existing element changes size, that element does not count as a layout offset as long as the change does not cause other visible elements to change their starting position

• How to reduce layout movement:

  • The CSS Transform property allows you to animate elements without triggering layout transformations:
    • Use transform: scale() to replace changes to the height and width properties
    • For moving components left and right, avoid changing the top, right, bottom, or left attributes and use transform: Translate () instead.
    • The reason why Transform can improve CLS experience is that the GPU(Image Accelerator) process will open a new compound layer for it, which will not affect the default compound layer, so it will not affect the surrounding DOM structure, and the change of properties will also be handed to the GPU, which will not affect the backflow redraw. But creating new composite layers is expensive, so don’t overuse them.

• The CLS score for good user experience should not exceed 0.1

For more on CLS, see web.dev/ CLS /

Speed Index:

Measure the speed of visible filling of page content. This is the average time it takes to display the visible part of the page. Depending on the size of the viewport, the lower the score, the better.

What the page looks like when it loads

Opportunities

In Opportunities there are specific suggestions on how to improve the loading performance of this particular page. We can modify our code as suggested and re-check if the page performance has improved.

Diagnostics

The Diagnostics section provides more detailed information on factors that affect page load time.

Passed audits

Passed audits show the state of our site

How to Improve Performance

• Identify critical code and eliminate non-critical code.

• Js optimization. By default, all JavaScript blocks the parser, so JS optimization is especially important

  • After identifying the key JS code, inline it to the page. Once the page loads, it will have the content needed to handle the core functionality of the page. Non-critical JS code is introduced through urls.
  • Non-critical JS, we can add asynchronous keywords to the script tag to instruct the browser not to block DOM builds while waiting for the script to become available such as:<script src="app.js" async></script>(But note that it is not sequential, after the script load execution is not sequential)
  • Break up the js

• CSS optimization, loading and parsing of CSS blocks the parser, so CSS optimization is also important

  • Identify the key CSS and inline it on the page. CSS that are not critical are introduced through urls.
  • Compress the CSS file and reduce the CSS size

• Preload key resources

  <link rel="preload" as="script" href="critical.js">
  <link rel="preload" as="style" href="styles.css" >
Copy the code

• Avoid heavy network load

  • Defer sending requests until needed
  • Minimize and compress network load
    • The compressed file
    • HTTP compression, at least using gzip to compress text-based resources, consider Brotli ~q11. Brotli is superior to Gzip in terms of compression ratio.
  • Use WebP instead of JPEG or PNG for images. WebP images are smaller than JPEG and PNG images (typically reducing file size by 25-35%). This reduces page size and improves performance.

• Using the cache

  • DNS cache
  • CDN cache
  • A resource cache

• Using pre-render

• Avoid multiple page redirects. Redirects can slow down your page load. When a browser requests a redirected resource, the server typically returns the following HTTP response:

  HTTP/1.1 301 Moved Permanently Location: /path/to/new/ LocationCopy the code

  The browser must then make another HTTP request at the new location to retrieve the resource. This extra travel across the network can delay loading of resources by hundreds of milliseconds.

• Keep the number of requests low and the number of transfers small

• Reduce server response time

Coverage

The Coverage panel helps us check the Coverage of our code to remove unwanted code

• As shown in the figure below, approximately 76% and 30% of jQuery and Lodash files are unused, respectively.

  

• Click on the jquery.js line. DevTools opens the file in the Sources panel. If a line of code has a green bar next to it, that line of code has been executed. The red bar indicates that it is not executed and is definitely not needed at page load time.

  

Performance

Analyze and record the performance of the page as it is running or the page as it is loading.

Performance analysis

The performance result graph is as follows:

FPS

Every time you see a red bar above an FPS, it means that the frame rate has dropped so low that it can damage the user experience. In general, the higher the green bar, the higher the FPS.

CPU

The fact that the CPU chart is full of color means that the CPU was used up during the recording process. The blue outline represents the CPU chart and the corresponding meaning of the chart’s color. From the graph, we can tell that the page spent most of the rendering time.

main

The activity chart of the main thread over time, with the x axis representing records over time. Each bar represents an event. A wide bar indicates that the event took longer. The Y-axis represents the call stack. The top event causes the bottom event. (The red triangle in the upper right corner of the event. Whenever you see a red triangle, a warning that there may be a problem related to this event)

Click to see specific stack events to check performance bottlenecks

• Summary

Summarize the details of how long the event took and analyze which lines of code might be causing a performance bottleneck

• Bottom-Up

Look directly at the activities that spend the most time

• Call Tree

See which root activities are causing the most work. The root activity is the activity that causes the browser to do something. For example, when you click on a page, the browser fires an Event activity as the root activity. This Event may cause the handler to execute, and so on. For example, Animation Frame Fired, Paint, and Composite Layers are the root activities.

• Event log

View activities in order of activity during the recording period

• About the use of performance not name one by one, for details, please read this article: developer.chrome.com/docs/devtoo…

The last

Thank you for reading, if you have any questions please correct!