Replies: 4 comments
-
we already have similar RFC #8981 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Any update on this? It would be awesome to send early hints. :) |
Beta Was this translation helpful? Give feedback.
-
i love the idea of Early Hints natively in nextjs. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
This is an idea that came to me after trying to solve a problem I faced at work where the
getInitialProps
call takes too long and it was holding the HTTP response from starting to stream. I have screenshots and more details here#16730
In short, when server is busy computing the response data we can take send part of the document (the
<head>
) to let the client start downloading assets.Suggestion: Eager
<head>
Taking advantage of chunked transfer encoding we can render the document
<head>
before rendering entire document. In a separateReactDOM.renderToString
call we render the document<head>
and start the response stream with it. OncegetInitialProps
(and other data fetching functions) of Document is completed, we render the document again and continue the response stream with the rest of document.Document rendered string should not contain the
<head>
element.page/_head.tsx
To simplify things we can introduce a new special page that contains all static
<head>
content. This will allow for dynamic<head>
with props and customgetServerSideProps
that is separate from the main DocumentgetServerSideProps
. This page will be optional just like_app
and_document
. If this page exist, Next.js will use it to render the initial response stream.Challenges
This is not a trivial change. Next.js always assumed that the document is rendered and sent in one shot.
<head>
with propsNext.js allows users to make dynamic
<head>
part of the document by allowing props to be passed to the<head>
part of_document
. If all props for_document
is computed in one function, the head can not be produced before computing all props which is the main rationale for this proposal. Introducingpages/_head.tsx
can solve this problem.next-server
code complexityEverything in next-server from
renderToHTMLWithComponents
tosendPayload
is assuming single chunk responses. Changing code to reflect this design would be quite difficult.Content dependent headers
Some headers depend on the content. For example we need the entire response to compute the
ETag
header. With chunked encoding we can take advantage of HTTP Trailers to send those headers after response stream is drained.Problem with Trailers is that they have poor tooling. Chrome dev tools and cURL for instance don't show them by default (Chrome bug)
Implementation roadmap
First, to understanding chunked encoding better, take a look at the example server I put together here:
https://github.com/mohsen1/straming-http-example/blob/master/server.js
This should be an experimental feature for a while. It's a big change and can break many things. We can also do this only if
pages/_head.tsx
is available in userland.Alternatives
I considered H/2 Push initially to solve this problem. I'm open to know if there are more alternatives.
HTTP/2 Push
Alternative to HTTP streaming we can could depend on HTTP/2 Push to push out assets. I looked into H/2 Push and it feels like an overkill. H/2 Push is extremely hard to configure. The browser cache is ignored when pushing assets with HTTP/2 Push. We had to implement complex caching logic to enable HTTP/2 Push, otherwise we could waste bandwidth pushing assets that browser already has in cache.
103 Early Hints and
Link
header103 Early Hints status code allows for sending
Link
headers that will hint to the client to download various assets. This can help us avoid streaming chunked responses altogether but browser support is probably not good.Benefit over H/2 Push is that server doesn't have to do cache management. Browsers will decide to download assets based on their cache management policies.
Drawbacks:
Beta Was this translation helpful? Give feedback.
All reactions