Tracking feature usage in pre-rendered pages

Skip to first unread message

Jason Chase

Sep 8, 2022, 4:25:30 PMSep 8
to blink-api-owners-discuss
In, the goal is to include prerendered pages in the UseCounter feature tracking. Currently, prerendered pages are excluded, meaning that feature usage on those pages is not recorded at all.

Pages may be speculatively prerendered, but then not activated, meaning the user never sees or interacts with the page. I'm wondering if a feature should be recorded as used, or ignored, in this scenario (comment thread).

I don't know if we have data, or a prediction, to support an opinion. It could very well be that the volume of prerendered, not activated, pages never gets large enough to affect the metrics for any one feature. We could just pick an approach that seems reasonable (include or exclude), and not worry about it until there's evidence of significant impact.

Given UseCounter data is often used in compat decisions (especially deprecations), do the API owners have an opinion on this scenario?


Yoav Weiss

Sep 8, 2022, 11:38:38 PMSep 8
to Jason Chase, blink-api-owners-discuss
If a feature deprecation breaks a prerendered page and no user ever sees it, does it make a sound?

I'm tending to say that if such breakage is not user visible, than it doesn't matter. As long as we count usecounters in prerendered and activated pages, that seems good enough from my perspective.

You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Tim Dresser

Sep 14, 2022, 4:56:17 PMSep 14
to blink-api-owners-discuss, Yoav Weiss, blink-api-owners-discuss,
Restricting to recording use counters for "actually navigated" loads feels correct to me, and I believe results in the least semantic change from the current definition.

It sounds like Yoav and +Jason Chase agree.

I think it's safe to consider this sufficiently strong consensus to go ahead and ship with that model.


Kouhei Ueno

Sep 14, 2022, 5:02:03 PMSep 14
to blink-api-owners-discuss, Tim Dresser, Yoav Weiss, blink-api-owners-discuss,,
Thank you all!

I also think the option makes most sense.
toyoshim@ and kenoss@ also seemed fine with deferring until activation.

So let us take this as a consensus and proceed with the approach.
kenoss@: Would you proceed with the UMA deferrer [CL] (or equivalent) + the option 1?

Ken Okada

Sep 14, 2022, 11:19:41 PMSep 14
to blink-api-owners-discuss, Kouhei Ueno, Tim Dresser, Yoav Weiss, blink-api-owners-discuss,,
Thank you all for the decision!

UMA deferrer for UseCounterPLMO is a bad option because the PLMO can record lots of metrics and consumes memory.
I'll try to implement by replay.
Reply all
Reply to author
0 new messages