Start with a classic interview question

(Part of this article has been edited from an online article)

What happens from the time the user enters the URL until the page loads?

  1. DNS resolution (resolving domain names, resolving urls to corresponding IP addresses)
  2. TCP connection (establish TCP network connection with this IP, three-way handshake)
  3. Sending an HTTP request
  4. The server returns data in response to HTTP
  5. The browser takes the response data, parses the response, and displays the parsed results to the user

What front-end performance includes

This is a performance breakdown I pulled from an article that focuses on performance monitoring

Front-end performance monitoring – Key indicators

  • The first screen time
  • Bad time
  • Total page download time

Browser performance first content overview

Performance we through the window. The preformance. Timing this property to get the related performance parameters

Window. The preformance. Timing (record the timestamp) pages each state

So what do these parameters mean, and what are their trigger mechanisms

Let me show you a classic picture

Let’s translate that

Prompt for unload - User jump behavior (Enter URL in address bar and press Enter, NavigationStart, startTime // Previous page of current browser window closes start timestamp unloadStart // Previous page unload triggers start timestamp [unload] - Previous page unload Time unloadEnd // Previous page Unload Triggers End timestamp redirectStart // Returns the timestamp at the start of the first HTTP jump. If there is no jump, or the jump is not within the same domain, Redirect - redirectEnd returns the timestamp at the end of the last HTTP redirect. If there is no redirect, or if the redirect is not within the same domain, FetchStart // Returns the timestamp when the browser is ready to read the document using an HTTP request. DomainLookupStart // Returns the timestamp at the start of the domain name query. If persistent connections are used, or the information is obtained from the local cache, the return value is the same as the value of the fetchStart attribute [DNS] - domain name query domainLookupEnd // Returns the timestamp at the end of the domain name query. If a persistent connection is used or the information is fetched from the local cache, the return value is the same as the value of the fetchStart attribute. ConnectStart // Returns the timestamp when the TCP connection was established and sent to the server. If persistent connection is used, the return value is the same as the value of the fetchStart attribute [TCP] secureConnectionStart // the value is the moment before the secure connection handshake. If the property is not available, undefined is returned. If the property is available but HTTPS is not used, 0 connectEnd // returns the timestamp when the connection between the browser and the server was established. If a persistent connection is established, the return value is the same as the value of the fetchStart attribute. Connection establishment refers to the time stamp when all handshake and authentication processes are completed back to the handshake between the browser and the server to start the secure connection. If the current page does not require a secure connection, RequestStart returns the timestamp when the browser made an HTTP Request to the server (or when it started reading the local cache) Returns the timestamp when the browser receives (or reads) the first byte from the server. // Return the timestamp when the DOM structure of the current page begins to parse (i.e., when the document. readyState property becomes "loading" and the corresponding readyStatechange event is triggered). DomInteractive // Returns the timestamp when the DOM structure of the current web page ends parsing and the embedded resource starts loading (i.e., when the document. readyState property changes to "interactive" and the corresponding readyStatechange event is triggered) DomContentLoadedEventStart / / returns the current web page DOMContentLoaded event occurs (i.e., after parsing the DOM structure, all the scripts running) the timestamp domContentLoadedEventEnd / / DomComplete // Returns when the DOM structure of the current page was generated (i.e. Document.readyState property changed to "complete", As well as the corresponding readyStatechange event when it occurs) timestamp loadEventStart // Returns the timestamp when the callback function of the current page load event starts. If the event has not yet occurred, return 0 [onLoad] -window. onLoad trigger loadEventEnd // Return the timestamp at the end of the callback function run for the current page load event. If the event has not already occurred, return 0. Keep judging through the while loop until you loadEventEnd>0 and you're completely loaded! There are no more data requests on the network, and the DOM is rendered with replication codeCopy the code

Pay attention to

Due to the window. The preformance. Timing is a at different stages, are constantly revised a parameter object, so the proposal in the window. The onload performance data reading and reporting

Key data acquisition

  • First screen time: tricky to calculate, more on later
  • ResponseEnd – navigationStart
  • Total page download time: loadEventEnd – navigationStart

Other data:

  • DNS resolution time: domainLookupEnd – domainLookupStart
  • TCP connection time: connectEnd – connectStart
  • First packet request time: responseEnd – responseStart
  • Dom interpretation time: domcomplete-dominteractive
  • DomContentLoadedEventEnd – navigationStart
  • .

First screen time calculation

At present, the first screen time method is not unified in the industry, and the following calculation methods are commonly used:

  • Use the loading time of the last image in the first screen as the first screen time (suitable for the first screen elements to be rendered by the server)

Method: bind onload events to all img images on the page to record the loading time of images. In window.onload, calculate the offsetTop of each img; Collect the image data corresponding to the height of the first screen and calculate the maximum onload time

  • Image similarity comparison method to determine the first screen time by comparing the changing trend of pixels in continuous screenshot images (suitable for scenes with asynchronous request for data rendering)

Method: Capture the screen every 100ms through html2Canvas plug-in; Then obtain the center point of each screen nine cells, obtain the sum of pixels of the red channel to get a value, through continuous screen capture and comparison of the sum of the value, monitor whether the first screen is loaded. (The method of similarity comparison of screenshot images is the most scientific and intuitive, but it consumes the running resources of local devices. And because of complex operations, the performance of page logic script execution will be affected.)

  • First screen module tag method (most pages are rendered asynchronously)

Method: Use inline JavaScript code to record the current timestamp in the HTML document corresponding to the end of the tag in the first screen

  • Custom module content calculation (too complex to customize each page)

Methods: To simplify the calculation of the first screen time by customizing the module content

  • Use onLoad or domReady trigger time to indicate the first screen time

Our first screen calculation

First, we need to introduce window. The performance. However, () method, for later use

window.performance.getEntries()

The page load resource and network request information are retrieved after the call

We get an array, which contains all the static resources and network request information of the page. We use initiatorType to get the attributes of each element

“Xmlhttprequest” stands for an interface request

First screen computing mode

  • The default value is domContentLoadedEventEnd – navigationStart
  • In the case of a VUE project, the Mounted trigger time is used as the demarcation point.
  • For react projects, use the componentDidMount trigger time as the cut-off point.
  • Through the window. The performance. However, all content (), filter mounted, componentDidMount before all request content, if there is a xmlhttprequest, finally returned to the response time is used as the first screen time
  • For SSR projects, use the default calculation method (domContentLoadedEventEnd – navigationStart)

You may be wondering, we do not include rendering and image loading times in the calculation of the first screen time, right?

Indeed, we do this on two premises:

  • Normally we expect browser rendering times to be fast
  • Page loaded images must be captured (this is controlled by each line of business)

So this first screen calculation method is more like “first screen data start rendering time” (because all the data needed for the first screen rendering has been obtained at this point).

There will be a certain degree of error when the picture is too much or too large

Why are we doing this?

  • To implement automatic statistics, you do not want the logic of performance statistics to be forced into the business code
  • As close as possible to the actual first screen load time
  • Complete the data collection without taking up too much of the browser’s first-screen loading performance

Currently, the calculation methods of the first screen time vary from company to company, but the calculation method that is closest to the first screen time must be based on the actual situation of each company.

In fact, the accuracy of data and the performance cost of collecting data are a kind of game, and the company should choose the most appropriate way.

Prompt for Unload - Front-end learning training, video tutorials, learning routes, please add Weisin Haomei0452Copy the code