Live data from Hacker News

A 14kb page can load much faster than a 15kb page

endtimes.dev

291–300 of 356 posts

Re: A 14kb page can load much faster than a 15kb page

#291
post #199
post #18

The relevant QUIC draft recommends a similar window[0], so HTTP/3 looks like it will behave the same. [0] https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...

Oh really? Here I thought QUIC would put an end to all this.

My understanding is that QUIC will not help much if your page is self contained (no references to outside resources). Because this page is the only resource and QUIC is all about parallelizing multiple resources. In regards to congestion control QUIC is very similar to TCP [1].

Basically QUIC avoids a case where your image #2 waits for image #1 (head of line blocking). It loads both images in parallel streams. In classic HTTP, TCP was asked to load image #1, then it was asked to load image #2 and TCP have to provide responses in order. So even if a single TCP segment of image #1 is lost, image #2 will have to wait. Browsers try to open multiple TCP connection to avoid head of line blocking, but there is a limit to that.

QUIC also combines TCP and TLS handshakes, so initial latency should be improved somewhat

[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-recove...

Re: A 14kb page can load much faster than a 15kb page

#292
post #243
post #13

Earlier quoted context omitted.

62 bytes is surely not right :) I see your 31.4kb uncompressed, but 9.6kb over the wire.

Folks, b is bits, B is bytes. For someone who deals with IT/telecomm the careless use of bits, bytes, B, b, kB/s, kb/s, kbps, MiB/s, Gbit is a source of confusion, because all those abbreviations have a very specific and distinct meaning. And whenever someone writes something not very obvious (eg Gbit for line speed, or kb for a size of a file or network transfer chunk), I need to figure out if they don't understand…

In this case, I figured the context is enough to figure it out. People don't tend to talk about how many bits of content their browser downloaded.

Re: A 14kb page can load much faster than a 15kb page

#293
The section on satellite internet should probably be updated to clarify that LEO satellite networks like Starlink orbit at 1/100 the distance of GEO satellites, so the parts of the latency calculation involving uplink and downlink become much less important. (The rest of the numbers in the latency calculation still apply.)

Re: A 14kb page can load much faster than a 15kb page

#294
post #123

I like the idea mentioned in the article of increasing the number of packets sent in the slow start - as far as I know you could just crank that from the server side TCP stack to something much larger, right?

Yeah, now that most of us control the server, is this an option?

Yes. This is what I use on my hobby sites and home network. About a decade ago I was using 16 when the default changed to 10 from 3. This is with fq_codel+cdg. Most prefer bbr for servers but I have my own quirky use cases.

    ip route change local 127.0.0.0/8 dev lo initcwnd 128 initrwnd 128
    ip route | grep default | while read p; do ip route change $p initcwnd 32 initrwnd 32; done
I would suggest performing significant testing from high latency connections before making changes on anything important. i.e. iperf3/nuttcp from a VM in another country. This would also be a good time to get numbers from different congestion control algorithms and default qdiscs. e.g. net.ipv4.tcp_congestion_control and net.core.default_qdisc [1]

[Edit] I should also add that changing these values may require different methods depending on the distribution. [2]

[1] - https://www.kernel.org/doc/Documentation/sysctl/net.txt

[2] - https://serverfault.com/questions/546523/linux-initcwnd-and-...

Re: A 14kb page can load much faster than a 15kb page

#295
I think 14KB 'rule' is less relevant these days, but is a good mnemonic to "put the most critical data at the start of the page". Even if this page has to be large, browsers are streaming it and can start processing before it is fully consumed.

https://www.tunetheweb.com/blog/critical-resources-and-the-f...

Re: A 14kb page can load much faster than a 15kb page

#296
post #205

Earlier quoted context omitted.

Never tried it, but its listed as an option at https://linux.die.net/man/8/ip

Seems fraught with potential issues. Can I do this just for nginx?

Possibly but I've never tried this. One could create a virtual routing table and apply ACL's for the nginx listening ports then apply the initcwnd and initrwnd routing changes to that virtual table.

Re: A 14kb page can load much faster than a 15kb page

#297
post #264

Earlier quoted context omitted.

Have to say, I absolutely love Caddy as a general webserver and reverse-proxy. Lightweight, easy to configure, relatively flexible, sane defaults.

> easy to configure, relatively flexible, sane defaults Compared to what? You think nginx is not easy to configure or has insane defaults somehow? Really baffled why people come out of the wood work to pile on beautifully architectured designs in favor of some random project they happen to like or just because it's written in a language they have a special affinity for like Go or something.

I looked into nginx as a replacement for Apache a few years ago and gave up because of the weird dichotomy between open-source nginx and commercial nginx. There seemed to be a lot of FUD about the OS version coming from the commercial people so I moved on.

With the announcement a couple of days ago that the commercial nginx folks are embracing OS again I might take another look.

Re: A 14kb page can load much faster than a 15kb page

#298
post #11

Does this mean your website should also only use HTTP for maximum speed.

I guess so. The OP replied and said yes, but he's banned for being an anti-semite and a COVID minimizer, so I'll say it again for those who have dead comments hidden. It's a shame that you can't have both speed and security. One possibility is to have a subdomain, insecure.blah.com, that doesn't redirect to HTTPS by default.

For a static site HTTPS is wholly unnecessary.

Re: A 14kb page can load much faster than a 15kb page

#299

The section on satellite internet should probably be updated to clarify that LEO satellite networks like Starlink orbit at 1/100 the distance of GEO satellites, so the parts of the latency calculation involving uplink and downlink become much less important. (The rest of the numbers in the latency calculation still apply.)

It is nice that they thought of "oil rig bros" though. I can't imagine the publically funded research ships I've worked on will even legally/politically be allowed to use Starlink even when within good coverage areas of it, at least not for a long time due to institutional pressures, and there's a risk that people see Starlink as "the" new shiny satellite provider and assume that's the worst-case latency/bandwidth target!

Like - our 2mbps internet connection shared between ~50 people does _actually work_, the Internet is _fine_, but so much of the WWW is frustratingly broken - not just because of large page sizes (we have caching proxies onboard, large downloads are fine), but predominantly because of so much parallel loading, servers being impatient with connect/read timeouts, DNS servers treating us like a DDoS attack, a lack of progressive enhancement (page blank = hanging waiting on a font to load from jsdelivr...). Seeing people still focusing on the nitty gritty like optimising for page loads given TCP slow-start is nice to see from a "LITERALLY accessible all over the world" standpoint :-)

Re: A 14kb page can load much faster than a 15kb page

#300
This is mostly nonsense, you can easily check for yourself.

Load up the OP's page with Chrome dev tools network tab open.

Connection start: 90ms (60ms of which is SSL handshake) Request/Response: 30ms request / 30ms response

So the whole post is about yak shaving not splitting the 30ms response portion of a request that already takes 5x that (150+ms).

Sure it's a bit faster, but your users will not notice the difference between a 14kb page and a 15kb page over https (which you hopefully have on).

Post reply on HN