preface

The Performance API has been available in modern browsers since the IE9 era (around 2011), so the compatibility is ok, so check out what the API does.

1. window.performance

1.1 Overall Structure

Let’s look at the main structure of Performance:

Where the overall performance sequence of the page is in timing property, main structure:

If you want to know what each field represents, you can take a look at this graph:

Use the console table (window. Performance. Timing) up the format (by field corresponds to the order of meaning)

1.2 Parameter Meaning

• navigationStart
  • Is the Unix millisecond timestamp at the end of the previous document immediately after uninstallation in the same browsing environment.If there is no previous document, its value equalsfetchStart.
  • It can be directly interpreted asWhere the page starts loading.
• unloadEventStart
  • Is the Unix millisecond timestamp when the Unload (En-us) event was fired.This value returns 0 if there is no previous document, or if the previous document or one of the pages to be redirected is a different source.
  • Can be understood asDifferent fields, 0, that is, load a new page, is 0, can be ignored
• unloadEventEnd
  • Is the Unix millisecond timestamp when the Unload (en-us) event handler ends. If there is no previous document, or one of the different sources of the previous document or the page to jump to, this value returns 0.
  • Different fields, 0, that is, load a new page, is 0, can be ignored
• redirectStart
  • The Unix millisecond timestamp for the time the first HTTP redirect began. If the redirection did not occur, or if one of the redirects is non-cognate, the value returns 0.
  • Different fields, 0, that is, load a new page, is 0, can be ignored
• redirectEnd
  • The Unix millisecond timestamp for when the last HTTP redirect was completed and the last byte of the HTTP response was received. If no redirection has occurred, or if one of the redirects to a different source, the value returns 0.
  • Different fields, 0, that is, load a new page, is 0, can be ignored
• fetchStart
  • A Unix millisecond timestamp for when the browser is ready to grab the document using an HTTP request. This is before checking the application’s cache.
  • In the absence of redirects and page unloads, andnavigationStartThe same time stamp
• domainLookupStart
  • Is the Unix millisecond timestamp when domain name resolution began. If a persistent connection is in use, or the information is already stored by a local resource or cache, this value is equivalent tofetchStart.
  • If DNS is cached, the value is 0 and can be ignored
• domainLookupEnd
  • Is the Unix millisecond timestamp at the end of domain name resolution. If a persistent connection is in use, or the information is already stored by a local resource or cache, this value is equivalent tofetchStart.
  • If DNS is cached, the value is 0 and can be ignored
• connectStart
  • Indicates that TCP starts to establish the connection time node. If the browser does not make a TCP connection (such as using a persistent webscoket connection), both are equal to domainLookupEnd;
• connectEnd
  • Represents the time node when the TCP connection is complete. If the browser does not make a TCP connection (such as using a persistent webscoket connection), both are equal to domainLookupEnd;
• secureConnectionStart
  • If the page uses HTTPS, its 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 is returned
• requestStart
  • The Unix millisecond timestamp for the time the browser sends a request to fetch the actual document from the server or cache. If an error occurs at the transport layer after the request is started and the connection is reopened, this property will be set to the appropriate value for the new request.
• responseStart
  • Received by the browser from a server, cache, or local resourceThe first byte of the responseThe Unix millisecond timestamp of.
• responseEnd
  • Receives from a server, cache, or local resource for the browserThe last byte of the responseOr the Unix millisecond timestamp when the connection was closed.
• domLoading
  • To start working for the parser, i.eDocument.readyStateChange to ‘loading‘andreadystatechangeThe Unix millisecond timestamp at which the event was raised.
• domInteractive
  • End work for the parser in the main document, i.eDocument.readyStateChange to ‘interactive‘and is equivalent toreadystatechangeThe Unix millisecond timestamp at which the event was raised.
• domContentLoadedEventStart
  • On behalf ofDOMContentLoadedThe time point at which the event is triggered
• domContentLoadedEventEnd
  • On behalf ofDOMContentLoadedIndicates the end time of the event
• domComplete
  • The parser for the main document is finished,Document.readyStateA ‘complete‘
  • The equivalent ofreadystatechangeThe Unix millisecond timestamp when the event was raised.
• loadEventStart
  • forloadThe Unix timestamp at which the event was triggered by the present document. If the event is not raised, it returns 0.
• loadEventEnd
  • forloadThe Unix millisecond timestamp when the event handler is terminated and the loading event has completed. If the event was not triggered or did not complete, the value will return 0.

1.3 Field Analysis

To further confirm the timing of each node, we can use NetWork and Performance on the Chrome Console:

Practice Step 1

Timing = timing; timing = timing

Note the time shown in the second figure, and get

1616012122257 (loadEventEnd) – 1616012118346 (navigationStart) = 3911ms is equal to the time it takes for the web page to start loading until the Load event completes

1616012120068(domContentLoadedEventEnd) – 1616012118346 (navigationStart) = 1722ms is equal to the time it takes for the web page to start loading until DomContentLoaded is complete

Practice Step 2

What about the other fields? Let’s go to NetWork to find a resource

The HTML resource was initially loaded => Queued at 0 => Queued => Stalled => SSL established => Request Sent => Waiting(TTFB – Time to First Byte) => Content Download

First, explain what the stages mean:

1. Queued at 0 和 QueueingIs the amount of time a resource load queue takes to queue. This is related to the number of transactions currently being processed by the browser, but is generally small.
2. StalledEven if you start working on the resource, you’ll have to put it on hold if something else suddenly comes up.
3. SSL (Secure Socket Layer Protocol Layer)This is available in the case of HTTPS, the Web protocol that establishes an authenticated and encrypted session between the Web server and Web client.
4. Request SentThat’s when you start sending requests
5. Waiting(TTFB)The first byte wait time, which can be understood asRequest Sent 到 First byte receivedTime required.
6. Content DownloadThe content download time, the size of the content and the current Internet speed can affect this time.

Here’s an easy chestnut to remember:

Suppose you go to a bank

1. 10Hit the bank, soQueued at 10:00And thenThe line lasted an hour
2. 11You are put on hold for 15 minutes when the teller suddenly gets a call from the bank president asking him to attend to some other business.Stalled15 minutes)
3. 11:15Finally, it’s you, and the teller finds you are a little higher and asks for your identity authentication. At this time, you are required to enter your password and brush your face. Finally, it takes 15 minutes to complete all the procedures (SSL)
4. 11:30You’re finally ready to start your business, and you start asking questions:How much can I withdraw? (Request Sent)
5. The teller is new, so she is slow to operate, take your card, input the card number, query, calculate, and passed10Minutes to tell you the balance on your card (Waiting TTFB)
6. Because you are so rich, it takes time for the teller to take out and check the money and give you stacks of money20Minutes (Content Download)

TTFB is an important indicator of server response speed. The shorter the TTFB time, the faster the server response.

The main times that may affect the duration of TTFB are:

1. Between the browser and the serverThe network is not goodIf you are in China and the server is in Africa, then you”Issues raised“It takes N network nodes to get to Africa, which must be a long time. (The network is not good)
2. If the server receives a request from the browser, it reads the database first and thenSynchronously processes large amounts of dataAnd then send the data to the client, which will take a long time. (Time consuming logic)

Typically, server rendered pages have long TTFB resources

Practice Step 3

Can the above times be represented through the Performance API? It’s true to tell you the truth.

I’ve taken a look at the performance API’s methods and explained them briefly. Let’s look at the overall structure:

Let’s look at the exact meaning of the method:

• performance.getEntries()
  • This returns static resources (including webworkers) that are emitted when the browser loads a web pagePerformance Record List

Each item has a structure of at least:

{name: 'the name of the resource ', entryType:' the type of the resource, such as resource for static resource, paint for render event ', startTime: 'resource request start time (offset from page load start)', duration:' resource request time '(resource load start => end)}Copy the code

Give me two chestnuts:

1. Static resource types:

2. Render type:

You can see that there are many other fields besides the above, but this object extends several other object properties, Including PerformanceMark, PerformanceMeasure, PerformanceFrameTiming, PerformanceNavigationTiming and PerformanceResourceTiming.

Let’s look at two more chestnuts to see which point in time they correspond to:

• This one is A redirect resource (set to A), similar to page loading, so there is A load event

• This is the static resource type (set to B)

Redirection resource type (A) :

{
    // TCP connection starts
    connectEnd: 29.009999999288993.// TCP connection completed
    connectStart: 10.269999999763968.// Unencode the size
    decodedBodySize: 320036.// DOM complete (including parsing)
    domComplete: 1022.3799999994299.// The end time of the DomContentLoaded event corresponding to the page
    domContentLoadedEventEnd: 705.3900000000795.// DomContentLoaded start time
    domContentLoadedEventStart: 692.4199999994016.// dom interactive time
    domInteractive: 519.4899999996778.// DNS parsing is complete
    domainLookupEnd: 10.269999999763968.// DNS parsing starts
    domainLookupStart: 5.699999999706051./ / scheduling
    duration: 1030.9849999994185.// The size after encoding
    encodedBodySize: 78155.// Resource type navigation redirect
    entryType: "navigation".// Start the requested event
    fetchStart: 0.534999999217689.// Specify the type of trigger, e.g. navigation Link script, etc
    initiatorType: "navigation".// The load event completion time of the corresponding page
    loadEventEnd: 1030.9849999994185.// Start time of the load event on the corresponding page
    loadEventStart: 1022.4199999993289.// Request the resource name
    name: "https://www.baidu.com/",
    nextHopProtocol: "HTTP / 1.1".// Redirection times
    redirectCount: 0.// The redirect is complete
    redirectEnd: 0.// The redirect starts
    redirectStart: 0.// Request started
    requestStart: 29.144999999516585.// The data response is complete, i.e. the data download is complete
    responseEnd: 253.8349999995262.// The data response has started, i.e. the data has just started to download
    responseStart: 221.83999999924708./ / SSL time
    secureConnectionStart: 16.709999999875436,
    serverTiming: [],
    // When the resource starts to trigger
    startTime: 0.// Transfer size
    transferSize: 78846.// The loading type is only available under navigation
    type: "reload".// When the last page was uninstalled
    unloadEventEnd: 251.25499999921885.// The uninstallation start time of the previous page
    unloadEventStart: 250.11999999969703,
    workerStart: 0,}Copy the code

The main difference is that there is no load DOMContentLoaded.

Practice Step 4

Now look at the networks of A and B

A:

B:

You will find

A:

ResponseEnd (253.8349999995262) - startTime (0) = total time in the lower right corner (253.8, approximately equal to the253.29, a little error) loadEventEnd (1030.9849999994185) - startTime (0) = duration (1030.9849999994185) responseEnd (253.8349999995262) - responseStart (221.83999999924708) = Wating(TTFB)s time31.995000000279106, TTFB display value:31.93) domainLookupEnd (10.269999999763968) - domainLookupStart (5.699999999706051DNS Lookup = DNS Lookup4.570000000057917, display value:4.57) connectEnd (29.009999999288993) - connectStart (10.269999999763968) = Initial connection18.739999999525025, display value:18.75) connectEnd (29.009999999288993) - secureConnectionStart (16.709999999875436) = SSL (actual value:12.299999999413558, display value:12.30FetchStart = fetchStart0.534999999217689, which at this time could not be determined whether it preceded Queueing or laterCopy the code

B:

ResponseEnd (325.6149999997433) - startTime (275.24999999968713) = total time in the lower right corner (50.36, approximately equal to the50.38Duration () = duration (50.36500000005617)Copy the code

Some data of B are 0, which may be due to cache or other reasons, so we do not calculate them one by one.

Practice Step 5

Let’s take A look at the corresponding picture of A in the Performance panel

I did the math carefully

0 corresponds to the time before TTFB (0-29ms), which takes 29 (18.75 + 4.57 + 2.88 + 2.26 = 28.46)

1 corresponds to TTFB (29-221.93), which takes 192.93 time

2 corresponds to Content Download (221.93-253.83), which takes 31.9 hours

Through the above examples, we can conclude (the following generation refers to their time) :

$DNS Lookup = domainLookupEnd – domainLookupStart$

$Initial connection = connectEnd – connectStart$

$SSL = connectEnd – secureConnectionStart$

$TTFB = responseEnd – responseStart$

DNS Lookup => Initial Connection (SSL included in connection) => TTFB

Practice Step 5

Performance-getentries () is an example of how a single resource works. Performance-getentries () is an example of how a single resource works.

To verify reliability, I opened three different web pages and turned off the network cache

1. Web page 1: www.json.cn/

Performance. Timing value:

navigationStart	                1616233754952
unloadEventStart	        1616233755153
unloadEventEnd	                1616233755156
redirectStart	                0
redirectEnd	                0
fetchStart	                1616233754956
domainLookupStart	        1616233754956
domainLookupEnd	                1616233754956
connectStart	                1616233754956
connectEnd	                1616233754956
secureConnectionStart	        0
requestStart	                1616233754974
responseStart	                1616233755144
responseEnd	                1616233755147
domLoading	                1616233755159
domInteractive	                1616233755723
domContentLoadedEventStart	1616233755723
domContentLoadedEventEnd	1616233755729
domComplete	                1616233756837
loadEventStart	                1616233756837
loadEventEnd	                1616233756841
Copy the code

The Performance panel

The time when FP/FCP/LCP/L occurs is related to the time in performance. Timing

This time,

FP FCP LCP time consistent: 358.4ms

DCL: 787.3 ms

L: 1898.6 ms

NavigationStart (1616233754952) as the initial time:

FP FCP LCP: 1616233754952 + 358.4 = 1616233755310.4 (after domLoading 1616233755159)

DCL: 1616233754952 + 787.3 = 1616233755739.3, in the vicinity of domContentLoadedEventEnd 1616233755729, can be said to be approximately equal, but not much difference

L: 1616233754952 + 1898.6 = 1616233756850.6, in loadEventEnd 1616233756841 vicinity, also approx

2. Page 2: Devhints.io /

navigationStart	                1616234946001
unloadEventStart	        1616234946335
unloadEventEnd	                1616234946335
redirectStart	                0
redirectEnd	                0
fetchStart	                1616234946003
domainLookupStart	        1616234946003
domainLookupEnd	                1616234946003
connectStart	                1616234946003
connectEnd	                1616234946003
secureConnectionStart	        0
requestStart	                1616234946011
responseStart	                1616234946254
responseEnd	                1616234946273
domLoading	                1616234946344
domInteractive	                1616234947467
domContentLoadedEventStart	1616234947467
domContentLoadedEventEnd	1616234947469
domComplete	                1616234949225
loadEventStart	                1616234949225
loadEventEnd	                1616234949227
Copy the code

FP FCP LCP ：504.7 ms

DCL: 1475.1 ms

L: 3231.3 ms

FP FCP LCP: 1616234946001 + 504.7 = 1616234946505.7 (after domLoading 1616234946344)

DCL: 1616234946001 + 1475.1 = 1616234947476.1 domContentLoadedEventEnd 1616234947469

L: 1616234946001 + 3231.3 = 1616234949232.3, loadEventEnd 1616234949227 is also approx

3. Page 3:

navigationStart	                1616236044085
unloadEventStart	        1616236044641
unloadEventEnd	                1616236044641
redirectStart	                0
redirectEnd	                0
fetchStart	                1616236044088
domainLookupStart	        1616236044088
domainLookupEnd	                1616236044088
connectStart	                1616236044088
connectEnd	                1616236044088
secureConnectionStart	        0
requestStart	                1616236044093
responseStart	                1616236044632
responseEnd	                1616236044633
domLoading	                1616236044642
domInteractive	                1616236045952
domContentLoadedEventStart	1616236045952
domContentLoadedEventEnd	1616236045953
domComplete	                1616236046263
loadEventStart	                1616236046263
loadEventEnd	                1616236046272
Copy the code

FP FCP: 2195.5 ms

LCP: 2191.3 ms

DCL: 1872.6 ms

L: 2191.3 ms

FP FCP: 1616236044085 + 2195.5 = 1616236046280.5,

LCP: 1616236044085 + 2191.3 = 1616236046276.3, also near L

DCL: 1616236044085 + 1872.6 = 1616236045957.6, in the vicinity of domContentLoadedEventEnd 1616236045953, can be said to be approximately equal, but not much difference

L: 1616236044085 + 2191.3 = 1616236046276.3, in loadEventEnd 1616236046272 vicinity, also approx

So in summary of the above examples, the page loading events in their time formula:

$L = loadEventEnd – navigationStart$

$DCL = domContentLoadedEventEnd – navigationStart$

The above two formulas are definite

conclusion

1. For a single resource, its load time:

Chronological order of occurrence:

DNS Lookup => Initial Connection (SSL included in connection) => TTFB

Time:

$DNS Lookup = domainLookupEnd – domainLookupStart$

$Initial connection = connectEnd – connectStart$

$SSL = connectEnd – secureConnectionStart$

$TTFB = responseEnd – responseStart$

2. For the entire page load

Time:

$L = loadEventEnd – navigationStart$

$DCL = domContentLoadedEventEnd – navigationStart$

FP currently appears to have occurred after domLoading, but I think it may have occurred before it

FCP/LCP definitely happened after domLoading, but it has little to do with the sequence of DCL and L, and may come before or after it (the specific relationship will be explored later).

I haven’t finished it. I’ll write it later