Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Redefining ‘Page Load’ in the Age of Single-Page Apps

DZone's Guide to

Redefining ‘Page Load’ in the Age of Single-Page Apps

Single Page Applications work differently than entire sites and there a lot of loads happening by Javascript asynchronously or in the background. Fortunately, there are monitoring tools that can help.

· Web Dev Zone
Free Resource

Learn how to build modern digital experience apps with Crafter CMS. Download this eBook now. Brought to you in partnership with Crafter Software

Websites are no longer websites. More precisely, a website is no longer a “site,” a single, static location. Instead, the race to build more immersive digital experiences is making websites more dynamic and interactive, with content and logic updated in real time. Websites are now often called “web applications,” whether they comprise e-commerce shopping carts, media/content galleries, software portals, or other functions.

This evolution has allowed developers to create more engaging experiences for users, but some of the foundational thinking about how we measure website performance hasn’t kept up with these changes. For example, while page load time remains a key metric for how web apps are measured, the term’s definition no longer completely matches how web apps are designed and used. That’s particularly true with the shift towards “Single Page Apps,” such as with React or Angular. The result can dramatically over or under measure your page load times, or miss certain page loads completely. That can skew a key metric that development, business, marketing, and IT stakeholders all use to make important decisions about their websites.

Reviewing the Definition of a Page Load

So, how should we think about this new world of page loads?

The web performance community took a major step forward in 2010 when Chrome, Firefox, and Internet Explorer began to implement the W3C spec that would become the Navigation Timing API standard. Increased visibility into page load timing was a recognized need, and while it was possible to manually build timing instrumentation into a website, this new browser API provided a less-intrusive, standard way to capture this information from the web browser itself. The Navigation Timing spec continues to be actively used and updated, with expanded support and improvements to timing granularity.

The API describes a series of milestones that occur during a page load, culminating with the window.load event. When the window.load event fires, it demarks the end of the document-loading process, when all of the objects in the document are in the DOM, and all the images, scripts, stylesheets, and sub-frames have finished loading. For a static website, when the window.load event is fired, the page is fully loaded into the browser window, completely rendered and ready to be used.

Page Load Process for Traditional Websites

page oad process diagram

For static websites, the window.load event accurately reflects when the page is loaded and ready to use.

A New World of Dynamic Content

Modern web applications are designed and architected very differently, however. To create rich user experiences, they heavily leverage AJAX calls and JavaScript execution to manipulate the page and change content, views, and the user experience well after the window.load event.

We can see this in a number of use cases:

  • Dynamic content loading: Pulling customized content dynamically based on user consumption
    • Examples: Customized news/video content based on user viewing patterns, customized product recommendations for a shopping cart, customized user-account information
  • Lazy loading: Downloading content only after the user scrolls it into the window viewport, in order to speed the initial page load by reducing the amount of content involved
    • Example: Scrolling through a photo-album carousel, dashboard, or content widgets
  • Third-party widgets: Pulling components and content from external services
    • Examples: Social media widgets from Twitter or Facebook, feedback widgets, discussion widgets, display advertisements
  • Real-time content: Continuous polling of a backend system to pull refreshed data
    • Examples: Live game trackers, election results, live blogs, event broadcasts
  • Pre-loaded content: Loading content invisibly behind the scenes for a more seamless user experience
    • Examples: Infinite scrolling news sites that automatically load the next article as the user scrolls through the first, autoplaying video content

These more sophisticated experiences drive increased architectural complexity for web applications, and the window.load event no longer captures a complete representation of the users’ experiences.

Page Load Process for Modern Web Applications

pageload process diagram

For dynamic web apps that continue to pull content, the window.load event no longer matches when the page is loaded and ready to use.

Dynamic Views With Single-Page Apps

Single-Page Apps (SPAs)—often built with frameworks or libraries like React, Angular, Ember, Backbone, and others—take these ideas around dynamic user experiences to the next level. More than just dynamic content or widgets, SPAs render completely new views for a user as part of a route change. After clicking on a link, users may think that they’ve navigated to another page, but they may have actually just had dynamically pulled content re-rendered client-side, without a full page refresh.

Visibility to track these route changes has become important since users experience them as a new “soft” page load. However, the window.load event is unable to track these route changes and would see these subsequent user interactions and route change activities as still part of the original page load.

Notably, while many developers are implementing SPAs using these JavaScript frameworks, others view SPAs more as a design philosophy, a way to dynamically generate new views for their users without a new page load. They may choose to avoid relying on a framework—and the learning curve/lock-in that comes with the framework’s pre-built scaffolding—and build something custom based on SPA principles. What ultimately matters, however, is being able to delineate the start and stops to these route changes so you can measure what users are actually experiencing.

Understanding The "True" Customer Experience of Your Page Load

Between dynamic content and SPAs, the gap between the window.load event and when a user can actually use the page becomes increasingly significant. A page may take only 200 ms for the onload event to fire, but by the time all the AJAX calls have finished and the DOM has settled, it may be 1000 ms (or even double that) before the page is fully rendered and usable. This later time is a more accurate representation of the customer experience.

And this is just a simplified example. Many modern web experiences employ several of these design use cases at once, which can further slow the “true” customer experience of the page. For companies that care about their digital customer experience, getting a true view of the customer experience of a page load can be an enlightening experience, uncovering how long it really takes for a user to start engaging with web content, not to mention the impact this can have on key metrics like conversions, engagement, and digital revenue.

Measuring Page Loads in a New World of Dynamic Web Pages

The window.load event remains an important metric, but it increasingly tells only a partial story of the customer’s page load experience. Let’s take a look at New Relic Browser’s SPA monitoring to see what happens after that initial page load event for a Angular application:

averagen pageload time

For a given page load in an application, we can see breakdowns across backend time, frontend time, and when the window.onload event occurred. This is far more complete information than the window.load event alone, which would have missed all the AJAX calls and JavaScript execution that occurred afterward, and would have significantly underestimated how long users were waiting to use the page. In the example above, some instances seemed to take 3 seconds for the page load based on the window.load event, when it actually took close to 10 seconds in frontend time for the page to be finished.

This deeper visibility into page loads is valuable, though, in a Single-Page Application, it may be the case that route changes make up a greater part of your user experience than page loads. In this same Angular application, we can see that there’s actually more throughput traffic with route changes than for page loads.

throughput of pageloads

The same way we can look into page load timings, we can also drill into route change timings with New Relic Browser’s framework-agnostic SPA instrumentation. No matter what framework is being used, or even if something is custom-built based on SPA principles, we can get this deep visibility into this frontend performance.

average route change time

Once you have visibility into what customers are actually experiencing during page loads and route changes, the next question is how to improve it.

Check out Clay Smith’s post on Building Network-Friendly Single-Page Apps for some best practices; his tips apply to any modern dynamic frontend application, especially Single-Page Apps. And in the coming weeks, we’ll take a technical deep dive into how page loads and route changes should be measured to more accurately reflect your customer experience, including framework-agnostic capture of AJAX calls and JavaScript execution timings for a given user interaction. Stay tuned!

Resources

The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.

Crafter is a modern CMS platform for building modern websites and content-rich digital experiences. Download this eBook now. Brought to you in partnership with Crafter Software.

Topics:
single page apps ,web dev ,site performance ,site metrics

Published at DZone with permission of James Nguyen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}