Clarification on workerCacheLookupStart

[ErikWitt]

Hey! The explainer looks very interesting. Especially workerMatchedRouterSource is very useful, we would certainly track it. workerFinalRouterSource is very cool as well as soon as race-network-and-fetch-handler is fixed (see crbug).

I am not sure we will be able to test the OT because it is hard to get our customers to add the token as header to the service worker. A way for 3rd party origin trials for service worker features would be awesome in the future :) (our script is imported into the customer hosted service worker file).

What I do not quite get from the explainer, will I get workerCacheLookupStart even when I do the cache lookup manually from the fetchEvent or only if I specify cache as a static route?

PS: we would also be interested in workerRouterEvaluationStart. We are using static routing already a lot and are seeing very good performance gains in RUM (up to 300ms in median for returning users on android). Understanding the performance of static routes even deeper, could be valuable.

[quasi-mod]

Thanks for the feedback!

I am not sure we will be able to test the OT because it is hard to get our customers to add the token as header to the service worker. A way for 3rd party origin trials for service worker features would be awesome in the future :) (our script is imported into the customer hosted service worker file).

Let me check and see what we can do to enable 3rd parties.

What I do not quite get from the explainer, will I get workerCacheLookupStart even when I do the cache lookup manually from the fetchEvent or only if I specify cache as a static route?

Sorry for the confusion. Current OT only shows workerCacheLookupStart for cache lookup with static routing API.
We want to expand the workerCacheLookupStart for fetchEvent in general (access to cache-storage in general), but since it requires to address quite a lot of challenges (e.g. what to do if we have multiple cache lookups in a fetch), generalization is still a work in progress.

PS: we would also be interested in workerRouterEvaluationStart. We are using static routing already a lot and are seeing very good performance gains in RUM (up to 300ms in median for returning users on android). Understanding the performance of static routes even deeper, could be valuable.

Thank you so much! This is one of the things we really wanted to hear back in this OT.
As of this OT, we implemented the field and can be tested as well.
For the spec part, we will discuss them and get back to you.

[quasi-mod]

CC: @sisidovski @yoshisatoyanagisawa

[yoshisatoyanagisawa]

Thanks for the feedback and question :)

For the 3rd party OT, we have recognized the issue (https://crbug.com/40278041), but we could not prioritize it for a while. I also remember is is not trivial to implement.

For workerCacheLookupStart, as Keita mentioned, it has been limited to the SW static routing API. There was a suggestion to generalize it to the fetch handler, but we have not implemented yet because the semantics on the field is not clear. Especially, the case that there is multiple cache look ups or cache look up won't be used in the respondWith(). We would like to have feedbacks on this.

And thanks for the feedback on workerRouterEvaluationStart. There is also a discussion on the field necessity. If there is more supporting materials how it is useful for you, it helps us to push the field necessity in the WG.

[sisidovski]

@yoshisatoyanagisawa This origin trial is used to extend the resource timing API. It exposes the service worker related fields, but the enabled feature does not belong to the ServiceWorker itself. Unlike the previous OT that we held for the static routing, I assume this OT doesn't have restrictions from ServiceWorker. So 3rd party OT should be available, but probably we have to update or recreate the entry in the OT dashboard. https://developer.chrome.com/origintrials/#/view_trial/1689412810217357313

[yoshisatoyanagisawa]

@sisidovski Yeah, that is true. 3rd party should also be able to run the OT. And as you touched and I also understood from https://developer.chrome.com/docs/web-platform/third-party-origin-trials, there might need to have the option to request a third-party token.

[quasi-mod]

@ErikWitt Hi!
This is just a FYI, but we will be enabling 3rd party OTs for this feature from Chrome 133 (will be on stable channel at the end of January).
We will let you know when its live. You will need to update the OT token (re-register) once it is ready. Thanks!

[quasi-mod]

@ErikWitt Hi. Since Chrome 133 has been released, you can now use the 3rd Party OTs.

Please re-register to the OT with the "Third-Party matching option" enabled.
Note that third party OTs will only work with Chrome 133 and later, and will not work with previous releases.

Let us know if there is anything we can do.
Thanks!

[dertheodor]

Hey @quasi-mod ,
I'm Theo, a colleague of Erik.

I was just testing out the feature and have re-registered the OT beforehand (with 3rd party and match subdomains set to both to yes). I couldn't find the exposed window.performance.timing data.
I created a small site to show you this https://theotest.app.baqend.com/v1/file/www/index.html. Maybe I am missing out on something.

Would be grateful for any kind of help! :)

[quasi-mod]

Hi @dertheodor !

Thanks for testing the OT!
Let me clarify so that I am on the same page with you.

Looking at what you gave me, it seems like you are using the old PerformanceTiming API (accessed with window.performance.timing).

Our feature is implemented on the new PerformanceResourceTimingAPI and PerformanceNavigationTiming API.

From my local testing, I was able to see the new fields using performance.getEntriesByType('resource') and performance.getEntriesByType('navigation'). Could you confirm if you could see the new fields with them?

Thanks so much!

[dertheodor]

Hi @quasi-mod, thanks for the clarification! That works.
I was referring to the MD from here resource-timing-api.md where the code was showing usage of the old window.performance.timing API :)
We will implement this soon and hopefully be back with some more feedback . Greetings!

[quasi-mod]

@dertheodor Thanks for confirming, and extremely sorry about the wrong example.
I've updated the examples on the explainer.

Looking forward to hearing back from you all :).
Thanks!

[ErikWitt]

Hi @quasi-mod we have implemented the origin trial and just evaluated the first data.

The data looks a bit unexpected:

1. The first chart shows the distribution of workerRouterEvaluationStart for returning user page impressions (the ones that usually experience high boot times) by plotting percentiles for mobile and desktop devices. The numbers are much higher than we expected and are very close to what we otherwise see as workerStart (aka boot time) for the Service Worker. This would suggest that static routing would not have a big impact on performance.
2. Since we have tracked substancial improvements from static routing on TTFB in the past, we though that there must be something wrong. So the second chart shows TTFB as well as the "boot time" (computed via workerStart + workerRouterEvaluationStart) over time for returning user page impressions on mobile devices. If you ignore the big drop in the metric (that came when we introduced static routing and before we have tracked workerRouterEvaluationStart), you can see that the "boot time" stays more or less constant while the TTFB drops by >100ms.

I am not quite sure if we have misinterpreted the metrics but we would have assumed workerRouterEvaluationStart to be close to 0 or at least much lower than workerStart.

[ErikWitt]

To get a better understanding of TTFB changes, I check out the attribution data before static routing vs. the time after we implemented the new tracking and static routing.

The chart shows

• Time to workerStart reduced quite a bit (or has changed to workerRouterEvaluationStart)
• Service Worker init reduced
• DNS and TCP/TLS become visible (with Service Worker they were hidden in the responseTime I guess)
• Server response time has reduced (in part because DNS and connection are seperated but even when I add dns and connecting back to responseTime, it is still 100ms faster than before)

Since this is a before vs. after comparison, I cannot 100% be sure that there was a TTFB improvement incidentally at the same point in time, I think it is rather unlikely.

What I do not quite understand is

• Why did bother the time to workerStart as well as swInit reduce? Or rather, what is captured as the time before workerStart and what is captured by service worker init exactly?
• Why did the response time improve as well? I would have expected the improved to come only from more efficient service worker handling

[quasi-mod]

Hi @ErikWitt , thanks for the feedback, and sorry for the delay.
The feedback you gave us is really interesting, so let me ask a couple of questions so that we can understand more.

• Is there any site or demo we could use to locally reproduce your problems?
• What kind / how many rules are specified in the router?
• How are each fields (workerRouterEvaluationStart, workerStart, SW Init, etc) calculated?
• Just to confirm, all of the data here is taken from the Performance Navigation Timing API (i.e. main resource)?

Generally speaking, the router evaluation time should be in microsecond order, but depending on how you calculate them, it may look like it is taking a longer time.

Regarding your questions:

Why did bother the time to workerStart as well as swInit reduce? Or rather, what is captured as the time before workerStart and what is captured by service worker init exactly?

Just to be sure, could you tell us how the workerStart and SWInit are calculated? Generally, workerStart is recorded right before starting the SW and conducting fetch. Hence workerStart should contain operations such as redirects, and also the router evaluation time as well.

Why did the response time improve as well? I would have expected the improved to come only from more efficient service worker handling

This is interesting. I think you are right, and response time should not change drastically. I guess it may seem that the response time is shorter depending on how you calculate it.
One scenario which this may happen is when you specify the race rule. For race rules, we start network requests before SW is started, so the response time would also be earlier. In addition, if the SW does things in the fetch handler other than sending network requests to fetch, then it would look if it took a longer time.
Let me check a bit more if there are other scenarios and get back to you.