You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm requesting a TAG review of Timing Info for ServiceWorker static routing API.
Service Worker provides timing information to mark certain points in time. This is exposed and used by the navigation timing API as well as the resource timing API. It currently records two times:
Start time
Fetch event dispatch time
However, it currently does not have any fields related to the ServiceWorker Static Routing API. Developers would benefit from having fields that provide information such as:
the matched route (the route that the Static Routing API evaluated)
the actual source from which the resource was retrieved
the time it took to match the route
the time to look up the cache for the cache source
This information will allow developers to measure the latency incurred by the API such as router evaluation time or time required to conduct cache lookup, or determine if the matched source is the final source used (can find out if the matched source failed to get the resource or not, and which source was used as the alternative).
User research: It is a well-studied phenomenon that faster sites are better for users, and timing info APIs are used for measurement to evaluate their sites, but we have not conducted any user studies specifically on this feature. We often get some feedback from partners about logging and debugging difficulties of the API.
Security and Privacy self-review²: No change from original static routing API proposal (link)
The group where the incubation/design work on this is being done (or is intended to be done in the future): Web Incubator Community Group
The group where standardization of this work is intended to be done ("unknown" if not known): Web Performance Working Group and possibly Service Workers Working Group
Existing major pieces of multi-stakeholder review or discussion of this design: not available yet
Major unresolved issues with or opposition to this design: n/a
This work is being funded by: Google
You should also know that...
[please tell us anything you think is relevant to this review]
The text was updated successfully, but these errors were encountered:
Hi @quasi-mod - thanks for sending us this. One thing that came up immediately in our initial discussion was the lack of a security & privacy discussion in the explainer (info on writing explainers). It seems that since this is dealing with timing, there might be some additional security issues that need to be explored or discussed beyond what was done already for Static Routing API. This is probably fine, but anything that touches timing carries some risk, particularly when it touches on resources that might be shared, like caches.
We're continuing to discuss and will provide additional feedback.
Hi @quasi-mod could you please add a security & privacy consideration section, including some info on abuse cases, and also can you add some user needs at the top of the explainer (how does this benefit end users), before discussion of the background ?
Hi @torgo. Thanks for looking into our proposal!
I will add the security & privacy concern in to the explainer, and will let you know as soon as its ready.
Hi, just a FYI, but we have merged the User needs section to the explainer, and are currently working on a security & privacy concern section, which is undergoing a review (Draft PR: WICG/service-worker-static-routing-api#30).
こんにちは TAG-さん!
I'm requesting a TAG review of Timing Info for ServiceWorker static routing API.
Service Worker provides timing information to mark certain points in time. This is exposed and used by the navigation timing API as well as the resource timing API. It currently records two times:
However, it currently does not have any fields related to the ServiceWorker Static Routing API. Developers would benefit from having fields that provide information such as:
This information will allow developers to measure the latency incurred by the API such as router evaluation time or time required to conduct cache lookup, or determine if the matched source is the final source used (can find out if the matched source failed to get the resource or not, and which source was used as the alternative).
Explainer: url
User research: It is a well-studied phenomenon that faster sites are better for users, and timing info APIs are used for measurement to evaluate their sites, but we have not conducted any user studies specifically on this feature. We often get some feedback from partners about logging and debugging difficulties of the API.
Security and Privacy self-review²: No change from original static routing API proposal (link)
GitHub repo: url
Primary contacts (and their relationship to the specification):
Organization/project driving the design: Google Chrome
External status/issue trackers for this feature:
ChromeStatus
Mozilla Standards Position
WebKit Standards Position
Further details:
You should also know that...
[please tell us anything you think is relevant to this review]
The text was updated successfully, but these errors were encountered: