Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synthetic Response via Static Routing API #32

Open
sisidovski opened this issue Sep 18, 2024 · 1 comment
Open

Synthetic Response via Static Routing API #32

sisidovski opened this issue Sep 18, 2024 · 1 comment

Comments

@sisidovski
Copy link
Collaborator

sisidovski commented Sep 18, 2024

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants