Last December we opened up our brand new privacy-first Web Analytics platform to everyone. Today, we’re excited to announce the release of three of the most requested features: adding multiple websites to an account, supporting Single-page Applications (SPA) as well as showing Core Web Vitals in Web Analytics.

Since we launched two months ago, we’ve received a lot of feedback from our users. We are really happy that we are able to provide our privacy-first analytics to so many of you.

Popular analytics vendors have business models driven by ad revenue. Using them implies a bargain: they track visitor behavior and create buyer profiles to retarget your visitors with ads; in exchange, you get free analytics.

Our mission is to help build a better Internet, and part of that is to deliver essential web analytics to everyone with a website without compromising user privacy. We’ve never been interested in tracking users or selling advertising. We don’t want to know what you do on the Internet — it’s not our business.

When we launched Web Analytics, each account was only able to measure one website. We are happy to announce that all users can now add up to 10 websites.

Add one or more new sites via the Cloudflare Dashboard by selecting "Add site" in Quick Actions.

For measuring multiple subdomains (a.example.com and b.example.com) there are two options:

1. Add the root domain (example.com) to Web Analytics and add the same JavaScript snippet on all subdomains (a.example.com and b.example.com)

2. Add the subdomains separately using multiple sites. Here you have to add separate snippets.

We use the hostname to validate the request, so remember that you can only use the JavaScript snippet if both the configured and actual hostnames match.

When we talked to customers about the multiple site feature, we got the feedback that it is very important to add all sites to Web Analytics and be able to track them. But they also said that it would be even more powerful to have the option to see analytics for all your sites combined in one place.

We listened. If you select "View Web Analytics for all sites’ on the Web Analytics overview page, you can now see all your sites listed and apply filters to them using site tags.

With frameworks such as Angular, React, or Vue.js being very popular, one of the most requested features for Web Analytics was supporting single-page applications (SPA).

SPAs work differently from a standard web application or website because they don't load a new page every time there's user interaction. Instead, they dynamically rewrite the current web page with new data retrieved from the web server.

Since we've previously collected metrics only when the page load event is triggered, we had to change the transmission and interpretation of the signals from our JavaScript snippet to include sending metrics whenever there are any route changes made by the application or the website.

We are happy to announce that we successfully implemented SPA support and enabled it for all customers.

You might have noticed that some websites keep the # in the URL whenever you navigate their webpages. You would see URLs like the following:

https://cloudflare.com/#blog
https://cloudflare.com/#marketing

The portion separated by the # is called a fragment, and based on the fragment changes, SPAs dynamically pull the resources to rewrite the webpage. That is how it was done before the HTML 5 History API was introduced and widely used. These days most SPA libraries/frameworks use HTML 5 History API to keep your UI in sync with the URL instead of using # (although, some still support #-based routers). In most cases you won’t easily notice a SPA by looking at the URL path.

To support analytics for SPAs, we implemented sending additional payloads to the beacon endpoint, which collects the data for analytics, whenever we detect any changes to the state of the History API. The JavaScript snippet overrides the pushState method and listens to the onpopstate event. By tracking the History API's state, you'll now see the route changes in SPAs within the Web Analytics dashboard.

Some older SPA libraries/frameworks still support hash-based routers. If your application or website is using a hash-based router, unfortunately it is not yet supported in Web Analytics. However, this is our initial launch to support SPAs, so stay tuned for any improvements and updates.

SPA support is automatically enabled for all domains in Web Analytics.

Core Web Vitals is an initiative by Google to provide unified guidance for quality signals that are essential to delivering a great user experience on the web.

In September 2020, we introduced Web Vitals for customers using Browser Insights, and many customers love getting those unique insights into their website performance. But we were also aware that Browser Insights wasn't available to all our Web Analytics customers simply because they're not able to onboard to the rest of Cloudflare for Infrastructure. Specifically, they're not able to change their DNS servers.

So today, we're introducing Core Web Vitals to Web Analytics as well.

You can see the Core Web Vitals metrics in the same dashboard as Visits and Page Views and check how healthy your website performance is.

This is just the start for our privacy-first Web Analytics.

We’re excited to integrate more closely with the rest of Cloudflare and give customers even more detailed stats about performance and security (not just traffic). We’re also hoping to make our analytics even more powerful as a standalone product by building support for alerts, real-time updates, and more.

Please let us know if you have any questions or feedback, and happy measuring!

The good news is that modern web browsers expose lots of performance data that can help you understand how your web page performs. With the launch of Browser Insights today, we can analyze the performance from the perspective of the web browser and what the end user actually experiences. In this post, we’ll dive into how we think about performance and utilize the timing APIs in the web browser.

In the old days, the only way for a developer to profile performance was to intercept requests and measure the time from the beginning of the page load until the end of the load event.

Today, we can use Web APIs that are supported by modern browsers. This is part of the web standard called the Performance API. The Performance API consists of a collection of individual APIs that include:

• Navigation Timing (for timing information related to the page and navigation)

• Resource Timing (for timing data regarding the loading of an application's resources)

• Paint Timing (that provides timing information about paint operation during the page construction)

In this blog post, we will primarily focus on the Navigation Timing API.

To see what’s collected with the Performance API, you can open the Developer Tools in Chrome browser and type ‘performance’ in the console tab (or type in performance.timing to get direct access to the PerformanceTiming attribute).

Try expanding the Performance object by clicking on the arrow before the label and again expand the ‘timing’. This is called PerformanceTiming, which includes all the timings that relate to the current page load as UNIX epoch timestamp (milliseconds). The timing attributes shown are not in the order of the load. So for better understanding, let’s look at the illustration provided by the W3C.

Image from https://www.w3.org/TR/navigation-timing/

As we can see from the diagram shown, each element (represented as a box above) in the order from left-to-right, represents the navigation flow of the page load. Each element has an attribute from the starting point to the end (and some have multiple attributes!) so that we can measure the elapsed time for each element. For example, to get the Request Time, you could type in the command like shown below in the console which appears to be 60 milliseconds.

Once your website is proxied through Cloudflare and Browser Insights is enabled, we write and inject a JavaScript beacon into the web page. Our beacon collects metrics from the Performance API to send to our edge, where it can be used to understand where your website is slowing down or having any network problems. The reported data is shown in the Cloudflare dashboard on the Speed Page showing as averages of each timing metric:

The metrics we surface are:

• DNS (domainLookupEnd - domainLookupStart): How long the DNS query takes. This could appear as zero if the connection is reused or the content was stored in the local cache (memory or disk).

• TCP (connectEnd - connectStart): How long it takes to establish a TCP connection to the server. If HTTPS, this process includes TLS negotiation time.

• Request (responseStart - requestStart): The time elapsed between making an HTTP request and receiving the first byte of the response.

• Response (responseEnd - responseStart): The time elapsed between the first byte and the last byte of the response received. You can think of this as a resource download time.

• Processing (domComplete - domLoading): How long it took to render the page. If this number is big, you can optimize your document architecture, resource size, or configure settings under the Speed page such as Auto Minify the source code. This document process can be drilled down more with domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, and domComplete. We plan to provide more detailed analytics on this later on.

• Load Event (loadEventEnd - loadEventStart): When the browser finishes loading its document and resources, it triggers a `load` event. This duration may be helpful to you if you have additional functions or any logic for the load event.

• Total Time: Sum of each timing metrics shown on the graph.

If you are seeing any spikes or unusual form of a line in the stacked line chart, you could start investigating on each element to see what is causing the problem.

For more about how to use Browser Insights, see our announcement blog post.

In this blog post, we’ve focused on the Navigation Timing API, because it’s at the heart of our first version of Browser Insights. In the near future, we plan to incorporate metrics from some of the other APIs. For example, we can break down some of the longer timings by looking at individual resource loads, and pointing out what’s taking longer. In addition to that, we plan to track JavaScript errors, provide a way to measure A/B performance, set up monitoring/alerting based on the metrics, and so on. So stay tuned!