We know that to do page performance optimization must have data support, otherwise you can’t measure page performance, let alone optimization. How is page performance measured? The world’s martial arts can only be broken quickly. Fast is on behalf of our page performance is good, and time is fast fast data indicators. For timing, the W3C working group has proposed a set of specifications for various points in time during the browser loading process, some of which have been implemented by browser vendors. Let’s take a look at what the metrics are and how to see page performance.

PerformanceNavigationTiming

PerformanceEntry interface

All Performance interface families inherit the PerformanceEntry interface.

So let’s take a look at what attributes this interface defines

name

Current Page address

entryType

In PerformanceNavigationTiming interface, entryType is’ navigation ‘

startTime

0

duration

LoadEventEnd Time and startTime interval.

This value represents the time from the start of the web page to the end of DOM parsing and all resources in the document downloading.

PerformanceNavigationTiming interface

unloadEventStart

Onunload Time point before the callback is executed

unloadEventEnd

Onunload Time point at which the callback ends

domInteractive

The point at which document. readyState becomes interactive

At this point, the DOM has been parsed, but other resources may be loading, such as images, CSS, and so on.

domContentLoadedEventStart

The point at which DOM parsing completes and the ‘DOMContentLoaded’ callback begins

domContentLoadedEventEnd

The point at which DOM parsing is complete and the ‘DOMContentLoaded’ callback is completed

domComplete

Document. The readystate to ‘complete’

When the DOM is parsed, the resource files in the document are all loaded.

loadEventStart

Unload Point at which the event callback starts execution

At this point document. readyState is already ‘complete’

loadEventEnd

Unload Point at which the event callback completes

type

  • navigate

    Normal navigation types, such as browser url type, A TAB jump, form submission, and so on.

    Navigate is either of the following types.

  • reload

    Refresh the page

  • back_forward

    Go back to the web page

  • prerender

    Pre-rendered web page

Does the SPA page operation history.pushState change the type? Of course not. Because navigation refers to the process by which the browser loads an address. History. Back? Again, just doing the history stack will not trigger navigation unless the page is loaded

meaning

We can see that after reading the above interface document PerformanceNavigationTiming focus in this period of time:

Start: The browser starts loading the document (or rather from the unload event of the previous page)

End: DOM parsing is complete and all resources are loaded.

So what does this interface give us for performance analysis? That’s DOM parsing time.

blocking

For advice on

The main thread of the rendering process has multiple functions. DOM and CSSOM parsing, style calculations, page layout calculations, and JavaScript code all run on this thread, which means that these tasks are mutually exclusive.

When parsing an HTML document, if you encounter a script tag (synchronous), whether inline or inline, stop parsing the HTML and wait for the JavaScript code to load and execute (click here to see why).

Therefore:

  • If the external JavaScript file is too large, the loading speed is slow, sorry, the parsing work is delayed;
  • If the JavaScript code takes time to execute, sorry, parsing is delayed.

The direct consequence of the analysis is that we see the time of the web page is also delayed, the intuitive consequence is the white screen time becomes longer.

So, whether you write the

Calculate time

Duration = loadeventenden-start = loadeventenden-start = loadeventenden-start

Isn’t.

Loading style files and media resources does not block the main thread of the renderer process. So the time should be domInteractive – start?

Sorry, that’s not true either.

The loading of style files does not affect document parsing. However, if both the CSS and JavaScript files are exported to a page, the browser will wait for all the exported CSS to be downloaded and converted to CSSOM before continuing to execute the script.

Why is that? Because JavaScript has the ability to manipulate CSSOM, this creates dependencies.

So, while CSS network load requests do not block document parsing, because of the above, you must wait until all the external CSS resources on the page have been downloaded and converted to CSSOM before parsing the document continues.

So time is domContentLoadedevent-start?

Sorry, not yet…

Navigation starts with the unload callback of the previous page and continues until the current page completes DOM parsing and resource loading. This process also includes requesting and receiving data and resources from the server. We need to subtract out this time period to figure out where we started. What about the time period? Analyze ~ in the next article