2

On a static website I precompress pages to .gz files with maximal compression level and serve them using gzip_static on;. I also have HTTP/2 enabled.

My question is whether these things go well together, because I see mostly HTTP/1.1 requests in the logs.

  • why precompress when nginx will do that for you? – Reverend Tim Sep 19 '17 at 13:44
  • The idea is that these files are compressed only once, rather than in each request. A second benefit is that high compression levels are possible. – Harmen Sep 19 '17 at 13:49
  • True, but there really isn't any need unless you're serving millions of requests and are that concerned about the bandwidth explosion. \shrug. – Reverend Tim Sep 19 '17 at 13:50
  • @ReverendTim ... in my experience, you can always find good uses for CPU time in a server, and pre-compressing is a no-brainer when it comes to optimizations. Also, good Brötli compression is quite CPU-demanding. Ah, yes, there is Brötli now. – dsign Sep 19 '17 at 14:08
  • Every byte saved is less time spent loading the page on user's device. Furthermore, there is correlation between page loading times and conversion. – Tero Kilkanen Sep 19 '17 at 14:30
2

Best way to test it would be to go to one of the assets in chrome, and see what protocol you're using. Just bear in mind that most browsers also require ALPN enabled as well as HTTP/2.

That means you'll need an up to date openssl install, an up to date nginx install, and an SSL.

EDIT: You can test if you have ALPN enabled by doing nginx -V 2>&1 | grep ALPN and seeing if you get a response.

  • Right, ALPN might be the issue here. I have nginx/1.13.5 with OpenSSL 1.0.1f on Ubuntu 14.04 – Harmen Sep 19 '17 at 13:58
  • @Harmen - updated my response :) – Reverend Tim Sep 19 '17 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.