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

As AI Scales Across Enterprises, Breaking Points Emerge

Rapid AI adoption and the unique ways AI workloads operate is redefining the scope and structure of what these teams must deliver. This shift is forcing organizations to rethink how they manage scale, automation, and control, according to The State of SRE and Platform Engineering 2026, a new report from Dynatrace ...

Preparing Network Infrastructure for AI Starts with the Basics

AI is usually talked about as a software tool, but it also depends heavily on the network behind it. Whether a company is using AI for chatbots, automation, monitoring, analytics, or employee support, all of that information has to move across the network in a reliable and secure way. That means AI is not just an application decision. It is also an infrastructure decision. Before organizations rush into AI, they should ask a simple question: Is our network ready to support it? ...

Agentic Operations Begin with Governed Middleware Access

Enterprise AI often lacks governed access to where business processes actually execute. Without that access, AI agents may be able to reason, but they cannot operate reliably across enterprise workflows. For AI agents to effectively carry out workflows, they will require integration-layer context and controls. Organizations can implement these prerequisites by providing AI with managed access to the middleware layer ...

The Network Data Problem Slowing Down Enterprise AIOps

Enterprise networks rarely behave the same way for very long. A routing adjustment in one region may unexpectedly alter application performance in another. A cloud migration may introduce hidden dependencies that go unnoticed until an outage occurs. All the while, the network is managed by several different teams, each of whom use different tool sets — and as a result, have different views of the network ... There’s usually an engineer who remembers why traffic fails over a certain way between sites, or which transparent firewall was added where. The problem is that human memory cannot scale alongside enterprise-scale networks ...

The Governance Gap Behind AI's Infrastructure Problem

Ask an infrastructure team how confident they are in their ability to govern AI, and most will tell you they've got it handled. A recent survey of 406 IT decision-makers and platform engineering leaders found 86% expressing exactly that confidence. Ask the same group whether they have a formal written AI governance policy, and the number drops to 30%, according to Spacelift's Infrastructure Automation Report ...

MEAN TIME TO INSIGHT Podcast - Episode 27: Observability Unification

In MEAN TIME TO INSIGHT Episode 27, Shamus McGillicuddy, EMA VP of Research, Network Infrastructure and Operations, and Parker Hathcock, EMA Research Director covering IT Service/Operations (ServiceOps), discuss observability unification in modern IT operations ... 

5 Reasons Traditional VPNs Struggle in a Cloud-First World

Virtual Private Networks became a cornerstone of enterprise security at a time when corporate infrastructure looked very different from today ... For years, this model worked well. But the architecture behind VPNs assumed a centralized corporate environment—one where the network itself was the hub of activity. In a cloud — first world, that assumption no longer holds ...

What 1.8 Million Outages Say About Who Is Really On Call in August

Website outages get resolved just as fast in August as they do in November. I went looking for the opposite: the summer slowdown everyone assumes is there once the people who fix things are away. It isn't in the data we collected, covering 1.8 million confirmed outages across tens of thousands of websites ...

Why Enterprises Are So Unhappy with Their IT Infrastructure

This year, many of the cloud infrastructure contracts signed in the early days of the AI boom will come up for renewal. As the year goes on, I anticipate we'll see a significant amount of cloud vendor swapouts and multi-cloud adoption, and the reason isn't just GPU depreciation. It's because they're tired of their current cloud providers ...

Agentic AI Just Became Your Newest Production Dependency. Are You Tracking It Like One?

There's a moment the many observability teams have experienced days into bringing a new service into production: you realize that the vendor's claims of "intelligent" behavior included a large serving of hype. Their dashboards look nice until they don't, the failure modes are a black box, and no one on the team can confidently explain why the system did what it did at 2 am. Agentic AI is about to force every Ops team to relive that moment at web-scale until they start treating these systems as the dependencies they actually are ...

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

As AI Scales Across Enterprises, Breaking Points Emerge

Rapid AI adoption and the unique ways AI workloads operate is redefining the scope and structure of what these teams must deliver. This shift is forcing organizations to rethink how they manage scale, automation, and control, according to The State of SRE and Platform Engineering 2026, a new report from Dynatrace ...

Preparing Network Infrastructure for AI Starts with the Basics

AI is usually talked about as a software tool, but it also depends heavily on the network behind it. Whether a company is using AI for chatbots, automation, monitoring, analytics, or employee support, all of that information has to move across the network in a reliable and secure way. That means AI is not just an application decision. It is also an infrastructure decision. Before organizations rush into AI, they should ask a simple question: Is our network ready to support it? ...

Agentic Operations Begin with Governed Middleware Access

Enterprise AI often lacks governed access to where business processes actually execute. Without that access, AI agents may be able to reason, but they cannot operate reliably across enterprise workflows. For AI agents to effectively carry out workflows, they will require integration-layer context and controls. Organizations can implement these prerequisites by providing AI with managed access to the middleware layer ...

The Network Data Problem Slowing Down Enterprise AIOps

Enterprise networks rarely behave the same way for very long. A routing adjustment in one region may unexpectedly alter application performance in another. A cloud migration may introduce hidden dependencies that go unnoticed until an outage occurs. All the while, the network is managed by several different teams, each of whom use different tool sets — and as a result, have different views of the network ... There’s usually an engineer who remembers why traffic fails over a certain way between sites, or which transparent firewall was added where. The problem is that human memory cannot scale alongside enterprise-scale networks ...

The Governance Gap Behind AI's Infrastructure Problem

Ask an infrastructure team how confident they are in their ability to govern AI, and most will tell you they've got it handled. A recent survey of 406 IT decision-makers and platform engineering leaders found 86% expressing exactly that confidence. Ask the same group whether they have a formal written AI governance policy, and the number drops to 30%, according to Spacelift's Infrastructure Automation Report ...

MEAN TIME TO INSIGHT Podcast - Episode 27: Observability Unification

In MEAN TIME TO INSIGHT Episode 27, Shamus McGillicuddy, EMA VP of Research, Network Infrastructure and Operations, and Parker Hathcock, EMA Research Director covering IT Service/Operations (ServiceOps), discuss observability unification in modern IT operations ... 

5 Reasons Traditional VPNs Struggle in a Cloud-First World

Virtual Private Networks became a cornerstone of enterprise security at a time when corporate infrastructure looked very different from today ... For years, this model worked well. But the architecture behind VPNs assumed a centralized corporate environment—one where the network itself was the hub of activity. In a cloud — first world, that assumption no longer holds ...

What 1.8 Million Outages Say About Who Is Really On Call in August

Website outages get resolved just as fast in August as they do in November. I went looking for the opposite: the summer slowdown everyone assumes is there once the people who fix things are away. It isn't in the data we collected, covering 1.8 million confirmed outages across tens of thousands of websites ...

Why Enterprises Are So Unhappy with Their IT Infrastructure

This year, many of the cloud infrastructure contracts signed in the early days of the AI boom will come up for renewal. As the year goes on, I anticipate we'll see a significant amount of cloud vendor swapouts and multi-cloud adoption, and the reason isn't just GPU depreciation. It's because they're tired of their current cloud providers ...

Agentic AI Just Became Your Newest Production Dependency. Are You Tracking It Like One?

There's a moment the many observability teams have experienced days into bringing a new service into production: you realize that the vendor's claims of "intelligent" behavior included a large serving of hype. Their dashboards look nice until they don't, the failure modes are a black box, and no one on the team can confidently explain why the system did what it did at 2 am. Agentic AI is about to force every Ops team to relive that moment at web-scale until they start treating these systems as the dependencies they actually are ...