First of all let's verify if you are using HTTP/1.1 or HTTP/2.
Open your developer tools in Chrome or Firefox, add the protocol column and reload the page. you should see a number of images loaded from http1.akamai.com and a number from http2.akamai.com:
If you are not seeing HTTP/2 here then something is preventing HTTP/2 from being used (likely a proxy or anti-virus software) which might explain this. Though I see from your screenshot that "Your browser supports HTTP/2!" so I presume you are using HTTP/2 but no harm checking.
What the test does is load 378 images to make up each globe. Loading so many resources is something that HTTP/1 is particularly bad at, and which HTTP/2 is particularly good at - mostly due to HTTP/2 allowing multiplexing.
So if you are using HTTP/2 but are not seeing HTTP/2 being faster then it's likely due to one of these reasons:
- There is something caching the resources locally meaning you are loading them locally and not directly from Akamai. E.g. if you have a company proxy that does some caching for you. Now Akamai does set a
Cache-Control: max-age=0, no-cache, no-store
HTTP header on the resource so it shouldn't be cached, but still - proxies have done stranger things! to be honest loading this site in 0.62 seconds in HTTP/1 sounds too fast unless you are sitting in Akamai's data center, so this is what I think is happening. Try another HTTP/2 test (I have my own one on my blog for example).
- You have a super fast network with no latency. Latency is the main reason that HTTP/1.1 is slower than HTTP/2 as time is wasted sending requests back and forth, during which time no other requests can be sent on that connection. You're latency looks unreasonably low from your screenshots so you must have a super cool connection. Either that or you live next door to Akamai or are reading it locally.
- You are on a network with a lot of packet loss. HTTP/2 uses one TCP connection (mostly) and while that is good for most use cases, it actually gets worse on bad networks as all HTTP/2 streams are held up by a single TCP packet loss (until HTTP/1.1 where 6 independent connections can act truly independently). QUIC looks to solve that by moving away from TCP to a UDP based protocol with TCP-like reliability provided at the stream rather than connection level. But in this case I'd expect both HTTP/1.1 and HTTP/2 to be slower than the screenshots you're giving so don't think it's that.
- You have a sucky HTTP/2 browser. I have seen HTTP/2 implementation issues in even the most popular browsers. Try another browser. you already say this is working as you expect in Chrome but not Firefox so it may be something browser-specific. But again that doesn't explain why the HTTP/1.1 scores are sooo low.