A, network

Just to understand the concept

DOMContentLoaded and Load and Finish

– DOMContentLoaded and Load

DOMContentLoaded: The DOM tree is built. That is, an HTML page parses the HTML structure from top to bottom to close the tag at the end

Load: The page is loaded. After the DOM tree is constructed, load external resources such as images in THE HTML/CSS. After the loading is complete, the page is loaded.

DOMContentLoaded will take less time than Load, with the time difference roughly equal to the time it takes for the external resource to Load.

– Finish

Finish: Finish is the time at which all HTTP requests are sent to the page until the response is complete. The http1.0/1.1 protocol limits the number of concurrent requests for a single domain name to 6. Requests for resources such as CSS) within the limit of 6 concurrent requests. HTTP2 has no limit on the number of requests

Finish takes longer than Load, which means the page has a significant amount of requests,

The Finish time is smaller than the Load time, which means that the page request is small. If the page is a static page with only one HTML document request, the Finish time is roughly equal to the HTML document request time.

The page sends the request and the page parses the document structure on two different threads,

So Finish time is not directly related to DOMContentLoaded and Load.

Use the Performance panel in chrome Developer Tools to solve performance bottlenecks

In front of the word

Use the Performance panel of Chrome DevTools to record and analyze all the activity of the page at runtime. This article details how to use the Performance panel to solve performance bottlenecks

To prepare

【 Anonymous mode 】

Anonymous mode keeps Chrome running in a relatively clean environment. For example, many Chrome plug-ins are installed, which may affect our performance analysis

Use the shortcut CTRL + Shift + N to code a new TAB of Chrome in anonymous mode

[Mobile Device CPU]

Mobile devices typically have much weaker cpus than desktops and laptops. When analyzing pages, you can use a CPU Throttling to simulate a mobile device CPU

In DevTools, click the TAB for Performance. Make sure Screenshots CheckBox is checked; Click the Capture Settings (⚙️) button and DevTools displays a number of Settings to simulate various situations; For emulating the CPU, select 4x Slowdowns, and Devtools begins emulating the 4x slow CPU

An overview of

【 composition 】

The Performance panel has the following four panes:

1. Control buttons.

2. The overview. Advanced summary of page performance (FPS: frame rate, CPU:CPU usage, NET: network requests)

3. Flame chart. Visualization of CPU stack tracing (left name is main thread events, Network: Network request details)

4. Data statistics. Summary data in the form of graphs (summary: statistics report, bottom-up: Event duration order, Call Tree: Event Call order, Event log: Event occurrence order)

Color representation: HTML files are blue, scripts are yellow, style sheets are purple, media files are green, and other resources are gray

【 Take notes 】

Open the page you want to record, and then reload the page. The Performance panel automatically records page reloads.

To Record page interactions, open the Performance panel, then press the Record button or type the keyboard shortcut Cmd+E (Mac) or Ctrl+E(Windows/Linux) to start recording. When recording, the **Record ** button turns red. Perform the page interaction, then press the Record button or type the keyboard shortcut again to stop recording

Once the record is complete, DevTools guesses which part of the record is most relevant and automatically scales to that part

To view

2. The Overview 】 【

The Overview pane contains the following three charts:

1, the FPS. Frames per second. The higher the green vertical line, the higher the FPS. The red blocks on the FPS chart indicate long frames that are likely to stall

2, the CPU. CPU resources. This area diagram indicates the type of event that consumes CPU resources

3, NET. Each colored bar represents a resource. The longer the bar, the longer it takes to retrieve the resource. The light-colored part of each bar represents the wait time (from the time the resource is requested to the time the first byte is downloaded)

Click or drag the mouse to select A part of the flame map automatically matched to the same part, you can use W(zoom in), S(zoom out), A(left move), and D(right move) key adjustment selection.

【 Flame chart 】

See one or three vertical dashed lines on the flame chart. Blue line: : DOMContentLoaded event. Green line: time of first drawing. Red line: Load event

When you select an event in the fire diagram, the Details pane displays additional information about the event

​

diagnosis

[JS]

JavaScript calculations, especially those that trigger a lot of visual changes, can degrade application performance. Don’t let poorly timed or long-running JavaScript interfere with user interaction

Here are some common JavaScript problems

1. High overhead input handlers affect responses or animations

Let the browser handle touch and scroll as late as possible, or bind to listening

2. Poorly timed JavaScript affects responses, animations, loading

Use requestAnimationFrame, spread DOM operations across frames, and use network worker threads

Long running JavaScript affects the response

Move pure computing work to the Web worker. If DOM access is required, use requestAnimationFrame

“Style”

Style changes can be expensive, especially if they affect multiple elements in the DOM. As soon as the style is applied to the element, the browser must determine the impact on all related elements, recalculate the layout, and redraw

Click the Recalculate Style event (shown in purple) to see more information in the Details pane. If style changes take a long time, the performance impact can be significant. If style calculations affect a large number of elements, there is another aspect that needs to be improved

To reduce the impact of Recalculate Style events, use attributes that have less impact on rendering performance. For example, use transform and opacity property changes to animate, and will-change or translateZ to elevate moving elements

Here are some common CSS problems

1. High overhead style calculations affect responses or animations

Any CSS properties that change the element geometry, such as width, height, or position; The browser must check all the other elements and redo the layout. Avoid CSS properties that trigger rearrangements

2. Complex selectors affect responses or animations

Nested selectors force the browser to know everything about all other elements, including parents and children. Try to refer to elements with only one class in CSS

Layout (or rearrangement) is the process that browsers use to calculate the position and size of all elements on a page. The layout pattern of a page means that one element can influence another; For example, the width of the body element generally affects the width of its children, nodes throughout the tree, and so on. This process can be complicated for browsers. As a general rule of thumb, if geometry is returned from the DOM request before the frame completes, you will find that “forced synchronous layout” occurs, which can be a major performance bottleneck when operations are frequently repeated or performed against large DOM trees.

【 rearrangement 】

Layout (or rearrangement) is the process that browsers use to calculate the position and size of all elements on a page. The layout pattern of a page means that one element can influence another; For example, the width of the body element generally affects the width of its children, nodes throughout the tree, and so on. This process can be complicated for browsers. As a general rule of thumb, if geometry is returned from the DOM request before the frame completes, you will find that “forced synchronous layout” occurs, which can be a major performance bottleneck when operations are frequently repeated or performed against large DOM trees.

The Performance panel determines when a page causes a forced synchronous layout. These Layout events are marked with red vertical bars

Layout jitter refers to the repeated forcible layout synchronization. This happens when JavaScript repeatedly writes and reads from the DOM, forcing the browser to recalculate the layout repeatedly

【 redraw 】

Drawing is the process of filling pixels. This is often the most expensive part of the rendering process. If you notice a page stalling in any case, you probably have a drawing problem.

Composition is the process of putting drawn parts of a page together for display on the screen. In most cases, if you stick to only synthesizer attributes and avoid drawing together, you’ll get a huge performance improvement, but you need to be aware of excessive layer counts

Do not use the following code

* {
  will-change: transform;
  transform: translateZ(0);
}
Copy the code

This is a roundabout way of saying you want to improve every element on the page. The problem here is that each layer created requires memory and management, which is not free. In fact, on devices with limited memory, the performance impact can far outweigh any benefit from creating a layer. The texture of each layer needs to be uploaded to GPU, which further limits the bandwidth between CPU and GPU and the memory available for texture processing on GPU. If most of the rendering time is spent on drawing, it indicates that there is a drawing problem

Here are some common drawing problems

1. Draw storm impact response or animation

Large drawing areas or large overhead drawing affect the response or animation. Avoid drawing, elevate elements that will be moved to their own layer, and use deformation and opacity

2. Layer surge affects animation

Raising too many elements too much with translateZ(0) can seriously affect animation performance. Be careful to raise layers, and only raise layers if you know there will be a real improvement