Chapter 7. Service Workers: Analytics Monitoring

Let’s jump right into the first application of service workers, analytics monitoring.

Performance Monitoring Today

Over the last few years, third party performance monitoring tools have gained a lot of traction due to all the benefits they provide for most businesses. The reason these tools have had a significant impact on businesses is because of all the powerful data they are able to provide. More specifically, these tools are able to monitor performance by collecting timing metrics, which are then correlated to various revenue growth or even conversion business metrics. Businesses are then able to make logical decisions based on these key performance indicators (KPIs) to improve the end user’s experience overall and gain that competitive edge over other businesses.

Many popular performance monitoring tools exist today, as shown in Figure 7-1; some are in-house, but the majority are third party components that are able to collect and present the data in a logical way.

Each of these has unique capabilities bundled with the data and metrics they provide for measuring performance. Some measure performance over time versus others that measure single snapshots or even request transactions. And of course, some take the approach of real user monitoring (RUM) versus simulated traffic performance monitoring.

So what do third party analytics monitoring tools have to do with service workers? Typically, these tools expose their services via REST APIs. Given this approach, these tools are unable to track and provide data for offline experiences. As we advance in technology, year by year, it is important to note that we are constantly coming up with new ways to provide new types of experiences for our end users. If performance metrics have that much of an impact on the business and on the end users, then it’s critical that we provide that data for offline experiences.

Track Metrics with Service Workers

The navigator.connect API enables third party analytics platforms to register service workers that expose APIs to track metrics, for both online and offline experiences. As long as the services are available/implemented by service workers, we can use the navigator.connect API to connect to third party platforms.

In Example 7-1, note that we need to define two event handlers. We need to first successfully install the service worker and connect to the third party platform via the activate event. Then, during each fetch event, we can log and save pertinent metrics.

Example 7-1. Connect to third party API

self.addEventListener('activate', function(event) {
    	event.waitUntil(
         navigator.services.connect('https://thirdparty/services/
                                    analytics', {name: 'analytics'}));
});

self.addEventListener('fetch', function(event) {
   		navigator.services.match({name: 'analytics'}).then(
       		port.postMessage('log fetch'));
});

These service workers are then able to report these metrics when connectivity is reestablished so that they can be consumed by the service. Numerous implementation strategies exist for reporting the metrics; for example, we can leverage background sync so that we do not saturate the network with these requests once the user regains connectivity.

Where Do Performance and Security Fit In?

Why is leveraging service workers for third party analytics a potentially better solution than what we have today?

Many third party analytics tools that provide RUM data require injection of a particular blocking script in the <head> of a base page. This script cannot run asynchronously and cannot be altered in any way. The problem is that placement of a third party blocking script at the beginning of the page may delay parsing or rendering of the HTML base page content, regardless of how small or fast it is. Mpulse and Adobe Analytics are good examples of tools that require blocking JavaScript at the <head> of the base page. By introducing third party content earlier in the page, the site is more susceptible to single point of failure or even script injection, if that third party content is compromised or the third party domain is unresponsive. Generally, more popular third party performance tools are reliable, but there are some with security holes, or that cause performance degradation to the first party site.

Service workers remove the piece of monitoring code from the initial base page that collects and beacons out data to the third party platforms. By placing the connect JavaScript logic in the installation event handler, we have less blocking client-side JavaScript that can run asynchronously, which reduces the risk for single point of failure or script injection attacks. Thus there is no impact to the parsing or rendering of the HTML content.

Last Thoughts: Now Versus the Future

If service workers can help third party performance monitoring tools go “unnoticed” to the site and end user, why are they not being leveraged everywhere already? As with any new technology, coming up with a standard takes time—time to vet, time to find the holes, and time to gain popularity. Also note that third party platforms need to expose their services to service workers. Many timing APIs have yet to include this functionality, such as Google’s Navigation Timing API. Given their infancy, and the reasons mentioned above, service workers still have a long way to go before becoming part of the “standard.”

Previous Chapter

6. Service Workers: An Introduction

Next Chapter

8. Service Workers: Control Third Party Content