Modern websites need to implement a number of technologies for performance. Sometimes making them work together is a challenge on its own.
Modern Web Stack for Performance
Varnish doesn’t support SSL out of the box. So we must use Nginx for SSL termination.
No website is perfect in the way it renders. So we must use Nginx PageSpeed Module.
Finally, we need to compress the output where appropriate using Gzip or Brotli, the new compression method by Google.
But how do we actually make things work for SSL encrypted website, PageSpeed and Brotli compression altogether? We have to use a bunch of software and questions are raised every time a new component is being introduced:
- Nginx (SSL terminator) Do we compress here – on the edge? Is this where we should put PageSpeed?
- Varnish Shall we compress in Varnish?
- Nginx (web server) Do we compress here – “behind Varnish”?
Let’s review possible configuration approaches.
#1. PageSpeed + Brotli on the Edge (SSL terminator)
In this approach we will enable Gzip and Brotli in the SSL Terminator (nginx).
We have to add Accepting-Encoding "" to proxy_pass configuration to make sure that the terminated web server doesn’t do compression on its own.
Pros: ngx_pagespeed, Gzip and Brotli will work without much configuration efforts.
Cons: gzip_static and brotli_static cannot be used (but they probably won’t work in general with ngx_pagespeed at all); more RAM *might be required on the Varnish server. More CPU for gzipping and brotli-ing on the terminator server! Cannot be used when Varnish and SSL terminator nginx are on slow link (because data between them will fly uncompressed)
#2. PageSpeed + Brotli on the Web Server (Behind Varnish)
This is the configuration that was introduced in Citrus server stack.
Nginx (SSL) terminator – (no gzip, no brotli, no PageSpeed)
Nginx (Web server) – will have Gzip, Brotli and PageSpeed. Those can include maximum compression for static files, i.e. gzip_comp_level with max setting 9 for CSS and JSS (those will be cached, no worries) location. Varnish will cache compressed static files and further CPU impact will be negligible. Essentially, Varnish acts as dynamic gzip_static, virtually 🙂
For PageSpeed support in Varnish we will need to implement downstream cache config. We make Varnish aware of Brotli compression via special VCL configuration.
Pros: high compression levels, compressed content is cached, less CPU usage.
Cons: possible higher load for traffic site due to PageSpeed rebeaconing requirements (can be disabled).
We’ve made our choices. What about you? Let us know in comments.