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.

Harmen
  • 167
  • 8
  • 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
  • @TeroKilkanen - when it comes to a couple of ms change, it really doesn't make much of a difference. Conversions / bounce rates are only hindered past 1s load times last time I checked. – Reverend Tim Sep 19 '17 at 15:04

1 Answers1

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.

Reverend Tim
  • 799
  • 7
  • 14