Core Web Vitals versus instant data
Google published an API to fetch this RUM data, for free. But there are important nuances:
- It is delayed
- It is Google Chrome only (and yes, Google Chrome on iOS is excluded, unfortunately);
- It costs a lot of time to set it up properly;
- You'll need a fair amount of knowledge.
This especially is something to consider when using solutions with a wide variety of features. Most SEO or uptime monitoring toolings started to also embed Core Web Vitals, but often with the above restrictions.
Missing metrics
We already noticed that clients started using RUMvision as other solutions didn’t embrace the Core Web Vitals metrics just yet, or were slow to adopt new metrics such as INP.
Limited debugging information
Whenever using PageSpeed Insights, you get to see the 3 Core Web Vitals metrics plus 3 additional metrics. PageSpeed Insights is calling the additional metrics “other notable metrics”. But when you want to deep-dive and debug, you need way more information than just a set of metrics. For example:
- Are issues only happening under specific conditions;
- And what are the nuances per -for example- TTFB and LCP?
When talking about conditions, we are talking about device conditions, internet connectivity conditions, page conditions, and caching conditions:
- Are performance issues caused by device memory?
- Are TTFB issues the result of caching strategy differences, query strings, or just specific pages or CDN?
- And is it caused by increased DNS look time, connection time
- And does the LCP depend on the internet speed, lazyloading or did you forget to add the fetch priority attribute?
Not all Real User Monitoring solutions will track these nuances, lacking the possibility to alert you.
Privacy compliant
Privacy compliance has two cases here:
- With a European audience, you should comply with the GDPR
- And data should be stored within the European Union as well.
GDPR
GDPR is the European privacy law. As part of the GDPR, one isn’t allowed to store all types of user information. Any personally identifiable information (PII) can’t be stored without user consent. The boundaries are sometimes quite thin here, so that’s why we are privacy compliant by default. From there on, you can configure your snippet to decide what to track. Or actually, start tracking information after you’ve asked for consent via a cookie notice.
And by the way: we never actively send IP addresses and user agent strings to our servers. Any browser analysis will be done client side so that we don’t need to actively receive or store this kind of information.
European data storage
Data is not allowed to be shared with others. This means that choosing a RUM solution that is storing data outside of Europe or could be accessed by parties outside of Europe automatically means that it doesn’t comply with GDPR.
Tell us what to track
Most RUM solutions will track everything. But when you think about it, that isn’t necessary. In the end, many pages will be the same when it comes to technical and UX characteristics. We aren’t saying you should only track one URL per page type, as you are then likely to miss nuances.
Nevertheless, when using RUMvision, we made it very easy for you to decide which pages to track. You can use regular expressions to track all product pages when the availability of products and thus product pages are changing regularly. Moreover, you can:
- Set up a sampling rate when specific regular expressions or URLs are receiving too many requests;
- And actively exclude pages, such as checkout or account-related pages.
Load what you choose
We like this one the most, as no other Real User Monitoring solution out there is doing what we do when it comes to limiting the impact on performance.
Sure, some other solutions might allow you to track specific URLs only. But we went the extra mile with this one.
We will only bundle and then load the JavaScript based on your needs.
Let’s be honest: in the end, any Real User Monitoring solution will involve JavaScript. A RUM solution will tell you about performance issues, but shouldn’t become on themselves.
Whenever choosing your tracking options in the snippet configurator, we will show you the impact on the (uncompressed) snippet file size! Quite convenient and transparent!
Impact of snippets by third parties
We don’t impact performance
The sooner our snippet is loaded, the more data it will track and thus the more accurate the data will become. This isn’t different from any other tracking solution, such as heatmaps or analytics. The advantage of RUM solutions over analytics is that RUM is working with percentiles, so missing a few data points might not impact 75th or 80th-percentile outcomes that much.
So, although we like to believe that real UX and Real User Monitoring deserve priority to boost conversion, our snippet doesn’t need the highest priority.
We won’t load on all pages
Yes, we said this already. But most third parties saying this means: we won’t collect data on all pages, but the JavaScript is still loaded and executed. For example, the typical cookie-consent implementation will continue to impact your performance on every other page hit. Even if the visitor already accepted cookies. Sure, the triggers need to be submitted to your (Adobe or Google) Tag Manager, but that’s everything a cookie notice needs to do from that moment.
That’s where we decided to come up with a neat trick: all URLs or Regular Expressions are saved in your browser during that session. When navigating to another page, the URL will first be checked against your URLs and Regular Expressions. If there isn’t a match, our JavaScript won’t even be executed.
You can easily check this by opening DevTools, navigating to the network panel, and filtering on a “RUM-“ file loaded from CloudFront. You will see that it will be executed on your homepage, but likely not on your sitemap or privacy page (depending on your configured URL rules).
Snippet dev-mode
We didn’t just create an idle snippet. You can actively communicate with our snippet. But only when you opted into this in the snippet configuration.
For example, maybe you told us to track country or device information in the snippet configuration. If you did, it would be a shame if you’re using yet another third party to fetch such information and provide users with tailored notices, such as alerting them to visit the USA shop when they’re from the USA but reached the UK domain.
And the same applies to core Web Vitals as well. If another third party is tracking this as well, then we don’t need the library. You could then disable our library in the configuration settings, and be sure to report every metric to us manually.
You can all do this by calling specific functions. Such as rumv(‘get’, ‘browser_brand) or rumv(‘get’, ‘browser_version’). This way, you could even warn people when they are on older browsers, or choose to load polyfills on certain occasions.
