There was some knowledge floating around that 860 bytes was the
optimal size, I think it was from an Akamai engineer or something,
but the HTML 5 Boilerplate server configs use 256 bytes, and I
actually have HTML content that is less than 860 bytes, so I guess
I could benefit from compressing it. gzip compression is costly
for the compression side, but very quick for the client, so this
is a good thing.
See: https://github.com/h5bp/server-configs-nginx/blob/master/nginx.conf
This reverts commit a38d822fad.
The docs definitely recommend twice a day. From a note on certbot's
installation page:
> if you're setting up a cron or systemd job, we recommend running
> it twice per day (it won't do anything until your certificates
> are due for renewal or revoked, but running it regularly would
> give your site a chance of staying online in case a Let's
> Encrypt-initiated revocation happened for some reason). Please
> select a random minute within the hour for your renewal tasks.
See: https://certbot.eff.org/#ubuntuxenial-nginx
Take an opinionated stance on HTTPS and assume that hosts are using
HTTPS for all vhosts. This can either be via custom TLS cert/key
pairs defined in the host's variables (could even be self-signed
certificates on dev boxes) or via Let's Encrypt.
Google's PageSpeed Insights tool pointed out that the Genericons
in WordPress' Jetpack module could be compressed.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
nginx is caching HEAD requests, then when users come along and do
a GET request they get an HTTP 200 with no request body. It seems
setting fastcgi_request_methods to GET doesn't stop nginx from caching
HEADs, so for now just add the $request_method to the key.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Bypasses caching for logged in users (right now only for sessions
where the "wordpress_logged_in" cookie is set. Doubles the trans-
actions per second as measured by siege:
$ siege -d1 -t1M -c50 https://mjanja.ch
Signed-off-by: Alan Orth <alan.orth@gmail.com>
