diff --git a/README.md b/README.md
index dc7bfb367b614003e1c0bae6704c4e2f44c8865f..e4a87a798a61a4fdebbe16e6d128bb56dcf8e964 100644
--- a/README.md
+++ b/README.md
@@ -36,3 +36,27 @@ the BigPipe module is built upon.
 - https://www.drupal.org/developing/api/8/render/arrays/cacheability/auto-placeholdering
 - https://www.drupal.org/documentation/modules/dynamic_page_cache
 - https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919
+
+## Varnish
+
+- BigPipe uses streaming, this means any proxy in between should not buffer the response: the origin needs to stream directly to the end user.
+- Hence Varnish should not buffer the response, or otherwise the end result is still a single flush, which means worse performance again.
+- BigPipe responses contain the header `Surrogate-Control: no-store, content="BigPipe/1.0"`.
+
+Therefore the following VCL makes Varnish compatible with BigPipe:
+
+```
+vcl_fetch {
+  if (beresp.Surrogate-Control ~ "BigPipe/1.0") {
+    set beresp.do_stream = true;
+    set beresp.ttl = 0;
+  }
+}
+```
+
+
+## Other (reverse) proxies
+
+Other (reverse) proxies, including CDNs, need to be configured in a similar way.
+
+Buffering will nullify the improved front-end performance. This means that users accessing the site via a ISP-installed proxy will not benefit. But the site won't break either.