Slow performance is one of the top employee complaints. It is challenging to troubleshoot because the issue might originate from the device, the network, the infrastructure, or the application itself. For software as a service (SaaS) applications, the underlying cause could also reside at the network or the infrastructure level outside the company.

Page loads tab

The average page load time is measured using the onload event defined by the navigation timing level 2 on the http://w3.org website. For more information, see the Navigation timing API section below.

What is considered a navigation event?

A navigation event is a change triggered on a web page when the URL changes and the browser populates its history with a new entry. The browser history is a list of visited addresses allowing users to return to a previously visited page.

The dashboard reports values for two types of navigations out-of-the-box:

  • Hard navigations take place when the browser sends a request to load a whole new page.

  • Soft navigations allow for measuring the speed of asynchronous page loads where the browser does not load a new page. They are very common in single-page applications (SPA). Soft navigations have to be enabled for each application. Refer to the Configuring web applications documentation for more information.

The difference between hard and soft navigations

A hard navigation event is triggered at the technical level when a document is loaded. This behavior can be identified in the browser developer tools using the Network tab. One of the web requests should be of the document type. Soft navigations are all other navigations when the browser does not load document request types.

Troubleshooting slow page loads

The flexibility, capabilities and ease of use of the Page loads dashboard empower IT professionals to quickly identify problem areas and focus on employees who may be having issues with specific pages of an application.

You can troubleshoot slow page loads by setting thresholds and filters. Thresholds can be set up for each application individually, or default settings can be used. Refer to the Threshold documentation for more information.

There are various approaches to troubleshooting slow page loads:

  • You can filter all data by clicking on the Frustrating indicator of the Page loads widget, as shown in the illustration below. This allows you to focus quickly on problem areas.

  • Once the Frustrating filter has been applied, you can narrow down your search in the Key pages section. Apply additional filters by clicking on specific key pages that have page load issues. The number of affected employees is displayed at the top of the Investigate more panel in the right-side panel.

  • You can start your investigation by selecting peaks in the timeline using a click-and-drag action. Then apply the Frustrating filter of the Page loads widget to narrow your search.

  • When soft navigations are switched on, you can use the Page load time widget to filter data by browser, operating system, location, or other options. Refer to Configuring geolocation documentation for more information about the geolocation feature.

  • You can then follow up on your search for slow page loads with an investigation using the Investigate more panel.

  • You can diagnose slow performance issues using the Diagnostics feature. Click on the Diagnostics icon in the right side menu to open the Troubleshoot application slowness panel.

  • You can use the Connectivity feature in combination with the filters to correlate web application issues with the network interface and VPN status. Clicking on Connectivity in the Investigate more panel will open the New investigation dashboard and automatically generate necessary NQL statements along with the table of results.

Page loads metrics

Hard Navigations

The number of employees represents those who performed at least one page-load action. It is mapped onto its own timeline for users to easily draw a visual correlation with the Average page load time widget above. This number can differ from the one in the Adoption dashboard, which is based on focus time. It is possible to focus on a browser tab but not perform any action that would trigger a navigation event. For instance, reading text or scrolling usually does not trigger any navigation.

In the timeline, the data is broken down according to the following categories:

  • Backend is an estimated response time on the backend. Its accuracy depends on how the application performs.

  • Network refers to the network response time value which corresponds to the time taken by potential redirections, DNS lookups, TCP connections and response time.

  • Client refers to the client response time value and is equal to the total page load time minus the sum of the backend and network times: client time = total page load time - (backend time + network time).

You can follow up on your search for slow page loads using the Investigate more panel in which the breakdown of the data is carried over and categorized according to Backend, Network and Client.

In order to fully understand how page load times are measured and calculated, let’s take a look at the navigation timing API and break it down by events and attributes from the moment an old page is unloaded to the moment a new page is loaded. See the illustration and definitions below for events and attributes involved in the process.

Backend time is the time between when the client starts sending a request requestStart and when the clients start receiving a response responseStart.

Network time is the sum of the time between:

  • redirectStart and redirectEnd

  • domainLookupStart and connectEnd

  • responseStart and responseEnd

Client time is the time between unloadEventEnd and loadEventEnd minus the backend and network times.

Resources timing events

Unload event An unload event is triggered when the user navigates away from the page or when the page is reloaded.

Redirect The time it takes to follow HTTP redirects.

DNS The time it takes to resolve domain names.

TCP The time it takes to establish a socket connection between the browser and the webserver.

SSL The time it takes to establish a secure socket connection between the browser and the webserver.

Request The time it takes to wait for the first byte of the document response.

Response The time it takes to download the document response.

Processing The time it takes by the browser to process and build the DOM.

Load The time it takes to load the DOM, including DOM processing.

Number of bytes transferred HTTP response sizes.

DOM events and attributes

There are various onload events that are triggered before a page can be fully loaded. The browser fires an onload event which can trigger additional functions or logic on the page. Such events are also used in the process of calculating page load times:

domLoading  attribute provides the start time of the entire process.

domInteractive  event is triggered when the browser has completed parsing the HTML and constructed the DOM.

domContentLoadedEventStart and domContentLoadedEventEnd events mark the start and end times of a render tree creation. The process begins when the CSS object model is ready.

domComplete event is triggered when the processing is completed and all the resources are ready.

Note that the sum of the timing elements shown above is not always equal to the total page load time because other factors such as concurrent OS tasks may affect the loading time of the page.

Soft navigations

A soft navigation consists of the following sequence of distinct events (some are optional):

  1. User's interaction and/or hard navigation triggering the soft navigation

  2. Changes in the rendering of the page

  3. A request for new resources from the backend

  4. Waiting time for the backend to respond

  5. Receiving of resources from the backend

  6. Processing on the client-side based on the new resources

The information above is applied in the timeline to Backend, Network, and Client as follows:

  • Client time is defined as the sum of 1. & 2. & 6.

  • Network time is the sum of 3. & 5.

  • Backend time is 4.

Transactions tab

The transactions complement the monitoring of page loads by tracking important changes of states within a web application that do not necessarily require a complete reload of the page.

The evolution of the average transaction duration over time helps you quickly identify the current trend and spot whether it is reversing or stabilizing.

You can investigate incomplete transactions using the investigate more side panel. The possible statuses of transactions that help you understand why they are incomplete and are listed in the NQL data model.

Transactions metrics

Transaction duration corresponds to the difference between the time when the transaction end and the transaction start is detected. Only complete transactions are taken into account when computing durations in the dashboard.

The number of employees represents the number of employees who made at least one transaction, complete or incomplete, for a given time period.

Filter transaction duration by browser, operating system, location, or other options. Refer to Configuring geolocation documentation for more information about the geolocation feature.


Last updated