Cookies are small text files that allow us to create the best browsing experience for you on our site. By continuing
to use this website or clicking "Accept & Close", you are agreeing to our use of cookies. To understand how we use cookies or how to manage them, please see our cookies policy.
Traditionally, application performance monitoring focused on infrastructure and server-side performance. With around 80% of page load time occurring in the browser, a holistic understanding of application performance now involves evaluating both frontend and backend services.
Monitoring and optimizing the speed of frontend services and resolving UX errors are also crucial to delivering an exceptional experience for your application users. As static HTML websites are giving way to single-page applications and complex web apps with dynamic features, the need for frontend monitoring takes on a different turn.
Why Page Load Time Matters
Impact of page loading time on SEO, page views, conversions, and revenue has been extensively researched and established by industry experts through various case studies. Even a few milliseconds improvement in page speed can significantly contribute to your bottom line.
A slow-loading page not only deters incoming traffic but also potential visitors. According to research data, most online visitors expect a page to load within two seconds. A large number of dissatisfied customers will retell their bad experience causing possible loss of future sales.
Page Load Time
Impact
Under 3 seconds
Ideal
More than 3 seconds
53% visitors will bounce*
For every 1 second delay
16% decrease in customer satisfaction11% loss of page views7% decrease in conversions
Page load time is a performance metric that directly impacts user engagement and consequently, a business’s bottom line. To improve the client-side performance, let us understand how a browser renders a web page.
Many factors can affect the critical rendering path (CRP), including the CSS and JavaScript on the page. To speed up the performance of any application, we need to identify what is slowing it down before we can optimize it.
Browser APIs
Performance APIs help in analyzing page performance and identifying bottlenecks. The Navigation Timing API exposes time-related information during a page load, providing timestamps for individual navigation events. From when the user clicks a link to the final onload event, the Navigation Timing API and Resource Timing API record events with start and end timings. The APIs record metrics from real user interactions on the site, providing insight into the critical rendering path performance experienced by page visitors.
User Timing API can be used to create custom performance metrics by inserting API calls at different parts of the application. We can use this API to measure JavaScript performance and extract detailed timing data for specific JS tasks. While Navigation Timing API returns simple timestamps, User Timing provides data to the order of microseconds.
Frontend Performance KPIs
First Contentful Paint
This records the point at which a visual element first appears on a web page. The visual may be just raw HTML without custom fonts or images. Incidentally, this could be significantly different from the final web page displayed to the user.
Speed Index
Pagespeed index is the time taken for a web page to look ready to the user. Though the page may seem visually complete, there may be other things still loading in the background unknown to the viewer.
Time to Interactive
This denotes the time when a page becomes fully functional allowing users to interact with the page elements. For instance, a button visible on the page becomes clickable only when the page becomes interactive.
Largest Contentful Paint
A relatively new metric that better correlates with the user experience in comparison with some of the older metrics. LCP indicates the time in milliseconds taken for rendering the largest content (DOM) element visible within a viewport.
Browser APIs
Performance APIs help in analyzing page performance and identifying bottlenecks. The Navigation Timing API exposes time-related information during a page load, providing timestamps for individual navigation events. From when the user clicks a link to the final onload event, the Navigation Timing API and Resource Timing API record events with start and end timings. The APIs record metrics from real user interactions on the site, providing insight into the critical rendering path performance experienced by page visitors.
User Timing API can be used to create custom performance metrics by inserting API calls at different parts of the application. We can use this API to measure JavaScript performance and extract detailed timing data for specific JS tasks. While Navigation Timing API returns simple timestamps, User Timing provides data to the order of microseconds.
Frontend Performance KPIs
First Contentful Paint
This records the point at which a visual element first appears on a web page. The visual may be just raw HTML without custom fonts or images. Incidentally, this could be significantly different from the final web page displayed to the user.
Speed Index
Pagespeed index is the time taken for a web page to look ready to the user. Though the page may seem visually complete, there may be other things still loading in the background unknown to the viewer.
Time to Interactive
This denotes the time when a page becomes fully functional allowing users to interact with the page elements. For instance, a button visible on the page becomes clickable only when the page becomes interactive.
Largest Contentful Paint
A relatively new metric that better correlates with the user experience in comparison with some of the older metrics. LCP indicates the time in milliseconds taken for rendering the largest content (DOM) element visible within a viewport.
Measuring CRP Performance
There are two different approaches when measuring CRP performance—automated tests and real user metrics. We often use automated tests to identify optimization opportunities and monitor the real-world performance of a page using browser APIs.
Synthetic Monitoring
This approach relies on a series of automated tests run on a web page to report on the CRP performance. Tools such as Lighthouse and Webpagetest adopt this approach to provide a generic overview of page performance. The results may vary depending on assumptions made in terms of the device type, network connections, etc. However, the method allows us to rapidly test and improve page performance iteratively during the development phase.
Real User Monitoring
The second approach is to measure real user metrics. Using browser APIs that provide precise timestamps, it is possible to accurately measure performance in production environments. The API data can be sent to tools like Google Analytics or other performance monitoring tools to be incorporated into reports. This approach provides an unerring picture of real-world CRP performance as experienced by visitors to your page.
Synthetic Monitoring
This approach relies on a series of automated tests run on a web page to report on the CRP performance. Tools such as Lighthouse and Webpagetest adopt this approach to provide a generic overview of page performance. The results may vary depending on assumptions made in terms of the device type, network connections, etc. However, the method allows us to rapidly test and improve page performance iteratively during the development phase.
Real User Monitoring
The second approach is to measure real user metrics. Using browser APIs that provide precise timestamps, it is possible to accurately measure performance in production environments. The API data can be sent to tools like Google Analytics or other performance monitoring tools to be incorporated into reports. This approach provides an unerring picture of real-world CRP performance as experienced by visitors to your page.
Improving Page Speed in Single Page Applications
Performance bottlenecks in SPAs can be effectively identified by monitoring the applications using Chrome Devtools extensions such as Lighthouse as well as analyzing real user data. Real user monitoring (RUM) can be done either using tools such as AppDynamics or New Relic Browser or using performance APIs such as the Navigation Timing and User Timing APIs.
Lazy Routing and Rendering
Your SPA can take forever to load especially if you load all the scripts in a single file. Bundling the JS into module-specific chunk files can significantly reduce the initial loading delay. Bundling can be extended to other assets such as HTML and CSS too. It can be applied to build the DOM for above-the-fold contents by deferring the rendering of other resources. By assigning rendering priorities for the various components on a page, we can improve LCP and Time to Interactive.
Prefetching
As opposed to the preload feature, which tries to load a critical resource faster, prefetch aims to load non-critical resources sooner. For instance, fonts are normally loaded after the CSS and JavaScript when the browser starts building the render tree. When we prefetch fonts, we are hinting at the future need of the resource and allowing the browser to download it sooner without waiting for the completion of JS execution.
Lazy Data Fetching
Just like JavaScript, data serving can also be bundled and prioritized. We can decide to serve data needed to display in the viewport before fetching and serving the remaining data. Any trigger such as time or user scroll can be used to initiate rest of the data download.
Progressive Web Apps
Using libraries such as Workbox, we can add offline support to the application. Performance improves as we create a mobile-app-like experience for users with service workers and effective caching strategies.
Your SPA can take forever to load especially if you load all the scripts in a single file. Bundling the JS into module-specific chunk files can significantly reduce the initial loading delay. Bundling can be extended to other assets such as HTML and CSS too. It can be applied to build the DOM for above-the-fold contents by deferring the rendering of other resources. By assigning rendering priorities for the various components on a page, we can improve LCP and Time to Interactive.
Prefetching
As opposed to the preload feature, which tries to load a critical resource faster, prefetch aims to load non-critical resources sooner. For instance, fonts are normally loaded after the CSS and JavaScript when the browser starts building the render tree. When we prefetch fonts, we are hinting at the future need of the resource and allowing the browser to download it sooner without waiting for the completion of JS execution.
Lazy Data Fetching
Just like JavaScript, data serving can also be bundled and prioritized. We can decide to serve data needed to display in the viewport before fetching and serving the remaining data. Any trigger such as time or user scroll can be used to initiate rest of the data download.
Progressive Web Apps
Using libraries such as Workbox, we can add offline support to the application. Performance improves as we create a mobile-app-like experience for users with service workers and effective caching strategies.
