WICG / service-worker-static-routing-api

A repository for the ServiceWorker static routing API.
Other
24 stars 6 forks source link

Synthetic Response via Static Routing API #32

Open sisidovski opened 1 week ago

sisidovski commented 1 week ago

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.

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; });
};
yoshisatoyanagisawa commented 1 week ago

Considering the App Shell, I just wondered what bring this different from the cache source. The cache source needs the renderer for the main frame to call fetch() while the synthetic response fetches directly without the main frame's renderer. Therefore, the synthetic response might be slightly faster than the cache source by skipping JavaScript execution (including the environment setup) in the renderer. Since the AppShell's content part can be replaced by a response from the server, the synthetic response might be a faster way to set up the App Shell than the cache source.