Troubleshooting slow page loads
Last updated
Last updated
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 experiencing issues with specific pages of an application.
Troubleshoot slow page loads by reviewing performance thresholds and setting filters. You can set the thresholds for each application individually or use default settings. For more information, refer to the Threshold documentation.
There are various approaches to troubleshooting slow page loads:
Start your investigation by evaluating the Average page load time metric at the top, as well as the Backend, Device & App network and Client metrics adjacent to it. By default, these metrics show the overall performance of the application, considering all navigations across different pages.
A long backend time indicates that the server is taking an extended period to process requests. This can be due to inefficient server-side code, inadequate server hardware, or resource-intensive operations. To address long backend time issues, application developers may need to optimize the code or upgrade the server hardware. You can examine resource timings for XMLHttpRequests (XHRs) using the waterfall metrics. XHRs with extended computation times indicate slow server calls and can be optimized accordingly.
A long network time can indicate issues such as network congestion, slow internet connections, large file sizes, or geographical distance between the server and the client. To isolate these issues, you can examine network time by country, entity, location.type, ISP, adapter type, and largest resources.
A long client time can indicate issues such as slow rendering of page elements, excessive JavaScript processing, inefficient CSS styling, or the device/OS handling other tasks. To address these issues, application developers may need to optimize the client-side code by reducing the number of HTTP requests, minifying CSS and JavaScript files, or leveraging browser caching.
Next, look for recent changes in performance using the timeline that shows page load time over time. You can toggle the Backend, Device & App network and Client metrics on this chart to observe their evolution over time. Use the Employees chart below to identify impact of high or low usage on page load time performance.
Adjust the time filter to focus on the periods with exceptionally poor performance. This can be done using the zoom functionality of the chart or using the timeframe picker in the top right corner.
You can then evaluate the Key Pages & URLs breakdown. Different pages have varying performance characteristics in modern SaaS applications. This section highlights the pages that cause the most frustration in your environment. The breakdown includes five columns to provide additional context. Look for pages with exceptionally high % Frustrating Page Loads compared to the others.
Click on these pages to apply a filter to the dashboard. The graphs at the top of the page will update accordingly. Then, the steps above to identify whether the page is slow due to a backend, network or client issue.
Check the remaining breakdowns (Devices, Location, Organization and Technical) to identify other dimensions that contribute to significantly poor experience. Filter data by browser, operating system, location, or other options. For more information about configuring geolocation, refer to the Configuring geolocation documentation.
You can follow up on your investigation of slow page loads in the Investigations module by using the action menu options in the top right corners of the widgets.
To troubleshoot web applications in more detail, use waterfall analysis metrics. These metrics help you pinpoint the exact sources of performance bottlenecks, identify error-prone elements and highlight resource-intensive components within web applications. Waterfall metrics are available under the Resource analysis tab of the Web applications troubleshooting library dashboard.
Refer to the Web Application Advanced Troubleshooting documentation for more information.
The Nexthink Application Experience browser extension collects these metrics using Performance Resource Timing API.
Name | NQL Syntax | Description |
---|---|---|
Longest resource during a navigation (name, type, size and duration)
•longest_resource_url
•longest_resource_type
•longest_resource_load_time
•longest_resource_size
Longest resource refers to the resource that experienced the lengthiest loading time among all the necessary elements for rendering a web page. If a specific resource takes a significantly longer time to load compared to others, it may be affecting the overall loading speed of your web application.
Largest resource during a navigation (name, type, size and duration)
•largest_resource_url
•largest_resource_type
•largest_resource_load_time
•largest_resource_size
Largest resource refers to the resource that had the biggest file size to be fully loaded while loading a web page. When a user's browser needs to download and render large resources, it can lead to increased latency and slower page load times. Analyzing large resources can help identify files that may be optimized or compressed to reduce their size.
Number of domains contacted
domains_contacted
Number of domains contacted indicates the number of unique domain names from which various resources—images, scripts, stylesheets, fonts and other— are being fetched.
These domains can include the application's own domain, as well as domains for third-party resources like analytics scripts, ads, content delivery networks (CDNs) and more.
Each unique domain contacted represents a separate server from which the browser needs to fetch resources, and this can impact overall page load times.
Number of resources
number_of_resources
Number of resources indicates the total number of resources—images, scripts, stylesheets or other files—loaded during a navigation event. The more resources a web page has, the longer it may take to load and render in the browser. By analyzing the number of resources, you can identify opportunities to optimize the performance of your web application. For example, you might consider minimizing or combining CSS and JavaScript files, compressing images or using caching techniques to reduce the number of requests made to the server.
Number of large resources
number_of_large_resources
Number of large resources indicates the number of resources—images, scripts, stylesheets, or other files—that are larger than 100KB, during a navigation event. When a user's browser needs to download and render large resources, it can lead to increased latency and slower page load times. Analysing large resources can help identify files that may be optimized or compressed to reduce their size.
Number of resource errors
number_of_resource_errors
Number of resource errors indicates the number of resources—images, scripts, stylesheets, or other files—that failed to load or encountered errors during a navigation event. Resource errors can indicate that certain files or assets are missing from the web application. This may result in broken links, missing images or non-functional scripts.