I’ve long been a believer that the best way to learn something is to try it and make mistakes and figure it out as you go. I’ve done that recently with this blog.
After many years of hosting this blog at two shared hosts, HostGator and Site5, I’ve moved this site to a VPS at DigitalOcean. I’ve been a customer there for several years, host many web sites for both my professional and personal projects, and very much enjoy their service. The nerd in me thinks its just super cool that I have servers running at DigitalOcean in New York, San Francisco, and London.
I also wanted to and squeak out as much performance as I could from a $5 server. So, in order to learn how it works, I’ve setup Nginx to serve as a reverse proxy in front of Apache. Nginx is super fast at serving static files, and Apache is good at dynamic stuff but is a memory hog, so you can try and tweak the two to work efficiently together. Don’t want to mess with all that configuration and setup? I very highly recommend Serverpilot. It basically sets all this up for you if you use Ubuntu on your server. I’ve been a paying customer for a few months and love the service.
In the spirit of learning, I wanted to learn how to set up SSL with Let’s Encrypt. Let’s Encrypt is a new service offering free SSL certificates that you issue and revoke via the command line. They’ve made getting and installing SSL certificates brain-dead easy, which is good because otherwise it’s a difficult process with many steps that could lead to errors.
Why SSL? That little padlock is pretty, sure, but more importantly, Google is using HTTPS as one of its magical ranking factors when it reviews a site. Given the state of security and personal information, if you are collecting any data from your users, you should be doing that over HTTPS to protect your user’s information, especially with information like credit cards, addresses, personal information and more. It’s trivial to get setup, so if you can, you should.
Is HTTPS critical for this site? Not really. I don’t collect information, but setting up something like Let’s Encrypt to distribute an SSL certificate to me was so easy, why not. I hope more shared web hosts will offer a service like Let’s Encrypt to it’s users.
To use Let’s Encrypt, you’ve got to first install it on your server. You’ll need to close the git repository first.
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
Switch to that directory, and at a basic level, just run this command:
You’ll be walked through the setup. If you want to skip some of those steps, you can do it via the command line:
./letsencrypt-auto certonly --standalone --email [YOUR_EMAIL] -d [YOUR_DOMAIN] -d [YOUR_DOMAIN_WITH_WWW]
This will generate your certificates, but then it’s up to you to configure Nginx or Apache to use them.
Let’s Encrypt is great – but there’s a catch. You must renew the certificates every 90 days. Doing so isn’t hard, just run that
./letsencrypt-auto script again. Better yet, you can set up a script that checks and renews certificates and set it as a CRON job. No worries.
Here’s the challenge about HTTPS: you’ve got to go all-or-nothing or you’ll get mixed content warnings on your site. If you’re using default WordPress and not using a service like a CDN, adding SSL won’t be a big deal. If you’re hot linking images from another site, you may have a problem. Most image services are moving to HTTPS, including the Photon image hosting service available as part of WordPress’ JetPack service.
As I turned on HTTPS, I ran into issues because I host my uploaded content at Amazon and have a custom CNAME that points to a CloudFront distribution. In English, my image uploads are moved to an Amazon S3 bucket, then distributed via their CloudFront CDN, but instead of using their cloud front.com domain name, I made my own: cdn.hewt.in. I have not setup SSL for that domain, so I’ve decided to use the domain name Amazon gave me for my CloudFront distribution, which does over SSL. HTTPS images sorted.
Here’s another fun thing I’m trying. This site is now available over HTTP/2. Many browsers now support HTTP/2. HTTP/2 is different, sure, but why. The HTTP/2 site says this:
At a high level, HTTP/2:
- is binary, instead of textual
- is fully multiplexed, instead of ordered and blocking
- can therefore use one connection for parallelism
- uses header compression to reduce overhead
- allows servers to “push” responses proactively into client caches
This graphic from CloudFlare shows the difference pretty well:
Instead of having to open multiple connections to a site in order to download content, HTTP/2 is binary and you can send more data down the pipe. You probably don’t see it, but major sites are already using HTTP/2, or a slightly different technology, SPDY. Sites like Google, Facebook, Reddit, and more are already serving over this new technology. Not to belabor the point: but faster is always better.
Here’s the rub about HTTP/2. It only runs over HTTPS, for now. Why? CloudFlare explains:
HTTP/2 does not technically require an encrypted connection, but the majority of implementations only support HTTP/2 when used in conjunction with SSL/TLS. No browsers currently support HTTP/2 over an unencrypted connection. For practical purposes, this means that your website must be served over HTTPS to take advantage of HTTP/2.
This link at CanIUse.com will tell what browsers support HTTP/2.
Here are a few demo sites that show you the difference in speed:
- Test your site’s speed between HTTP 1.1 and HTTP/2
I learned a bunch of stuff this weekend, which is always fun.