Quick Primer to Single Page Applications (SPA) and Tracking SPA pages

DZone 's Guide to

Quick Primer to Single Page Applications (SPA) and Tracking SPA pages

Tracking and analytics with SPAs isn't always as straightforward as you might think. Let's take a look at some considerations to ensure you are collecting accurate data.

· Web Dev Zone ·
Free Resource

SPA relies on the HTML 5 History API. Using mPulse's SPA settings, we can track the soft-navigation. Soft-navigation is when the URL changes on the browser but it doesn't actually re-load the entire page.

I was trying to understand how Single Page Applications work and came across the article Using the HTML5 History API by CSS-Tricks. In this excellent article, they explain the concept of the HTML5 history API. Normally, when you navigate from one URL to another, the browser reloads the whole page. However, you may want to change certain parts of the page and not reload the entire page. This could be accomplished by using AJAX requests. However, if you just use AJAX, the URL of the page remains the same. So if you need to share this specific view, there is no way to do so. That is where the History API comes in.

Understanding the History API

The History API is able to manipulate the URL without forcing the browser to load the entire page. It offers two main functions: history.replaceState and history.pushState.

  • history.replaceState: This changes the URL but does change the navigation flow in the browser. So a user hitting the back button will not go back to the original view of this SPA page, but, rather, gets redirected to the page they came from.
  • history.pushState: This method will replace the URL and record the current view information. So a user hitting the back button will go back to the original view of the SPA page.

For more a detailed explanation of the two methods, refer to the official documentation on manipulating the browser history on the MDN site.

SPAs introduce a challenge to measuring performance. On regular web pages, browsers are collecting a host of performance-related information based on the NavTiming API. However, when SPA navigation occurs, the page doesn't really reload. Since this does not occur, the browser is not rebuilding the DOM. As a result, it is not able to report on the performance associated with the navigation.

To work around this, Real User Monitoring (RUM) solutions like mPulse rely on the history API. By observing the changes to this plugin, it is able to detect navigation and then measure the timing information.

Testing an SPA Page

Since I work at Akamai, I had access to mPulse. So I thought of trying to see how this works. I created a dummy website using the code for Ghostbusters SPA from the CSS-Tricks website. In their example, we have the following:

  • Landing URL: https://css-tricks.com/examples/State/
  • SPA Navigation:
    • https://test-woocommerce.akshayranganath.com/peter.php
    • https://test-woocommerce.akshayranganath.com/ray.php
    • https://test-woocommerce.akshayranganath.com/egon.php
    • https://test-woocommerce.akshayranganath.com/winston.php

In effect, when the user first lands at the home page, it has a regular navigation layout. This is calledSPA Hard in mPulse. All other navigations within this sub-section of the website are calledSPA Soft or soft navigations. If a user were to directly use the URL for any of the characters, it would cause the browser to load the page normally and be measured as an SPA Hard navigation event.

Test Results

When I set up the tests, the median page load time shows up as 15 seconds based on 8 views. This included both SPA (SPA-Soft) and non-SPA (SPA-Hard) timing information.

When I look at the performance of hard navigation, the page load time from 4 views now jumps to 17.4 seconds.

If I now filter to just the soft navigations, the page load time drops to 129 milliseconds from 4 views.

If we never had the soft navigation beacons, we may have misinterpreted the site performance as over 17 seconds. However, this represents the initial view that includes the time to load the SPA framework. However, the pages speed up dramatically once the framework is ready. Without the information on soft navigation calls, you may misinterpret the engagement on your website. A user, in this case, could load the home page and access four other sub-pages. Without SPA tracking, your RUM analytics may show a user just accessed one page and bounced. This could corrupt your bounce rate and conversion measurements.

Take Aways

If you have an SPA-based website you could be missing critical performance information signals or misinterpreting the data.

  • Enable SPA tracking if you have designed your page to use SPA frameworks.
  • Understand if you have the right filters in place when looking at numbers. Mixing the SPA and non-SPA navigation will give you numbers that may not be actionable to your teams.
  • On the other hand, missing SPA navigation will reduce the engagement and conversion metrics. So carefully instrument their measurement for a holistic picture.

Hope this has been useful.

single page application development, spas, web application performance, web dev

Published at DZone with permission of Akshay Ranganath , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}