The New Internet: What You Need to Know About HTTP/2

Kent Alstad

Since HTTP 1.1 was introduced 17 years ago, the Internet has evolved. This evolution introduced many changes, among them the development and delivery of rich content to users. These improvements enhanced the online experience, but did come at a cost, and the currency was performance – performance challenges that HTTP 1.1 was never designed to handle.

In February 2015 the Internet Engineering Task Force (IETF), who develops and promotes voluntary Internet standards, released a new HTTP/2 version to cope with those challenges and to adapt to the evolution that internet content has undergone.

Here's what you need to know about the challenges HTTP 1.1 faced and the improvements that HTTP/2 has introduced:

HTTP 1.1 Challenge: HTTP 1.1 allowed the client to send only one object request per TCP connection at a time. Request for the next object could only be sent after the first request received the complete reply from the server.

HTTP/2 Improvement: HTTP/2 enables transaction multiplexing – so that the browser can send any number of requests and receive the responses interleaved and out of order. As a result, the use of the TCP connection between the browser and the server is much more efficient, the wait between subsequent requests and replies is eliminated and this all leads to faster page load times.

HTTP 1.1 Challenge: When visiting most webpages, the browser is requested to provide a lot of information about the session, such as transaction info (i.e. encoding used, cache control), user/server identification, cookies, etc. This information has to be provided in the HTTP header with each HTTP transaction. This can add up to a lot of data, adding more delay to the page download time.

HTTP/2 Improvement: HTTP/2 introduces a new symmetrical header compression capability, where both the client and the server use an advanced header compression algorithm to reduce the header's payload. In addition, with HTTP/2, it's enough to send the full header only once per page, and not per transaction, reducing even further the uplink payload from the client to the server. The result again is faster webpage download time.

HTTP 1.1 Challenge: With HTTP 1.1, communication could only be initiated by the client, which meant that the server could only push resources to the client, after the client has asked for them.

HTTP/2 Improvement: With HTTP/2 the server can also initiate resource push to the client, even before the client knows they will need those resources. This bi-directional communication can reduce the number of "Get" transactions, and use the available bandwidth between the server and the client much more efficiently, leading again to faster web application response times.

Why Upgrade to HTTP/2?

HTTP/2 is an important upgrade that can provide performance improvements for your web applications. It can reduce the amount of bandwidth required to support the same amount of users on your site through enabling better header compression and fewer requests. This means that web applications can have faster response times and serve your users better.

Nearly 60% of leading web browsers (including Chrome, Firefox, Internet Explorer, Safari, Opera and others) already natively support HTTP/2 – so your audience is ready for it!

Is HTTP/2 Right for Any Web Application?

While the IETF doesn't mandate encrypted web communication for HTTP/2, allowing clear text (HTTP based), communication as well, all browsers' implementation of HTTP/2 require a secured (HTTPS) connection.

This means that if a site doesn't support HTTPS URLs, or can't be upgraded to HTTPS, it can't use the new protocol. In many cases, even if the site can use encrypted HTTPS communication, it may have some severe performance penalties, having to encrypt all communication to/from the server. So only sites that have a good infrastructure that can efficiently handle HTTPS communication will be able to de-facto benefit from the performance boost HTTP/2 has to offer.

Another challenge that exists with HTTP/2 is that, unlike the majority of browsers that already have mature support for HTTP/2, many web server platforms don't offer stable and mature support for the new protocol. The implementations of HTTP/2 support also often still suffer from unexpected behavior, partially due to the lack of a testing tool that supports HTTP/2 protocol analysis.

Moreover, one of the capabilities that HTTP/2 offers in order to improve performance is server push – where the server pushes resources to the client, before the client ask for them. To leverage this capability the server needs the ability to determine which resources to push, to make the web transaction faster. Understanding which objects to push before the user asks for them, ensuring those objects don't already exist in the browsers' cache (otherwise – it will make the transaction slower not faster), is a capability no web servers natively have today.

These limitations may cause some site owners to delay their adoption of HTTP/2, but there are solutions that can help.

How Do I Accelerate HTTP/2 Adoption For My Web Applications?

One way to accelerate adoption is by making new use of your application delivery controller (ADC). Some ADCs provide an embedded functionality of HTTP/2 gateway, enabling protocol translation from HTTP/2 on the client side to HTTP 1.1 on the server side, and vice versa. Using such a solution, ensures the ADC vendor that its HTTP/2 gateway is fully debugged, operational and ready for production environments, thus eliminating the risk of deploying immature code in the web server platform.

While this type of deployment can leverage some of the new HTTP/2 capabilities, the server push functionality still requires application-specific logic, to determine which objects the server can push to clients to accelerate page load time (i.e. not push client objects that are already in their cache).

The best way to maximize the acceleration potential that HTTP/2 can provide is to incorporate web performance optimization (WPO) technology. Some WPO engines already have the ability to anticipate which resources the user will need that aren't yet in their cache or which pages the user is likely to visit next. These types of WPO engines leverage the HTTP/2 server push function to push those resources to the user, even before the user asks for them.

The combination of HTTP/2 with WPO engines can deliver significant performance acceleration to web applications and this can make the upgrade investment worthwhile.

Kent Alstad is VP of Acceleration at Radware.

Related Links

Hot Topics

The Latest

Keys to Building a Partner Ecosystem That Scales

I've spent a lot of time in the channel, and one thing I keep coming back to is this: a partner program is only as good as what it looks like in the field. Many programs look great on paper, but when a partner is in front of a customer navigating a complex hybrid environment or trying to make the case for AI-powered observability, the gap between what a vendor promises and what it actually delivers becomes very clear, very fast ...

How AI Agents Are Reshaping DataOps for the Always-On Enterprise

Enterprises today operate in a real-time environment where uninterrupted access to trusted data has become a baseline expectation for users, applications and automated systems. Traditional DataOps models, built on manual effort and human triage, cannot keep pace with this always active demand. AI agents are emerging as the operational backbone, ensuring consistent data availability, reinforcing trustworthiness and enabling a level of scale that manual processes cannot achieve ...

AI Deepfakes: Rethinking Trust in the Workplace

For decades, trust in the digital workplace rested on familiar signals. We trusted faces on video calls, voices on the phone, and emails that appeared to come from people we knew. These cues felt human and intuitive. They anchored how decisions were made, approvals were granted, and access was authorized. AI-powered deepfakes have quietly broken that model ...

Nine in Ten Enterprises Plan Cloud Data Repatriation amid Rising Cloud Costs and Data Sovereignty Mandates

Cloud migration was supposed to be a one-way door. For most enterprises, it turns out it isn't. Cloud data repatriation is a real and growing trend. A new survey ... finds that 89% of organizations plan to expand their on-premises infrastructure footprint over the next two years — and 75% have already moved at least some workloads back from public cloud in the past 24 months. The findings point to a broad rethinking of where data belongs ...

Why ITOps Need Right-Sized AI, Not Bigger Models

Over the past few years, large language models (LLMs) have revolutionized the software industry. Given their ability to excel at multi-step reasoning, LLMs have helped enterprises streamline workflows and adapt to the unknown. However, employing such models comes with sky-high costs, latency issues, and limited flexibility. In the realm of IT operations, it is generally wiser to employ smaller, domain-specific models instead ...

The End of Reactive DevOps: AI-Driven Observability for Zero-Defect Digital Systems

For years, DevOps teams operated under a simple assumption: collect enough telemetry, and you can find and fix any problem. That assumption is breaking down. Modern enterprises now operate across microservices, hybrid cloud environments, APIs, Kubernetes, and highly automated delivery pipelines. Releases happen continuously, dependencies shift constantly, and failures spread faster than teams can diagnose them ...

5 Takeaways from the Observability Forecast for Media and Entertainment

New Relic surveyed IT and engineering leaders from the media and entertainment (M&E) sector to understand what's working — and where challenges persist with their observability practices. The findings reveal how M&E organizations are navigating rising platform complexity, audience expectations, and AI-driven change. Below are five takeaways that stand out ...

Why Moving Off the Cloud Is the Easy Part and What Comes Next Is Where Things Get Hard

Let me start with something I've seen play out more times than I can count. A team hits a wall with the cloud. Costs creep up, then spike. Performance starts to feel inconsistent. Someone in finance asks a simple question like "why did this double?" and nobody has a clean answer ... Maybe this isn't the right place for everything. That realization feels like a breakthrough, like you've identified the problem. In reality, you've just identified the starting line ...

MEAN TIME TO INSIGHT Podcast - Episode 24: Network Observability Tool Sprawl

In MEAN TIME TO INSIGHT Episode 24, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network observability tool sprawl ... 

Capacity Isn't a Guess: Observability-Driven Sizing for On-Prem Databases

In cloud-native systems, scaling is often as simple as moving a slider. For on-premise databases, the stakes are different. Over-provisioning hardware is expensive. Under-provisioning leads to performance bottlenecks that are difficult to fix once the equipment is in the rack ...

The New Internet: What You Need to Know About HTTP/2

Kent Alstad

Since HTTP 1.1 was introduced 17 years ago, the Internet has evolved. This evolution introduced many changes, among them the development and delivery of rich content to users. These improvements enhanced the online experience, but did come at a cost, and the currency was performance – performance challenges that HTTP 1.1 was never designed to handle.

In February 2015 the Internet Engineering Task Force (IETF), who develops and promotes voluntary Internet standards, released a new HTTP/2 version to cope with those challenges and to adapt to the evolution that internet content has undergone.

Here's what you need to know about the challenges HTTP 1.1 faced and the improvements that HTTP/2 has introduced:

HTTP 1.1 Challenge: HTTP 1.1 allowed the client to send only one object request per TCP connection at a time. Request for the next object could only be sent after the first request received the complete reply from the server.

HTTP/2 Improvement: HTTP/2 enables transaction multiplexing – so that the browser can send any number of requests and receive the responses interleaved and out of order. As a result, the use of the TCP connection between the browser and the server is much more efficient, the wait between subsequent requests and replies is eliminated and this all leads to faster page load times.

HTTP 1.1 Challenge: When visiting most webpages, the browser is requested to provide a lot of information about the session, such as transaction info (i.e. encoding used, cache control), user/server identification, cookies, etc. This information has to be provided in the HTTP header with each HTTP transaction. This can add up to a lot of data, adding more delay to the page download time.

HTTP/2 Improvement: HTTP/2 introduces a new symmetrical header compression capability, where both the client and the server use an advanced header compression algorithm to reduce the header's payload. In addition, with HTTP/2, it's enough to send the full header only once per page, and not per transaction, reducing even further the uplink payload from the client to the server. The result again is faster webpage download time.

HTTP 1.1 Challenge: With HTTP 1.1, communication could only be initiated by the client, which meant that the server could only push resources to the client, after the client has asked for them.

HTTP/2 Improvement: With HTTP/2 the server can also initiate resource push to the client, even before the client knows they will need those resources. This bi-directional communication can reduce the number of "Get" transactions, and use the available bandwidth between the server and the client much more efficiently, leading again to faster web application response times.

Why Upgrade to HTTP/2?

HTTP/2 is an important upgrade that can provide performance improvements for your web applications. It can reduce the amount of bandwidth required to support the same amount of users on your site through enabling better header compression and fewer requests. This means that web applications can have faster response times and serve your users better.

Nearly 60% of leading web browsers (including Chrome, Firefox, Internet Explorer, Safari, Opera and others) already natively support HTTP/2 – so your audience is ready for it!

Is HTTP/2 Right for Any Web Application?

While the IETF doesn't mandate encrypted web communication for HTTP/2, allowing clear text (HTTP based), communication as well, all browsers' implementation of HTTP/2 require a secured (HTTPS) connection.

This means that if a site doesn't support HTTPS URLs, or can't be upgraded to HTTPS, it can't use the new protocol. In many cases, even if the site can use encrypted HTTPS communication, it may have some severe performance penalties, having to encrypt all communication to/from the server. So only sites that have a good infrastructure that can efficiently handle HTTPS communication will be able to de-facto benefit from the performance boost HTTP/2 has to offer.

Another challenge that exists with HTTP/2 is that, unlike the majority of browsers that already have mature support for HTTP/2, many web server platforms don't offer stable and mature support for the new protocol. The implementations of HTTP/2 support also often still suffer from unexpected behavior, partially due to the lack of a testing tool that supports HTTP/2 protocol analysis.

Moreover, one of the capabilities that HTTP/2 offers in order to improve performance is server push – where the server pushes resources to the client, before the client ask for them. To leverage this capability the server needs the ability to determine which resources to push, to make the web transaction faster. Understanding which objects to push before the user asks for them, ensuring those objects don't already exist in the browsers' cache (otherwise – it will make the transaction slower not faster), is a capability no web servers natively have today.

These limitations may cause some site owners to delay their adoption of HTTP/2, but there are solutions that can help.

How Do I Accelerate HTTP/2 Adoption For My Web Applications?

One way to accelerate adoption is by making new use of your application delivery controller (ADC). Some ADCs provide an embedded functionality of HTTP/2 gateway, enabling protocol translation from HTTP/2 on the client side to HTTP 1.1 on the server side, and vice versa. Using such a solution, ensures the ADC vendor that its HTTP/2 gateway is fully debugged, operational and ready for production environments, thus eliminating the risk of deploying immature code in the web server platform.

While this type of deployment can leverage some of the new HTTP/2 capabilities, the server push functionality still requires application-specific logic, to determine which objects the server can push to clients to accelerate page load time (i.e. not push client objects that are already in their cache).

The best way to maximize the acceleration potential that HTTP/2 can provide is to incorporate web performance optimization (WPO) technology. Some WPO engines already have the ability to anticipate which resources the user will need that aren't yet in their cache or which pages the user is likely to visit next. These types of WPO engines leverage the HTTP/2 server push function to push those resources to the user, even before the user asks for them.

The combination of HTTP/2 with WPO engines can deliver significant performance acceleration to web applications and this can make the upgrade investment worthwhile.

Kent Alstad is VP of Acceleration at Radware.

Related Links

Hot Topics

The Latest

Keys to Building a Partner Ecosystem That Scales

I've spent a lot of time in the channel, and one thing I keep coming back to is this: a partner program is only as good as what it looks like in the field. Many programs look great on paper, but when a partner is in front of a customer navigating a complex hybrid environment or trying to make the case for AI-powered observability, the gap between what a vendor promises and what it actually delivers becomes very clear, very fast ...

How AI Agents Are Reshaping DataOps for the Always-On Enterprise

Enterprises today operate in a real-time environment where uninterrupted access to trusted data has become a baseline expectation for users, applications and automated systems. Traditional DataOps models, built on manual effort and human triage, cannot keep pace with this always active demand. AI agents are emerging as the operational backbone, ensuring consistent data availability, reinforcing trustworthiness and enabling a level of scale that manual processes cannot achieve ...

AI Deepfakes: Rethinking Trust in the Workplace

For decades, trust in the digital workplace rested on familiar signals. We trusted faces on video calls, voices on the phone, and emails that appeared to come from people we knew. These cues felt human and intuitive. They anchored how decisions were made, approvals were granted, and access was authorized. AI-powered deepfakes have quietly broken that model ...

Nine in Ten Enterprises Plan Cloud Data Repatriation amid Rising Cloud Costs and Data Sovereignty Mandates

Cloud migration was supposed to be a one-way door. For most enterprises, it turns out it isn't. Cloud data repatriation is a real and growing trend. A new survey ... finds that 89% of organizations plan to expand their on-premises infrastructure footprint over the next two years — and 75% have already moved at least some workloads back from public cloud in the past 24 months. The findings point to a broad rethinking of where data belongs ...

Why ITOps Need Right-Sized AI, Not Bigger Models

Over the past few years, large language models (LLMs) have revolutionized the software industry. Given their ability to excel at multi-step reasoning, LLMs have helped enterprises streamline workflows and adapt to the unknown. However, employing such models comes with sky-high costs, latency issues, and limited flexibility. In the realm of IT operations, it is generally wiser to employ smaller, domain-specific models instead ...

The End of Reactive DevOps: AI-Driven Observability for Zero-Defect Digital Systems

For years, DevOps teams operated under a simple assumption: collect enough telemetry, and you can find and fix any problem. That assumption is breaking down. Modern enterprises now operate across microservices, hybrid cloud environments, APIs, Kubernetes, and highly automated delivery pipelines. Releases happen continuously, dependencies shift constantly, and failures spread faster than teams can diagnose them ...

5 Takeaways from the Observability Forecast for Media and Entertainment

New Relic surveyed IT and engineering leaders from the media and entertainment (M&E) sector to understand what's working — and where challenges persist with their observability practices. The findings reveal how M&E organizations are navigating rising platform complexity, audience expectations, and AI-driven change. Below are five takeaways that stand out ...

Why Moving Off the Cloud Is the Easy Part and What Comes Next Is Where Things Get Hard

Let me start with something I've seen play out more times than I can count. A team hits a wall with the cloud. Costs creep up, then spike. Performance starts to feel inconsistent. Someone in finance asks a simple question like "why did this double?" and nobody has a clean answer ... Maybe this isn't the right place for everything. That realization feels like a breakthrough, like you've identified the problem. In reality, you've just identified the starting line ...

MEAN TIME TO INSIGHT Podcast - Episode 24: Network Observability Tool Sprawl

In MEAN TIME TO INSIGHT Episode 24, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network observability tool sprawl ... 

Capacity Isn't a Guess: Observability-Driven Sizing for On-Prem Databases

In cloud-native systems, scaling is often as simple as moving a slider. For on-premise databases, the stakes are different. Over-provisioning hardware is expensive. Under-provisioning leads to performance bottlenecks that are difficult to fix once the equipment is in the rack ...