A 14kb page can load much faster than a 15kb page (2022) (opens in new tab)

> You could try replacing KaTeX with MathML: https://w3c.github.io/mathml-core/

I would love to use MathML, not directly, but automatically generated from LaTeX, since I find LaTeX much easier to work with than MathML. I mean, while I am writing a mathematical post, I'd much rather write LaTeX (which is almost muscle memory for me), than write MathML (which often tends to get deeply nested and tedious to write). However, the last time I checked, the rendering quality of MathML was quite uneven across browsers, both in terms of aesthetics as well as in terms of accuracy.

For example, if you check the default demo at https://mk12.github.io/web-math-demo/ you'd notice that the contour integral sign has a much larger circle in the MathML rendering (with most default browser fonts) which is quite inconsistent with how contour integrals actually appear in print.

Even if I decide to fix the above problem by loading custom web fonts, there are numerous other edge cases (spacing within subscripts, sizing within subscripts within subscripts, etc.) that need fixing in MathML. At that point, I might as well use full KaTeX. A viable alternative is to have KaTeX or MathJaX generate the HTML and CSS on server-side and send that to the client and that's what I meant by server-side rendering in my earlier comment.

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.

If you want to test out some examples from your website to see how they'd look in KaTeX vs. browser MathML rendering, I made a tool for that here: https://mk12.github.io/web-math-demo/

> 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 a viable approach, I've been reluctant to introduce Node or other tooling outside the CL ecosystem into this project. I wouldn't have hesitated to add this extra tooling on any other project, but here I do. I like to keep the stack simple here, since this website is not just a utility; it is also my small creative playground, and I want to enjoy whatever I do here.

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.

Well there is mathml but it has poor support in chrome til recently. That is the website native equations formatting.

I usually prefer compiling it to HTML or SVGs, but sometimes, if you have a lot of math on your page, bundling MathJax can take up less space. (Not sure if that'd still be true after compression.)

Humans aren’t robots. If it’s interesting, fun and inspiration comes freely then it often makes sense to pursue. Even to only have something to talk about, to learn, to teach.

* https://sirupsen.com/napkin/problem-15

* https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-p...

I'm not going to dig it up for you, but this is in line with what I've read and observed. I set this to 20 packets on my personal site.

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 the MTU is ridiculously small and the IW is similarly absurd.

We would probably be better off if consumers on >1gbps links got higher MTUs, then an IW of 10-30 could be reasonable everywhere. MTU inside cloud providers is higher (AWS uses 9001), so it is very possible.

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

It’s extreme. But you can still apply to UI. Getting initial paint elements under 14k is good. Eg index.html with the css needed to draw .

Text, yes. Graphics? SVGs are not as small as people think especially if they're any more complex than basic shapes, and there are plenty of things that simply cannot be represented as vector graphics anyway.

It's fair to prefer text-only pages, but the "and graphics" is quite unrealistic in my opinion.

If you want a fancy syntax highlighter for code blocks with multiple languages on your website, that is alone about that size. E.g. regex rules and the regex engine.

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

[0] https://wyczawski.dev/

This. A million times this.

Performance isn’t seen as sexy, for reasons I don’t understand. Devs will be agog about how McMaster-Carr manages to make a usable and incredibly fast site, but they don’t put that same energy back into their own work.

People like responsive applications - you can’t tell me you’ve never seen a non-tech person frustratingly tapping their screen repeatedly because something is slow.

Indeed.

To add to this, bloated performance is often 'death by a 1000 cuts' - ie there isn't just one thing that makes it slow, but it's the cumulative combination of many individual choices - where each choice doesn't incrementally make that much difference, but the cumulative effect does.

ie if you have 100 code changes, each one adding 'just' a 10 millis - suddenly you are a second slower - and yet fixing any one problem has a minimal effect.

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

The actual reason is almost always some business bullshit. Advertising trackers, analytics etc. No amount of trying to shave kilobytes off a response can save you if your boss demands you integrate code from a hundred “data partners” and auto play a marketing video.

Blaming bad web performance on programmers not going for the last 1% of optimization is like blaming climate change on Starbucks not using paper straws. More about virtue signaling than addressing the actual problem.

That and SPA

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.

This. It's exactly why Microsoft use modern frameworks such as React Native for their Start Menu used by billions of people every day.

That’s not what I said. Only that the responsible engineers know which tradeoffs they make, and are competent enough to do so.

a corporation large enough to have a team of experienced SREs that know which details to obsess over will also have enough promotion-hungry POs and middle managers to tell them devs to add 50MB of ads and trackers in the web page. Maybe another 100MB for an LLM wrapper too.

:)

Too many cooks spoil the broth. If you got multiple people pushing agenda to use their favorite new JS framework, disregarding simplicity in order to chase some imaginary goal or hip thing to bolster their CV, it's not gonna end well.

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

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.

Agreed, though containers and K8s aren’t themselves to blame (though they make it easier to get worse results).

Debian Slim is < 30 MB. Alpine, if you can live with musl, is 5 MB. The problem comes from people not understanding what containers are, and how they’re built; they then unknowingly (or uncaringly) add in dozens of layers without any attempt at reducing or flattening.

Similarly, K8s is of course just a container orchestration platform, but since it’s so easy to add to, people do so without knowing what they’re doing, and you wind up with 20 network hops to get out of the cluster.

Docker good actually

If you’re implying that Docker is the slop, instead of an answer to the slop, I haven’t seen it.

Lobsters, Dlangs forum and HN is one of the few places I know that loads instantly, I love it. This is how it should be like!

Doesn't Rails asset pipeline have an effect on the page size, like if Propshaft being used instead of Sprockets. From what I remember, Propshaft intentionally does not include minification or compression.

Indeed it does not :-)

It was more a quick promote Rails comment as it can get dismissed as not something to build fast website in :-)

Inlined svg as well. It’s a mess.

There was no such assumption, that was just the first example after which he mentions normal roundtrip latencies are usually in the 100-300ms range.

Just because everything else is bad, doesn't invalidate the idea that you should do better. Today's internet can feel painfully slow even on a 1Gbps connection because of this; websites were actually faster in the early 2000s, during the transition to ADSL, as they still had to cater to dial-up users and were very light as a result.

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

Arguably it's been this way since web 2.0 became a thing in like 2008?

In that spirit I have a userscript, ironically called Youtube HD[0], that with one edit sets the resolution to 'medium' ie 360p. On a laptop it's plenty for talking head content (the softening is nice actually), and I only find myself switching to 480p if there's small text on screen.

It's a small thing, but as you say internet video is relatively heavy.

To reduce my AI footprint I use the udm=14 trick[1] to kill AI in Google search. It generally gives better results too.

For general web browsing the best single tip is running uBlock Origin. If you can master medium[2] or hard mode (which will require un-breaking/whitelisting sites) it saves more bandwidth and has better privacy.[3]

To go all-out on bandwidth conservation, LocalCDN[4] and CleanURLs[5] are good. "Set it and forget it," improves privacy and load times, and saves a bit of energy.

Sorry this got long. Cheers

[0] https://greasyfork.org/whichen/scripts/23661-youtube-hd

[1] https://arstechnica.com/gadgets/2024/05/google-searchs-udm14...

[2] https://old.reddit.com/r/uBlockOrigin/comments/1j5tktg/ubloc...

[3] https://github.com/gorhill/ublock/wiki/Blocking-mode

[4] https://www.localcdn.org/

[5] https://github.com/ClearURLs/Addon

> but optimizing everywhere is a recipe for using up the resources to actually optimize where it matters.

Is it? My front end engineer spending 90 minutes cutting dependencies out of the site isn’t going to deny YouTube the opportunity to improve their streaming algorithms.

I feel this way sometimes about recycling. I am very diligent about it, washing out my cans and jars, separating my plastics. And then I watch my neighbour fill our bin with plastic bottles, last-season clothes and uneaten food.

Yes but drops in the bucket count. If I take anything away from your statement, it is that people should be selective where to use videos for communications and where not.

> 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.

Is it really? I was surprised to see that surfing newspaper websites or Facebook produces more traffic per time than Netflix or Youtube. Of course there's a lot of embedded video in ads and it could maybe count as streaming video.

The problem is that a lot of people DO have their own websites for which they have some control over. So it's not like a million people optimizing their own websites will have any control over what Google does with YouTube for instance...

It matters at web scale though.

Like how industrial manufacturing are the biggest carbon consumers and compared to them, I’m just a drop in the ocean. But that doesn’t mean I don’t also have a responsibility to recycle because culminate effect of everyone like me recycling quickly becomes massive.

Similarly, if every web host did their bit with static content, you’d still see a big reduction at a global scale.

And you’re right it shouldn’t the end of the story. However that doesn’t mean it’s a wasted effort / irrelevant optimisation

I feel better about limiting the size of my drop in the bucket than I would feel about just saying my drop doesn't matter even if it doesn't matter. I get my internet through my phone's hotspot with its 15gig a month plan, I generally don't use the entire 15gigs. My phone and and laptop are pretty much the only high tech I have, audio interface is probably third in line and my oven is probably fourth (self cleaning). Furnace stays at 50 all winter long even when it is -40 out and if it is above freezing the furnace is turned off. Never had a car, walk and bike everywhere including groceries and laundry, have only used motorized transport maybe a dozen times in the past decade.

A nice side effect of these choices is that I only spend a small part of my pay. Never had a credit card, never had debt, just saved my money until I had enough that the purchase was no big deal.

I don't really have an issue with people who say that their drop does not matter so why should they worry, but I don't understand it, seems like they just needlessly complicate their life. Not too long ago my neighbor was bragging about how effective all the money he spent on energy efficient windows, insulation, etc, was, he saved loads of money that winter; his heating bill was still nearly three times what mine was despite using a wood stove to offset his heating bill, my house being almost the same size, barely insulated and having 70 year old windows. I just put on a sweater instead of turning up the heat.

Edit: Sorry about that sentence, not quite awake yet and doubt I will be awake enough to fix it before editing window closes.

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 how many years web developers have spent obsessing over this document-based legacy system and how to improve its performance? Not just years, their whole careers! How many cool technologies were created in the last 35 years? I lost count. Honestly, why are big tech companies still building on top of a legacy system, forcing web developers to waste their time on things like performance tweaks instead of focusing on what actually matters: the product.

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 a darn about even trying to send a signal.

On the other hand - its kind of like saying we dont need to drive env friendly cars because it is a drop in the bucket compares to containerships etc

Sure there are more resource-heavy places but I think the problem is general approach. Neglecting of performance and overall approach to resources brought us to these resource-heavy tools. It seems just dismissive when people pointing to places where there could be made more cuts and call it a day.

If we want to really fix places with bigger impact we need to change this approach in a first place.

Of course, but my point is that it's still a constraint we should have in mind at every level. Dupont poisoning public water with pfas does not make you less of an arsehole if you toss your old iPhone in a pond for the sake of convenience.

LLM companies should provide how much energy got consumed processing users request. Maybe people will think twice before generating AI slop

Let's take it further: That atmosphere of wastefulness not only concerns bandwidth and energy use but also architectural decisions. There's technology that punches far above its weight class in terms of efficiency and there's the opposite. It seems like a collective form of learned helplessness, on both sides, the vendors and users. IMHO, the only real reason for slow, JavaScript-heavy sites is surveillance and detailed, distributed profiling of users. The other would be animated UI giving dopamine hits, but that could totally be confined to entertainment and shouldn't be a cue for "quality" software.

Or how much energy it took to even get to work by car that day.

What if I already eat salad?

I'm just investigating why the nightly backup of the work server is taking so long. Turns out python (as conda, anaconda, miniconda, etc) have dumped 22 million files across the home directories, and this takes a while to just list, let alone work out which files have changed and need archiving. Most of these are duplicates of each other, and files that should really belong to the OS, like bin/curl.

I myself have installed one single package, and it installed 196,171 files in my home directory.

If that isn't gratuitous bloat, then I don't know what is.

Slightly veering off topic but I honestly wonder how many burgers will I fry if I ask ChatGPT to make a fart app?

Now open an average news site, with 100s of request, tens of ads, autoplaying video ads, tracking pixels, etc., using gigabytes of ram and a lot of cpu.

Then multiply that by the number of daily visitors.

Without "hamburgers" (food in general), we die, reducing the size of usesless content on websites doesn't really hurt anyone.

Just wondering how do you reached at the energy calculation for serving that 14k page?

For a user's access to a random web page anywhere, assuming it's not on a CDN near the user, you're looking at at ~10 routers/networks on the way involved in the connection. Did you take that into account?

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.)

> the environmental impact of jackasses mining jackass coin, or jackasses training LLMs is not insignificant

Whataboutism. https://en.m.wikipedia.org/wiki/Whataboutism

> You're just pushing the idea that all human activity is some sort of disease that's best disposed of. That's essentially just wishing the worst on your own species for being successful.

Strawmaning. https://en.m.wikipedia.org/wiki/Straw_man

Every bloody mention of the environmental impact of our activities gets at least a reply like yours that ticks one of these boxes.

Yes. I don't know how it could be achieved other than having JS rendered the whole thing, wait until time designated before showing it all. And that time could be dependent on network connection.

But this sort of goes against my no / minimal JS front end rendering philosophy.

A lot of people don't realize that all these so-called issues with TCP, like slow-start, Nagle, window sizes and congestion algorithms, are not there because TCP was badly designed, but rather that these are inherent problems you get when you want to create any reliable stream protocol on top of an unreliable datagram one. The advantage of QUIC is that it can multiplex multiple reliable streams while using only a single congestion window, which is a bit more optimal than having multiple TCP sockets.

One other advantage of QUIC is that you avoid some latency from the three-way handshake that is used in almost any TCP implementation. Although technically you can already send data in the first SYN packet, the three-way handshake is necessary to avoid confusion in some edge cases (like a previous TCP connection using the same source and destination ports).

I have a suspicion that the 30 second loading time is not caused by TCP slow start.

Slow start is about saving small-integer-numbers of RTT times that the algorithm takes to ramp up to line speed. A 5-30 second load time is an order of magnitude off, and almost certainly due to simple asset size.

Well, exactly that, I'm looking for inspiration.

Depending on who's visiting your site and how often, the rest probably isn't in cache though. If your site is a product landing page or a small blog or something else that people are rarely going to repeatedly visit, then it's probably best to assume that all your assets will need to be downloaded most of the time.

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

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.

That's like saying vacuum tubes are only one option in the radio market.

The quality of connection is so much better, and as you can get a starlink mini with a 50GB plan for very little money, its already in the zone that just one worker could grab his own and bring it on the rig to use on his free time and to share.

Starlink terminals aren't "infrastructure". Campers often toss one on their roof without even leaving the vehicle. Easier than moving a chair. So, as I said, the geostationary legacy system immediately becomes entirely obsolete other than for redundancy, and is kinda irrelevant for uses like browsing the web.

Why can't we just pay with a payment card at electric chargers? Drives me insane.

Please though, for the love of dog, have your site serve a complete chain and don't have the browser or software stack do AIA chasing.

This hasn’t been the case since TLS1.3 (over 5 years ago) which reduced it to 1-RTT - or 0-RTT when keys are known (cached or preshared). Same with QUIC.

Makes sense, thanks!

For the longest time I tried arguing with my ISP that I only needed around 20Mbit. They did have a 50Mbit at the time, but the price difference between 50, 100 and 250 and meant that you basically got ripped off for anything but the 100Mbit. It's the same now, I can get 300Mbit, but the price difference between 300 and and 500 is to small to be viewed as an actual saving, similar, you can get 1000Mbit, but I don't need it and the price difference is to high.

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

The site is very fast indeed

And in the last few years, access has grown tremendously, a big part of which has been Jio's aggressive push with ultra-cheap plans.

The article says this is not a TCP layer technology, but something employed by servers as a bandwidth estimating algorithm.

You are correct in that TCP packets are processed within the kernel of modern operating systems.

Edit for clarity:

This is a web server only algorithm. It is not associated with any other kind of TCP traffic. It seems from the down votes that some people found this challenging.

Yet another reason that QUIC is better.