Earlier this year the HTTP/2 protocol was ratified, and by now all major browsers are supporting it. HTTP/2 promises to speed up page load time by 12% to 47%, and has thus generated quite a bit of buzz in the web community. Most browsers will only support HTTP/2 over TLS, which makes encryption de facto mandatory, although the HTTP/2 standard itself does not require encryption. This raises the concern that implementing HTTP/2 is an exercise best left to highly technical folks. Here we show you how you can take advantage of the hot new protocol in 3 easy steps without first acquiring a degree in DevOps.
Before we start - a few useful tools to have
Chrome has a great extension - HTTP/2 and SPDY Indicator. It will put a lovely blue lightning bolt into the address bar when you are receiving content from a website over HTTP/2.
Firefox’ Developer Tools put cute green lock icons next to each request’s domain if it was received over https. This helps you troubleshoot SSL/TLS issues. Also, the headers section contains neat info regarding protocol version, HTTP/2 vs. HTTP/1.1, as well as a X-Firefox-Spdy header which will eventually read “h2” if you set up everything correctly.
You will need edit access to your Drupal site's settings.php, and perhaps to a few other files to fix HTTPS issues.
Finally, you should be logged into your domain registrar's admin panel, so you can readily make changes to your DNS setup.
Step 1: Sign up for CloudFlare
The good news is that CloudFlare announced on Dec. 3 that they now support HTTP/2. Furthermore, the communication from CloudFlare back to your Drupal site does not require HTTP/2 nor encryption. This sets the stage for our exercise. Better still, you will also be able to benefit from CouldFlare’s other features, such as blindingly fast Anycast DNS, serving requests from closer to your visitors (aka CDN), protection against distributed denial of service and other attacks, and a host of other cool things. All for free, unless you want to avail yourself of CloudFlare's more upscale features.
So, go ahead and sign up for CloudFlare and choose their free plan for now. Once signed up and logged in, add your site to CloudFlare and follow the steps they tell you to take. This will involve changing name service to CloudFlare’s DNS servers and pointing your domain name to a CF-supplied Ip address. The DNS change will take anywhere from a few minutes to hours. It is always stated that DNS changes can take up to 48 hours to trickle throughout the net, but I have never seen it this slow. Your mileage may vary, so be patient.
We won’t go into more detail here since CloudFlare’s guidance is easy to follow and documentation is detailed.
Step 2: Enable SSL
Once your site is active on CloudFlare per the Overview tab in your CloudFlare dashboard, click on the Crypto tab. Enable SSL and wait a few minutes until your certificate is active.
If you're going to run your Drupal site under HTTPS, you must set the $base_url parameter in settings.php. Edit your settings.php file, uncomment and change this line to read:
$base_url = ‘https://www.yourdomain.com'; // NO trailing slash!
Substitute your own domain name, of course, and also in every example following from here.
Then try and reach your site via https://.www.yourdomain.com [1]. Your should get a response over the secure protocol - check the lock icon in your address bar and details in Firefox' Developer Tools. If not, check all your steps this far. However, you may find that not all requests are served over https. Firefox’ Developer Tools in the Network section has a nice little green lock icon next to each request, so you can keep easy tabs over which request is served over which protocol. Alternatively, check headers for each and read the details.
While it is theoretically possible to serve some assets not securely and therefore over plain old HTTP/1.1, browsers will show a nasty broken lock icon and warn users that their connection is not completely secure, so you’d probably be shooting yourself in the foot leaving it that way. I found that on two out of three sites I had to dive into the theme layer and change hardcoded paths to protocol relative. A simple text search across my site's code base for the URL paths not serving over https (as highlighted by Firefox' Developer Tools) showed which file was responsible, and the fix was a straightforward change from src=“http://www.yourdomain.com/asset” to the protocol-relative src=“//www.yourdomain.com/asset” (note deletion of http:). This will use either http and https, depending on how the parent request was served, leaving the door open to revert back later if you find you didn’t like the changes we propose here. Make sure all items are served over HTTPS. For
Now take another look at request headers in Firefox’ Developer Tool for the https version of your site. You will find entries like this:
Yay, we are running over HTTP/2! If you installed the HTTP/2 Indicator extension into Chrome you will also see the blue lightning bolt. Bask in the glory for a moment, and then proceed.
Step 3: Complete the switch - run over HTTPS only
Now that all requests to your site can serve over HTTPS, it is time to clean up. Head into the Page Rules tab on CloudFlare, and add a new rule. Into the URL Pattern box type: http://www.yourdomain.com/* [2], substituting your own domain name of course. Then turn on the Always Use HTTPS option, and click the Add Rule button. What we are saying here is that every request for a non-encrypted URL should be redirected to the equivalent secure URL.
Now access your site over http (type http://www.yourdomain.com [3] into the address bar) and watch the URL immediately change to https and the lock icon turn green. Congratulations, you are essentially done.
Bonus point: In CloudFlare's Crypto tab, turn on HTTP Strict Transport Security and change the Max-Age header top 1 month. There's a scary warning in there, and it is true, if you decide to disable HTTPS afterward all visitors who received this header will not be able to access your site for a month. However, if your checks this far showed that your entire site served great under HTTPS and HTTP/2, why would you turn back now? Up to you.
So was it worth it?
https//livingwiththewebers.com home page (yeah, I know, upgrade to D8 desperately needed)
timings from Chrome Developer Tools, average of three page requests, after one cache warm request
Protocol Finish DOMCntentLoaded Load
HTTP/1.1 .16s 0.821 0.940s
HTTP/2 0.930 0.752s 0.925s
Improvement 20% 8.4% 2%
https//livingwiththewebers.com/art/refurbishing-brooks-leather-saddle (an image-rich page)
timings from Chrome Developer Tools, average of three page requests, after one cache warm request
Protocol Finish DOMCntentLoaded Load
HTTP/1.1 .34s 0.988s 1.56ss
HTTP/2 0.98s 0.784s 0.889s
Improvement 27% 21% 43%
https//www.bleatingheart.com home page
timings from Chrome Developer Tools, average of three page requests, after one cache warm request
Protocol Finish DOMCntentLoaded Load
HTTP/1.0.795s 0.636s 0.753s
HTTP/2 0.636s 0.529s 0.590s
Improvement 20% 17% 22%
https//www.bleatingheart.com home page
timings via webpagetest.org from Dulles, Chrome browser, native connection, average of three page requests, after one cache warm request
HTTP/2 via CloudFlare, HTTP/1.1 directly to Drupal server
Load Time First Byte Start Render Visually Complete Speed Index
HTTP/2 1.450s 0.241s 1.295s 1.500s 1460
HTTP/1.1 1.728s 0.176s 1.193s 1.700s 1600
Improvement 16% -37% -8.5% 12% 9%
Overall, most metrics improve noticeably, especially as the number of requests per page increases. Time to first byte and start render times are obviously impacted, as we burn cycles negotiating the secure connection, but then we more than make up for it because the browser does not have to open new connections and simply multiplexes all requests over the existing TPC/IP connection. Witness the lovely waterfall, where the absence of orange sections in the requests back to our own domain is very obvious, as is the close succession of requests, until we hit the requests for Google domains. Compare to the same waterfall measured over HTTP/1.1 with the typical bunching of up to 6 simultaneous connections.
You may ask yourself whether CloudFlare having to reach back to your Drupal site via HTTP/1.1 is a performance penalty or trade-off. For a small, low traffic site this is definitely the case for the first request. However, once CloudFlare has cached your assets and/or established connections back to your Drupal site, page load times consistently improve. Plus, you do have the SEO and trust advantages of HTTPS, and the protection of CloudFlare, all of which are nothing to sneeze at.
