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.
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?
> 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.
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.
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.
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.
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.
> 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.
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...
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.
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).
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.
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.
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.
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.
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.
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 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 ...
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.
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.
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
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.
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.
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.
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).
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.
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...
> 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.
I don't care about how big a page is. I care how fast it loads.
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).
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.
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.
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.
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
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).
84 comments
[ 4.1 ms ] story [ 154 ms ] thread---
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...
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.
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.
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.
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...
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...
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.
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.
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.
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.
Small sizes at extreme cost to UX is not worth it.
Can you point to a specific problem?
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.
Were you unable to find the information you wanted?
Was the site confusing?
Or it was just aesthetically unpleasant?
It's not just a matter of aesthetic, it's a matter of visual parsing.
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 :)
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?
> I know it's only about 2.5k, but I have a screenshot. 114kB transferred.
What?
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.
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.
https://news.ycombinator.com/from?site=10kbclub.com
PS I am biased because mine is on there.
Still, those 6kB of text turn into 44kB of HTML with the markup, I should probably do something about that.
Actually Hacker News is quick as well.
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).
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.
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.
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).
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.
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.
you should care about both, not everyone has unlimited data capacity.
this is something we should reward, less chrome, more ideas and expression (unless said chrome is also partly that)
- 512kb.club
- 250kb.club
- 10kbclub.com
- 1kb.club
- no-js.club
- js1k.com
- js1024.fun
- nocss.club