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!