Accelerates Page Cache misses using the BigPipe technique.

Install it and it works. There's no configuration, no UI.

Technical explanation

The BigPipe module in Drupal 8 only is able to accelerate responses for personalized requests. (Requests that have a session.)

Drupal 8 will cache unpersonalized responses by default. But the first request for such an unpersonalized response is not yet cached, and is slow to render (single flush, so blank screen for a relatively long time).

This module uses BigPipe to accelerate the first unpersonalized response! And after that first response is sent, the response is stored in Page Cache. Which means that any subsequent requests for that unpersonalized page will be answered very quickly by Page Cache!

That's what this module does :)

Why is this not in Drupal core?

Because having BigPipe accelerate sessionless responses only makes sense when Page Cache is enabled. And we don't want to make the BigPipe module in Drupal core require the Page Cache module to be enabled.
That's why this module exists: it transparently layers on additional functionality, and can only be enabled if you install both the BigPipe and Page Cache modules.

Want more detail? BigPipe-accelerated responses in Drupal 8 core are never cached by reverse proxies (Page Cache, Varnish …) But accelerating the first sessionless responses using BigPipe is useless if it means that subsequent requests for the same URL are not cached in the reverse proxy. And in order for that response to be cacheable, it must be possible to correctly invalidate it from the cache. To do that, we'd need Symfony to support HTTP trailers, so that we can send the cache tags for the dynamically rendered content after it's been streamed. But since Symfony doesn't support that, Page Cache can't support that, and hence we can only make this work for Page Cache, not for every reverse proxy. Hence this contrib module has a hard requirement for Page Cache. You can use this with Varnish just fine, but only if you also have Page Cache enabled.

So, when using Varnish: the first request will be streamed by BigPipe, and not cached in Varnish. The second request will be a Page Cache hit, not a Varnish hit. The third request and all later requests will be Varnish hits.

For full detail, see #2657684: Refactor BigPipe internals to allow a contrib module to extend BigPipe with the ability to stream anonymous responses and prime Page Cache for subsequent visits.

Supporting organizations: 
Sponsored all development, including the necessary API support in Drupal 8

Project information