Separate soft nav endpoints

[sgomes]

Is there any chance that soft-nav functionality could be separated from hard-nav functionality in the future, at a source level?

The current approach makes sense from a developer experience perspective, but it comes with an unfortunate compromise: it inflates bundle size in a non-preventable way for consumers that don't need soft nav data, since the functionality is built into the existing endpoints and merely toggled with a boolean. This means it can't be tree-shaken away, and removing it would involve maintaining a set of patches.

Would something similar to the separate attribution endpoints be a possibility?

To be fair, the inflation isn't massive (around 3KB raw, or 1KB gzipped), but it is a large % increase over v5 (> 50%, going by the raw numbers). We try very hard to keep our RUM script as small as possible, since it needs to be widely deployed across every page we host, and web-vitals already accounts for around half of our bundle with v5; v6 would be a significant step back.

Thanks!

[mmocny]

FWIW the size difference isn't all from the extra soft-nav support, so it might be worth estimating the real cost savings first?

[sgomes]

Thanks, @mmocny! I'll run some tests and let you know what I find.

[tunetheweb]

I do suspect it's mostly the soft nav code to be honest. There were some other small fixes in v6, but the big change (in terms of lines of code AND functionality) was the soft nav code.

@sgomes , while I understand the concern here, and obviously would prefer our bundle size to be as small as possible (I did get a 😢 comment from @philipwalton on the PR to update the bundle size in the README), I'm not sure this is a good direction for the library, and will attempt to explain why:

At the moment soft navs is a new thing, has not (yet) been integrated into CrUX and the wider Core Web Vitals initiative. Not to mention there isn't cross-browser support of this functionality and I haven't heard any concrete plans of that from the other browsers. This is one reason why it's a separate option at present, and not the default.

The other main reason being that SPA sites would need to ensure they are beaconing back the URL, when I suspect many depending on analytics solution filling that in automatically (often using the original hard nav URL). So need some more work to ensure this would not be a breaking change and report the wrong metrics for the wrong URL.

My vision for the future would be that soft navs measurement becomes the default, rather than an opt-in (whether by a reportSoftNavs config option, or a separate build). Yes, this would be unnecessary for non-SPA sites but by making it the default devs don't even need to think about this (you wouldn't believe the number of developers I speak to who are unaware that they are using SPA architecture on their site!).

I also have questioned whether we should drop the non-attribution build as I'd really like to encourage websites to benefit from all the attribution to be able to investigate issues, rather than just measure the metrics. That would have similar bundle size increase implications, but I honestly question why sites would want to measure the metrics, without the extra information to improve them.

So, I'm reluctant to introduce a soft nav build option, and create a further barrier for people to adopt. I think it also adds more complexity (do I need the normal build, the attribution build, the soft nav build? Which JS module version?).

Anyway, those are my initial thoughts but let's leave this issue open so others can comment and see if this is should be something we consider.

[mmocny]

The task of measuring soft-navs should not cost as much (in terms of complexity and payload) as it currently does. I think we could also strive to improve the implementation of the performance timeline to remove some extra tedious bits. web-vitals.js is sort of a litmus test for the design of the apis.

---

Barry: is there any substantial amount of code added for backwards compat etc that can be expected to be removed in future versions?

[sgomes]

Thank you, @mmocny and @tunetheweb!

First of all, here are the numbers I came up with, based on our RUM script, which makes use of five exports: onFCP, onINP, onLCP, onTTFB, and onLCS.

Our bundle is currently 12317 bytes raw, or 4647 gzipped (at gzip level 5).

Using 6.1.0 as-is, that would jump to 15347 bytes raw, or 5530 gzipped, a 883 byte increase in gzipped size (not quite the 1KB I'd estimated).

If I hack 6.1.0 to turn the runtime conditions into literal falses (so that they're tree-shaken away), we get 13535 bytes raw, or 5088 bytes gzipped, a 441 byte increase, which is almost exactly half of the total increase.

So the split wouldn't cover all of it, but the increase does mostly seem to come from soft navigations in some way, since it looks attributable to all the new plumbing, like navigationId/navigationInteractionId/navigationURL.

So it's not as big of a win as I'd hoped, but it's still a win.

I also have questioned whether we should drop the non-attribution build as I'd really like to encourage websites to benefit from all the attribution to be able to investigate issues, rather than just measure the metrics.

I can give you our perspective on this, and the idea we're working towards: separate builds.

The goal is to keep doing what we're doing in general: have a lightweight (<5KB), measurement-only build we can deploy everywhere, and have it run on every page, for every visit. You're right that it is a little limited; although you can still get a surprising amount of information from the metrics alone and a few extra LCP fields like the LCP type, resource URL, etc.

However, when we'd need to really dig into a problem (say, an INP issue that only affects some users), we'd have the possibility to switch to a more demanding "debug" build, which would allow us to collect extra information to help debug specific problems. That's where we could have the full attribution data, collect and report more metrics, and pull in more dependencies to help us with all this.

---

I don't know how common our use-case is, of course, and I fully concede that 🙂

Perhaps the soft navigation (and potential attribution) size increase isn't really a factor for most folks. I imagine most are in the position of measuring performance in their own sites, and not necessarily in the position of trying to inject an unintrusive (but ultimately unsolicited) RUM script into their customer's sites, in an attempt to obtain the data to improve the service.

[tunetheweb]

Barry: is there any substantial amount of code added for backwards compat etc that can be expected to be removed in future versions?

No I don't think so.

We moved to Baseline Widely available code in v5 (which also upset @sgomes IIRC as some of our new JS syntax like arrow functions transpiles less optimally for the wider browser support he wants as they have one only one build, even though most of those browsers will only support TTFB 😀). So there isn't a lot of backwards compat code since that. A couple of checks that Performance Observer actually exists (since Firefox allows you to disable that for some reason), which should gate most things so mostly we assume modern APIs exist and don't check for them.

On the soft nav side, I also pulled out most of the earlier implementation before release (e.g. it only works where getLargestInteractionContentfulPaint() is supported and not the older largestInteractionContentfulPaint).

Outside of soft navs, there is some extra logic for INP to handle the fact that Event Timing/LoAF ordering wasn't previously guaranteed that could be simplified now you've fixed that. But it's not a huge amount of code to be honest compared to the rest of the library. The bigger gain would be in masking the code more readable. But haven't done this yet as not sure if the other browsers will need it if/when they support LoAF.

[sgomes]

(which also upset @sgomes IIRC as some of our new JS syntax like arrow functions transpiles less optimally for the wider browser support he wants as they have one only one build, even though most of those browsers will only support TTFB 😀)

Your memory is correct, sorry for making these annoying requests 😄 For context on why that was important, while you're right that we effectively only got TTFB from web-vitals, we do have data collection of our own for other extremely important metrics like all of the Navigation Timing ones (and level 1 of that has been around since forever). We could have maintained a fork of our script, but we opted for maintaining a fork of web-vitals instead, since the differential script serving story is still very tricky, and having a single script that gets loaded and executes on every browser is much simpler and more robust.

In any case, years later we're moving away from ES5 altogether now and dropping the web-vitals fork, which even allowed us to shed some extra bytes with the terser ES2020+ syntax. Or well, that was the plan with v5 anyway 😄

Again, these are mostly customer sites we're dealing with, so we need to be pretty mindful of the unsolicited script we're adding. It needs to be small, and it needs to not break, because we don't want to be a nuisance. But again, I fully understand if you deem our use-case to be too unique.

[ErwinHofmanRV]

We have a similar challenge/consideration:

• As a RUM provider, we try hard to keep our JS footprint small. Shipping a performance monitoring tool that itself adds a significant amount of JS would be a bit ironic.
• Which isn't easy when trying to attribute data on top of what web-vitals provides and keeping (new AI) bots/crawlers out
• So, we try to shave off anything we can, which is what I like about web-vitals v5

Because based on features that can be enabled per site, we ship:

• either the non-attribution build (truth be told, probably 99% of our clients run the attribution build as otherwise our health check features aren't as valuable)
• and only ship the soft-navs build when SPA tracking is enabled in their feature/tracking settings.
• and in case of v5.2.0, there's a 3641-bytes difference between minified soft-nav and non-soft-nav build
  This size difference isn't a deal-breaker for clients, but with an ever-growing amount of JS + as a RUM provider, it feels right to keep bundle size in check where we can.

But I understand both sides. Especially this argument:

devs don't even need to think about this

I do wonder if shipping it by default would fully solve that problem. Developers who aren't aware of the soft-nav nuances may also not realize that they need to treat navigationType: 'soft-navigation' differently when analysing their data, let alone group by it etc.

We will eventually move to v6 (or v7) as v5 won't be maintained anymore. For now, v5 still serves us well and the ability to choose between different builds is one of the reasons we're in no rush to move away from it and want to give this a short thought internally.

RE: reportSoftNavs
I would advocate for keeping the reportSoftNavs flag. That way, we can:

• set it to false on a fully MPA site where we're not interested in modals etc
• configure JS to report soft-navs on (facet)search changes on an otherwise MPA site, but set it to false on product pages to prevent an opened fancybox or clicked product variant/size/color from potentially being reported as a soft nav

[sgomes]

Sticking with 5.x is an option we also considered, but web-vitals is particularly valuable in that it includes a lot of learned lessons around browser quirks and real-world complexity, and fixes and improvements don't tend to get backported to older versions (e.g. #755).

For now, we're going to be maintaining a lite fork of 6.x internally, for use in our lightweight, standalone, hard-nav-only script (the one I was talking about above). Maintenance costs worry me, but hopefully we'll be able to drop it if/when web-vitals becomes more modular.

For the SPA-focused tooling we're currently building, where size is less important, we'll stick to the official 6.x version.

[tunetheweb]

Interesting feedback thanks both.

I'm still not fully convinced both for (mostly selfish!) maintainability reasons, and complexity of having 4 builds (standard, standard SPA, attribution, attribution SPA) across ES, UMD, and IIFE builds, but I wonder if there is some some extra way we could incorporate this into the code with some sort of build flag, without separate build versions to allow this to be tree shaken for those that want this?

[sgomes]

Thank you, @tunetheweb!

From our end, we already consume web-vitals as a source package, in order to control exact transpilation output ourselves, as well as to be able to rely on some unexported library internals (e.g. waitForPageHide).

So if the trade-off is to only expose the modular options through a build flag, in order to keep the dist build simple, that could definitely work for us!

[mmocny]

Does anyone have ideas that might lite-en this library, without opting to split out necessary functionality?

---

One idea: Today we support separate onFoo() entry points, though I suspect a large majority of devs actually subscribe to all of them. If the library unified into a single interface, registered a single PerformanceObserver with a single set of lifecycle events, and reported a single stream of updates, etc-- it might be able to save some redundancy (in both implementation and runtime). (We could still create thin wrappers for onFoo() for compat.)

I took a very quick stab at this, and while keeping existing tests passing, I could reduce bundle size by -12.7% (though less, when compressed), and that including the code needed to add in back-compat, which could be pruned out.

[sgomes]

There's a whole range of techniques you could use to make your dist smaller; sometimes the hard part is knowing when to stop! 😄

I have a bit of experience there with our RUM script, but if you're looking for pro tips, you probably want to look into something like preact and the tricks they employ, because they're way ahead of anything I've done 🙂

In general, here are a few things that I've found to help.

At the architectural level:

• Avoiding large modules, with lots of different imports and exports, is a good idea. Bundlers generally find it difficult to tree-shake effectively in these situations, and end up essentially assuming all imports are needed for all exports. It's best to keep small, single-purpose modules, and use barrel export files if necessary for DX. This is not really an issue in web-vitals; it does very well in this regard.
• One thing that web-vitals does less well is to combine multiple concerns into a single return value. For example, we have no need for ratings, deltas, or metric IDs in our script, but since they're part of the return value in initMetric, we end up with things like the rating configs and the generateUniqueID() function in the bundle, even though we never look at their outputs. The ID might be a little tricky to avoid, but for calculated fields it may be worth considering not including them in the return value, and providing a separately exported method to calculate them if the user needs it.
• Using boolean options (like reportSoftNavs) to control function behaviour is pretty much a guarantee you'll be making consumers buy into the cost of both codepaths, regardless of which one(s) they use. One option to maintain a similar level of simplicity while keeping things modular is to have a registration system of sorts within the library; you'd have two different inits (one for hard navs, one for soft navs), each of which would add its own logic (probably through a callback) to a global handler, which would give you that single path through which all events would flow. It's a bit more work internally, but from the outside the only difference is importing and calling two inits, instead of providing a boolean to a single init. This approach could also play into your idea of having a single subscription endpoint, @mmocny.

At the code/build level:

• The first thing you need to do is pick a metric: either raw size or compressed size. This is because these two work very differently; while raw size primarily rewards minified output terseness, compressed size rewards minified output entropy instead. It's pretty common for a change that drops raw size to actually increase compressed size.
• Once you've picked a metric, add it to your build output and to your CI, on PR comments (via something like compressed-size-action). Great way to catch regressions 🙂
• When trying to reduce entropy, consistency becomes quite important, so it may be worth it to e.g. always use the same control flow approach, or keep the same set of parameters across a family of functions even if some of them don't need all of them. It's somewhat unintuitive, though, and the only thing that really works is trying something and seeing how the numbers move.
• Mangling names makes a big difference, and you're already doing the right thing by manually marking which ones are part of the intended public API, and which ones can be mangled (the ones that start with _). We use the same approach.
• Using multiple compression passes with terser can really help, as can playing around with a few other options. Here's our current compress config:

  compress: {
    passes: 3,
    pure_getters: true,
    unsafe_arrows: true,
    unsafe_methods: true,
    hoist_funs: true,
  },

  Some of these are unsafe, which means you'll need to make sure your tests cover the possibility for breakage there.

These are the ones I remember off the top of my head, but I'm happy to lend a hand looking into things a bit closer with web-vitals specifically if you'd like.