# HTTP's Brief History

It's worth going back to the flannel-soaked 1990s if we're going to talk about the transition from HTTP/1.1 to HTTP/2. HTTP was formerly a basic protocol for a simple task: efficiently transferring documents from a web server to your machine. This was due to the fact that the web was simple, consisting of documents and a scattering of images that were easy to fling around on the hardware of the time.

In the early 1990s, HTTP (Hypertext Movement Protocol) became widely used to simplify the transfer of "hypertext" documents. These were simple papers with largely text and a few graphics that were formatted and linked to other hypertext documents using HTML. The 1.0 specification was adopted in 1996. For the needs of the mid-90s web, this version was beautiful and easy — create a connection, download a file, close the connection, and repeat for each file required to display a web page.

However, by the end of the 1990s, things had begun to shift. The internet was swiftly growing into something more than a glorified global Choose Your Own Adventure with linked pages to click through. People began to buy and sell items, necessitating the need for protection. People wanted to use their browsers to watch films, edit documents, and send silly animated greeting cards in addition to photographs. For these new use-cases, the method of one connection, one file was quite slow.

As a result, in 1999, the World Wide Web Consortium (W3C) changed the HTTP specification to version 1.1. This version was a stopgap, adding capabilities to the 1.0 standard to improve the speed and efficiency of web servers that powered this new "hypermedia" version of the web.

After that, the innovation came to a halt. As you're probably aware, the web changed a lot more between 1999 and 2015 than it did between 1996 and 1999, but we lived with the HTTP/1.1 protocol for those 16 years, cramming more and more new apps within the old specification.

# Transitioning from HTTP/1.1 to HTTP/2

The breaking point in HTTP/1.1 was achieved well before HTTP/2 was released in 2015. Since the early 2010s, Google has been developing SPDY (pronounced "speedy"), their own HTTP/1.1 replacement. This protocol made use of the existing HTTP/1.1 infrastructure, but changed the way requests were routed via it. SPDY employed multiplexing to download numerous resources quickly over a single connection, and a translation layer allowed it to be "back-ported" to existing applications.

GMail and Google Apps, for example, were becoming increasingly complicated web-based apps that worked more like desktop applications than webpages, so it makes reasonable that Google would take the lead on this. In fact, the SPDY protocol was so well-designed that it was utilised as the foundation for HTTP/2 by the W3C.

As a result, the HTTP/2 specification based on SPDY was officially ratified by the W3C in 2015, and all major browsers began to implement the protocol.

# What Makes HTTP/2 Faster Than HTTP/1.1?

In the same way that "videotaping" something with your smartphone is archaic today, the concept of "webpages" is. A constant two-way stream of data is a key aspect of the functionality of modern websites, which behave more like applications.

Every keystroke, for example, sends data to Google's servers when you type something in a Google Doc, as I am typing this post right now. Google's servers process the information and deliver updates to your browser with the text you've written, as well as other useful information like suggestions, the document's most recent change status, and more. Each keypress on HTTP/1.1 would open a new connection to the server, sending each character you typed across the wire. Then, to add the character to the screen you're looking at, your browser would have to constantly "ping" Google's server to see if the document's status had changed. That's a lot of relationships to make, and each one takes time.

It's effectively a continual two-way stream over a single connection with HTTP/2. Google's server is constantly listening for data from your browser, and your browser is constantly listening for data from Google. It's no longer necessary to submit data, wait for a response, update the screen, send more data, wait for a response, and so on. Rather, everything takes place in real time. A web "document," such as a Google Doc, can refresh itself so frequently that it appears to be a native application on your computer.

The following are the major differences between HTTP1 and HTTP2:

HTTP2 is binary rather than textual, and it is completely multiplexed rather than ordered and blocked.

As a result, HTTP2 can use just one connection for parallelism.

HTP2 reduces overhead by compressing headers.

HTTP2 allows servers to "push" responses into client caches in advance.

#Why Should You Make the Switch to HTTP/2?

Switching from HTTP/1.1 to HTTP/2 is one of the most popular and impactful suggestions we make while performing technical audits of websites. We can frequently increase a website's performance considerably for very little money or time.

Perhaps you don't have any dynamic elements in your company. Perhaps your pages are mostly static text and image creations, as they were in the early days of the internet. This is fantastic — HTTP/2 is incredibly low-hanging fruit in your scenario! Simply changing your hosting to use HTTP/2 will greatly increase the speed with which your material is sent to users, as all of your page's content will be delivered down the pipe on a single connection rather than numerous connections.

It's so critical that Google's algorithm is likely to use it as a pass/fail test – when we use Google's Lighthouse to evaluate a website, the tool doesn't even make tips to improve HTTP/1.1 delivery – it simply says to upgrade to HTTP/2.