Join us and do something challenging

Performance monitor

Starting with Chrome 64, a new monitor has been added to monitor page performance in real time. We usually use Performance when analyzing page Performance, but it provides retrospective data, not real-time data. If you want to see Performance data in real time, you can use the Performance Monitor, which is a great tool to help you troubleshoot problems such as memory leaks

What the panel does

The list bar on the left can be clicked to select the information you want to view, and relevant data is marked at the end of the list, such as CPU usage. The waveform area on the right is a timeline that draws real-time views of various aspects of page load or runtime performance

Capabilities currently available

  • CPU usage

This command is used to observe the CPU usage

  • JS heap size

Memory space occupied by the current site

  • DOM nodes

  • JavaScript event listeners

You can see how many JavaScript event listeners are registered

  • Documents

That corresponds to Document in memory

  • Document Frames

HTMLFrameElement (Iframes, workers)

  • Layouts / sec

The frame rate per second at which a page is relaid

  • Style recalcs / sec

The frame rate per second that a page is drawn while recalculating styles

Use examples to see the practical value

IO /malyw/pen/Q… Cdpn. IO /malyw/fullp…

Javascript Profiler & Performance

The data captured by the JavaScript Profiler panel is part of the Performance panel data, and the official long-term goal is to remove it, so we’ll skip it here. Starting with Chrome 58, the Timeline panel is renamed to Performance.

Kayce Basques: The long-term goal is to remove the old JavaScript CPU Profiler, and get everyone working with the new workflow.

Top function operation area

5 commonly used buttons

  • Record starts recording directly and does not stop automatically

  • Reload starts recording performance metrics when the page is reloaded after a refresh, and automatically stops recording when the loading is complete

  • Clear Clear records

  • Load Profile Imports a Profile file. Save Profile Saves a Profile file

Chrome Trace Viewer for visualization

If you select Save Profile, you can see the saved Json file. If you are curious about its structure, look at its format

[{// name: the name of the event, for example, displayed in the panel
        "name":"thread_name".// Categories can be a list separated by commas
        "cat":"__metadata".// Event type PHASES, which are single characters, vary according to the type of output event, important parameter
        "ph":"M".// The trace timestamp of the event is timestamp, the granularity is microsecond
        "ts":0.// This parameter is optional for the thread timestamp of the event. The granularity is microseconds
        "tts":0.// The number of the event process is process ID
        "pid":1084.// Thread ID thread ID
        "tid":0.// Some of the necessary parameters for event types can be configured here
        "args": {
            "name":"xx"}},... ]Copy the code

Google has made a powerful visual presentation and analysis tool. Previously, there was a dedicated trace-Viewer project. Catapult is a collection of performance tools developed by Chromium engineers that can be used to collect, display, and analyze the performance of Chrome, Websites, and even Android. We open it in the browser chrome:// Tracing

The overall UI style is simple and simple, and it is easy to use

Here import a test example, you can try

[{"name": "Lark calendar"."ph": "b"."cat": "daily"."id": "my-day"."pid": "Main"."tid": "Lark calendar"."ts": 0},
  {"name": "Lark calendar"."ph": "e"."cat": "daily"."id": "my-day"."pid": "Main"."tid": "Lark calendar"."ts": 37800000000}, 

  {"name": "Write code"."cname": "good"."ph": "X"."pid": "Main"."tid": "Work"."ts": 0."dur": 3600000000}, 
  {"name": "Write code"."ph": "X"."pid": "Main"."tid": "Work"."ts": 12400000000."dur": 20000000000."args": {"mark":"X and dur for the beginning and end."}},

  {"name": "Eat"."ph": "B"."pid": "Main"."tid": "Leisure"."ts": 3600000000."args": {"mark":"B-e can also be used for beginning and ending."}},
  {"name": "Eat"."ph": "E"."pid": "Main"."tid": "Leisure"."ts": 12400000000},

  {"name": "Swimming"."ph": "X"."pid": "Main"."tid": "Leisure"."ts": 32400000000."dur": 5400000000},

  {"name": "process_name"."ph": "M"."pid": "Main"."args": {"name": "Timeline"}}]Copy the code

All event types (ph) and its related phase can see docs.google.com/document/d/ here…

A timeline history of multiple records

In the top bar, there is an unimpressive drop-down box that shows the most recent timeline session. Click on it to see the history. After testing, you can keep up to 5 recent history timelines. Each option can see its title, recording duration, time elapsed since recording, and overview miniatures

Three scalable capabilities

Screen keyframe snapshot

Enable Screenshots to take Screenshots for each frame

The Memory graph

Turning on the Memory option records some data in the form of a chart, similar to what the Performance Monitor records (similar to stock moving averages). You can see Performance metrics at any given moment by moving the mouse over them, and it works well with key screenshots

Web Vitals specifies performance indicators

Web Vitals is a Google initiative that aims to provide unified quality standards for page performance and quality, even if site maintainers do not have deep research in performance, they can have a direction to optimize. Key metrics have evolved over time, and currently focus on user experience loading, interactivity, and visual stability. The recommended target for the three metrics is the 75th quartier, and you can analyze them using Lighthouse

Largest Contentful Paint (LCP) : measures loading performance . To provide a good user experience, LCP should occur within 2.5 seconds when the page first starts loading. First Input Delay (FID) : measures interactivity . To provide a good user experience, pages should have a FID of less than 100 milliseconds . Cumulative Layout Shift (CLS) : Measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.

The above summary is that the largest chunk of content should be rendered, the first interaction time should be as early as possible, the meaningless jitter of the page should be small and the number of times should be less. Check the Web Vitals option, and the data shown in the following figure will appear in the panel

Force memory garbage collection

At the end of the collection garbage, there is an inconspicuous small garbage bin, which is used to allow the browser to manually intervene in a GC. To see the effect of this button, you can open the Performance Monitor to observe the effect. When clicking on the garbage collection, the memory space will be reduced to a certain extent. The reason for this is manual GC

Other Settings

Clicking on the pinion opens an area with four actionable items

Disable JavaScript samples

By default, when recording metrics, the browser will record the JavaScript detailed call stack. By clicking this switch, you can cancel the recording. Compare the following two images

Enable advanced paint instrumentation

Open the Paint event to view the advanced information, select the Paint event will add a Paint profile TAB below, select the Frames will add Layers TAB, enabling this function will slow down the analysis, the page will become card

Network / CPU

Network allows you to set the current Network conditions and simulate weak Network scenarios. CPU Settings limit the computing power of a computer’s CPU. For example, 4 x slowdown makes the CPU run 4 times slower than normal. (Because the different browsers on the device architecture can’t really emulate the CPU on the mobile device)

Analysis Results panel

This track in the Overview panel shows the recorded data in chronological order from left to right, from top down FPS, CPU, and NET. This chart gives you a rough idea of frame fluctuations, CPU activity (peak yellow), and network activity

The little red line means that the frame rate has dropped a lot, potentially harming the user experience

The different colored vertical lines represent the current state, which correspond to the tag in the Timings

Network View Expand Network to see that the timeline corresponds to the phases of Network request data and duration, and the different priorities are shown from the top down, with HTML files in blue, scripts in yellow, style sheets in purple, media files in green, and other resources in gray

Hover over to see relatively detailed data

Frames frame by frame view, hover the mouse over one of the green squares, each showing the time and frame rate for a particular frame

Interactions Interactions record user Interactions, such as mouse clicks and text input

Timings Time nodes that record key performance indicators, such as FCP and LCP

Main Main thread view, from left to right, displays the Main thread execution logs in chronological order, and from top to bottom, displays the cause of events. Complete information can be viewed here github.com/GoogleChrom…

The essence of Raster is coordinate transformation and geometric discretization. This view mainly records the time axis of the Raster task. The Raster task is to determine which pixels of each rendered pixel should be drawn on the screen

The Compositor recorded the execution timeline of the GraphicsLayer layer from the END of the HTML Paint phase to the GPU as a texture. Calculate the visible and soon-to-be-visible portions of the page (scrolling); CSS animation processing

The GPU can directly see whether GPU rendering acceleration is enabled and the usage of each time node

ServiceWorker Thread ServiceWorker thread has its own JS environment. This view is used to see the activity of the thread

Chrome_childIOThread is a core process of Child Processes(Renderer, GPU, Utility). It is used to observe the I/O calls of Child Processes