Ever had a problem where you needed to optimize your JavaScript or CSS, but didn’t have a way to locate it?

You might say you can use Chrome’s Timeline to record, but timeline only records data, not updates in real time.

Here, you can consider using Chrome DevTools’ Performance Monitor, which can observe Performance data in real time.

Display the Performance Monitor Performance Monitor

To turn on the performance monitor, do the following

  • Open your browser and enter the url you want to monitor
  • According to theF12Open Chrome Console
  • According to the key combinationCtrl+P(Windows, MAC: Command + P)
  • The input> Show Performance MonitorTo turn on the performance monitor

Note that after pressing Ctrl+P(Windows, MAC shortcut is Command +P), you can type? Six different commands are prompted:

  • .Open the file (Source)
  • :, Go to line, jumps to the specified line of the file
  • @, Go to symbol
  • !, Run snippet, Run snippets
  • >Run command, Run command

Performance Monitor Performance indicators

As you can see, there are mainly four

  • CPU usage: INDICATES the CPU usage
  • JS head size, the size of the JS memory
  • DOM Nodes: Indicates the number of DOM Nodes mounted in memory
  • JS event listeners
  • Document
  • Document Frames
  • Layouts/SEC, the process used by browsers to calculate the location and size of all elements on a page
  • Style recalcs/SEC, page Style redrawn

Effect after implementation:

Audits

Diagnose the current web page in terms of network utilization and web page performance, and give some optimization suggestions. For example, list all CSS files that are not used.

For details on how to use the files, see Introduction to Chrome DevTools Audits functionality

Note that using Chrome Audits requires “turning over walls”

Performance Analysis

You can use the Performance Monitor to observe these problems, and then use the Performance tool to analyze the Performance.

As shown in the image above, after a certain amount of time (seconds or minutes), Chrome Devtools will output a short analysis report, as shown below:

Common performance problems

JavaScript to calculate

In particular, computations 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 issues

  1. High-overhead input handlers affect responses or animations, allow the browser to handle touch and scroll as late as possible, or bind listeners
  2. Poorly timed JavaScript affects responses, animations, loading, using requestAnimationFrame, having DOM operations spread across frames, using network worker threads
  3. Long-running JavaScript affects the response, shifting pure computational 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

Here are some common CSS problems

  1. High-overhead style calculations affect responses or animations, any CSS properties that change 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, and nested selectors force the browser to know everything about all the other elements, including parent and child. Try to refer to elements with only one class in CSS

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 web page means that one element can affect other elements, 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 and 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 compositing attributes only and avoid drawing them together, you will see a significant improvement in performance, but you need to be aware of the excessive number of levels

A link to the

  • New Chrome Devtools Performance Usage Guide
  • Details of Chrome developer tools (5)-Application, Security, Audits panels
  • Audits and Chrome performance plug-ins