Custom timing

When you are ready to get more out of your monitoring, you can start with custom timing, by creating one (or multiple) of the following:

Be sure to share your tech stack to benefit from our integrated options

Integrated options

Based on your tech stack characteristics, we will be able to come up with Custom Timing suggestions. A few examples:

  • Shopify is (unofficially) exposing server information via Server-Timing.
    You can collect and benefit from this as well, for example to get to the root of TTFB challenges even more;
  • CDN's or hosting (observability) partners might start to expose information via Server-Timing.
    If this typically becomes available for all sites running on such CDN or hosting, we will then introduce custom timings. Site owners should then be able to import them into their custom timing configuration.

When available, you will recognize this by an indicator within the "Add timing" button. This indicator will show how many integrated custom timing options are available for you to import. This is illustrated in the screenshot below:

Pausing and deleting

Site owners can either pause or delete custom timings. Both when they were added manually or when they were imported.

When you delete imported custom timing, you can re-import them again at all times, as they will just continue to be available as long as your tech stack characteristics aren't changing.

Custom timing types

You can manually add and configure custom timings. To do this, click on the "Add timing" button at the top, and a modal will appear, asking you what you want to add. See the screenshot below.

Do note that in order to make custom timing work, you should enable it in your tracking configuration. The reasoning is as follows:

  • Extra tracking also involves additional JavaScript. By forcing users to enable it specifically, we are able to make them aware as our configuration comes with a kilobyte indicator when enabling or disabling features;
  • Custom timing is part of our Ecommerce and Enterprise plans. Whenever you downgrade to the Essential plan, we keep your configured timings, but disable its tracking automatically;
  • Whenever you use custom timing and have collected all the information you need, you can disable all custom timing, via one single checkbox in your tracking configuration. This allows users for easy enabling and disabling them all at once.

the identifier you are using is case sensitive, and only allows extended alphanumeric characters.
Anything that doesn't match [a-zA-Z0-9-_] will be replaced by a dash.

The meaning of each custom timing type is described below.

Server Timing

In short: We collect data that you reveal on your pages via the Server Timing API and use them as under-the-hood metrics along with TTFB.

RUMvision is already able to collect the breakdown of your TTFB, to show additional server side timing information. But this won't be enough when your site is typically dealing with server response time challenges.
Server timing then is ideal to get information that otherwise would not be available. That way, it can allow you to get additional information on back tasks. Also note that next to timing information, Server Timing can also communicate a description, which can be used as custom dimensions.
See the mozilla docs for a technical background on Server timing.

Example of usage:

  • You could communicate the time involved with database queries, amount of queries, CMS time, template rendering time or plugin time;
  • Or our server timing could be used as filtering/dimension-data, to grab the template that is used (Shopify does this), or if a page could be fetched from your CMS cache by communicating either hit or miss, which will then become visible as a filter;
  • CDN's could communicate their own added latency;
  • Or as filtering/dimension-data, for example when a CDN is configured to share the location of a user, or the location of the server that served the contents to the browser (currently done by Shopify) and the cache status (HIT, MISS, DYNAMIC).

Element Timing

In short: Add the elementtiming attribute to your image- and text-nodes, and we collect the render time as additional metrics.

Element Timing is an ideal mechanism to get the render information of either images or block leven text nodes. While LCP will often be the same element in lab data testing, the LCP will vary a lot within RUM data, as no user nor their conditions are the same. This prevents you from getting a conclusive impression of how one specific element is performing.
See the mozilla docs for a technical background on PerformanceElementTiming.

Example of usage:

  • if you always want to have a clear number of your hero image, you could configure element timing for your hero image;
  • if your logo is important from a branding perspective, you might want to track render information of your logo;
  • on product pages, the title is the first important element from a user (engagement) perspective as the image will always be a bit more delayed. So you could add element timing to specific headings;
  • element timing could even be used for cookie notices, to see how they are performing compared to your LCP or hero image.

User Timing

In short: Use performance.mark to add waypoints in your pages, and we collect them as additional metrics.

With user timing, you can set marks across either the HTML source code of your page, or your JavaScript files.
See the mozilla docs for a technical background on performance.mark().

Example of usage:

  • if you are heavily working on optimizing the head, or actually embedding new third parties, you might want to know the impact on performance. You could set a waypoint at the end of the head to see how the browser parser is impacted;
  • You could set a waypoint in a critical JavaScript file to see at what moment in time it is being executed, and decide to speed things up or actually slow it down to not impact other metrics (such as FCP or LCP).

Custom Dimension

In short: Introduce custom filters such as author, deploy_version or other information, to allow you to segment your data even more.

With custom dimensions, you are able to share information with RUMvision in an automated way. This information will then become available as a (custom) filter, allow you to do thorough analysis.

Example of usage:

  • If you haven't set up page URL's to collect data per template type, you could use a custom dimension. If the page template type is already exposed by your platform, you might want to use "Custom selector";
  • When you're continuously doing deploys, you could communicate the deploy or version number of -for example- your frontend. This way, filtering allows you to exclude older versions when analyzing, or actually compare them;
  • Or -if your platform or theme allows you to do so- you could do simple pagespeed A/B tests within the same page. You could test the effect across the same template type (to prevent outcomes to be skewed), but different implementations.

Let's assume you suspect that the value of a specific query string parameter (utm_content) is causing issues and you want to research this. However, due to privacy reasons, we don't track query string values by default. You could then:

  • add the keys to a list of allowed keys for which you want to track the values as well;
  • or isolate utm_content specifically by use the following to collect its value:
const utmContent = new URLSearchParams('utm_content') || 'unset';
rumv("dimension", "utm_content", utmContent );

Do note that in order to force your RUMvision profile to collect it, you will need to add utm_content as custom dimension which is illustrated in the screenshot.