Remove streaming support

[ascorbic]

Summary

I propose removing support for streamed rendering in SSR, in order to improve performance and unlock a number of features.

Background & Motivation

Astro supports streams in on-demand rendering, which allows the server to start returning a response before every component has rendered. This can improve TTFB, and in some cases allow content to be displayed quicker. However it is not as powerful as in other frameworks that support streaming, because it does not support out-of-order rendering. This mean it just stops at the first component that has not resolved, which can leave the page in an arbitrarily partially-rendered state.

Some of the drawbacks of streaming:

• If there is an error in a component rendered after the response headers have been sent, it cannot change the HTTP status code, meaning an error page will return a 200 code.
• The Astro.response can only be modified at the page level
• The head has already been rendered when components are rendered, meaning it cannot have things such as preloads added
• Supporting streaming prevents several features and DX improvements from being implemented, even in prerendered or cached pages
• Web streams are slow in Node. We have some workarounds to improve this, but there is nonetheless a real performance impact from using them

Some features that would be unlocked by removing streaming:

• Allow any error thrown in a component to trigger a 500 status code
• Allow mutation of Astro.response in any component
• Head bubbling #481
• Automatic preloads for priority images
• Font components hoisted into the head
• Inject script tags (e.g. frameworks, server islands runtime) into the head, instead of inline

Goals

• The scope of this is just to remove streaming for pages
• Keep backwards-compatibility at the adapter level

Non-goals

• Removing support from endpoints. These will continue to support streaming
• Implementing any of the features and patterns unlocked by this

[delucis]

I think we’d need some real world benchmarks showing that removing streaming was actually faster in static builds and server requests. There are certainly some tempting things unlocked by this, but it’s a big architectural change so we should be confident we’re not accidentally shooting users in the foot, especially those working at scale/with high performance requirements.

It would also be good to survey the patterns used by other successful frameworks to understand how they do things and what we can learn from them.

it is not as powerful as in other frameworks that support streaming, because it does not support out-of-order rendering. This mean it just stops at the first component that has not resolved, which can leave the page in an arbitrarily partially-rendered state.

Might another option be to improve this behaviour potentially?

[ascorbic]

There are potential ways to implement out of order streaming, but that wouldn't help any of the other issues.