Our team is glad to announce today our next major upgrade,
planned deployed on 19th September, with a brand-new test probe technology. We’re detailing within this post all the evolutions and improvements. This is one of our biggest update, with amazing news such as HTTP/2 support and much more to discover…
We have been working on it for a couple of months: our website speed test tool is about to support HTTP/2. As a reminder, this new version of the protocol, not really widespread yet, is gradually replacing HTTP/1 and is already used by some major websites as Facebook or Wikipedia for example.
In matter of web performance, HTTP/2 is a real game changer. Even if only a few websites are taking advantage of this protocol, most of the web browsers already support HTTP/2. That’s why we couldn’t miss this evolution any longer!
We are glad to announce the next release of a new version of our testing probe technology, with a lot of new features and upgrades to come: HTTP/2 support naturally, but not only!
This new version will be deployed on Monday, 19th September. We will notice our customers as soon as we will have a definitive date for this upgrade.
The numerous changes to come will bring noticeable evolutions within our website speed test results. That’s why we wrote this detailed post about this update, so that you could anticipate the major impacts!
If you just want to have an overall idea of the upgrade for now, you will find a shortlist of the changes at the end of the post.
HTTP/2 support for speed tests & adapted checkpoints
With our next version,HTTP/2 support won’t only concern our speed tests, but also our advices. Indeed, our checkpoints will be adapted for the pages where this protocol is detected.
As Matt Wilcox explained it, a lot of HTTP/1 best practices (hacks!) become useless with HTTP/2, and sometimes even harmful. Unlike most of the other testing tools, you will not see inaccurate advice within our results for HTTP/2 web pages.
Please note that, concerning HTTP/2 usage, you may face different situations, with different effects to be expected on Dareboost results. Your website can load exclusively over HTTP/2, as well as only partially (using an HTTP/2 CDN for example), or even HTTP/2 might only be used for a couple of assets (if you are using a Facebook widget for example, that is delivered over HTTP/2).
As a consequence, the effects of the HTTP/2 support won’t be the same from a website to another. But in any case, Dareboost will always get closer to real user experience.
Websockets, Brotli & Quic support
Working to find a way to deal with HTTP/2 , we also succeed in solving other limitations, such as supporting websockets or Quic protocol for example. Some of our users were waiting for Websockets for a long time, and had to blacklist these requests in order to avoid timeouts. No need anymore in a couple of weeks!
About Quic protocol, no significant changes to be expected . As far as we know, this protocol is only used by some Google services, with slight effects to come on your website speed test results.
Let’s talk now about Brotli, a compression algorithm (more efficient than gzip) that gradually spread on the web. Not only Dareboost will soon support it, but will also take it into account in its quality checkpoints. As a consequence, note that our next upgrade could bring a slight effect on your pages weight (as Facebook widgets support Brotli for example, it will save a few bytes more than gzip).
More globally, the Chrome web browser we are running on our probes will be upgraded to its latest version.
That global refactoring of our technical basis lead us to take another decision: removing the web browser choice within our desktop analyses (and consequently, removing the Firefox option). You may already have noticed some limits within Dareboost analyses with Firefox (no AdBlock setting for example).
That choice will make us more agile for further developments. Moreover, we believe that synthetic performance monitoring, as we propose it, is not the more appropriate way for cross browser performance comparison. Real User Monitoring appears to be more relevant for this kind of tests.
As a consequence, Firefox will be removed from our test probes, and all the existing monitors using this web browser will automatically be switched to the Chrome browser.
Naturally, be sure that we never stop looking at all the news and updates concerning the major web browsers on the market. We’re saying goodbye to Firefox on our probes, but we are still loving it!
Latency & bandwidth : more realistic
As our test probes are located in datacenters, they are benefiting from much better connections than an average internet user. As a consequence, latency and bandwidth limitation are restricted by our software.
This policy has been totally rethought, basing it on Chrome native functionalities (regarding bandwidth) and system layers (latency).
Big changes have to be expected, especially for HTTPs websites whose latency impact was too ‘optimistic’ so far.
The bandwidth limitation will also be more realistic and its consequences will be fairer allocated between requests. That will mostly bring changes within your timeline/waterfall, as our tests showed not so significant impacts on overall measures.
The W3C CSS validator will fade
Standards are important, we won’t deny it. However, web technologies are moving so fast today that this validator became a source of disturbance for a lot of our users. As a consequence, we decided to remove it and prioritize the new features concerning HTTP/2 support.
Overall loading time, better detection of analyses ending
The full load time we compute is based on the detection of the end of network traffic. Our new probes will be more clever about it, ensuring that the onload event has been triggered before ending the test.
So far, there might be a slight delay between the analysis starting and the first request being sent. That’s exactly the same behaviour with an average web browser. But we have chosen to process the data to eliminate this delay (that was random) in order to make our reports easier to understand.
The timeline will change too, by displaying the browser internal redirections, previously hidden. FYI, these kind of redirection can occur when using the upgrade-unsecure-requests CSP directive we have already mentioned in our previous post concerning Mixed Content.
API minor update
If you use our API without activating visualMetrics (SpeedIndex, …), you won’t get any longer the screenshot taken during the analysis. We take the opportunity to remind you that our API documentation is available here, and that a changelog is also provided.
This update is probably one of the most significant evolution for Dareboost speed tests since our first release, even if, dislike a few other updates, most of the changes may not be noticed at the first sight!
The web of tomorrow is coming, and Dareboost will be there, by supporting all kind of new protocols and so bringing web performance to a whole new level.
Others upgrades are to come soon: a new timeline UI, smart alerts on monitoring, or again new best practices dedicated to HTTP/2. You’d better not forget to subscribe to our newsletter to do not miss any of these next updates!
As a conclusion, here is a summary of the main changes to expect on 19th September:
- HTTP/2, Websockets, Quic & Brotli support
- HTTP/2 related tips in the Dareboost reports
- Firefox removed. Chrome updated to its last version
- Improved latency & bandwidth management
- W3C CSS validator removal
- Overall loading time: onload as a mini. limit
- Internal redirects displayed within the timeline
- API minor update