Performance timings are part of the recommendation Navigation Timings. Their goal is to detail the main technical steps of a page loading time, from the request taking-over to the end of the loading of all the resources (except those loaded in an asynchronous way after the onload event).
Here is an overview of those events in time:
We count not less than 20 events that we can gather in 3 big stages:
- what occurs before the sending of the HTTP request to the server
- the sending of the request/the reception of the answer
- the processing of the answer and the building of the web page
For each event, a timestamp is available (number of milliseconds from the 01/01/1970). If you want to get the time elapsed between 2 events, all you have to do is calculating the difference between their values. Now, let’s discover these 3 big stages in details.
Preparation of the request
To begin with, the browser takes over the the user’s request to access a web page (navigationStart). Then, come the time related to the possible redirection required to accede to the page, provided that these redirections take place on the same domain (redirectStart et redirectEnd).
Then comes the fetchStart, that indicates the browser is preparing to check if it has the wanted resource in its cache.
In the absence of redirection on the same domain and if the resource was absent of the cache, you’ll find the DNS lookup time (domainLookupStart and domainLookupEnd). The time necessary to establish the connection to the server will follow (connectStart and connectEnd), potentially including an extra event in the case of a secured connection (secureConnectionStart).
Request execution/Response receipt
The second stage of performance timings is for sure the easiest one to approach. The connection to the remote server is established, it remains to send the HTTP request (requestStart), and receive its reply (responseStart et responseEnd). The difference between responseStart and requestStart allows to get the Time To First Byte. You’ll have a clear idea of the processing time of the server by taking off the latency to this value.
The last step of the loading remains, and is at the time the hardest one and the one gathering 90% of the user’s perceived waiting according to the golden rule given by Steve Souders: the frontend processings. The browser receives an answer in a text form, that are to interpret and to complete new contents so that the final page can display itself.
The first step consists in changing the HTML code into an arborescence (DOM) that could be interpreted and manipulated by the browser. We get the duration of this construction by calculating the difference between domLoading et domInteractive.
Then come the event domContentLoaded, that allows to determine from when the DOM and CSSOM trees are both ready. At that point, the synchronous scripts and those declared in defer were executed.
Once all the resources of the page are loaded and interpreted, the event domComplete is triggered. The last step occurs: the browser launches its onload event (loadEventStart and loadEventEnd), that can cause the triggering of new asynchronous behaviours.
Note that the user can stop the loading of the page at anytime. You will then get the events unloadEventStart and unloadEventEnd.
Performance timings provide solid bases to detect the bottlenecks of your page loading. But they are far from allowing you to understand the loading from the user point of view, since it doesn’t give any information about interactivity or page rendering.
The start render, the speed index or else the visually complete are equally precious metrics that will help you in your optimization procedures. They will be the subject of a next article very soon.