HTTP/2 testing happening at TinkerTry.com, speed-up not currently available on Chrome (Fixed on Sep 20 2016, ALPN now implemented!)
You can confirm whether any page has HTTP/2 enabled by simply visiting KeyCDN's handy online checker:
There's some risk of embarrassment here, as I reveal even more of the underbelly of TinkerTry.com. 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).
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.
Given 56% of visitors to TinkerTry.com 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 TinkerTry.com, in its current configuration:
- there's no noticeable speed-up when HTTP/2 is turned on
- Firefox is about 1.5x the speed of Chrome
- 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 extremetech.com and theverge.com. 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 webpagetest.org 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.
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 webpagetest.org 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.
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.
At the moment, I'm back to testing out KeyCDN live on TinkerTry.com.
I'm also looking into the big move to PHP7, which requires cloning my Cloudways instance to Debian 8 first, see:
Cloudways Introduces Debian 8 On Its Managed Cloud Platform
Feb 16 2016 by Pere Hospital at Cloudways
- How to migrate your application to a Debian 8 Jessie Server
Feb 15 2016 by Cloudways
QUIC is what's coming up next, read all about it at:
- QUIC – Faster Content Delivery on Layer 4
Jun 27 2016 by Brian Jackson
QUIC adoption will likely take quite a while, as server support is currently rather scarce, see:
QUIC, a multiplexed stream transport over UDP
The Chromium Projects
- Google has tested its speedy QUIC internet protocol on YOU – and the early results are in - Notice anything peppier about your Google searches lately?
Apr 17 2015 by Neil McAllister at The Register
The move to Debian 8 with PHP7 is now complete. Carefully monitoring.
I also re-added the status.tinkertry.com 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 webpagetest.org 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:
- Supporting HTTP/2 for Google Chrome Users
Jun 7 2016 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.
- Announcing Support for HTTP/2 Server Push
Apr 28 2016 by Vlad Krasnov
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.
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:
"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?
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!
At igvita.com, you'll find many great articles by Google's Ilya Grigorik, such as:
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.
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 https://tinkertry.com/fohr 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.
I decided to ask Cloudways support whether they could manually turn on OCSP Stapling, and provided the instructions and rationale in these links:
- DigitalOcean - How To Configure OCSP Stapling on Apache and Nginx
In this page load Waterfall View, showing a visit from Australia to the Cloudways server in New York, you can see that ocsp.digicert.com is getting hit first, to check the validity of the tinkertry.com 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:
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.
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:
The following article has some CDN speed test links here:
- About TinkerTry Infrastructure - What's TinkerTry.com running on?
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:
Getting Ready for HTTP/2: A Guide For Web Designers And Developers
Feb 16 2016 by Rachel Andrew at Smashing Magazine
Roll out HTTP/2 optimization.
Once your server supports HTTP/2, the rest is up to you. Stop using the old best practices and switch to the new. This will mean that users with browsers that do not support HTTP/2 will get a slower experience, which is why the driver behind your change should be the tipping point when the majority would benefit.
HTTP/2 For Web Developers
Dec 10 2015 by Ryan Hodson at CloudFlare
7 Tips for Faster HTTP/2 Performance
Oct 26 2015 by Valentin Bartenev at NGINX
- TLS has exactly one performance problem: it is not used widely enough.
Everything else can be optimized.
Ilya Grigorik @igrigorik, web performance engineer at Google.