Intent to unship: support for streaming responses

[westonruter]

The PWA plugin includes support for streaming responses. This allows for a header to be pre-cached with the body and footer then being combined in the response. The result is that a user should perceive a faster loading experience. For all the details and a demo video, see #85.

The support for streaming responses in WordPress was really a proof of concept to show that it could be done. But there are some key challenges that limit its applicability:

1. Since the header is pre-cached, the requested body needs to included additional logic to modify the head as required. For example, it has to update the document.title, sync meta tags, update stylesheets, and so on. Some of these aren't as much of a problem when AMP is involved because all scripts are asynchronous and AMP web components are being used, but the AMP plugin had to be specifically built to support this (Add service worker streaming for AMP documents ampproject/amp-wp#1503). For a non-AMP page, a big challenge would be scripts in the head which would need to be replaced/removed from the precached header. Assuming the precached header includes the site nav menu, then the body response also has to do the work of synchronizing nav menu item classes.
2. Response headers sent in a navigation request are not processed by the browser. For example, if making a request to ?p=123 intending to redirect to the permalink, this will not just work because the body response is streamed after the precached header was already rendered. This would mean all logic for handling response headers (e.g. Location) would need to be replicated in JS.
3. Streaming responses works well when the header does not change from page to page. This is definitely not the case in WordPress, since get_header() includes output for a lot of page-specific markup, including styles, title, metadata, body classes, nav menu item classes, etc.

All this being said, adding support for streaming responses in WordPress was interesting, but it doesn't seem widely applicable, especially not for the 80%. And thus it should be removed.

[amedina]

This is a correct assessment. While it was an interesting and important exercise, and it may be made available in the future, it should not be part of the foundational aspects of an integration of PWA capabilities into WordPress core.