Reprint please retain this part of the content, indicate the source. In addition, the front end team of Toutiao is looking forward to your joining us
Why does UI performance lag? Why do crash monitors scream in the middle of the night? JS error why repeatedly black hands? Serial request timeout, who is responsible? What is hidden behind hundreds of abnormal users? Is it interaction distortion or code decay that is behind all of this? Stay tuned tonight to share “Into Chrome” and let us follow the camera into Chrome’s inner world.
Without further ado, let’s take a look at how Chrome Tools works:
The Animations inspector
What is an animation group? What is an animation group?
An animation group is a group of animations that appear to be related to each other. Animators and developers must schedule and time each animation to have a coherent visual effect. The animation inspector predicts which animations are related based on the start time (not counting delays, etc.) and groups them side by side (as shown above), that is, a group of animations that are all triggered in the same script block is grouped into one group.
Region Introduction Region introduction
Animation inspector is divided into four main parts, combined with the following figure:
-
Zone 1 can clear all currently captured animation groups, or change the speed of the currently selected animation group. Zone 1 can clear all currently captured animation groups, or change the speed of the currently selected animation group.
-
Area 2 allows you to select animation groups, which can then be examined and modified in pane 4. Area 2 allows you to select animation groups, which can then be examined and modified in pane 4.
-
Zone 3 can pause and start the animation, or jump to specific time points in the animation. Zone 3 can pause and start the animation, or jump to specific time points in the animation.
-
Area 4 checks and modifies the currently selected animation group. Area 4 checks and modifies the currently selected animation group.
The main purpose
Check the animation
You can slow play, replay, and check the source code of the animation group. After capturing an animation, you can check it in several ways
- Play button is set to pause, drag the red vertical bar can freely control the animation progress
- Hover over the thumbnail of the animation to see its preview
- If you click on the thumbnail, the animation will play back in the viewport, and if you click on the replay button, you’ll get the same effect
- Adjust the speed button to choose three rate, 100%, 25%, 10% selected after all animation groups according to the proportion to play, so that you can let us get a better look details adjustment speed button to choose three rate, 100%, 25%, 10% selected after all animation groups according to the proportion to play, so that you can let us get a better look the details
- Click on one of these animations to navigate to the code associated with the current animation
Modify animation Modify animation
Modify animation group time, delay, duration, or keyframe offsets. Currently, editing Bezier curves and keyframes is not supported.
-
You can adjust the duration of the animation by dragging the solid circle of the animation.
-
If the animation defines any keyframe rules, these will be represented as hollow circles. Click and drag one of them to change the duration of the keyframe. If the animation defines any keyframe rules, these will be represented as hollow circles. Click and drag one of them to change the duration of the keyframe.
-
Hold down the color block area to drag the entire animation to add delay
supportive
Current supported type
An SVG animation can use some attributes of SVG, such as fill
An unsupported type
Canvas animation WebGL animation requestAnimationFrame animation setInterval Animation Lottie animation
Demo presentation
Keyframe animation demo: the animate. Style / # usage animation demo: interactive-examples.mdn.mozilla.net/pages/css/a… The transition transition animation demo: interactive-examples.mdn.mozilla.net/pages/css/t… SVG animation demo: CDpn. IO /suez/fullpa… Cdpn. IO /jjperezagui…
Lighthouse reviews web applications
Lighthouse is an open source automation tool designed to improve the quality of web applications. It runs a series of tests on a page and then generates a report on the page’s performance. Lighthouse scores the results of each selected test and recommends improvements that can be considered Google’s web best practices.
How to use it? How to use it?
In Google Chrome 60 or later, it can be found.
Test Item Category
The test items included page performance, PWA, best practices, accessibility (accessibility), SEO
Device type
Currently, only Mobile and Desktop are available
Generate a report
Select the items to be tested, click generate report and wait for the results. In this example, only Performance and Best practices are selected
Performance analysis Performance analysis
The scores can be calculated using the performance calculator, and the weights can be seen here
First Contentful Paint
FCP first content rendering: the time it takes the browser to render the first piece of DOM content after the user navigates to the page. Images, non-blank canvas elements, and SVG on a page are also treated as DOM content, but do not include anything inside an IFrame.
This is the first time a user is starting to see content on a page, but just because there is content doesn’t mean it’s useful content (headers, navigation bars, etc.), nor does it mean there is content for the user to consume.
The specific criteria of this part are as follows:
| FCP time(in seconds) | Color-coding | FCP score(HTTP Archive percentile) |
|---|---|---|
| 0–2 | Green (fast) | 75-100. |
| 2, 4 | Orange (moderate) | 50-74. |
| Over 4 | Red (slow) | 0–49 |
Time to Interactive
The first CPU idle occurs when the user can start interacting with the page; When the user is fully able to interact with the page, the interactive-time TTI is obtained. This metric is used to mark the point in time when the application has been visually rendered and can reliably respond to user input. Applications may fail to respond to user input for a number of reasons:
-
The JavaScript required for the page component to run has not been loaded. The JavaScript required for the page component to run has not been loaded.
-
A task that takes a long time blocks the main thread
TTI is important because some sites optimize content visibility at the expense of interactivity. This can lead to a frustrating user experience: the site seems ready to go, but when the user tries to interact with it, nothing happens.
A page is considered to be fully interactive when:
-
This page displays useful content, which is measured by FCP,
-
Event handlers have been registered for most visible page elements
-
The page responds to user interactions in 50 milliseconds. The page responds to user interactions in 50 milliseconds.
Preferably Interactive The exact method of calculating the indicators can be found in the following table on First Interactive and Preferably Interactive to explain the TTI scores:
| TTI metric(in seconds) | Color-coding |
|---|---|
| 0–3.8 | Green (fast) |
| 3.9–7.3 | Orange (moderate) |
| Over 7.3 | Red (slow) |
Speed Index
SI represents the rate at which content is filled in the visual area of the page, and the lower the value, the better. Please refer to github.com/WPO-Foundat…
| Speed Index(in seconds) | Color-coding | Speed Index score |
|---|---|---|
| 0–4.3 | Green (fast) | 75-100. |
| 4.4–5.8 | Orange (moderate) | 50-74. |
| Over 5.8 | Red (slow) | 0–49 |
Total Blocking Time
Total blocking time TBT, which is the total blocking time of all long tasks between FCP and TTI. Suppose a total of several tasks as shown below are executed on the page between FCP and TTI: long task (execution time > 50ms) and short task (execution time < 50ms)
Any task that takes more than 50ms to execute is a long task, and it is assumed that the time after 50ms is blocked. So long task blocking time = total execution time – 50ms
So in the case above, TBT is equal to 345ms in total. The high and low of this indicator actually affects the high and low of TTI, or several indicators related to the long task.
Largest Contentful Paint
The LCP measures the render time of the largest content element visible to the user within the standard viewport. The value changes as larger elements appear on the page rendering (the LCP metric stops recording after the user’s first interaction).
In fact, the LCP is a better indicator of a page’s performance because it is constantly updated. For example, FCP also records the Loading animation on the page, but it is not what users want to see at this time. Therefore, with the change of FCP, it can better express specific performance data. In the official recommended time interval, 2.5 seconds indicates a good user experience.
Cumulative Layout Shift
CLS is an important indicator to measure the visual stability of a page. In projects, it is common to encounter problems such as asynchronous loading of resources, resulting in dynamic DOM addition. If you determine the jitter of the page content, it helps you locate these problems.
Look at an example: storage.googleapis.com/web-dev-ass…
For example, the text moves 25% of the screen height distance, and the area affected by displacement accounts for 75%, so the CLS is 0.25 * 0.75 = 0.1875. The CLS recommended value is less than 0.1, which means less page jitter and better user experience.
Changes Local change tracing Changes Local change tracing
Chrome 65 now supports Changes, which tracks Changes made locally by users in DevTools.
For example, 🌰
Tc39. Es /process-doc…
Coverage code Coverage (CSS and JS)
Coverage has been supported since Version 59 of Chrome. Dynamic Analysis is used to collect Coverage at runtime.
What can be done?
The coverage panel is used to find unused CSS and JS code. After a page or code loads, this panel tells you which code is unused and which is used.
-
The URL bar is the URL of the resource that has been analyzed. The URL bar is the URL of the resource that has been analyzed.
-
The Type column indicates whether the resource contains CSS, JavaScript, or both. The Type column indicates whether the resource contains CSS, JavaScript, or both.
-
Total bytes is the total size (in bytes) of the resource. Total bytes is the total size (in bytes) of the resource.
-
Unused Bytes Indicates the number and proportion of Unused Bytes. Unused Bytes Indicates the number and proportion of Unused Bytes.
-
The last column is a visualization of total and unused bytes. The red parts of the bar chart are unused bytes. The green parts are the bytes used. The last column is a visualization of total and unused bytes. The red parts of the bar chart are unused bytes. The green parts are the bytes used.
-
The top left drop-down box is to select coverage granularity (Chrome 80), which can specify whether code coverage data should be collected per function or per Block. Blocks have more detailed coverage, but are much more expensive to collect. By default, DevTools now uses per Function by default. The top left drop-down box is to select coverage granularity (Chrome 80), which can specify whether code coverage data should be collected per function or per Block. Blocks have more detailed coverage, but are much more expensive to collect. By default, DevTools now uses per Function by default.
What’s the use of this data?
A word of warning. Finding unused code is relatively easy. But refactoring a codebase so that each page only ships the JavaScript and CSS that it needs can be difficult. This guide doesn’t cover how to refactor a codebase to avoid unused code because these refactors depend highly on your technology stack.A word of warning. Finding unused code is relatively easy. But refactoring a codebase so that each page only ships the JavaScript and CSS that it needs can be difficult. This guide doesn’t cover how to refactor a codebase to avoid unused code because these refactors depend highly on your technology stack.
Finding unused code is easy, but refactoring the code base so that each page contains only the required JavaScript and CSS is difficult.
If a file has low coverage, it usually means that the user is loading too much unnecessary code, which predictably leads to performance degradation over slow networks. In addition, more code being parsed and compiled means more hardware resource consumption and significant performance issues on low-end devices.
Many programs may be in the relatively old warehouse, and legacy code exists for a long time, it is likely that code in the library there are a large number of dead code, but who also dare not delete them, because of JS of the dynamic characteristics of the language, you can’t turn what looks rough “not used” code directly deleted, Unless you know all the code execution paths, Coverage can provide a baseline.
