What is the Navigation Timing API?
- The navigation timing API is an interface that provides web applications with timing-related information from browsers.
- It simply breaks down the events required to retrieve and display webpages in a browser and provides a timestamp for each event.
What events does the navigation timing api cover?
The events it covers are all the main events that occur during a typical pageload. This means that the navigation timing api is a great way to breakdown these events to better understand how a webpages loads.
The main events are:
- NavigationStart
- Redirect
- Appcache
- DNS
- TCP
- Request
- Response
- Processing
- onLoad
Within each of the above events several time stamps are available which will require us to look at each event separately and in order.
Navigation Start
- Navigation start is actually the moment just before a new page is requested.
- It is initiated by a user clicking a link or hitting enter after writing an url in a browser navigation bar.
Timestamp:
Navigation start is a user initiated event beginning the process of going to a web page or resource.
Once this event occurs, a new page load has begun.
Redirect
The redirect event (events) measures redirect time which allows us to measure in total the amount of time redirects took for a page load.
- Redirect time measures the amount of time it takes a request to follow a redirect.
- May also refer to "total redirect time" which is the time taken to follow all redirects.
Timestamps:
- redirectStart
- redirectEnd
There are two main ways that redirect time can be measured within the navigation timing api.
- Using the redirectStart and redirectEnd timestamps may measure a specific redirect
- Using fetchStart - navigationStart to measure overall redirect time.
Appcache
Appcache stands for application cache. In a browser, it is the browser cache.
The appcache event is basically covering the scenario of when a resource is loaded from the browser cache rather than being retrieved from the network (a common scenario).
If the cache was not considered, it could appear that resources loaded instantaneously from a network, which wouldn't be very accurate.
Timestamp:
- fetchStart is a recorded moment in time where the browser first attempts to retrieve a document.
- fetchStart may be used as the beginning timestamp upon which other performance metrics are measured.
DNS
- DNS time is the amount of time it takes a domain lookup to occur while a browser retrieves a resource.
Timestamps:
- domainLookupStart
- domainLookupEnd
DNS lookups can cause significant delays in rendering a webpage. DNS lookup time can tell us how much of a delay is occuring.
TCP
- TCP connection time measures the time taken to establish the transport connection as well as other time intervals such as SSL handshakes.
- More simply put, it is the time it takes a browser to establish a connection with a server.
Timestamps:
TCP connection time measures only the establishment of a connection, not the use of that connection.
The entire TCP connection time can be measured using the connectStart event and the connectEnd event.
It is notable that TCP connection time includes the SSL handshake (the establishing of a secure connection).
The SSL time can be measured using the secureConnectionStart event and the connectEnd event.
Request
The request event represents the requesting of a resource / resources over an established connection. As such, there is only one timestamp.
Timestamp:
requestStart is the moment the browser requests the current document from the server, relevant application caches, or from local resources.
Response
The response measures when a response is given and how long that response takes.
Timestamps:
- responseStart is the time immediately after the browser receives the first byte of the response from the server, or from relevant application caches or from local resources.
- responseEnd is the time immediately after the user agent receives the last byte of the current document or immediately before the transport connection is closed, whichever comes first.
Processing
The processing stage is where the browser has most of what it needs to display the page, but is processing the data by parsing and requesting additional subresources requested by the documents. This is where the critical rendering path can be measured.
Timestamps:
- domLoading
- domInteractive
- domContentLoaded (domContentLoadedEventStart / domContentLoadedEventEnd)
- domComplete
Let's look at each of those time stamps a little closer.
domLoading
- domLoading is the time immediately before the user agent sets the current document readiness to 'loading'.
- It means the browser has the document and is about to do something with it.
domInteractive
- domInteractive is the time immediately before the user agent sets the current document readiness to 'interactive'.
- The browser has finished parsing all of the HTML and DOM construction is complete.
- It is the beginning of the browser dealing with page subresources.
domContentloaded
- domContentLoaded is the point when both the DOM is ready and there are no stylesheets that are blocking JavaScript execution 1.
- This event typically marks when both the DOM and CSSOM are ready.
- This means that the render tree can now be built.
- If there is no parser blocking JavaScript then DOMContentLoaded will fire immediately after domInteractive.
- Further measured using domContentLoadedEventStart and domContentLoadedEventEnd time stamps
domComplete
- domComplete is the time immediately before the user agent sets the current document readiness to 'complete'.
- It simply means the page and all of its subresources are ready.
- All of the processing is complete and all of the resources on the page (images, etc.) have finished downloading - the loading spinner has stopped spinning.
onLoad
The onLoad event means that the page is loading now (being seen by the user). The final step in every page load is the browser firing an onload event which can trigger additional application logic.
Timestamps:
- loadEventStart
- loadEventEnd
In closing
This article covered the main events that are measured by the Navigation Timing API.
The source information we used are from the Varvy web performance glossary and the following recommended resources:
by