Speed
Last updated
Last updated
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.
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.
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.
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.
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.
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.
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.
A soft navigation consists of the following sequence of distinct events (some are optional):
User's interaction and/or hard navigation triggering the soft navigation
Changes in the rendering of the page
A request for new resources from the backend
Waiting time for the backend to respond
Receiving of resources from the backend
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.
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.
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.
RELATED TASKS