Approved this February by the Internet Engineering Task Force (IETF), HTTP/2 is the first major update to HTTP since 1999, when HTTP/1.1 was standardized. Designed with performance in mind, one of the biggest goals of HTTP/2 implementation is to decrease latency while maintaining a high-level compatibility with HTTP/1.1. Though not all testing activities will be impacted by the new protocol, it’s important for testers to be aware of any changes moving forward.
That being said, in this post we’d like to highlight some HTTP/2 changes, challenges and considerations as they relate to load and performance testing.
Because of its compatibility with HTTP/1.1, HTTP/2 will not change the way existing websites or applications function. In fact, not only will your application code and HTTP APIs continue to work properly, but it’s likely that your applications will also perform better and consume fewer client- and server-side resources. But what does this mean for performance testers?As we mentioned previously, the implementation of HTTP/2 will not affect all testing activities. For example, when it comes to automated software testing, the activity won’t be impacted until the solution supports HTTP/2. In other words, if the browser supports the new protocol there won’t be an issue.
From the moment a team begins to engage in protocol-based testing, however, HTTP/2 becomes a challenge. Testers will need a tool that records and supports the new protocol. Performance engineers will still have to give recommendations in terms of server configuration and architecture, which may be tricky unless there is a comprehensive understanding of each web layer (proxies, web server, caching server, load balancer, etc.) impacted by HTTP/2 implementation.
While we’ll have to wait for the first real benchmarks to have a clear understanding of the technical behavior of each module, new modules are currently in beta release—so now is the time to play around and learn how to modify the settings.
Keep in mind, although HTTP/2 is built to decrease latency in order to improve page load speed in web browsers, this protocol will not guarantee good performance. It is in no way an excuse to skip load and performance testing.
As HTTP/2 becomes more prevalent, one of the largest challenges testing teams will face is the doubling up of test cases. Moving forward, most systems will support both HTTP/1.1 and HTTP/2. For performance testers, this means the creation of extra scenarios. Testing teams will need to generate load from users with browsers that do not support HTTP/2 and from users whose browsers support the latest release. These tests will be more complex and will result in more work for load and performance testers. Teams will have to validate that their project’s web layers support the load of both protocols. Few companies will deploy HTTP gateways to avoid the extra management task associated with the use of both protocols, but in these cases, HTTP gateways will need to be tested to minimize latency.
Of course, HTTP/2 also comes with a cost. Companies will need to bring on high-level experts that can upgrade web servers, vendors will need to update their own equipment, and all of this will need to be tested. Load and performance testers will need to understand this new protocol and the modules of each vendor to properly configure the architecture. There will be a tricky, expensive learning curve. However, as the first engineers interact with HTTP/2, their knowledge and expertise may help lessen its severity.
Because so little is known about the widespread effects HTTP/2 may eventually have, there are still several considerations and questions floating about that, when addressed, may change the game for load and performance testers.
Timing is a huge concern. How long will it take before every browser supports the new protocol? Sources assert that HTTP/1.1 will be around for at least another decade, and most servers and clients will have to support both HTTP/1.1 and HTTP/2 standards. This means twice as many test cases resulting in a more time consuming, expensive, labor intensive testing process.
Before the testing process even begins, however, testers will need to determine an ideal response time with HTTP/2—but how will we measure the response time to download resources pushed by the server? Historically, we’ve measured it as the time between the client sending a request to the server and receiving the requested data. With HTTP/2, this logic won’t make sense anymore.
Regardless, at some point, new benchmarks and limits must be set in order to establish a consistent, industry-wide standard. Already, big Internet players like Microsoft and Twitter have implemented the protocol and they, along with other early adopters, will begin to shape and mold these standards.
HTTP/2: No Pain, No Gain
Though it may cause load and performance testing teams some grief in terms of cost and workload, HTTP/2 will ultimately make our applications faster, simpler and more robust by offering new opportunities to optimize apps and improve performance.
Moving forward, testers should work with app architects and developers to understand when their own application will support HTTP/2 – it will need to be tested. As browser support for HTTP/2 becomes more widespread, tester will also need to know which browsers have been optimized for the protocol in order to include those in their test plan.