What does HTTP/2 mean? If the webpage loads slowly, will switching to it make it faster? I used curl and F12 to cross-check

recently, I was browsing my little blog and casually pressed F12 to check out the Protocol column in the Network panel. Here's a little pitfall I'll mention first: the address bar doesn't show anything, and the webpage doesn't pop up "This website has been upgraded." Without looking at this panel, ordinary users can't tell whether they're connecting to version 1.1 or version 2. My site and GitHub both list h2, Baidu still uses HTTP/1.1, and just as I felt the urge of 'my site is finally behind,' a more real question popped up: How much faster can this thing actually make web pages go?

to clarify: HTTP/2 is about replacing the engine, not just opening a separate fast lane.

HTTP/2 is the second major version of the HTTP protocol. Compared to 1.1, it doesn't thicken the network cable or bring the server closer to me. The main change is "how to arrange requests within the same connection."

has a premise that many people don't ask, but it's very important: the HTTP/2 used in browsers is basically bound to HTTPS. If the website you visit still starts with http://, it's most likely still 1.1. Because when the browser and server shake hands, there's an ALPN step, and both sides negotiate like a code: "I support h2, do you support it?" Only after agreeing do you switch over. So when I later tested with curl, I always started with https. This isn't to show professionalism, but because in reality, HTTP/2 basically only appears under this condition.

Also, don't assume HTTP/2 is "ten times faster when opened." It's more like swapping a tricycle for a container of goods on the same road—each delivery time isn't much different. The more goods there are, the more traffic gets congested, and that's when the gap becomes clear.

HTTP/1.1: A domain name only has 6 lines

. The old protocol had a rule I didn't understand at first: browsers can usually open up to 6 TCP connections simultaneously for the same domain. When a web page becomes complex, dozens of requests for images, CSS, JS, and interfaces are queued. If the first six are full, the rest have to wait.

even more frustrating is the "frontline blockage." On the same TCP connection, the server returns data in order; if the first request gets stuck, no matter how early the response arrives, it can only wait in the buffer. When I wrote about the differences between TCP and UDP before I mentioned that TCP recognizes order, while HTTP/1.1 stuffs a bunch of requests into this order-recognizing pipe, inheriting all the drawbacks.

is why old websites love to play with 'Sprite Maps' and 'domain fragmentation,' splitting resources into multiple domains and allowing browsers to open more lines. To put it bluntly, this is trading bandwidth for waiting in line, which is quite frustrating. After HTTP/2 came out, these optimizations actually felt somewhat redundant.

HTTP/2: multiplexing, binary frame splitting, head compression

first trick, multiplexing . It allows dozens or even hundreds of streams running simultaneously on a TCP connection, each with a number. You reply to your image, I reply with my words—no one blocks the other. Losing a packet only affects the related stream, unlike 1.1 where the entire pipe gets blocked at once.

second move: binary frame splitting . 1.1 requests and responses are read line by line of text, while HTTP/2 splits the content into binary frames, making machine processing more direct. This change is invisible to ordinary users, but it helps reduce server pressure.

third move: head compression . I once grabbed a request header, and just the repetitive fields like User-Agent, Cookie, and Accept took up a large portion. HTTP/2 uses HPACK to create tables with duplicate headers, and the second time only provides an index number, so you don't have to write "What browser am I am" every time?

these three tricks sound like server-side optimization, but when applied to your own home, the most direct feeling is that pages with abundant resources can reduce the circulation of pages for a while.

I tested curl once, and the results were different from what I expected

I ran curl 7.88.1 on this machine, which includes nghttp2/1.52.0, so it can actively initiate HTTP/2. Just looking at the browser's H2 version, I couldn't give up, so I clicked it separately from the command line, and it matched exactly with the browser. First, let's see which version a single website negotiates to:

curl -s --http2 -o /dev/null -w '%{http_version}' https://www.shunot.com

output is 2. I went through several stations I frequented:

Baidu's result, I'm not surprised; their homepage is still stuck on version 1.1. This shows that HTTP/2 is not fully online; if the website is not open, it simply doesn't exist.

then I ran an even tougher test: sending 6 requests simultaneously to see how many TCP connections were created. In HTTP/2, 6 requests share 1 connection; With HTTP/1.1, it obediently opened 6 lines. In terms of total time, I measured 2.19 seconds versus 2.90 seconds. It's fast, but not as exaggerated as the "ding-first instant start."

I even compared it to my own blog: on a homepage with over twenty requests, on a computer HTTP/2 and 1.1 you can barely feel the difference, but when the signal is normal, the phone can be two or three hundred milliseconds faster, and you have to watch the meter to notice. So to be honest: when the network is good and resources are limited, the perceived improvement brought by HTTP/2 is limited. Its true value only becomes apparent when there are dozens of resources on a webpage or when mobile signal fluctuates, and issues like connection count and queue congestion become apparent.

situations where things really happen faster, and which situations are wasted even if you switch

The scenarios you can truly feel are just a few things: a page with many image interfaces, servers far away, and packet loss a bit higher. For example, watching videos, ten-minute slot is split into 64 , dozens of shard requests are squeezed into one connection, making HTTP/2 multiplexing more advantageous than 1.1.

changing is just as costly: the website has only three to five files, the server doesn't support H2, or your internet speed is only 10 Mbps. Another situation is browser cache is not active, and resources have to be redrawn every time, no matter how powerful the protocol is, it cannot prevent duplicate requests.

so don't treat HTTP/2 as a cure-all. It solves connection and scheduling issues, not bandwidth issues or server slowness.

how to check if your website and browser is HTTP/2

browser, I've already explained the method: F12, in the Network panel, right-click the table header and check the Protocol column. Showing h2 means HTTP/2, showing http/1.1 means the old protocol, and showing h3 means it has already moved to HTTP/3 and QUIC. If you haven't checked this column, first check F12 how to open the panel —you won't be embarrassed.

command line lookup is also simple:

curl -sI --http2 -o /dev/null -w '%{http_version}\n' https://www.shunot.comHTML122__ 
 Output 2 means you and the website have agreed on HTTP/2. For a more detailed look, click chrome://net-internals/#http2 in Chrome's address bar to see the browser's current H2 connection, but this page is quite messy; most users only need to check the Protocol column. 
 
When I showed my cousin this step, his first reaction was, what is Protocol? He couldn't remember the word. Actually, you don't need to memorize English; after opening the column, just recognize the words h2 and http/1.1. 
 if you run your own website, whether HTTP/2 can be enabled mainly depends on the server and certificate. Now, Nginx, Apache, and Caddy basically all support it, and there's rarely a need to tinker manually with the Baota panel. What really needs to be confirmed is that the port 443 certificate is working properly and the HTTP/2 switch isn't turned off. 
 Conclusion: Test first, then decide whether to tinker. I have laid this out in three steps, rather than immediately changing configurations: 
 


 first press F12 to check the protocol bar and confirm whether the site you visit often has H2. 
 
 sites with abundant web resources, try using an HTTP/2 browser to see if loading noticeably improves the process. 
 
 if your website isn't open yet, first check the certificate and server version; If it already shows H2, don't worry about it—your daily experience won't be ruined just because you change one more parameter. 

 day after I finished testing, I took a screenshot of the results and posted them in the group chat. Someone said I was bored. Actually, once you figure this out, and see people blaming 'web speed' entirely on a particular router, at least you won't go off track. Also, don't use Baidu's homepage 1.1 as a "technical weakness." Large sites often don't know how to support HTTP/2, but rather that the compatibility cost between old clients and large clusters is too high. That set of accounts is not within our discussion scope. 
 ultimately, HTTP/2 is worth knowing, but not worth mythologizing. For home broadband and regular web use, it's more like smartening the queue rules at intersections—the road is still the same, and the cars are the same.