4 ms·

I don't believe this for a second. When you play a game, you know what performance target it should be hitting, because you can visually see it. There's no mea

I don't believe this for a second. When you play a game, you know what performance target it should be hitting, because you can visually see it. There's no meaningful performance target for websites. Instant would be great, and so for matters of debate, let's say that's the next vsync poll and go with the most common poll rate that exists today, ~16ms for 60hz monitors. Is that going to happen? No. Since you don't know what the up/down speed is for any random given website, there's no way to know if what you're experiencing is just the server with a low upload speed to to your client, or the protocol itself. And the Internet connection of the website itself, the language the web server is written in, the performance of the software in question, and other factors are going to have dramatically more impact than the protocol version in question.

clnq 3y ago
> There's no meaningful performance target for websites. Instant would be great, and so for matters of debate, let's say that's the next vsync poll and go with the most common poll rate that exists today, ~16ms for 60hz monitors. Is that going to happen? No. You set an unreasonable arbitrary target and then say neither 1.1 nor 3 will reach it. Yes, I agree. But I don't understand how this is useful. Cloudflare's QUIC test page gets drawn in about 200ms for me with HTTP/3, while it takes about 250ms to draw it with HTTP 1.1. 50ms is 2-3 frames on a v-synced 60Hz monitor. I see the same "few frames quicker" effect on many basic websites that support HTTP/3, and much more significant changes on heavy websites or over poor infrastructure where head-of-line blocking can hurt more.