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

151–160 of 324 posts

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

#151

Post by 01HNNWZ0MV43FF »

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…

> Why can't browsers adopt a system like video streaming, where you "stream" a binary of your site?

I'll have to speculate what you mean

1. If you mean drawing pixels directly instead of relying on HTML, it's going to be slower. (either because of network lag or because of WASM overhead)

2. If you mean streaming video to the browser and rendering your site server-side, it will break features like resizing the window or turning a phone sideways, and it will be hideously expensive to host.

3. It will break all accessibility features like Android's built-in screen reader, because you aren't going to maintain all the screen reader and braille stuff that everyone might need server-side, and if you do, you're going to break the workflow for someone who relies on a custom tweak to it.

4. If you are drawing pixels from scratch you also have to re-implement stuff like selecting and copying text, which is possible but not feasible.

5. A really good GUI toolkit like Qt or Chromium will take 50-100 MB. Say you can trim your site's server-side toolkit down to 10 MB somehow. If you are very very lucky, you can share some of that in the browser's cache with other sites, _if_ you are using the same exact version of the toolkit, on the same CDN. Now you are locked into using a CDN. Now your website costs 10 MB for everyone loading it with a fresh cache.

You can definitely do this if your site _needs_ it. Like, you can't build OpenStreetMap without JS, you can't build chat apps without `fetch`, and there are certain things where drawing every pixel yourself and running a custom client-side GUI toolkit might make sense. But it's like 1% of sites.

I hate HTML but it's a local minimum. For animals, weight is a type of strength, for software, popularity is a type of strength. It is really hard to beat something that's installed everywhere.

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

#152

Post by 3cats-in-a-coat »

zelphirkalt wrote: post #148

My plain HTML alone is 10kB and it is mostly text. I don't think this is achievable for most sites, even the ones limiting themselves to only CSS and HTML, like mine.

This is about your "plain HTML". If the rest is in cache, then TCP concerns are irrelevant.

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

#153

Post by _nivlac_ »

A_D_E_P_T wrote: post #29
jofzar wrote: post #6

Earlier quoted context omitted.

It really depends on who your clients are and where they are. https://www.mcmaster.com/ was found last year to be doing some real magic to make it load literally as fast as possible for the crapiest computers possible.

Do you have any idea what they actually did? It would be interesting to study. That site really is blazing fast.

I am SO glad jofzar posted this - I remember this website but couldn't recall the company name. Here's a good video on how the site is so fast, from a frontend perspective:

https://youtu.be/-Ln-8QM8KhQ

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

#154

Post by mr_toad »

BlackFly wrote: post #127
welpo wrote: post #95

Earlier quoted context omitted.

> That said, I do use KaTeX with client-side rendering on a limited number of pages that have mathematical content You could try replacing KaTeX with MathML: https://w3c.github.io/mathml-core/

Katex renders to MathML (either server side or client side). Generally people want a slightly more fluent way of describing an equation than is permitted by a soup of html tags. The various tex dialects (generally just referred to as latex) are the preferred methods of doing that.

Server side rendering would cut out the 277kb library. The additional MathML being sent to the client is probably going to be a fraction of that.

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

#155

Post by silon42 »

3cats-in-a-coat wrote: post #152
zelphirkalt wrote: post #148

My plain HTML alone is 10kB and it is mostly text. I don't think this is achievable for most sites, even the ones limiting themselves to only CSS and HTML, like mine.

This is about your "plain HTML". If the rest is in cache, then TCP concerns are irrelevant.

You must also be careful not to generate "get-if-modified", or such checks.

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

#156

Post by zelphirkalt »

anymouse123456 wrote: post #147
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.

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…

Performance matters, but at least initially only as far as it doesn't complicate your code significantly. That's why a simple static website often beats some hyper modern latest framework optimization journey websites. You gotta maintain that shit. And you are making sacrifices elsewhere, in the areas of accessibility and possibly privacy and possibly ethics.

So yeah, make sure not to lose performance unreasonably, but also don't obsess with performance to the point of making things unusable or way too complicated for what they do.

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

#157

Post by jeroenhd »

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.

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

#158

Post by mr_toad »

djoldman wrote: post #141
susam wrote: post #74

I just checked my home page [1] and it has a compressed transfer size of 7.0 kB. / 2.7 kB main.css 2.5 kB favicon.png 1.8 kB ------------------- Total 7.0 kB Not bad, I think! I generate the blog listing on the home page (as well as the rest of my website) with my own static site generator, written in Common Lisp [2]. On a limited number of mathematical posts [3], I use KaTeX with client-side rendering. On such pages…

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

It’s a bit more work, usually you’re going to have to install Node, Babel and some other tooling, and spend some time learning to use them if you’re not already familiar with them.

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

#159

Post by notpushkin »

londons_explore wrote: post #129
crawshaw wrote: post #20

If you want to have fun with this: the initial window (IW) is determined by the sender. So you can configure your server to the right number of packets for your website. It would look something like: ip route change default via dev initcwnd 20 initrwnd 20 A web search suggests CDNs are now at 30 packets for the initial window, so you get 45kb there.

be a bad citizen and just set it to 1000 packets... There isn't really any downside apart from potentially clogging up someone who has a dialup connection and bufferbloat.

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

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

#160

Post by swores »

hiAndrewQuinn wrote: post #55
simgt wrote: post #10

Aside from latency, reducing ressources consumption to the minimum required should always be a concern if we intend to have a sustainable future. The environmental impact of our network is not negligible. Given the snarky comments here, we clearly have a long way to go. EDIT: some reply missed my point, I am not claiming this particular optimization is the holy grail, only that I'd have liked for added benefit of red…

Do we? Let's compare some numbers. Creating an average hamburger requires an input of 2-6 kWh of energy, from start to finish. At 15¢ USD/kWh, this gives us an upper limit of about 90¢ of electricity. The average 14 kB web page takes about 0.000002 kWh to serve. You would need to serve that web page about 1-300,000 times to create the same energy demands of a single hamburger. A 14 mB web page, which would be a prett…

If Reddit serves 20 billion page views per month, at an average of 5MB per page (these numbers are at least in the vicinity of being right), then reducing the page size by 10% would by your maths be worth 238,000 burgers, or a 50% reduction worth almost 1.2million burgers per month. That's hardly insignificant for a single (admittedly, very popular) website!

(In addition to what justmarc said about accounting for the whole network. Plus I suspect between feeding them and the indirect effects of their contribution to climate change, I suspect you're being generous about the cost of a burger.)

Post reply on HN