Live data from Hacker News

A 14kb page can load much faster than a 15kb page (2022)

endtimes.dev

291–300 of 324 posts

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

#291
post #282

Earlier quoted context omitted.

13 years ago, 10 packets was considered "cheating": https://news.ycombinator.com/item?id=3632765 https://web.archive.org/web/20120603070423/http://blog.benst...

We are in a strange world today because our MTU was decided for 10mbps ethernet (MTU/bandwidth on a hub controls latency). The world is strange because 10mbps is still common for end-user network connections, while 10gbps is common for servers, and a goodly number of consumers have 1gbps. The range means MTU varies from reasonable, where you can argue that an IW of anything from 1-30 packets is good, to a world where…

TL;DR we'd have to switch away from Ethernet (802.3) entirely. Even Jumbo frames are vulnerable to silent corruption. https://en.wikipedia.org/wiki/Jumbo_frame#Error_detection

It was a good decision at the time, back when everything was far slower and more expensive.

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

#292

Earlier quoted context omitted.

A question as a non user: What are you doing with the extra 500kB for me, the user? > 90% of the time in interested in text. Most of the reminder vector graphics would suffice. 14 kB is a lot of text and graphics for a page. What is the other 500 for?

I use it for fonts. My website [0] consists of about 15kB of compressed HTML + CSS and 200kB of fonts. [0] https://wyczawski.dev/

> 15kB of compressed HTML + CSS

Could be less than 14 if classes were not duplicating css.

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

#294
post #114

The geostationary satellite example, while interesting, is kinda obsolete in the age of Starlink

"Obsolete" suggests Starlink is clearly better and sustainable, and that's a very bold statement to make at this point. I suspect in few decades the stationary satellites will still be around, while Starlink would've either evolved drastically or gone away.

I can easily say they are obsolete. The same way old tech is obsolete. Sure, given a catastrophe, eventually maybe we'll be driving around in easier-to-fix old cars and such, and making communications with whatever simpler analog methods. For the use highlighted, geostationary satellites are absolutely obsolete, unless a catastrophe happens.

Questioning my premise is like saying its perfectly logical to plan your kitchen around eating MRE's because "they aren't obsolete". Today's satellite internet isn't yesterday's satellite internet.

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

#295

Earlier quoted context omitted.

I use it for fonts. My website [0] consists of about 15kB of compressed HTML + CSS and 200kB of fonts. [0] https://wyczawski.dev/

Why do I care about fonts? Honestly, if my browser had an option not to load fonts and use my default to save load time I ld choose that 19 out 20 times.

Firefox does have that option. The main annoying thing you'll encounter is that some websites use custom fonts for symbols.

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

#296
post #237

Earlier quoted context omitted.

Anything non-standard will kill shitty middleboxes so I assume spamming packets faster than anticipated will have corporate networks block you off as a security thread of some kind. Mobile carriers also do some weird proxying hacks to "save bandwidth", especially on But in practice, I think this should work most of the time for most people. On slower connections, your connection will probably crawl to a halt due to r…

Loss-based TCP congestion control and especially slow start are a relic from the 80s when the internet was a few dialup links and collapsed due to retransmissions. If an ISP's links can't handle a 50 KB burst of traffic then they need to upgrade them. Expecting congestion should be an exception, not the default. Disabling slow start and using BBR congestion control (which doesn't rely on packet loss as a congestion s…

Slow start could be a great motivator for battling website obesity though. If we could give people an easy win here (get your page size down to 300 kb and it will load in one roundtrip), I think more frontend devs would be thinking about it. (Not much more, though – most still won’t care, probably.)

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

#297
post #105

This could be another reason: https://blog.cloudflare.com/russian-internet-users-are-unabl... > ... analysis [by Cloudflare] suggests that the throttling [by Russian ISPs] allows Internet users to load only the first 16 KB of any web asset, rendering most web navigation impossible.

Hmm, could Cloudflare increase packet size (or initial window, or perhaps turn some other knob) for Russian traffic specifically?

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

#298

Earlier quoted context omitted.

> A web search suggests CDNs are now at 30 packets for the initial window, so you get 45kb there. Any reference for this?

* https://sirupsen.com/napkin/problem-15 * https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-p...

Thanks!

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

#299

Earlier quoted context omitted.

No article sorry, it's just what the bandwidth display on my home router shows. I could post some screenshots but I don't care for answering to everyone who tries to debunk them. Mobile version of Facebook is by the way much better optimized than the full webpage. I guess desktop browser users are a small minority.

Well Facebook has video on it. Highly unlikely that a static site is going to even approach watching a video.

Did you actually look?

Typical websites are not static and include a huge amount of JavaScript and other stuff from different ad networks, analysis tools, etc. It looks like most of it isn't cached. Video delivery on the other hand is incredibly well optimized because everyone knows it's data intensive.

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

#300

I agree with the sentiment here, the thing is, I've noticed that the newer generations are using frameworks like Next.js as default for building simple static websites. That's their bare bone start. The era of plain html + css (and maybe a sprinkle of js) feels like it's fading away, sadly.

I think that makes sense. I have done the hyper optimised, inline resource, no blocking script, hand minimised JS, 14kb website thing before and the problem with doing it the "hard" way is it traps you in a design and architecture. When your requirements change all the minimalistic choices that seemed so efficient and web-native start turning into technical debt. Everyone fantasises about "no frameworks" until the pr…

It is bit sad that web is optimized for developer not the user. Even with blog barely anyone would develop further.
Post reply on HN