HTTP/2 testing happening at, speed-up not currently available on Chrome (Fixed on Sep 20 2016, ALPN now implemented!)

Posted by Paul Braren on Jun 17 2016 (updated on Sep 21 2016) in
  • Network
  • Performance
  • WebDesign
  • You can confirm whether any page has HTTP/2 enabled by simply visiting KeyCDN's handy online checker:

    Cloudways Support Center - How to Enable HTTP/2 on Your Web Apps

    There's some risk of embarrassment here, as I reveal even more of the underbelly of This is my chance to share the somewhat convoluted backstory of what it takes to obtain better web page speeds, along with detailing the simple tools I use for testing and the lessons learned along the way. HTTP/2 is somewhat bleeding edge for the average blogger, much like going all https was in 2015. As you can see in the video below, the preliminary results are a bit surprising.

    The groundwork for HTTP/2 was laid back in March of 2015, when all TinkerTry content was moved to https, see also:

    HTTP/2 became much more feasible to deploy on April 26, 2016, Nginx 1.10 brings HTTP/2 support to the stable releases. This announcement also meant that web hosting providers could finally work on testing and deploying HTTP/2 for their customers, without resorting to beta code (Apache, NGINX).

    Screenshot from the Cloudways Web UI HTTP/2 toggle, pictured in the tweet below.

    This long-time-coming journey into HTTP/2 is just beginning for most, with Cloudways web hosting, which is really Digital Ocean, quietly allowing simple toggle activation of HTTP/2 on June 15th 2016. This is detailed in the long CloudWays feature-request thread that I actively participated in, where you'll see that Cloudways wisely "soft launched" the HTTP/2 feature, given the benefits of HTTP/2 are seriously tempered right now by the NPN issue, descried nicely in the Cloudways thread Implement HTTP2:

    Cloudways [Admin, Cloudways] commented · June 15, 2016 11:36
    Yes Bruce, we have released HTTP2 to be activated from Server Settings. Issue is that at the same time, we did it, Google did this:

    Essentially it means HTTP2 will NOT be available for Chrome (it will work for other browsers though). Our base servers are Debian and we are checking what is Debian going to do about it although it seems not a trivial situation to get out from.

    This is the reason we have not announced it, as after Google decision, it has severely diminished the impact of this feature. We are checking our options and will update here.

    You can of course experiment with it as long as you use any other browser but Chrome.

    Cloudways Team


    Given 56% of visitors to over the past year use Chrome browser, that's rather unfortunate.

    Temporary NPN issue aside, during my preliminary tests, I've already found that for, in its current configuration:

    1. there's no noticeable speed-up when HTTP/2 is turned on
    2. Firefox is about 1.5x the speed of Chrome
    3. too early to conclude much of anything, I'll need to investigate further

    For today anyway, I'm leaving HTTP/2 on, and carefully watching the day's average page load times globally. Thanks to some amazing help, Kirby based TinkerTry is already pretty lean and fast, without the heft/bloat of and Therefore, any eventual HTTP/2 speed-ups of TinkerTry may be less spectacular.

    I realize there are others that know far more about web hosting than I, with my articles and my time admittedly more focused on home lab virtualization. All the more reasons why constructive comments people leave below are so valuable for me, and for TinkerTry visitors. Please, feel free to chime in here! I have many further web optimizations pertaining to my page load times coming up in 3Q2016, so what I'm really after are comments that are about HTTP/2 in particular.

    See also the comparative results, as featured in the video.

    I'll be adding updates below this article as further developments and changes happen. I'm continuing to speed test HTTP/2 compatible CDNs like KeyCDN and CDN77 (speed-champ AWS CloudFront doesn't support HTTP/2 quite yet), with video of the process of quickly and easily moving among CDN providers coming up soon. Stay tuned!


    Excerpt from HTTP/2 Test Verify HTTP/2.0 Support:

    The tested TLS extensions are either NPN or ALPN. Next Protocol Negotiation (NPN) appeared as part of the SPDY protocol but it has been deprecated. Application Layer Protocol Negotiation (ALPN) is the successor of NPN and is approved by the IETF (RFC7301). However, NPN advertises the supported protocols from the server to the client and this test will show the advertised protocols if HTTP/2 is not supported. The protocol advertising has been reversed in ALPN (client to server). The first phase of this HTTP/2 check runs the ALPN test with only H2 in the protocol list.


    HTTP/2 testing happening at, speed-up not currently available on Chrome

    Jun 18 2016 Update

    I plan on further tests of my New York City-based Dediserve hosting service from a more distant datacenter, to determine if the effects of HTTP/2 are then more pronounced.

    FYI, using again, when testing from Sydney to my Cloudways web server in New York, it turns out my Time To First Byte (TTFB) is much worse with HTTP/2 on. It's bad (grade C) when testing with Firefox, and it's terrible (grade F) when testing with Chrome, seen in the comparative results.

    Jun 22 2016 Update

    I'm continuing to compare worldwide page load times for when I have CDN77, KeyCDN, and no CDN, and I'm concerned about time-to-first-byte. This is a work in progress. Meanwhile, I've added more good articles to read, down in the See also section below.

    Jun 28 2016 Update

    At the moment, I'm back to testing out KeyCDN live on

    I'm also looking into the big move to PHP7, which requires cloning my Cloudways instance to Debian 8 first, see:

    QUIC is what's coming up next, read all about it at:

    QUIC adoption will likely take quite a while, as server support is currently rather scarce, see:

    Jun 29 2016 Update

    The move to Debian 8 with PHP7 is now complete. Carefully monitoring.

    I also re-added the site monitoring service, which works great with any browser that's not Chrome.

    Finally, testing and re-testing seems to clearly indicate the the start of visual page loading is considerably slower for Sydney Australia when HTTP/2 is turned on. That time-to-first-byte seems to be the culprit, see these results comparisons, for example, and the rather telling graph it generated:


    I've turned HTTP/2 off for now on my Cloudways origin, but left it on (default) over at KeyCDN. This yields the best results for now, until I get some more time for more testing.

    See also this excellent article:

    I'm beginning to envy Ubuntu on Digital Ocean, since I'd like to offer HTTP/2 for Chrome users with ALPN. You see, my Cloudways managed hosting features Digital Ocean, AWS, and Google, but doesn't offer Ubuntu on any of those hosting platforms. It's also unknown how long it will be until OpenSSL 1.0.2 arrives on Debian. Source:

    Table published by Nick Shadrin at Nginx

    As you can see, only Ubuntu 16.04 LTS supports ALPN. This means that if you’re running your website on any other major operating system, the OpenSSL version shipped with the operating system does not support ALPN and Chrome users will be downgraded to HTTP/1.

    Jun 30 2016 Update

    Pushing Ahead

    Today, we’re happy to announce HTTP/2 Server Push support for all of our customers. Server Push enables websites and APIs to speculatively deliver content to the web browser before the browser sends a request for it. This behavior is opportunistic, since in some cases, the content might already be in the client’s cache or not required at all.
    Server Push Diagram
    It’s been touted as one of the major features of HTTP/2, and by enabling it, we cover the entire set of HTTP/2 features for all of our users. You can see it in action on our live Server Push demo.

    Image by Cloudways under the "Profiling Server Push" section of Announcing Support for HTTP/2 Server Push by Vlad Krasnov.

    I have also submitted a public Cloudways Suggestion:

    Implement OpenSSL 1.0.2 (or later) for Chrome to benefit from HTTP/2 using ALPN

    See the "Note:" section below:
    which says:
    "Currently HTTP/2 via NPN is supported at Cloudways. ALPN requires a more recent OpenSSL (1.0.2), which are not yet made available by Debian. If you are using the very latest build of Chrome, you will not be able to take advantage of HTTP/2 on your websites, because Chrome has dropped support for NPN. You will continue to access your websites on HTTP/1.1."

    I'm looking to get ALPN (Chrome) support for HTTP/2, see also:

    I've already gone to Debian 8:

    Wondering when Cloudways will offer OpenSSL version 1.0.2?

    Thank you!

    Paul BrarenPaul Braren shared this idea · June 30, 2016

    a great mechanism to get the dialogue going in a very transparent way. Don't forget to click the little vote button!

    Jul 01 2016 Update

    At, you'll find many great articles by Google's Ilya Grigorik, such as:

    Jul 02 2016 Update

    PHP7 itself has some tunable values such as MEMORY LIMIT and OPCACHE MEMORY, still tweaking those to determine what works best. Also investigating ways to further decrease that Time To First Byte (TTFB). Interesting to note that TTFB is now similar whether I have HTTP/2 set to on at Cloudways. I continue to leave KeyCDN's HTTP/2 setting turned to ON for most tests.

    Speed tests are ongoing.

    Jul 04 2016 Update

    It seems I may be done, for now. I have left the Debian server location in New York, and I now have various speed test tools showing me page load times that range from less than 4.5 seconds to load the image-rich article from Sydney, and less than 1.5 seconds from New York. Continuing to monitor using F12 tools in my browser, and many speed test sites, and Google Analytics Site Speed reports, including Avg. Server Response Time and Avg. Page Load Time.

    Jul 08 2016 Update

    OCSP Staple Not Enabled

    I decided to ask Cloudways support whether they could manually turn on OCSP Stapling, and provided the instructions and rationale in these links:

    In this page load Waterfall View, showing a visit from Australia to the Cloudways server in New York, you can see that is getting hit first, to check the validity of the certificate, before anything visual happens in the client browser. Same goes for this Waterfall View of a visit from New York to New York.

    It would be best to eliminate as many of these long round trips as possible, but it turns out Cloudways simply doesn't offer OCSP Stapling at this time. If this is a capability you also want, please cast your vote over on the Cloudways Service Improvement suggestions page:

    Jul 15 2016 Update

    This Brian Jackson over at KeyCDN is on quite a roll lately at the KeyCDN blog, cranking out quality articles that are truly informative, while managing to stay away from sounding salesy. Each is an interesting deep dive into the world of web site performance optimization, you should catch them all.

    • Top 12 Browser Compatibility Testing Tools
      JUL 14 2016 by Brian Jackson at KeyCDN

      There are a lot of different browser compatibility testing tools out there, below are 12 of the most popular ones.

    • Waterfall Analysis – Diving Into Your Website’s Requests
      JUL 05 2016 by Brian Jackson at KeyCDN

      What you really want to aim for is what we at KeyCDN call a “nice looking waterfall.” We will go more into what that means and how to achieve it later on in this post.

    • Analyzing HTTPS Performance Overhead
      JUN 28 2016 by Brian Jackson at KeyCDN

      It is important to note that we didn’t use Pingdom in any of our tests because they use Chrome 39, which doesn’t support the new HTTP/2 protocol. HTTP/2 in Chrome isn’t supported until Chrome 43. You can tell this by looking at the User-Agent in the request headers of your test results.

      HTTP Strict Transport Security (HSTS) is a security enhancement that restricts web browsers to access web servers solely over HTTPS. It helps your performance by eliminating unnecessary HTTP-to-HTTPS redirects and shifting this responsibility to the client, which will automatically rewrite all links to HTTPS.

    • HTTP/2 Statistics – KeyCDN Report on HTTP/2 Distribution
      APR 25 2016 by Brian Jackson at KeyCDN

      And as of April 13th, 2016, HTTP/2 traffic has now reached 68%. So in 6 months there has been a 17% increase in HTTP/2 traffic and adoption.

    • KeyCDN Enables HTTP/2 HPACK Compression
      APR 25 2016 by Brian Jackson at KeyCDN

      HPACK compression reduces the size of your headers by over 30% on average. There is less data now being sent which in turn will increase your content delivery speeds.

    This guy is a gem. He'd do any CDN company proud, and I'm glad he's currently working at KeyCDN, which I'm currently testing for my CDN needs here at TinkerTry.

    Sep 21 2016 Update

    How to enable ALPN in Cloudways.

    I now have ALPN working on my site to hopefully help my Chrome visitors out, monitoring performance over time. Video below of the simple method of deplying this new capability on Cloudways, basically, you just disable then re-enable HTTP/2, with guidance on where to find that button right here:


    HTTP/2 at Cloudways for - disabling then re-enabling gets you ALPN support for Chrome

    See also at TinkerTry

    The following article has some CDN speed test links here:

    I no longer use WordPress, but folks who do might find this article/video helpful, demonstrating a way to speed up most sites that contain many images, with minimal effort:

    See also

    Is TLS Fast Yet?