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

https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/

by truxs • 1 year ago

504 310 1 year ago

palata• 1 year ago

Fortunately, most websites include megabytes of bullshit, so it's not remotely a concern for them :D.

Hamuko2• 1 year ago

I recently used an electric car charger where the charger is controlled by a mobile app that's basically a thin wrapper over a website. Unfortunately I only had a 0.25 Mb/s Internet plan at the time and it took me several minutes just staring at the splash screen as it was downloading JavaScript and other assets. Even when I got it to load, it hadn't managed to download all fonts. Truly an eye-opening experience.

fouronnes3• 1 year ago

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

zevv• 1 year ago

And now try to load the same website over HTTPS

xrisk2• 1 year ago

Yeah I think this computation doesn’t work anymore once you factor in the tls handshake.

aziaziazi2• 1 year ago

From TFA:

Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms!

supermatt• 1 year ago

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.

mrweasel4• 1 year ago

I know some people who are experimenting with using shorter certificates, i.e. shorter certificate chains, to reduce traffic. If you're a large enough site, then you can save a ton of traffic every day.

tech22• 1 year ago

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.

moomoo11• 1 year ago

I’d care about this if I was selling in India or Africa.

If I’m selling to cash cows in America or Europe it’s not an issue at all.

As long as you have >10mbps download across 90% of users I think it’s better to think about making money. Besides if you don’t know that lazy loading exists in 2025 fire yourself lol.

jofzar• 1 year ago

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.

kosolam2• 1 year ago

The site is very fast indeed

A_D_E_P_T• 1 year ago

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

xrisk2• 1 year ago

I think you’d be surprised to learn that Indian mobile speeds are pretty fast, at 133 mbps median. Ranked 26th in the world (https://www.speedtest.net/global-index#mobile).

hyperbrainer• 1 year ago

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.

flohofwoe• 1 year ago

I wouldn't be surprised if many '3rd world' countries have better average internet speeds than some developed countries by leapfrogging older 'good enough' tech that's still dominating in the developed countries, e.g. I've been on a 16 MBit connection in Germany for a long time simply because it was mostly good enough for my internet consumption. One day my internet provider 'forcefully' upgraded me to 50 MBit because they didn't support 16 MBit anymore ;)

mrweasel4• 1 year ago

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.

mrweasel4• 1 year ago

Hope you're not selling to the rural US then.

masklinn• 1 year ago

There's plenty of opportunities to have slow internet (and especially long roundtrips) in developed countries e.g.

- rural location

- roommate or sibling torrent-ing the shared connection into the ground

- driving around on a road with spotty coverage

- places with poor cellular coverage (some building styles are absolutely hell on cellular as well)

paales2• 1 year ago

Or maybe we shouldn’t. A good experience doesnt have to load under 50ms, it is fine for it to take a second. 5G is common and people with slower connections accept longer waiting times. Optimizing is good but fixating isn’t.

9dev5• 1 year ago

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.

andrepd2• 1 year ago

a corporation large enough will have a team of experienced SREs that know over which detail to obsess.

Ahh, if only. Have you seen applications developed by large corporations lately? :)

achenet• 1 year ago

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.

elmigranto• 1 year ago

Right. That’s why all the software from, say, Microsoft works flawlessly and at peak efficiency.

9dev5• 1 year ago

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

SXX• 1 year ago

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

nasso_dev• 1 year ago

I agree, it feels like it should be how you describe it.

But if Evan Wallace didn't obsess over performance when building Figma, it wouldn't be what it is today. Sometimes, performance is a feature.

austin-cheney4• 1 year ago

I don’t see what size of corporation has to do with performance or optimization. Almost never do I see larger businesses doing anything to execute more quickly online.

zelphirkalt3• 1 year ago

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.

anymouse1234564• 1 year ago

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

Performance does in fact matter and all other things equal, a fast product is more pleasurable than a slow one.

Thankfully some people like the folks at Figma took the risk and proved the point.

Even if we're innovating on hard technical problems (which most of us are not), performance still matters.

zelphirkalt3• 1 year ago

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.

mr_toad3• 1 year ago

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

01HNNWZ0MV43FF3• 1 year ago

Docker good actually

sgarland6• 1 year ago

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.

hinkley12• 1 year ago

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

jeroenhd4• 1 year ago

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.

keysdev• 1 year ago

That and SPA

sgarland6• 1 year ago

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.

marcosdumay5• 1 year ago

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.

whoisyc2• 1 year ago

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.

DrScientist• 1 year ago

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.

exiguus• 1 year ago

I think, this is just an Art project.

andersmurphy• 1 year ago

Doesn’t have to be a choice it could just be the default. My billion cells/checkboxes[1] demos both use datastar and so are just over 10kb. It can make a big difference on mobile networks and 3G. I did my own tests and being over 14kb often meant an extra 3s load time on bad connections. The nice thing is I got this for free because the datastar maintainer cares about tcp slow star even though I might not.

- [1] https://checkboxes.andersmurphy.com

CyberDildonics• 1 year ago

If you make something that, well, wastes my time because you feel it is, well, not important, then, well, I don't want to use it.

sgarland6• 1 year ago

Depending on the physical distance, it can be much more than a few msec, as TFA discusses.

simgt5• 1 year ago

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 reducing the energy consumption to be mentioned

qayxc3• 1 year ago

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.

vouaobrasil6• 1 year ago

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.

timeon5• 1 year ago

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.

quaintdev• 1 year ago

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

simgt5• 1 year ago

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.

victorbjorklund• 1 year ago

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

vouaobrasil6• 1 year ago

Absolutely agree with that. I recently visited the BBC website the other day and it loaded about 120MB of stuff into the cache - for a small text article. Not only does it use a lot of extra energy to transmit so much data, but it promotes a general atmosphere of wastefulness.

I've tried to really cut down my website as well to make it fairly minimal. And when I upload stuff to YouTube, I never use 4K, only 1080P. I think 4K and 8K video should not even exist.

A lot of people talk about adding XYZ megawatts of solar to the grid. But imagine how nice it could be if we regularly had efforts to use LESS power.

I miss the days when websites were very small in the days of 56K modems. I think there is some happy medium somewhere and we've gone way past it.

raekk2• 1 year ago

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.

FlyingAvatar• 1 year ago

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.

vouaobrasil6• 1 year ago

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

atoav• 1 year ago

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.

OtherShrezzing• 1 year ago

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.

schiffern• 1 year ago

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

oriolid3• 1 year ago

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.

pyman6• 1 year ago

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.

hnlmorg3• 1 year ago

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

jbreckmckye2• 1 year ago

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.

ofalkaed• 1 year ago

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.

sylware• 1 year ago

Country where 10 millions people play their fav greedy-3D game in the evening, with state-of-the-art 400W GPUs, all at the same time...

presentation• 1 year ago

Or we can just commit to building out solar infrastructure and not worry about this rounding error anymore

hiAndrewQuinn3• 1 year ago

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 pretty heavy JavaScript app these days, would need about 1 to 3,000.

I think those are pretty good ways to use the energy.

ajsnigrutin4• 1 year ago

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.

justmarc4• 1 year ago

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?

swores• 1 year ago

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

justmarc4• 1 year ago

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

spacephysics• 1 year ago

This is one of those things that is high effort, low impact. Similar to recycling in some cities/towns where it just gets dumped in a landfill.

Instead we should be looking to nuclear power solutions for our energy needs, and not waste time with reducing website size if its purely a function of environmental impact.

zigzag3122• 1 year ago

So, anyone serious about sustainable future should stop using Python and stop recommending it as introduction to programming language? I remember one test that showed Python using 75x more energy than C to perform the same task.

mnw21cam• 1 year ago

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.

noduerme4• 1 year ago

Yeah, the environmental impact of jackasses mining jackass coin, or jackasses training LLMs is not insignificant. Are you seriously telling me now that if my website is 256k or 1024k I'm responsible for destroying the planet? Take it out on your masters.

And no, reducing resource use to the minimum in the name of sustainability does not scale down the same way it scales up. 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.

It's never clear to me whether people who push this line are doing so because they're bitter and want to punish other humans, or because they hate themselves. Either way, it evinces a system of thought that has already relegated humankind to the dustbin of history. If, in the long run, that's what happens, you're right and everyone else is wrong. Congratulations. It will make little difference in that case to you if the rest of us move on for a few hundred years to colonize the planets and revive the biosphere. Comfort yourself with the knowledge that this will all end in 10 or 20 thousand years, and the world will go back to being a hot hive of insects and reptiles. But what glory we wrought in our time.

simgt5• 1 year ago

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.

iinnPP• 1 year ago

You'll find that people "stop caring" about just about anything when it starts to impact them. Personally, I agree with your statement.

Since a main argument is seemingly that AI is worse, let's remember that AI is querying these huge pages as well.

Also that the 14kb size is less than 1% of the current average mobile website payload.

lpapez• 1 year ago

Being concerned about page sizes is 100% wasted effort.

Calculate how much electricity you personally consume in total browsing the Internet for a year. Multiply that by 10 to be safe.

Then compare that number to how much energy it takes to produce a single hamburger.

Do the calculation yourself if you do not believe me.

On average, we developers can make a bigger difference by choosing to eat salad one day instead of optimizing our websites for a week.

Mawr4• 1 year ago

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

timeon5• 1 year ago

What if I already eat salad?

ksec2• 1 year ago

Missing 2021 in the title.

I know it is not the exact topic, but sometimes I think we dont need the fastest response time but consistent response time. Like every single page within the site to be fully rendered with exactly 1s. Nothing more nothing less.

sangeeth963• 1 year ago

I think the advise is still very relevant though. Plus, the varying network conditions mentioned in the article would ensure it’s difficult if impossible to guarantee consistent response time. As someone with spotty cellular coverage, I can understand the pains of browsing when you’re stuck with that.

ksec2• 1 year ago

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.

the_precipitate• 1 year ago

And you do know that .exe file is wasteful, .com file actually saves quite a few bytes if you can limit your executable's size to be smaller than 0xFF00h (man, I am old).

cout• 1 year ago

And a.out format often saves disk space over elf, despite duplicating code across executables.

crawshaw2• 1 year ago

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 <gw> dev <if> initcwnd 20 initrwnd 20

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

londons_explore• 1 year ago

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.

notpushkin3• 1 year ago

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

sangeeth963• 1 year ago

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

Any reference for this?

ryan-c• 1 year ago

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.

darthShadow• 1 year ago

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

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

nh2• 1 year ago

13 years ago, 10 packets was considered "cheating":

https://news.ycombinator.com/item?id=3632765

https://web.archive.org/web/20120603070423/http://blog.benst...

crawshaw2• 1 year ago

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.

austin-cheney4• 1 year ago

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.

mzhaase• 1 year ago

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

austin-cheney4• 1 year ago

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.

jeffbee• 1 year ago

Yet another reason that QUIC is better.

firecall3• 1 year ago

Damn... I'm at 17.2KB for my home page! (not including dependencies)

FWIW I optimised the heck out of my personal homepage and got 100/100 for all Lighthouse scores. Which I had not previously thought possible LOL

Built in Rails too!

It's absolutely worth optimising your site though. It just is such a pleasing experience when a page loads without any perceptible lag!

ghoshbishakh• 1 year ago

rails has nothing to do with the rendered page size though. Congrats on the perfect lighthouse score.

Alifatisk4• 1 year ago

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.

firecall3• 1 year ago

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

apt-apt-apt-apt• 1 year ago

Yeah, the fact that news.ycombinator.com loads instantly pleases my brain so much I flick it open during downtime automonkey-ly

Alifatisk4• 1 year ago

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!

leptons• 1 year ago

I did a lot of work optimizing the template code we use on thousands of sites to get to 100/100/100/100 scores on Lighthouse. We also score perfect 100s on mobile too. It was a wild adventure.

Our initial page load is far bigger than 17.2KB, it's about 120KB of HTML, CSS, and JS. The big secret is eliminating all extra HTTP requests, and only evaluating JS code that needs to run for things "above the fold" (lazy-evaluating any script that functions below the fold, as it scrolls into view). We lazy-load everything we can, only when it's needed. Defer any script that can be deferred. Load all JS and CSS in-line where possible. Use 'facade' icons instead of loading the 3rd-party chat widget at page load, etc. Delay loading tracking widgets if possible. The system was already built on an SSR back-end, so SSR is also a big plus here. We even score perfect 100s with full-page hires video backgrounds playing at page load above-the-fold, but to get there was a pretty big lift, and it only works with Vimeo videos, as Youtube has become a giant pain in the ass for that.

The Google Lighthouse results tell you everything you need to know to get to 100 scores. It took a whole rewrite of our codebase to get there, the old code was never going to be possible to refactor. It took us a whole new way of looking at the problem using the Lighthouse results as our guide. We went from our customers complaining about page speeds, to being far ahead of our competition in terms of page speed scores. And for our clients, page speed does make a big difference when it factors into SEO rankings (though it's somewhat debatable if page speed affects SEO, but not with an angry client that sees a bad page speed score).

gammalost• 1 year ago

If you care about reducing the amount of back and forth then just use QUIC.

eviks• 1 year ago

Has this theory been tested?

justmarc4• 1 year ago

Does anyone know have examples of tiny, yet aesthetically pleasing websites or pages?

Would love it if someone kept a list.

hackerman_fi2• 1 year ago

There is an example link in the article. Listing more examples would serve no purpose apart from web design perspective

justmarc4• 1 year ago

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

FlyingSnake2• 1 year ago

There’s https://512kb.club/ which I follow to keep my website lightweight

wonger_• 1 year ago

10kbclub.com, archived: https://archive.li/olM9k

https://250kb.club/

Hopefully you'll find some of them aesthetically pleasing

adastra222• 1 year ago

The linked page is 35kB.

fantyoon• 1 year ago

35kB after its uncompressed. On my end it sends 13.48kB.

adastra222• 1 year ago

Makes sense, thanks!

susam3• 1 year ago

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, KaTeX adds a whopping 347.5 kB!

  katex.min.css              23.6 kB
  katex.min.js              277.0 kB
  auto-render.min.js          3.7 kB
  KaTeX_Main-Regular.woff2   26.5 kB
  KaTeX_Main-Italic.woff2    16.7 kB
  ----------------------------------
  Total Additional          347.5 kB

Perhaps I should consider KaTeX server-side rendering someday! This has been a little passion project of mine since my university dorm room days. All of the HTML content, the common HTML template (for a consistent layout across pages), and the CSS are entirely handwritten. Also, I tend to be conservative about what I include on each page, which helps keep them small.

[1] https://susam.net/

[2] https://github.com/susam/susam.net/blob/main/site.lisp

[3] https://susam.net/tag/mathematics.html

welpo• 1 year ago

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/

BlackFly• 1 year ago

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.

mk122• 1 year ago

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/

susam3• 1 year ago

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.

VanTodi• 1 year ago

Another idea maybe would be to load the heavy library after the initial page is done. But it's loaded and heavy nonetheless. Or you could create svgs for the formulas and load them when they are in the viewport. Just my 2 cents

djoldman• 1 year ago

I never understood math / latex display via client side js.

Why can't this be precomputed into html and css?

mr_toad3• 1 year ago

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.

susam3• 1 year ago

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.

marcthe12• 1 year ago

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

creata2• 1 year ago

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

popalchemist2• 1 year ago

Not trying to discourage you from adopting better solutions, but the delayed client-side rendering of a dynamic component like a Latex expression is almost (or sometimes literally) imperceptible to the averge user.

There is such a thing as over-optimization. All this SEO-driven performance chasing is really only worthwhile if the thing you're building is getting click-through-traffic in the millions of views.

It's a bit like worrying about the aerodynamics of a rowboat when you're the only one in it, and you're lost at sea, and you've got to fish for food and make sure the boat doesn't spring any leaks.

Yes, in the abstract, it's a worthwhile pursuit. But when you factor in the ratio of resources required vs gain recieved, it is hardly ever a wise choice of how to use your energy.

hmmokidk• 1 year ago

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.

smartmic• 1 year ago

If I understood correctly, the rule is dependent on web server features and/or configuration. In that case, an overview of web servers which have or have not implemented the slow start algorithm would be interesting.

mikl• 1 year ago

How relevant is this now, if you have a modern server that supports HTTP/3?

HTTP/3 uses UDP rather than TCP, so TCP slow start should not apply at all.

hulitu• 1 year ago

How relevant is this now

Very relevant. A lot of websites need 5 to 30 seconds or more to load.

throwaway019254• 1 year ago

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

ajross• 1 year ago

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.

gbuk20133• 1 year ago

As per the article, QUIC (transport protocol underneath HTTP/3) uses slow start as well. https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...

gsliepen• 1 year ago

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

ilaksh• 1 year ago

https://github.com/runvnc/tersenet

tgv• 1 year ago

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.

notpushkin3• 1 year ago

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

Alifatisk4• 1 year ago

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.

jbreckmckye2• 1 year ago

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 project is no longer a toy.

Whereas the isomorphic JS frameworks let you have your cake and eat it: you can start with something that spits out compiled pages and optimise it to get performant _enough_, but you can fall back to thick client JavaScript if necessary.

timeon5• 1 year ago

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

fleebee• 1 year ago

I think you're late enough for that realization that the trend already shifted back a bit. Most frameworks I've dealt with can emit static generated sites, Next.js included. Astro feels like it's designed for that purpose from the ground up.

austin-cheney4• 1 year ago

You have noticed that only just recently? This has been the case since jQuery became popular before 2010.

chneu• 1 year ago

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

zos_kia• 1 year ago

Next.js bundles the code and aggressively minifies it, because their base use case is to deploy on lambdas or very small servers. A static website using next would be quite optimal in terms of bundle size.

hackerman_fi2• 1 year ago

The article has IMO two flawed arguments:

1. There is math for how long it takes to send even one packet over satellite connection (~1600ms). Its a weak argument for the 14kb rule since there is no comparison with a larger website. 10 packets wont necessarily take 16 seconds.

2. There is a mention that images on webpage are included in this 14kb rule. In what case are images inlined to a page’s initial load? If this is a special case and 99.9% of images don’t follow it, it should be mentioned at very least.

hsbauauvhabzb• 1 year ago

Also the assumption that my userbase uses low latency satellite connections, and are somehow unable to put up with my website, when every other website in current existence is multiple megabytes.

ricardobeat• 1 year ago

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.

throwup238• 1 year ago

In what case are images inlined to a page’s initial load?

Low resolution thumbnails that are blurred via CSS filters over which the real images fade in once downloaded. Done properly it usually only adds a few hundred bytes per image for above the fold images.

I don’t know if many bloggers do that, though. I do on my blog and it’s probably a feature on most blogging platforms (like Wordpress or Medium) but it’s more of a commercial frontend hyperoptimization that nudges conversions half a percentage point or so.

hinkley12• 1 year ago

Inlined svg as well. It’s a mess.

youngtaff• 1 year ago

It’s not really relevant in 2025…

The HTTPS negotiation is going to consume the initial roundtrips which should start increasing the size of the window

Modern CDNs start with larger initial windows and also pace the packets onto the network to reduce the chances of congesting

There’s also a question as to how relevant the 14kb rule has ever been… HTML renders progressively so as long as there’s some meaningful content in the early packets then overall size is less important

maxlin3• 1 year ago

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

theandrewbailey2• 1 year ago

Starlink is only 1 option in the satellite internet market. There are too many embedded systems and legacy infrastructure that its not reasonable to assume that 'satellite internet' means Starlink. Maybe in 20 years, but not today.

maxlin3• 1 year ago

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.

3cats-in-a-coat3• 1 year ago

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

maxlin3• 1 year ago

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.

LAC-Tech• 1 year ago

This looks like such an interesting articles, but it's completely ruined by the fact that every sentence is its own paragraph.

I swear I am not just trying to be a dick here. If I didn't think it had great content I wouldn't have commented. But I feel like I'm reading a LinkedIn post. Please join some of those sentences up into paragraphs!

GavinAnderegg• 1 year ago

14kB is a stretch goal, though trying to stick to the first 10 packets is a cool idea. A project I like that focuses on page size is 512kb.club [1] which is like a golf score for your site’s page size. My site [2] came in just over 71k when I measured before getting added (for all assets). This project also introduced me to Cloudflare Radar [3] which includes a great tool for site analysis/page sizing, but is mainly a general dashboard for the internet.

[1] https://512kb.club/

[2] https://anderegg.ca/

[3] https://radar.cloudflare.com/

FlyingSnake2• 1 year ago

Second this. I also find 512kb as a more realistic benchmark and use it for my website.

The modern web has crossed the rubicon long time ago for 14kb websites.

mousethatroared3• 1 year ago

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?

nicce• 1 year ago

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.

filleduchaos• 1 year ago

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.

ssernikk• 1 year ago

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

[0] https://wyczawski.dev/

Brajeshwar• 1 year ago

512kb is pretty achievable for personal websites. My next target is to stay within 99kb (100kb as the ceiling). Should be pretty trivial on a few weekends. My website is in the Orange on 512kb.

zelphirkalt3• 1 year ago

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.

3cats-in-a-coat3• 1 year ago

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

silon42• 1 year ago

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

MrJohz2• 1 year ago

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.

nottorp• 1 year ago

So how bad is it when you add https?

xg15• 1 year ago

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 you even get the chance to send a byte of your actual content - but the handshake also includes multiple request/response exchanges between client and server, so it would require additional roundtrips even if it stayed below the 14kb boundary.

So the article's advice only holds for unencrypted plain-TCP connections, which no one would want to use today anymore.

The advice might be useful again if you use QUIC/HTTP3, because that one ditches both TLS and TCP and provides the features from both in its own thing. But then, you'd have to look up first how congestion control and bandwidth estimation works in HTTP3 and if 14kb is still the right threshold.

toast0• 1 year ago

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.

tomhow• 1 year ago

Discussed at the time:

A 14kb page can load much faster than a 15kb page - https://news.ycombinator.com/item?id=32587740 - Aug 2022 (343 comments)

mikae1• 1 year ago

Once you lose the autoplaying videos, the popups, the cookies, the cookie consent banners, the social network buttons, the tracking scripts, javascript and css frameworks, and all the other junk nobody likes — you're probably there.

How about a single image? I suppose a lot of people (visitors and webmasters) like to have an image or two on the page.

coolspot• 1 year ago

As long as your page doesn’t wait for that image, your page is going to be shown faster if it is 14kb.

tonymet2• 1 year ago

Software developer’s should be more aware of the media layer . I appreciate the author’s post about 3g /5g reliability and latency. Radio almost always retries, and with most HTTP your packets need to arrive in order.

A single REST request is only truly a single packet if the request and response are both < 1400 bytes. Any more than that and your “single” request is now multiple requests & responses . Any one of them may need a retry and they all need to arrive in order for the UI to update.

For practical experiments, try chrome dev tools in 3g mode with some packet loss and you can see even “small” optimizations improving UI responsiveness dramatically.

This is one of the most compelling reasons to make APIs and UIs as small as possible.

zigzag3122• 1 year ago

I agree. There's some good information in the article, but 14kb web page is a poor example. API requests would be a better example.

tonymet2• 1 year ago

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 .

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

Related Stories