Module Description
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 core only is able to accelerate responses for personalized requests. (Requests that have a session.)
Drupal 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 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 2 3 4 5 6 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.
Install it and it works. There's no configuration, no UI.
Technical explanation
The BigPipe module in Drupal core only is able to accelerate responses for personalized requests. (Requests that have a session.)
Drupal 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 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 2 3 4 5 6 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.
Module Link
Project Usage
3020
Security Covered
Covered By Security Advisory
Version Available
Production
Module Summary
This module accelerates Page Cache misses using the BigPipe technique.
Data Name
big_pipe_sessionless
OPENAI CHATBOT
OPENAI CHATBOT
