Author: Mei Yu

Performance optimization is a hot topic in the front-end field. This series of articles will be divided into three chapters: monitoring, load performance optimization, and runtime performance optimization

In order to optimize, you have to have metrics. Monitoring can objectively and systematically analyze performance bottlenecks, validate optimization results, and so on. So let’s start with how do we monitor it completely

Optimization methodology

Front-end performance is divided into load performance and run time performance

Load performance measurement

Load performance is the amount of time it takes for a user to enter a page and make the page usable. A good place to start is with a classic interview question: What happens when the user enters a URL, hits Enter, and sees the page?

  • DNS resolution: Resolves domain names into IP addresses
  • TCP Connection Establishment
  • Sending an HTTP request
  • The server parses the HTTP request and returns the result
  • The browser parses and returns the result

All we have to do is keep track of how long these processes take: modern browsers provide thatperformanceThe object provides us with a convenient way to extract these data. andcompatibilityIn this. Among themtimingObject details the timestamp of each node.Subtract the relevant time nodes to get the time taken for the corresponding process. As a developer, we are usually more concerned with the time it takes to read from the server, so fetchfetchStartAs a starting point. Here are some common time calculations:

const { fetchStart, domainLookupStart, domainLookupEnd, domInteractive, domContentLoadedEventStart } = performance.timing

// DNS lookup time
domainLookupEnd - domainLookupStart

// Blank screen time
domInteractive - fetchStart

// First screen time
domContentLoadedEventStart - fetchStart
Copy the code

The above calculation time is more used for SSR rendering, and now there is still a considerable part of the front end is SPA structure, rendered by JS in the client. In order to better meet the combination of monitoring indicators and user experience. Google puts forward indicators such as FP/FCP/FMP/TTI to help us collect relevant data. We often use the following two indicators

FCP(First Contentful Paint) The point at which any text, image, non-blank canvas or SVG is First drawn. It’s when the user first sees meaningful content. This time can usually be regarded as the blank screen duration. Access to the API

window.performance.getEntriesByType('paint')
Copy the code

TTI(Time To Intercative) identifies points in Time when an application has performed visual rendering and can reliably respond To user input. We usually use this value as the first screen time of a page. The browser does not provide a direct API to get it. But Google offers github.com/GoogleChrom… To obtain.

Run time performance metrics

Most businesses do not require runtime monitoring. But some focus on business scenarios, such as text editors, online classes, and sketchboards. The damage to user experience is huge, but also more unacceptable to users. For this kind of business, we develop test scenarios where chrome’s Perfermance tool can be used to test, detect and locate performance delays. But we still need the monitoring of the user test to understand the actual operation of the business line. RequestAnimationFrame is usually used to implement animations. But here we can also use it as a frame rate monitor. The simple idea is as follows:

const everyFrameCostTime = []
let timestamp = Date.now()
function detect() {
  const now = Date.now()
  const cost = now - timestamp
  timestamp = now
	everyFrameCostTime.push(cost)
  requestAnimationFrame(detect)
}
Copy the code

When the cost is higher than a specific threshold for several times in a row, it can be regarded as a page delay. It depends on the business scenario.

There are limitations to this as well, because of survivor bias, the monitoring code itself does not work when the page is stuck.

Data sent

Data transmission mode

A common practice is to send an IMG request to the server, then concatenate the data into URL parameters and send it along. Modern browsers provide navigator.sendbeacon (URL, data) methods to send data. The unload scenario does not even block the loading of the next page. In order to ensure the robustness of the base library and does not affect its own page performance. We need to do a good job of convergence and throttling.

Data delivery policy and storage

When the user base is too large or statistics does not need so much data, the data can be sent randomly to determine whether to send the data. Or the buried data can be encrypted locally and sent to the developer by the user when needed to troubleshoot problems and reduce the pressure on the data server

Refer to the link

www.w3.org/TR/paint-ti…

www.w3.org/TR/navigati…

Github.com/GoogleChrom…

Developer.mozilla.org/zh-CN/docs/…