10 KB Club: Curated list of websites whose home pages do not exceed 10 KB size(10kbclub.com)
10kbclub.com
10 KB Club: Curated list of websites whose home pages do not exceed 10 KB size
https://10kbclub.com/
84 comments
An instant page is one where a typical user click has the result fully rendered inside 100 milliseconds (almost imperceptible latency).
That's an incredibly hard to reach target. Establishing a secure connection from the browser to a server requires several round trips - 1 for DNS lookup, 1 for TCP handshake, 2 to establish the TLS connection, and 1 for the HTTP request. If you divide your 100ms perf budget equally between them that means your servers can be no more than 1800 miles away from the user using (100ms c) / 2 (for the round trip) / 5 requests*. Using TLS 1.3 removes one round trip which is definitely a good optimization. That's before you've even started any serverside rendering, session handling, db connections, etc.
Even with a really good edge network that's going to be incredibly hard to achieve.
I'd love it if every website served a page in 100ms, but it's never going to happen. I got https://ooer.com down to below 500ms for myself (495ms last time I checked) after a fair bit of effect. Getting any lower would be a waste of time. Users can wait an extra 400ms.
That's an incredibly hard to reach target. Establishing a secure connection from the browser to a server requires several round trips - 1 for DNS lookup, 1 for TCP handshake, 2 to establish the TLS connection, and 1 for the HTTP request. If you divide your 100ms perf budget equally between them that means your servers can be no more than 1800 miles away from the user using (100ms c) / 2 (for the round trip) / 5 requests*. Using TLS 1.3 removes one round trip which is definitely a good optimization. That's before you've even started any serverside rendering, session handling, db connections, etc.
Even with a really good edge network that's going to be incredibly hard to achieve.
I'd love it if every website served a page in 100ms, but it's never going to happen. I got https://ooer.com down to below 500ms for myself (495ms last time I checked) after a fair bit of effect. Getting any lower would be a waste of time. Users can wait an extra 400ms.
The 'typical user click' doesn't have to be the first page load...
Depending on the application, many clicks might be from page to page in the web-app. And it's very possible for the majority of clicks to involve no server roundtrip at all.
Depending on the application, many clicks might be from page to page in the web-app. And it's very possible for the majority of clicks to involve no server roundtrip at all.
HN readers will get quite cross with you if you recommend clientside rendering.
My page loads in 174ms using GTmetrix.com, but I also don't really have a lot on my page. It's more of an experimental test. I was going to submit mine to their club but i don't have 100 points for mine yet https://news.ycombinator.com/item?id=33686805
I recommend the parent reads High Performance Browser Networking for a good overview of the latencies involved. Thanks for breaking it down here!
I'd rather have a page load in 2 seconds and be done with than one that shows up in 500 millis and keeps loading advertising shit in the background for 10 seconds. Page size is merely a hint about the level of counter-user sophistication, the lower the better.
I’d rather a page that loads in 500ms and be done than either of those.
Maybe I can't afford a powerful server. But I can always afford not to use 6mb of JavaScript.
This seems to be really hard to do unless you're using global cdn and forgoing https. Ping between US and SG is almost 300ms in the best condition. That alone already blew the 100ms budget for visitors far away from your server location. And then we have https, where initial https handshake alone could take several hundreds ms (depending on various reasons).
> I don't care about how big a page is. I care how fast it loads.
you should care about both, not everyone has unlimited data capacity.
you should care about both, not everyone has unlimited data capacity.
On one hand I love this, but most of these sites are terrible and would have benefited from changes that would push it above 10kb.
Small sizes at extreme cost to UX is not worth it.
Small sizes at extreme cost to UX is not worth it.
Most of them would have benefited from a few lines of CSS that wouldn't have pushed them over 10KB!
The user experience is excellent.
Can you point to a specific problem?
Can you point to a specific problem?
I guess they did not mean the linked site itself, but most of the linked sites. They seem to be personal sites of individual people (developers, bloggers), and typically contain few paragraphs of unstyled text (Black font on white background) and few links. Which might be perfectly fine for such pages, but you can't build, for example, your company website this way. Even putting your company logo in decent resolution would push you over the limit :)
> Even putting your company logo in decent resolution would push you over the limit :)
Not wishing to disagree with the rest of your comment, but I expect many company logos can fit within the limit and look good when represented in compressed SVG (.svgz). Those can also be inlined on a home page to reduce initial view latency.
Not wishing to disagree with the rest of your comment, but I expect many company logos can fit within the limit and look good when represented in compressed SVG (.svgz). Those can also be inlined on a home page to reduce initial view latency.
So, specifically what's wrong? It looks no-nonsense and to-the-point.
Were you unable to find the information you wanted?
Was the site confusing?
Or it was just aesthetically unpleasant?
Were you unable to find the information you wanted?
Was the site confusing?
Or it was just aesthetically unpleasant?
68 bytes (0.07 KB :)
In the pic the text is slightly cut off, looks like i zoomed a few pixels by accident. Still, a touch of padding would improve it imo :)
<meta name="viewport" content="width=device-width, initial-scale=1">
In the pic the text is slightly cut off, looks like i zoomed a few pixels by accident. Still, a touch of padding would improve it imo :)
Titles would have improved the U.X at no cost.
A mailto link might have as well, personally I don't like them but a lot of people find them useful.
Also styling for the resume would have improved the reading ease.
It's not just a matter of aesthetic, it's a matter of visual parsing.
It's not just a matter of aesthetic, it's a matter of visual parsing.
[deleted]
It seems like every dev I know has the idea of making a minimalist website. I guess I would much rather see a curated list of beautiful (in some unique way) websites than another 1000 minimalist websites.
To me, search.marginalia.nu returns the best kind of website: hardware-resource-light and information-dense.
> The website must either be very noteworthy or some content from the website must have received at least 100 points on Reddit or Hacker News on at least one occasion.
It's great we now have an elite (10kb club) of the elite (100+ points on a link curator). I don't think this is particularly useful for discovery.
My new club, the 5kb club, requires at least 200 internet points, to be a member of the 10kb club, have met with the Queen before she passed and be under 5kb.
It's great we now have an elite (10kb club) of the elite (100+ points on a link curator). I don't think this is particularly useful for discovery.
My new club, the 5kb club, requires at least 200 internet points, to be a member of the 10kb club, have met with the Queen before she passed and be under 5kb.
My website, http://invece.org, is 5k not compressed. Assuming the linked images don't count.
Well in that case… if you don‘t count my css & js, i beat you!
Haha fair point. What I meant is that images are just kinda accessory: but actaully the client has to fetch them... so indeed I should sum all them.
Mine has 6kB of raw text, making it under 10kB would be difficult. Unless I split it into multiple pages artificially, one per project rather than the collapsible sections I have now.
Still, those 6kB of text turn into 44kB of HTML with the markup, I should probably do something about that.
Still, those 6kB of text turn into 44kB of HTML with the markup, I should probably do something about that.
[deleted]
Previous discussion: https://news.ycombinator.com/item?id=25556860
I thought, for sure, I was squarely in this club with my MD files hosted on GitHub. Then, I looked at point #1. 25kB transferred. Wut?
It looks like GitHub includes normalize.css, which is 12kB all by itself. Damn it.
Next I looked at the css framework I built and use for all my sites. I know it's only about 2.5k, but I have a screenshot. 114kB transferred. Damn it.
I'm not in this club even though I try to be tiny.
It looks like GitHub includes normalize.css, which is 12kB all by itself. Damn it.
Next I looked at the css framework I built and use for all my sites. I know it's only about 2.5k, but I have a screenshot. 114kB transferred. Damn it.
I'm not in this club even though I try to be tiny.
What if you just link to the raw files? Wouldnt look like nice HTML but could be insanely smaller.
> It looks like GitHub includes normalize.css
What?
> I know it's only about 2.5k, but I have a screenshot. 114kB transferred.
What?
What?
> I know it's only about 2.5k, but I have a screenshot. 114kB transferred.
What?
Okay, let me explain…
I publish only markdown files to GitHub starting with index.md. Behind the scenes GitHub does some Jekyll stuff that I don’t think much about. Whatever they use as a default theme includes a normalize.css file.
On the second point, I maintain a little css project I use for a lot of my other projects. It’s called Neat and it’s at https://neat.joeldare.com. It is only 2.5k of css, if you download and use it, but I have a screenshot in the demo page, which balloons it.
I publish only markdown files to GitHub starting with index.md. Behind the scenes GitHub does some Jekyll stuff that I don’t think much about. Whatever they use as a default theme includes a normalize.css file.
On the second point, I maintain a little css project I use for a lot of my other projects. It’s called Neat and it’s at https://neat.joeldare.com. It is only 2.5k of css, if you download and use it, but I have a screenshot in the demo page, which balloons it.
10K seems arbitrary, why not 14K as discussed here: https://endtimes.dev/why-your-website-should-be-under-14kb-i...
None of those websites are worth visiting. Guess you need more than 10KB to display any value.
But all of them need to have at least one article with 100 upvotes on Hacker News or Reddit, so it's probable at least some of them are worth visiting.
PS I am biased because mine is on there.
PS I am biased because mine is on there.
Berkshirehathaway.com would have made the list if they dropped Google Analytics.
As soon as you include images and custom fonts it becomes really hard to keep things small.
I just measured my landing page which looks like every other SaaS landing page out there and it's 12KB of HTML/CSS and 202KB of illustrations and fonts (4*35KB illustrations, 2*25KB fonts).
I just measured my landing page which looks like every other SaaS landing page out there and it's 12KB of HTML/CSS and 202KB of illustrations and fonts (4*35KB illustrations, 2*25KB fonts).
If you compile your webpages, there are tools to remove from fonts any unicode codepoint and weights and ligatures you don't use. Many fonts get 90% smaller. For fonts only displayed small, you can also simplify curves to get further smaller.
Thank you, that's a good tip.
> 12KB of HTML/CSS and 202KB of illustrations and fonts (435KB illustrations, 225KB fonts).
That's reasonable. I don't care whether a website is 10kb or 200kb, I mind if it's 20mb of things which aren't even necessary.
That's reasonable. I don't care whether a website is 10kb or 200kb, I mind if it's 20mb of things which aren't even necessary.
I think having custom fonts disqualify you from the intent of this (avoiding extra bloat that has (near) zero impact on the content/value of the page).
That's a software engineering perspective, ask a designer if typography has zero impact. It was hard enough talking mine down from a 1000$/year license in favour of open fonts because of the way the Q and G were shaped differently...
It should be up to the user what font they want to use.
Maybe not quite in the 10KB club, but Drudge Report and Craigslist both still look like 1998 high school computer club projects and load almost instantly.
Actually Hacker News is quick as well.
Actually Hacker News is quick as well.
That website currently weighs 9.50 kB. Hence, it cannot add too many more sites (without removing some other bits) before hitting its own arbitrary size limit.
Not as bad as the website listing websites that do not list themselves.
Couldn't they just add paging?
Also, they could move either the list or the description to a second page
My home page could get on this site if I reduce the amount of CSS, but I already have it remove unused items from the CSS. Eh, fun project for another day.
What’s the difference between a list and a curated list?
My assumption is that the list was automatically generated and contained many pages that met the aize criteria but were error messages, place holders, or other uninteresting things like a curse word repeating down the page, or worse, tiny POCs for CVEs
Most of these seem to be an introduction + a list of blog posts. I guess, why not. But it’s not really hard to do <10k with this kind of content.
These clubs remind me of this tweet (as someone that has always been the perf guy wherever I worked):
---
Also, hot take: users care way less about performance than you think. They want "fast enough", but we're over-indexing on "as fast as possible" instead of caring about other things that matter more to users.
Source: https://mobile.twitter.com/DavidKPiano/status/15787403709971...
---
Also, hot take: users care way less about performance than you think. They want "fast enough", but we're over-indexing on "as fast as possible" instead of caring about other things that matter more to users.
Source: https://mobile.twitter.com/DavidKPiano/status/15787403709971...
I have seen very little code that is written to be "as fast as possible" and a lot of code that aims to be "fast enough" and fails to meet that bar. Perhaps still worth being mindful about it?
Depends where you work I guess. There are still folks that deploy their React app in "dev mode" after all.
Hardly matters when almost every time it's slow server performance.
It's not just that. I'm 10ms from most CDNs on a 1.2gbps connection and half the sites I use load instantly (within a couple of refresh cycles on a 120Hz monitor) while the other half take several seconds. The number of round trips the latter sites need just to load some text is insane. Same goes for the 95%ile latency of their servers. You really need to fuck up both parts to achieve such high average latency.
Based on this comment I'm almost certain you have faster hardware than most of your users.
I do and am aware of it. But most of the time it's still server performance.
Show me a slow site and most of the time it's still the server holding it back on old hardware.
Show me a slow site and most of the time it's still the server holding it back on old hardware.
> Show me a slow site and most of the time it's still the server holding it back on old hardware.
I was with you but mostly it really isn't hardware.
Mostly it's missing database indexes, n queries instead of a join, and sometimes just one small piece of code that's doing something very inefficiently on every request.
I was with you but mostly it really isn't hardware.
Mostly it's missing database indexes, n queries instead of a join, and sometimes just one small piece of code that's doing something very inefficiently on every request.
I worked as a client performance engineer in a former life. It is not slow server performance “almost every time”.
> we're over-indexing on "as fast as possible"
Solid research on this exists, so there is not much to deny, at least when your goal is selling to the average user.
But: where is this magical place where people put heavy emphasis on performance? It certainly isn't here, and I would like to visit it for once. Companies caring, or giving their programmer the time to care, about performance are absolutely a rare sight. Unless they work in areas in which they are forced to care about it, and even then many stick to the minimum.
Snappy, low latency software is such a delight to encounter because it is just so damn rare. Especially on the web, I constantly feel like I'm wading through molasses, and the only reason I am able to endure this constant, agonizing pain is that I've gotten so used to it...
Solid research on this exists, so there is not much to deny, at least when your goal is selling to the average user.
But: where is this magical place where people put heavy emphasis on performance? It certainly isn't here, and I would like to visit it for once. Companies caring, or giving their programmer the time to care, about performance are absolutely a rare sight. Unless they work in areas in which they are forced to care about it, and even then many stick to the minimum.
Snappy, low latency software is such a delight to encounter because it is just so damn rare. Especially on the web, I constantly feel like I'm wading through molasses, and the only reason I am able to endure this constant, agonizing pain is that I've gotten so used to it...
Web is inherently slow.
You need to try hard to build a slow desktop app (using native libraries). There're some simple rules to follow if you want a snappy desktop app (like running heavy or I/O tasks in a separate thread). If your app is huge (like MS word), it might be slow, but that's another level of the problem.
There're no simple rules if you want to build a snappy web app. You need to think about performance on all levels. You need to think about TLS handshake. Does your certificate fits into first TCP packet? Does your entire conversation fits into first ten TCP packets? That's hard stuff. Is your CSS layout fast enough? Did you think about every resource your website uses?
That's just an observation. I don't know what to do. I don't even know how would I make it better. Web stack is mostly reasonable. Sometimes web stack goes to great lengths in pursue of performance, like replacing TCP with QUIC. That's huge technical accomplishment. WebAssembly is pretty fast for a sandboxed VM. JS is crazy fast for a dynamic language. Yet some startup webapp will make 60 HTTP queries on its first page and that's considered a norm.
You need to try hard to build a slow desktop app (using native libraries). There're some simple rules to follow if you want a snappy desktop app (like running heavy or I/O tasks in a separate thread). If your app is huge (like MS word), it might be slow, but that's another level of the problem.
There're no simple rules if you want to build a snappy web app. You need to think about performance on all levels. You need to think about TLS handshake. Does your certificate fits into first TCP packet? Does your entire conversation fits into first ten TCP packets? That's hard stuff. Is your CSS layout fast enough? Did you think about every resource your website uses?
That's just an observation. I don't know what to do. I don't even know how would I make it better. Web stack is mostly reasonable. Sometimes web stack goes to great lengths in pursue of performance, like replacing TCP with QUIC. That's huge technical accomplishment. WebAssembly is pretty fast for a sandboxed VM. JS is crazy fast for a dynamic language. Yet some startup webapp will make 60 HTTP queries on its first page and that's considered a norm.
> Web is inherently slow.
Absolutely, still there is "normal web latency" slow, "regular website" slow and then there is "reddit redesign" (and other popular sites) slow. Taking the latter as an example, it is easy to check how much faster it could be by using old.reddit.com instead.
For that type of slowness I have very little understanding, it's just a regression.
Absolutely, still there is "normal web latency" slow, "regular website" slow and then there is "reddit redesign" (and other popular sites) slow. Taking the latter as an example, it is easy to check how much faster it could be by using old.reddit.com instead.
For that type of slowness I have very little understanding, it's just a regression.
I tried building a modern Windows app to just show a grid of items, and performance was terrible. After I had done my part in creating the view, the framework just performed poorly for things like resizing or re-ordering cells (from like a sort).
A lot of people worry about super-scale prematurely, thinking that "fast enough" for each individual user means needing to be as far as possible because your have a great many users making concurrent requests.
Somewhat counter-intuitively to some: this way if thinking can actually make things needlessly less responsive for the individual users because of the "over-architecting" it can cause.
Somewhat counter-intuitively to some: this way if thinking can actually make things needlessly less responsive for the individual users because of the "over-architecting" it can cause.
I agree completely regarding "users want fast enough".
Also: for regular sites, html/css/js optimization is less important than server location. If your server is in Europe and your user is in the US, that's the big one, not your HTML, CSS or JS.
And if you're fetishizing over Lighthouse scores, stop. It's only a very rough measure and shouldn't be treated as a goal itself.
Also: for regular sites, html/css/js optimization is less important than server location. If your server is in Europe and your user is in the US, that's the big one, not your HTML, CSS or JS.
And if you're fetishizing over Lighthouse scores, stop. It's only a very rough measure and shouldn't be treated as a goal itself.
> It's only a very rough measure and shouldn't be treated as a goal itself
Lighthouse is a synthetic testing tool. It can be incredibly useful when you connect it to your CI build process and track scores over time – revealing how code changes affect (some) front-end performance metrics.[0] Of course, some scores are non-deterministic so you'll need to run it multiple times.[1] And you should be tracking real user data as well to validate it.
Using PageSpeed Insights to benchmark a site is akin to loading your website a single time on a single device and saying "wow, my site is slow"
Using Lighthouse in your browser to benchmark a site is akin to wasting your time.
[0] https://github.com/GoogleChrome/lighthouse-ci
[1] https://developers.google.com/web/tools/lighthouse/variabili...
Lighthouse is a synthetic testing tool. It can be incredibly useful when you connect it to your CI build process and track scores over time – revealing how code changes affect (some) front-end performance metrics.[0] Of course, some scores are non-deterministic so you'll need to run it multiple times.[1] And you should be tracking real user data as well to validate it.
Using PageSpeed Insights to benchmark a site is akin to loading your website a single time on a single device and saying "wow, my site is slow"
Using Lighthouse in your browser to benchmark a site is akin to wasting your time.
[0] https://github.com/GoogleChrome/lighthouse-ci
[1] https://developers.google.com/web/tools/lighthouse/variabili...
I agree if the website does lots of new connections with no cache, the users have a slow last mile internet, and we are talking about LA to Moscow. Otherwise trans Atlantic is fine, 80-150ms max ping is not that bad.
EDIT max ping of each of our recurring American users on websockets, about a thousand of them. No difference in usage pattern there between Europe and US, but sure we do not have many that have worse ping.
EDIT max ping of each of our recurring American users on websockets, about a thousand of them. No difference in usage pattern there between Europe and US, but sure we do not have many that have worse ping.
For us, effective page load time increases annoyingly when you're more than 1500km from the server. Fortunately most of our traffic can easily be cached, so having a caching server on US East and US West works fine.
If your entire page can fit in a single packet, RTT barely matters for most of the earth.
That fast enough is good enough shouldn't be a hot take?
But if you are implying that the web today is fast enough that for sure is a hot take. Our industry most certainly don't care the slightest about performance nor user experience.
Popups alone are proof of that.
But if you are implying that the web today is fast enough that for sure is a hot take. Our industry most certainly don't care the slightest about performance nor user experience.
Popups alone are proof of that.
I'm sad...I tested my page and its 14.1k. I suppose I should remove that header image.
the 'content ratio' column made my brain fly
this is something we should reward, less chrome, more ideas and expression (unless said chrome is also partly that)
this is something we should reward, less chrome, more ideas and expression (unless said chrome is also partly that)
- 1mb.club
- 512kb.club
- 250kb.club
- 10kbclub.com
- 1kb.club
- no-js.club
- js1k.com
- js1024.fun
- nocss.club
- 512kb.club
- 250kb.club
- 10kbclub.com
- 1kb.club
- no-js.club
- js1k.com
- js1024.fun
- nocss.club
I aspire to have my site on this list one day. But according to their rules, it would need to get 100 upvotes on Hacker News, and that's not realistic.
5. ... some content from the website must have received at least 100 points on Reddit or Hacker News on at least one occasion ...I found the instructions on how to measure the total download associated with a page useful.
Agreed: my home page is clocking in at around 2Kb or less but probably not of any interest to anyone outside of my very narrow silo.
Agreed: my home page is clocking in at around 2Kb or less but probably not of any interest to anyone outside of my very narrow silo.
And some of these pages fail that test badly. For example, sdf.org takes a whopping 1.60 seconds for the home page GET request to return a single byte.
I'd like to see a new leaderboard of 'instant' pages. An instant page is one where a typical user click has the result fully rendered inside 100 milliseconds (almost imperceptible latency).