HTTP 2. Is 2 Always Better Than 1?
Is two always better than one?
If we are talking about chins… then no! But, In the case of HTTP, then HTTP/2 is much better than HTTP/1.1
HTTP/2 was made available in 2015 and was the first new version of HTTP in nearly 20 years. With that release came a number of changes to keep up with a much more dynamic, media based, and interactive Internet. The main goal of HTTP/2 is to create a “lightweight” and speedy delivery of http requests and responses. This is achieved by reducing the number of requests/responses as well as the overall size of each. These improvements positively impact performance by requiring less bandwidth and resources to deliver content. Also, HTTP/2 can anticipate the data that the browser will request and deliver the response before an actual request is made. Let’s dig deeper…
Reduction in Number of Connections
Remember how browsers became more modern by supporting a higher number of connections because each http request (for example, an embedded image in a page) needed it’s own connection? HTTP/2 uses a multiplexing approach where multiple requests are served with a single connection. Fewer connections mean reduced load on both the servers and the clients. Win-win. Let’s say a page had 19 embedded requests. With HTTP/1, the simultaneous download rate was limited by the number of connections that the browser could support. Now, each connection can serve several requests, simultaneously.
Reduction in Header Size
Image compression has long been a wish for performance engineers to achieve faster load times. Now with HTTP/2, the headers are compressed. You might be thinking that headers are already small but think of the relative size of an API for a mobile application where often the header size exceeds the size of the request. Also, cookies and tokens are often stored in headers and can grow to be quite large. All of the content of the headers can be reduced using HTTP/2’s automatic compression.
Anticipates Your Needs
No HTTP/2 does not have a crystal ball or ESP. It cannot predict the future.
However, with HTTP/2 PUSH technology, certain content requests will be delivered to the browser cache before it has even been requested. Therefore, when the actual http request is made, content is delivered from cache and not from a long trip to the server. This type of PUSH behavior technology was introduced with AJAX but the difference here is that the content is made “ready” and not “used” until it is needed. This is also useful for updating or even expiring content within the browser cache, which has been a past struggle with web applications.
What’s It Mean For Performance Testing?
The good news for performance and load testers is that there isn’t a new technology to learn, the http status codes, headers, and methods are all the same and most existing commercial and open source load testing tools support the HTTP/2 protocol. Since HTTP/2 is now a binary protocol (not clear text) you need HTTP/s features in order to record/create/edit your load scripts and deserialize the binary content into clear text. You must either install the HTTP/2 plugin or enable the HTTP/2 feature or the load generators will default to HTTP 1.1. The load generators need to change their behaviors as well to mimic browsers, which support HTTP/2. This is the only way to load test and receive accurate response time metrics for pages.
Total Performance Consulting can help you get the most out of this transition to HTTP/2.
Contact us today and let’s chat.
