Synthetic Response via Static Routing API
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 3.6k
- Forks
- 324
- Avg merge
- 14d 22h
- Merged PRs (30d)
- 1
Description
Copied this from https://github.com/WICG/service-worker-static-routing-api/issues/32 to collect feedback from broader community.
Synthetic Response via Static Routing API
We'd like to explore whether the browser could invoke the navigation commit much earlier than the regular navigation by extending the Static Routing API. The navigation commit in the renderer process is currently started only after receiving the navigation response. While waiting for the response, the renderer process is mostly idle or not created yet. However, the commit navigation takes some time to process and it can delay the renderer process going to be ready. This is not efficient.
What if the Static Routing API can store the beginning of response in its database, and use it as the part of navigation response while waiting for the network? The browser will be able to start the commit navigation right after the navigation start. The Static Routing API should use one stream as a response. The stream won't be closed after receiving the actual network response. The browser appends the actual response to the stream until all response data is processed.
Here is the slide which was used in TPAC2024, explaining this concept more visually.
Is this similar to App Shell?
This is similar to what the app shell model does. But the Synthetic Response via Static Routing API would be better in most cases, because it doesn't involve the SW bootstrap. The static routing router evaluation is happened before starting the SW, while the regular app shell depends on the fetch handler.
However, what the Synthetic Response can do should be polyfillable like below:
onfetch = (event) => {
event.respondWith(new Response(synthetic_header, synthetic_body));
fetch(event.request)
.then(res => { plumb res.body to synthetic_body; })
.catch(e => { Set error_text to synthetic_body; });
};
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the copied WICG service-worker-static-routing-api issue and the linked Chromium navigation commit documentation. Review the TPAC2024 slide and the app-shell comparison to understand the proposed synthetic response and streaming behavior. The issue is exploratory, so a concrete implementation target and definition of done are not yet specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100