Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

endtimes.dev

Post reply on HN
Print view View original

231–240 of 324 posts

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

#231

Post by Naru41 »

pyman wrote: post #94
FlyingAvatar wrote: post #33

Earlier quoted context omitted.

The vast majority of internet bandwidth is people streaming video. Shaving a few megs from a webpage load would be the tiniest drop in the bucket. I am all for efficiency, but optimizing everywhere is a recipe for using up the resources to actually optimize where it matters.

Talking about video streaming, I have a question for big tech companies: Why? Why are we still talking about optimising HTML, CSS and JS in 2025? This is tech from 35 years ago. Why can't browsers adopt a system like video streaming, where you "stream" a binary of your site? The server could publish a link to the uncompressed source so anyone can inspect it, keeping the spirit of the open web alive. Do you realise ho…

The ideal HTML I have in mind is a DOM tree represented entirely in TLV binary -- and a compiled .so file instead of .js. And a unpacked data to be used directly in C programming data structure. Zero copy, no parsing, (data vaildation is unavoidable but) that's certainly fast.

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

#232

Post by anymouse123456 »

01HNNWZ0MV43FF wrote: post #204
anymouse123456 wrote: post #147

Earlier quoted context omitted.

This idea that performance is irrelevant gets under my skin. It's how we ended up with Docker and Kubernetes and the absolute slop stack that is destroying everything it touches. Performance matters. We've spent so many decades misinterpreting Knuth's quote about optimization that we've managed to chew up 5-6 orders of magnitude in hardware performance gains and still deliver slow, bloated and defective software prod…

Docker good actually

nah - we'll look back on Docker the same way many of are glaring at our own sins with OO these days.

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

#233

Post by marcosdumay »

jeroenhd wrote: post #157
9dev wrote: post #7

The overlap of people that don’t know what TCP Slow Start is and those that should care about their website loading a few milliseconds faster is incredibly small. A startup should focus on, well, starting up, not performance; a corporation large enough to optimise speed on that level will have a team of experienced SREs that know over which detail to obsess.

When your approach is "I don't care because I have more important things to focus on", you never care. There's always something you can do that's more important to a company than optimising the page load to align with the TCP window size used to access your server. This is why almost all applications and websites are slow and terrible these days.

Well, half of a second is a small difference. So yeah, there will probably be better things to work on up to the point when you have people working exclusively on your site.

> This is why almost all applications and websites are slow and terrible these days.

But no, there are way more things broken on the web than lack of overoptimization.

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

#234

Post by jeffbee »

mzhaase wrote: post #30
austin-cheney wrote: post #28

It seems the better solution is to not use HTTP server software that employs this slow start concept. Using my own server software I was able to produce a complex single page app that resembled an operating system graphical user interface and achieve full state restoration as fast as 80ms from localhost page request according to the Chrome performance tab.

TCP settings are OS level. The web server does not touch them.

Yet another reason that QUIC is better.

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

#235

Post by marcosdumay »

bobmcnamara wrote: post #215
mr_toad wrote: post #166

Earlier quoted context omitted.

Containers were invented because VMs were too slow to cold start and used too much memory. Their whole raison d'être is performance.

Can you live fork containers like you can VMs? VM clone time is surprisingly quick once you stop copying memory, after that it's mostly ejecting the NIC and bringing up the new one.

You mean creating a different container that is exactly equal to the previous one?

It's absolutely possible, but I'm not sure there's any tool out there with that command... because why would you? You'll get about the same result as forking a process inside the container.

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

#236

Post by marcosdumay »

vouaobrasil wrote: post #25
qayxc wrote: post #18

Earlier quoted context omitted.

It's not low-hanging fruit, though. While you try to optimise to save a couple of mWh in power use, a single search engine query uses 100x more and an LLM chat is another 100x of that. In other words: there's bigger fish to fry. Plus caching, lazy loading etc. mitigates most of this anyway.

Engineering-wise, it sometimes isn't. But it does send a signal that can also become a trend in society to be more respectful of our energy usage. Sometimes, it does make sense to focus on the most visible aspect of energy usage, rather than the most intensive. Just by making your website smaller and being vocal about it, you could reach 100,000 people if you get a lot of visitors, whereas Google isn't going to give…

So, literally virtue signaling?

And no, a million small sites won't "become a trend in society".

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

#237

Post by r1ch »

jeroenhd wrote: post #172
notpushkin wrote: post #159

Earlier quoted context omitted.

This sounds like a terrible idea, but can anybody pinpoint why exactly?

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 signal) makes a world of difference for TCP throughput.

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

#238

Post by whism »

susam wrote: post #187
djoldman wrote: post #141

Earlier quoted context omitted.

I never understood math / latex display via client side js. Why can't this be precomputed into html and css?

> I never understood math / latex display via client side js. Why can't this be precomputed into html and css? It can be. But like I mentioned earlier, my personal website is a hobby project I've been running since my university days. It's built with Common Lisp (CL), which is part of the fun for me. It's not just about the end result, but also about enjoying the process. While precomputing HTML and CSS is definitely…

Perhaps you could stand up a small service on another host using headless chrome or similar to render, and fall back to client side if the service is down and you don’t already have the pre rendered result stored somewhere. I suggest this only because you mentioned not wanting to pollute your current server environment, and I enjoy seeing these kind of optimizations done :^)

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

#239

Post by toast0 »

xg15 wrote: post #167

> Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms! Doesn't this sort of undo the entire point of the article? If the idea was to serve the entire web page in the first roundtrip, wouldn't you have lost the moment TLS is used? Not only does the TLS handshake send lots of stuff (including the certificate) that will likely get you over the 14kb boundary before y…

Modern TLS adds one round trip, unless you have TCP fast open or 0-RTT resumption; neither of which are likely in a browser case, so call it 1 extra round trip. Modern TLS includes TLS 1.3 as well as TLS 1.2 with TLS False Start (RFC 7918, August 2016).

And TLS handshakes aren't that big, even with certificates... Although you do want to use ECC certs if you can, the keys are much smaller. The client handshake should fit in 1-2 packets, the server handshake should fit in 2-3 packets. But more importantly, the client request can only be sent after receiving the whole server handshake, so the congestion window will be refreshed. You could probably calculate how much larger the congestion window is likely to be, and give yourself a larger allowance, since TLS will have expanded your congestion window.

Otoh, the important concept, is that early throughput is limited by latency and congestion control, and it takes many round trips to hit connection limits.

One way to apply that is if you double your page weight at the same time you add many more service locations and traffic direction, you can see page load times stay about the same.

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

#240

Post by hinkley »

marcosdumay wrote: post #233
jeroenhd wrote: post #157

Earlier quoted context omitted.

When your approach is "I don't care because I have more important things to focus on", you never care. There's always something you can do that's more important to a company than optimising the page load to align with the TCP window size used to access your server. This is why almost all applications and websites are slow and terrible these days.

Well, half of a second is a small difference. So yeah, there will probably be better things to work on up to the point when you have people working exclusively on your site. > This is why almost all applications and websites are slow and terrible these days. But no, there are way more things broken on the web than lack of overoptimization.

> half a second is a small difference

I don’t even know where to begin. Most of us are aiming for under a half second total for response times. Are you working on web applications at all?

Post reply on HN