Portent analyzed 100 million page views from 20 ecommerce sites, revealing that conversion rates drop significantly after 5 seconds of loading time. The study found that the ideal page load time is between 0-4 seconds.
You expect your website to bring you leads because:
You order content from experienced copywriters…
You place all necessary CTAs on the pages…
You care about structure…
You take professional photos for your blogs and product pages…
You've invested in backlinks…
You apply other effective marketing techniques from bestselling books…
But… nothing happens…
Your efforts and investments aren’t bringing the expected results. You don’t see traffic growth in GA4, your sales CRM is empty, your phone remains silent, and your sharks in the sales department are scrolling Instagram (probably not).
Why does that happen?
That happens, not because you hired the wrong people or you have a bad product (your product is the best on the market, right?)
And the marketing team is likely giving their best effort, especially with so many talented individuals around us…
Probably, it happens because you have issues with your website, I mean… technical issues. Because, even a tiny technical issue may break the camel's back…
Time is money, and in case we speak about technical SEO, time costs an enormous amount of money.
Even a few seconds lost in Page Speed may cost millions...
Need proof? Okay, let's see the cost of this “straw”. Let's see the cost of… 100ms!
Here are the latest studies on the matter:
A 100-millisecond delay hurt conversion rates by 7%.
We got a better ROI with a 100-millisecond improvement in load time.
100-millisecond in Extra Load Time cost us 1% Revenue.
Modern audiences don’t want to wait. This means that even if you have great content, if it takes too long to load… Sorry… you’re out.
At Digital Loop, we’re passionate about Technical SEO and Core Web Vitals (CWV) improvements. We create exceptional MarTech solutions that help our clients thrive.
*Just check out our website, see how fast it loads, and then come back to finish reading this article.
Tech SEO requires a comprehensive approach and a range of practical skills to distinguish what truly matters. Our team includes a dozen seasoned Tech SEOs, web developers, and MarTech consultants, which means we really know the Tech SEO field.
Why did I mention that? Today’s topic may be challenging for non-technical readers. That’s why I didn’t dive into technical details in this blog post but focused on explaining the importance of implementing modern approaches.
And in case you need Tech SEO support, just drop us a line.
In this blog post, I’ll briefly explain HTTP/1.1 and HTTP/2.0, and provide an overview of HTTP/3 protocols. You’ll see the differences in performance between the HTTP/1 and HTTP/2 protocols. Finally, I’ll show you a real-life use case illustrating the effects of implementing modern protocols on marketing KPIs.
Stick around, and let’s get started.
How did HTTP Appear? (Sneak Peek from the Stone Age to Nowadays)
Have you ever wondered how your favorite websites actually show up on your screen? It all started with something called HTTP, which stands for Hypertext Transfer Protocol.

HTTP (Hypertext Transfer Protocol) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems.
Picture this: back in the early days of the internet, computers needed a way to talk to each other so they could share information. HTTP was created to be the language computers use to communicate. It’s like the internet’s “Stone Age” because it was one of the first tools that made the web possible.
Brief Explanation of HTTP (Hypertext Transfer Protocol)
HTTP is like the mail carrier of the internet. When you type a web address into your browser, HTTP takes your request and delivers it to the website’s server.
Then, it picks up the website’s content (like text, images, and videos) and brings it back to you so you can see it on your screen. Without HTTP, you wouldn’t be able to surf the web, watch videos, or even read this article.

Why Compare HTTP/1 and HTTP/2?
You might be wondering, “If HTTP works fine, why should I care about different versions of it?” Well, just like phones, computers, and games have evolved, so has HTTP.
HTTP/1 was the original version that got everything started, and it was great for its time, but as websites became more complex and we started expecting faster speeds, HTTP/2 was introduced to keep up with our demands.
Overview of HTTP/1: History, Background, and Key Features
HTTP/1 was born in the early 1990s when the World Wide Web was just beginning to take shape. Back then, the internet was a much simpler place. There was mostly text, a few images, and not much else.
HTTP/1 was designed to handle these straightforward web pages, making it possible for people to access and share information globally.
Its development was led by Tim Berners-Lee, the father of the web, and quickly became the standard for how data was transferred over the internet.
Development of HTTP was initiated by Tim Berners-Lee at CERN in 1989 and summarized in a simple document describing the behavior of a client and a server using the first HTTP version, named 0.9. That version was subsequently developed, eventually becoming the public 1.0.
HTTP/1 works in a pretty straightforward way:
Step #1: When you want to visit a website, your browser sends a request to the server where the website is hosted.
Step #2: This request asks for the content of the site, like the text, images, and videos.
Step#3: The server then sends back a response, delivering the requested content to your browser, which then displays it for you.
This back-and-forth is called the request-response cycle, and it happens every time you load a new page.
As the web grew and websites became more complex, HTTP/1 started to show its limitations. One of the biggest issues is something called head-of-line blocking.
This happens when a request at the front of the line has to be processed before any others, causing delays.
Additionally, HTTP/1 often requires multiple connections to the server to load all the different parts of a web page, which can slow things down even more.
These issues make it hard for HTTP/1 to keep up with the demands of modern web applications.
As a result, developers and users started looking for better options, paving the way for newer protocols like HTTP/2 that could handle the modern web’s demands more effectively.
Introduction to HTTP/2: Performance, Key features
As the internet evolved and websites became more sophisticated, the need for a faster, more efficient way to communicate between browsers and servers became clear.
HTTP/2 wasn’t just thrown together overnight. It was carefully developed and standardized by the Internet Engineering Task Force (IETF), a group responsible for maintaining and improving internet protocols.
The process involved extensive research, testing, and input from the global tech community to ensure that HTTP/2 would be a robust and future-proof solution.
After years of work, HTTP/2 was officially published in 2015 as a major update to the original HTTP/1.
So, why does HTTP/2 work faster? What's the secret?
One of the biggest changes in HTTP/2 is the switch from a text-based protocol to a binary protocol.
In HTTP/1, the communication between your browser and the server was done using plain text, which was easy to read but not the most efficient.
HTTP/2, on the other hand, uses binary code, which is much faster for computers to process. This change alone makes data transfer quicker and more reliable.
What else was improved? Let's take a look…
Multiplexing: Multiple Requests Over a Single Connection
Remember how HTTP/1 often required multiple connections to load all the parts of a webpage? HTTP/2 fixes this with a feature called multiplexing. Now, your browser can send multiple requests over a single connection at the same time.
This means that different parts of a webpage can load simultaneously, reducing the waiting time and making your browsing experience much smoother.
Header Compression (HPACK) and Its Benefits
In HTTP/1, the headers (which contain information like cookies and content types) were sent as plain text, which could add up and slow things down, especially on complex websites.
HTTP/2 introduced header compression using a method called HPACK. This compresses the headers, reducing the amount of data that needs to be sent back and forth.
The result?
Faster page loads and a more efficient use of bandwidth.
Server Push: Preemptively Sending Resources
HTTP/2 also brought in a smart feature called server push. Instead of waiting for your browser to request every single element of a webpage, the server can preemptively send resources it knows you’ll need.
For example, if you visit a webpage, the server can automatically send images and stylesheets it knows are required, even before your browser asks for them. This can significantly speed up how quickly a page loads.
Comparing HTTP/1 and HTTP/2
Now that we’ve explored what makes HTTP/1 and HTTP/2 tick, it’s time to put them side by side and see how they really compare.
Feature | HTTP/1.1 | HTTP/2 |
---|---|---|
Performance Impact | Does not support multiplexing; each request requires a new TCP connection or blocking within connection. | Supports multiplexing; multiple requests can share a single connection without blocking. Reduces latency as requests can be sent concurrently over one connection. |
Header Compression | No header compression; headers are sent as plain text, leading to redundancy. | Uses HPACK header compression to reduce redundancy, saving bandwidth. Improves bandwidth efficiency and reduces page load times. |
Server Push | Does not support server push. | Supports server push; the server can send resources before the client requests them. Reduces load times by preloading resources likely needed by the client. |
Connection Reuse | Limited connection reuse; requires additional TCP connections for parallel requests. | Enhanced connection reuse; single TCP connection can handle multiple concurrent requests. Minimizes TCP connection overhead, leading to faster load times. |
Request Prioritization | No request prioritization; requests are handled in the order they are received. | Supports request prioritization, allowing important requests to be handled faster. Allows essential resources to load first, improving perceived load times. |
Binary Protocol | Uses a text-based protocol, making it less efficient in parsing and data transmission. | Uses a binary protocol, which is faster and more efficient for transmission and parsing. Binary protocol increases speed by reducing transmission size and parsing complexity. |
Security (TLS requirement) | Does not require TLS but often used with HTTPS. | Typically requires TLS encryption, adding an extra layer of security. Enhanced security boosts user trust and data protection, improving overall reliability. |
To help our non-technical readers better understand the difference between HTTP/1.1 and HTTP/2, I found an example that clearly illustrates the results of HTTP/1.1 compared to HTTP/2.
In the following simulation, a “main” document(big square) was fetched. This could represent the index of a website.
After retrieving the “main” document, the simulator fetches 99 linked items, which could include images, scripts, or other documents.
100 requests via HTTP/1.1

HTTP/1.1 is limited to 6 concurrent requests. The big box is the initial index or collection.
100 parallel requests via HTTP/2

HTTP/2 can fire off many parallel requests over 1 TCP connection
Source: https://evertpot.com/h2-parallelism/
When HTTP/1 Might Still Be Preferred
While HTTP/2 is generally better, there are still some situations where HTTP/1 might be preferred.
For example, if you’re dealing with legacy systems (older software or hardware that hasn’t been updated in years) they might only support HTTP/1.
Another case involves small websites. For small websites with few assets (e.g., single-page or static sites with limited images, scripts, or styles), the benefits of HTTP/2 (like multiplexing and server push) may not offer a significant advantage. HTTP/1.1 can handle these types of sites without much difference in performance.
SEO Case Study: How We Increased Website Speed by Switching from HTTP/1.1 to HTTP/2.0
So, I suppose you’re curious about how implementing HTTP/2 can impact marketing KPIs and SEO. To illustrate this, I’ve prepared a case study for you.
This case study explores how the Digital Loop team collaborated with a leading e-commerce company in the health industry to tackle the specific challenge of improving website performance and load speed.
Our client’s primary objective was to enhance page load speeds across their network of e-commerce websites. Although their sites already operated at relatively high speeds, they recognized the importance of further reducing load times to optimize user experience.
The Digital Loop team began by measuring the client’s current page load times, especially focusing on the time required to load static files such as images and CSS.
Initial testing under standard conditions showed an average load time of 2.013 seconds on landing pages using HTTP/1.1. However, tests under simulated slower 3G network conditions revealed significant delays, with load times exceeding 15 seconds in some cases.
This discrepancy underscored HTTP/1.1’s limitations, particularly for e-commerce sites with high static content loads.
In collaboration with the internal team, we set up processes and pipelines, developed a QA approach, and implemented HTTP/2 for the website network step-by-step.
Immediate Results
- Improved Page Views per Session: The HTTP/2 implementation led to a 5.6% increase in page views per session for mobile users. This metric underscored enhanced user engagement, with visitors browsing more pages during each session.
- Reduced Bounce Rate: A notable decrease of approximately 2.68% in bounce rate was observed following the optimizations, lowering the overall bounce rate below 20% from a prior level of 21.17%. Faster load times kept users engaged, reducing the likelihood of immediate exits and improving the chance of conversion.
- Conversion Rate Improvements (Client Reported): Although not quantitatively verified in this case study, the client observed a positive trend in conversion rates, attributing part of this improvement to faster load times achieved with HTTP/2.
*Faster speeds can directly influence purchase decisions, especially in e-commerce, where a seamless experience is critical.
By transitioning from HTTP/1.1 to HTTP/2, the project focused on addressing the limitations of HTTP/1.1 that slowed down static file loading and caused delays under constrained network conditions.
Read full case study here [link to case study]
HTTP/3 and Beyond: The future of HTTP
Of course, HTTP/2 has brought significant improvements to speed, security, and efficiency, but the story doesn’t end there. The future of HTTP is already taking shape with the development of new protocols like HTTP3, which promise to take web communication to the next level.
HTTP3 is the next big thing in web protocols, currently in the process of becoming widely adopted. One of the most significant changes in HTTP3 is the use of QUIC (Quick UDP Internet Connections), a Transport Layer Protocol that replaces TCP, the Transmission Control Protocol used by HTTP/1 and HTTP/2.
QUIC (Quick UDP Internet Connections) is a protocol Google has developed to improve the speed and reliability of web connections.
As we look toward HTTP3 and beyond, it’s clear that each new version of HTTP is part of a broader evolution, continually pushing the boundaries of what’s possible on the web.
Summing up…
I hope this content was clear and accessible, as it can be challenging to explain technical concepts using non-technical language.
Let's sum up what we've learned from today's blog post:
- HTTP/1 laid the foundation for the web and served us well for many years. However, as the web became more complex and users demanded faster, more secure browsing experiences, the limitations of HTTP/1 became apparent.
- HTTP/2 was developed to address these challenges, introducing significant improvements such as multiplexing, header compression, and server push.
- In our comparison, we saw how HTTP/2 outperforms HTTP/1 in nearly every aspect, from speed to security. While HTTP/1 might still be suitable for certain legacy systems, HTTP/2 is clearly the better choice for modern websites and web applications.
- From the case study, you've learned that improved performance, achievable through modern protocols like HTTP/2 or HTTP/3, directly impacts marketing KPIs such as bounce rates, page views, and conversions.
If you’re still using HTTP/1, now is the time to seriously consider upgrading to HTTP/2. The benefits are clear: faster loading times, better security, and a more efficient use of resources.