Copied this from WICG/service-worker-static-routing-api#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; });
};