27 ms·
1MB Club
- forgotmypw17 6y agoWhat's an easy way to measure total resources downloaded for a page?
- asenna 6y agoOn Firefox you can open up the console (right click -> Inspect Element), head to the "Network" tab and check the very bottom of that panel. It should give you details on how much time it took and the size of your request. You can refresh your page and it refreshes the data at the bottom as well. I believe it should be similar on Chrome and Safari as well, just locate the Network tab in the browser console.
- huangc10 6y ago1MB? no no, tres commas club please!
- aww_dang 6y agoI like to limit myself to around 100k for simple, interactive pages.
- SimeVidas 6y ago100 KB of images is not the same as 100 KB of JavaScript. You could technically still create a website that is a 1 KB HTML document that loads almost 1 MB of JavaScript, which is definitely too much.
- donohoe 6y agoI think they are looking at whatever loads in that initial Page Load.
- tutfbhuf 6y agoHow about WebAssembly? Whats your size limit for that?
- vaccinator 6y agoShould be 0kb for that
- SimeVidas 6y agoGood question. I don’t know.
- TACIXAT 6y agoI’ve always had a project in mind for a bespoke search engine that only indexes pages smaller than 65kb.
- nivenkos 6y agoOr a news aggregator that only accepts links to pages with the same restriction.
- conception 6y agoThere is a search engine that tries to do something like this... searches mainly for blogs and whatnot and I’m so sorry I can’t remember the name of it. :( Ironically you can google about and find it probably.
- stonogo 6y agoIs it https://wiby.me https://wiby.me? If not, I'd love to know more!
- gen220 6y agoThe surprise me feature has yielded some really good links! "Doom as a tool for system administration" [1], "What can you do with a slide rule?" [2], and of course some vintage 90s personal pages... some of which have been actively maintained to this day (!) [3] edit: that last page has some incredibly-detailed information about the various cars he's owned [4] [1]: https://www.cs.unm.edu/~dlchao/flake/doom/ https://www.cs.unm.edu/~dlchao/flake/doom/ [2]: http://www.math.utah.edu/~pa/sliderules/ http://www.math.utah.edu/~pa/sliderules/ [3]: http://www.billswebspace.com/ http://www.billswebspace.com/ [4]: http://www.billswebspace.com/124Abarth.html http://www.billswebspace.com/124Abarth.html
- Shared404 6y ago[1] Is actually a really cool idea. I thought it would just be a joke, but the article makes a good case for it, at least as a POC for a UI.
- jessmay 6y agoThe first item on the list, sjmulder.nl/en/ takes up to 2 seconds to load with TLS being over 500ms. Is this just some sort of self host?
- mp3k 6y agohttps://bundlephobia.com/ https://bundlephobia.com/
- billfruit 6y agoNice to know of CNN lite, had never heard of it before.
- DanielleMolloy 6y agoIndeed. Also, much less of an attention sink, and lynx-friendly. Are there more news websites like this?
- subprotocol 6y agoWow yeah, this made my day! It's nice not waiting 10 seconds for a video I don't want to watch to auto start playing (just so I can stop it).
- dynamite-ready 6y agoWould this page qualify? - https://quixical.com/welcome https://quixical.com/welcome
- noahtallen 6y agoWhat did they do to the scrolling!
- _threads 6y agoYES
- 1-6 6y agoReminds me of a dollar store.
- doctorbuttes 6y agoSure, many sites are bloated, but I can't help but feel the sentiment is somewhat dramatic. Cancerous growth? "Client-side queries!?" Performance is just one piece of the UX puzzle. Users don't really care about bundle size... They care if your site provides value in a reasonable amount of time.
- Yajirobe 6y agoCan you guys stop spamming the guy's github issues page?
- bochoh 6y agoI tweeted about text.npr.org this morning. Excellent resource.
- vegannet 6y ago1MB in size feels like an attempt to define “performant” without considering... performance. A speed test from an “average” connection that also measures first paint etc. would be much more meaningful: not all megabytes are equal. I love the idea, just needs a better measurement.
- alexchamberlain 6y agoI think that's a little unfair tbh; there are plenty of places that already do that, but don't take account of the memory footprints on the clients machine etc. I do agree that 1MB is arbitrary, but it's the right kind of arbitrary IMHO.
- SulfurHexaFluri 6y agoPretty easy to write a one line js loop that makes the page slow as shit.
- joshmanders 6y agoShout out to https://1mb.co/ https://1mb.co/
- soheil 6y agoInteresting that a site that champions for performance has an ungodly favicon [0] that is 10x larger (15KB) than the page itself. [0] https://1mb.club/favicon.ico https://1mb.club/favicon.ico
- shepherdjerred 6y agoWhat kind of an internet connection are you on that 15kb is significant? Performance is important, but if your site is clocking in at 17kb then you're probably doing okay.
- addedlovely 6y agoMay seem pedantic but those little gains do add up. A missing favicon also has a surprising impact.
- bombela 6y agoBut when you start this way, you quickly endup with the bloat that is modern software. Because each extra bit of waste seems justified at every steps along the way.
- cozzyd 6y agoSpoken like somebody who's never been to Antarctica. Or on a slow train WiFi for that matter...
- KMnO4 6y agoI did a quick Google search and discovered that SVG favicons are valid in most browsers, so for fun I reduced it by 95% down to 886 bytes: https://output.jsbin.com/yudonidujo https://output.jsbin.com/yudonidujo
- tomgp 6y agoIn 2005 I had to fill in a form to request a page size exception for our election results map on the BBC News site. The page weight was going to be just a little under 400kb. At the time the size considered acceptable for the whole page (images and all) was 75kb.
- scrooched_moose 6y agokb or kB? Assuming kB and dialup, which was 83% of the US at the time (easiest stat to quickly find), that was a difference of about 23s vs 121s load time. Edit: Seems like the UK would have been about 50/50 around that time according to this article: https://www.independent.co.uk/news/business/news/broadband-overtakes-dial-up-as-way-of-connecting-to-the-internet-492595.html https://www.independent.co.uk/news/business/news/broadband-o...
- folmar 6y agoAs far as my math goes 75k(b/B) on dialup (usual speed for that time is 56.6k) is either 1.3s or 10.6s. Either being acceptable at the time since browser loaded text first and rendered images when they came.
- scrooched_moose 6y agoIn theory yeah. In practice, 32 was about the best I ever managed and 24-26 was typical.
- tomgp 6y agoYes, sorry, kB. If I recall correctly our argument was that because after the initial load we only needed to poll occasionally for small data updates users would probably save time/ bandwidth overall (a familiar argument for the present day SPA advocates)
- ilaksh 6y agoI previously suggested something a little bit along these lines. But what I thought would be better would be a distributed database and a browser extension that would measure load times (or maybe page size) and stability and automatically update it.
- gfxgirl 6y agoI'm pretty happy with my bloated mess. Glad youtube and Spotify aren't limited to 1meg Glad Google Maps lets me view the world in 3D and with street views and make custom maps, and read reviews with photos, etc. Don't care that it takes more than 1meg. Love Apple's beautiful pages like the Macbook Air page at 14meg
- suyash 6y agowhat if those experiences could be provided with a smaller footprint? Try to think bigger than yourself. It would no doubt be faster but also would consume less bandwidth, less storage, less compute = less power meaning good for the environment.
- Falling3 6y agoI don't think anyone is going to argue that there are sites that provide huge utility in exchange for their size. No one is suggesting we google maps should clock in at less than a MB. But the point is that there's a continuing trend of websites' sizes growing much faster than their functionality - often with the former to the detriment of the latter.
- imheretolearn 6y agoI was once asked to debug an extremely slowly loading page. In the first 5 minutes it was evident that the client was doing things it wasn't supposed to do. It was downloading 300MB worth of resources to show the webpage. Incorrect implementations and inefficient use of libraries is the reason why we're seeing a bloated websites all over the web
- vagrantJin 6y ago> It was downloading 300MB worth of resources to show the webpage. Incorrect implementations and inefficient use of libraries is the reason why we're seeing a bloated websites all over the web In situations like that, it's right and proper to ask who built the site. Then shake your head with absolute contempt.
- grecy 6y agoand follow them around from job to job, giving yourself endless contacting work cleaning up their messes!
- strken 6y agoI've had to fix web apps like that, and no, that's not always right and proper. One example I can give is a tool which loaded 50MB of deeply nested JSON, because when it was written 5 years ago, the payload per item was 80% smaller and the company had 0.1% the number of items. The correct response is to work out who was responsible for maintaining the site for the past five years.
- the__prestige 6y agoI suspect this site's page will soon not qualify to be a part of this club :)
- m-chrzan 6y agoNice! I've gotten so jaded with how big and slow most of the modern web is, that randomly stumbling upon a tiny site prompted me to write about the joy of it on my blog (a much less than 1MB site itself): https://m-chrzan.xyz/blog/small-big-sites.html https://m-chrzan.xyz/blog/small-big-sites.html
- vmception 6y agoWe are finally just starting to see a contender for web3.js to get the same functionality without a bloated package size
- mark242 6y agoHere's the disconnect, which is why these "webpages need to be slim!" sites tend to make me think they're greybeard nostalgia for an internet that doesn't really exist anymore. Your 1mb webpage is approximately 60ms worth of Disney+ streaming. Your 1mb webpage is approximately 1.7s worth of Zoom chat. Your 1mb webpage is approximately 1.9s worth of Tiktok video. Unless you are specifically targeting low-bandwidth users, you need to worry about product market fit long before you worry about slimming your js bundles down.
- tomxor 6y ago> Unless you are specifically targeting low-bandwidth users There aren't some tiny number of low bandwidth users with some esoteric internet problem, there is a significant divide due to technological and geographic reasons. Averages are very misleading when the majority of people in cities connected to various fiber end points keep getting crazier and crazier speeds while 50% of the US is stuck on ADSL, with a theoretical max of 20Mbit down - add geographical limitations and that's often far lower due to line noise. Where I live in the UK it's also just a matter of luck, I live in the middle of a major city and yet in the 5 places I've lived over the last 10 years the only option was ADSL, and never >6Mbit. I haven't even started the argument about other countries with poorer internet infrastructure. When you assume being able to download at 1MiB/s is basic, you make the internet suck for a huge chunk of the population, they are not the majority - but barely.
- KMnO4 6y agoEven if you are able to get palatable speeds, bandwidth caps are an issue for some people. For example, I'm stuck with 40GB/month in rural Ontario (ie, 5 minutes outside of a city), which means I share roughly 1300mb per day with my household. I'm constantly watching the bandwidth meter tick up in my menu bar.
- kevindong 6y ago> Averages are very misleading when the majority of people in cities connected to various fiber end points keep getting crazier and crazier speeds while 50% of the US is stuck on ADSL, with a theoretical max of 20Mbit down - add geographical limitations and that's often far lower due to line noise. Can you cite your source on "50% of the US is stuck on ADSL"? Furthermore, do you mean 50% of the US land area or 50% of the US population? The former is plausible, the latter is not.
- ssijak 6y agoIn an age of 4k streaming being frugal with 1MB websites for the sake of it is kind of missing the point. Yes, we should care how we build stuff, and we should not use resources like there is no tomorrow, but on HN there is a sentiment that basically says that everything on the web after year ~2010 is terrible, hard to use and wasteful.
- bnchrch 6y agoAhh let the bikeshedding continue. In these situations all I want to say is "Who cares". Optimization matters when it actually solves a problem, before that it's just wasted effort. I don't hear the general public yelling from the rooftops "The web is too slow! Developers are building too fast! I wish we could go backwards!"
- baxtr 6y agoWell I agree and disagree :) as always it depends. I think it’s clear that especially on slow mobile connections people will close a site quickly if they don’t see results and this in turn yields lower sales for example. Also, Google will factor Speed into its algorithm. So you will lose traffic if you don’t optimize. At the same time, people at home with broadband wouldn’t care less. That’s actually a core reason for slow pages. People in offices with large monitors and huge bandwidth develop those sites
- stickfigure 6y agoI hear my users constantly yelling for more features. Not one has complained about the page load (5mb uncompressed, plus a delay for auth to initialize). I'll keep listening to my users.
- thesuitonym 6y agoBecause anyone who complains is given this treatment. We don't complain to everybody we just bounce.
- Shared404 6y ago> We don't complain to everybody Except on forum's. We complain there :P
- stickfigure 6y agoIf you're offering a service that is so uncompelling or so undifferentiated that the page load speed is a driving factor, than you should certainly focus on page load speed. On the other hand, Gmail regularly takes 10s+ to load and yet most users are glued to it. If you're a SaaS business, your marketing page is probably not your app. The people using your app care about usability, and page load speed is rarely the driving factor. Especially with SPAs.
- CogentHedgehog 6y agoIn some ways it's interesting to think that a modern website is larger than most operating systems used to be. I can understand why (frameworks, rich assets, etc) but it puts us in an interesting place. I wonder what the web will look like in 2030?
- discreteevent 6y agoIndeed, I remember running QNX from a floppy disk (1.44MB) complete with windowing system and utilities.
- CogentHedgehog 6y agoYeah, that sounds about right. I remember MS DOS used to fit on a 720k floppy -- back when they were literally floppy...
- CyberDildonics 6y agoReinventing QNX will be state of the art for decades to come.
- hbbio 6y agoHad to upvote, since I'm currently building a quite complex web application (using Svelte) for which I'm trying to restrict myself to 1Mb JS uncompressed (including SVG paths). To do this, there is almost no runtime dependencies - while I "lost" a few months building things I could borrow from bigger libraries (from parts of rxjs to much bigger component libraries/design systems), development speed is now excellent! Currently sitting at 750kb and close to feature completion so I'm pretty sure that it will be achieved.
- susam 6y agoHow accurate is this list? I see it mentions that visiting https://danluu.com/ https://danluu.com/ downloads only 9.1 kB but when I actually visit this website with Google Chrome, in the Developer Tools' Network tab, I see that a total of 21.7 kB is transferred. Name Status Type Size ------------ ------ -------- -------- danluu.com 200 document 2.5 kB analytics.js 200 script 18.9 kB collect 200 xhr 67 B favicon.ico 404 text/html 266 B Shameless plug: I maintain a lightweight home page myself at https://susam.in/ https://susam.in/ and I try to keep it as lean as possible without compromising on some custom formatting I care about. So far I have got the transfer size down to less than 6 kB.
- ffpip 6y agoAre you not using an ad blocker? danluu.com has google-analytics, which is a very large script. Please use uBlock Origin.
- susam 6y agoI do use uBlock Origin in general. However, I disabled it while verifying if the download size claimed in this post is accurate.
- RussianCow 6y agoI don't think an ad blocker should be assumed when calculating the size of a web page.
- tshaddox 6y agoIt would depend on precisely what you're measuring. If you're concerned about page loading speeds, then resources that don't block rendering or functionality (like, I assume, a proper GA integration) might not be worth considering. But if you're worried about, say, bandwidth usage, then of course you'd want to count everything.
- RussianCow 6y ago
- johnghanks 6y ago> These things are a cancerous growth on the web. lmfao a little dramatic. JS heavy sites _can_ be great experiences if they are developed properly just like <1MB sites can be garbage if they are poorly developed.
- syassami 6y agoMy personal fav: 148kb, $530B company. https://www.berkshirehathaway.com https://www.berkshirehathaway.com
- conductr 6y agoSeems impressive but considering most holding companies have no website maybe it’s bloated
- bak3y 6y agoCopyright © 1978-2020 Berkshire Hathaway Inc. Can it be assumed that this same website has been in place since 1978? Obviously not exactly like it is now, but probably not far off.
- vitus 6y agoI'd assume not, given that Tim Berners-Lee hadn't invented HTTP yet. But, the website looks rather similar to how it did back in 2001 (with the recognizable two-column list of bullet points): https://web.archive.org/web/20011129002047/https://www.berkshirehathaway.com/ https://web.archive.org/web/20011129002047/https://www.berks...
- zerocrates 6y agoHTML being from the early 90s or so, I wanna say "no." I wonder what the logic for the 1978 date is. It's hard for me to believe they had any reasonably connected predecessor of this in 1978.
- ciabattabread 6y agoIt’s the copyright for the entire website. There’s a letter to shareholders written March 14, 1978 - https://www.berkshirehathaway.com/letters/1977.html https://www.berkshirehathaway.com/letters/1977.html
- criddell 6y agoI assume you went through the proper channels to get written permission to make that link. From the legal disclaimer at the bottom: > linking to this website without written permission is prohibited
- _benj 6y ago> These things are a cancerous growth on the web. I'm a huge fan of minimalism using gopher:// frequently. But blanket statements like this seems seems a little too much. I'm personally aware of some educational tools that non-techy educator are able to use with just a user name and password. A few years ago in order to deliver tools like that the process was a physical CD, some key, some installation wizard... and if you had Mac? tough luck. Let's be conscious about bandwidth usage and bloat, but we are no longer in the 90's and, even if imperfect, progress has happened in tech
- harikb 6y agoTwo suggestions 1. Weight sites by some popularity count. Otherwise does anyone care if some random small site generates a 0.1k response just to get to the top 2. Do you plan continuously verify the download size is still accurate.
- stabbles 6y ago1. maybe weight websites by alexa rank? 2. some selenium github action would pretty much automate everything
- aresant 6y agoFrom a "Why, who cares" perspective website (and app) speed are highly correlated with conversion and engagement. Google's headline research on the subject says "Improving your load time by 0.1s can boost conversion rates by 8%." Some add'l data, sourced by Neilsen Group below: - Google found that increasing the load time of its SERPs by half a second resulted in a 20% higher bounce rate. - Google found 53% of mobile visits ended if a page took longer than 3 seconds to load. - Akamai aggregated data from 17 retailers (7 billion pageviews) and found that conversion rates were highest for pages that loaded in less than 2 seconds; longer load times correlated with 50% drops in conversion rates and increased bounce rates, especially for mobile visitors. - BBC found that for every extra second of page load time, 10% of users will leave. Want to sell / fix this? Here's the best three simple resource illustrating objective third party results from increasing site speed: - https://blog.hubspot.com/marketing/page-load-time-conversion-rates https://blog.hubspot.com/marketing/page-load-time-conversion... - https://wpostats.com/ https://wpostats.com/ - https://www.cloudflare.com/learning/performance/more/website-performance-conversion-rates/ https://www.cloudflare.com/learning/performance/more/website... Here is a more compelling deeper look from a leader in the UX space: - https://www.nngroup.com/articles/the-need-for-speed/ https://www.nngroup.com/articles/the-need-for-speed/ Here's a really well written article about how to PROVE to the powers that be that site speed is worth testing: https://web.dev/site-speed-and-business-metrics/ https://web.dev/site-speed-and-business-metrics/
- chrisin2d 6y agoI used to work for a major e-commerce company and will back this up. The importance of performance, of course, depends on the use case. In e-commerce, the biggest factors (that come to mind) to compete on are—SEO and brand aside—price, offerings, and convenience. Convenience has two dimensions: UX and performance. If a user has a very clear idea of what they want from your site, they'll probably be patient. If a user is channel surfing (and the vast majority are when it comes to shopping, comparing options, etc.), then every millisecond matters. Every millisecond spent loading is a millisecond not spent selling/convincing.
- LeifCarrotson 6y ago
- ChrisMarshallNY 6y ago1MB. When I started writing Web sites (late '90s), we'd get spanked for 50K pages. I'm not sure it's possible, anymore, with a lot of the CSS and JS libraries; let alone the content. But back then, we didn't have content delivery networks. CDNs make a huge difference.
- Uehreka 6y agoWe also had super grainy images, no fonts (besides the default set) and no videos. We can complain about bloat, but I don’t think comparisons to the 90’s are totally appropriate, except as a dunk.
- ChrisMarshallNY 6y agoIf you note, it wasn't actually a complaint, or a dunk. It was an observation, and recounting some personal experience. What is bloat, as far as I'm concerned, is hitting a page with a 4K background video. If you want a real "I had to walk 2 miles, barefoot" story, I can tell you about writing [C]WAP/WML sites (the old "m.<yourdomain>" sites). I actually considered using XSLT to extract WML from the regular site HTML.
- scoot 6y agoSome of us are older than that
- petercooper 6y agoI was going to say that I remember coding towards a 35-50KB limit in the 90s. That'd get you a load time within 10 seconds on a typical modem of the era, if you were lucky! :-) Couple that with only being able to use hex colors at multiples of 00, 33, 66, 99, cc, and ff, as well as having to cater for 640x480 resolutions - great times.
- hinkley 6y agoI used what was probably the first 1MB page on the internet to discover why realloc() was not a smart choice for progressive parsing of content. I showed the problem to the lead dev and he cut the load time by a factor of ten in as many hours. NCSA had a web page where you could list your web server and a couple of sentences about it. Which was great until Netscape came out and everyone was setting up web servers. This was back when Lycos was news to most people and Alta Vista was just launching. It was a poor man’s Yahoo. I don’t think it was a coincidence that the end of its usefulness came so close to the birth of better alternatives. The ungainliness of the status quo is usually what goads someone into trying something new.
- ergwwrt 6y agoOn a curious note, what's Hacker News score? Seems ala carte minimal no?
- jedimastert 6y agoChrome Devtools says a very respectable 62.6 kB
- petercooper 6y agoCurious, even with cache disabled I get somewhat less (13.2KB) but I assume that's what came over the wire and then expands after it's inflated(?)
- colordrops 6y agoWhere's the Nginx landing page.
- justinzollars 6y agolol Jira is 24 MB.
- yellowapple 6y agoI love it! I feel like the 1MB limit is excessively generous, especially for text-only pages. But maybe that's what makes it so damning when pages fail to adhere to it. I know at least one website I maintain fails it spectacularly (though in my defense it's entirely because of that website being chock-full of photos, and full-res ones at that; pages without those are well under that 1MB mark), while other sites I've built consist entirely of pages within a fraction of that limit. It'd be interesting to impose a stricter limitation to the 1MB Club: one where all pages on a given site are within that limit. This would disqualify Craigslist, for example (the listing search pages blow that limit out of the water, and the listings themselves sometimes do, too). I also wonder how many sites 1mb.club would have to show on one page before it, too, ends up disqualifying itself. Might be worthwhile to start thinking about site categories sooner rather than later if everyone and their mothers starts spamming that GitHub issues page with sites (like I'm doing right now).
- divbzero 6y agoAgreed. 1MB seems more reasonable as a per-site threshold. Or, alternatively, somewhere between 10kB and 100kB as a per-page threshold. For context, 1MB is the same order of magnitude as the original Doom which was about 2.4MB in size. [1] [1]: https://www.wired.com/2016/04/average-webpage-now-size-original-doom/ https://www.wired.com/2016/04/average-webpage-now-size-origi...
- Chris2048 6y agoI think it should be relative to content. As in versus actual text on the screen. This metric can also be applied "per-page" and "per-site", with less ambiguity for SPAs; every new load brings in more bytes, but also more text, thereby contributing to the ratio. Even better - fixed site-wide assets (i.e css, js) to features; hence loading an entire framework only to use a small % of it's features is penalised.
- highmastdon 6y agoDon’t forget that also 1MB of JavaScript is much much more heavy on the client than 1MB image
- deleted 6y ago[deleted]
- prague60 6y agoMy question for these kinds of complaints is, how do is it proposed we implement the same features and value that can be provided currently, with fewer downloas? Could we have Facebook without a huge download? Is this saying the web should not have these features? Are we intended to download each new application separately on a PC like we do mobile? I see so many complains about "the bloated web", but no solution that let's us keep the tremendous value the internet has given to the world. It just comes across so short-sighted and reactionary.
- gcblkjaidfj 6y agoWould be better if ranked by size:content instead of size alone.
- sheerun 6y agoIt should be something like 100kb compressed, not 1MB uncompressed
- hinkley 6y agoThere is a problem I’ve wrestled with at pretty much every webapp job I’ve had. People decide it’s more economical to add more stuff to existing pages than it is to introduce a new page. As time progresses the number of pages goes up logarithmic to the amount of functionality. This hits on two fronts. One is pressure from the non technical people, who want the cost of new stuff to be O(1). “This is so simple. Why do you have to make it a big deal?” Makes sense the first time. Makes no sense at all the 58th time. The other one is that we don’t have an easy way to carve up functionality and move it around efficiently. Webpack and friends try to solve this problem, but it leaves a lot to be desired. It’s easier logistically to have the same giant couple of JS bundles where almost every bit of logic is available everywhere. Which makes it more tempting to expose all functionality everywhere. I discovered at one point that the quite effective strategy I used for maintaining mature wikis is essentially applying the B-Tree algorithm by hand, with depth weighted by recency (eventually all outdated documentation is relegated to the leaves, or updated in order to avoid relegation). I have a hunch you could do much the same for websites, but I haven’t worked out how to do it in a spirit of refactoring (stability is the first word, but progress has the final say). There’s a related issue with Conway’s law, where the links on the main page or in the footer are always proportional to the number of divisions in the organization, and the number of initiatives currently in progress or recently finished. This vastly increases the decision tree even when you avoid having a giant landing page. I’ve only seen one solution to this and that is to treat these links as what they are: ads. Ads are either short lived or get rotated frequently to avoid overwhelming the audience.
- gargarplex 6y agoThere might be an opportunity to write minimalist web clients for popular services.
- tomcooks 6y agoPlease accept email suggestions， I'd like to avoid needing github
- tslocum 6y agoProject Gemini was created for a similar reason. https://gemini.circumlunar.space https://gemini.circumlunar.space
- maxk42 6y agoThis makes me happy. My latest project (unreleased) has its entire front page - including CSS, Javascript, and images - served in a single request with an unminified response payload of just over 4k. Part of what made it possible was the Mu CSS Framework: https://bafs.github.io/mu/ https://bafs.github.io/mu/
- gandalfian 6y agoWar and Peace 1.3mb. Ah well, a two pager I guess.
- GloriousKoji 6y agoOr we could zip it up and then use javascript to unzip it and display on the client side.
- jefftk 6y agoThis is already built into the browser. Your browser sends "Accept-Encoding" listing what decoders it has (ex: "gzip, deflate, br"), and then the server may encode the body with any of them. If it does, it will send "Content-Encoding: gzip" or similar to indicate which it chose.
- jefftk 6y agoThis site is listing transfer size, so if you serve it with "Content-Encoding: gzip" (as you should) you should be all set.
- deleted 6y ago[deleted]
- commonturtle 6y agoThis seems to be a common sentiment among developers today but honestly bloat doesn't bother me too much. I do want good performance from my websites, but with fast internet connections, who cares if it is 1KB or 1MB? Also, if you can develop a website for half the cost with twice the size, isn't that the right thing to do? Developer time is the expensive resource, and bandwidth is cheap.
- droobles 6y agoA fair assessment for an MVP in the US, but you fail to scale globally if your site is bloated as not all countries and territories have the access to data at low cost the US has. Definitely worth it to optimize and reduce bloat after establishing your product's place in the market (or develop from the get-go with reducing bloat in mind).
- bityard 6y ago> have the access to data at low cost the US has I don't know where you heard that, the US has some of the most expensive and slowest Internet access in the developed world. https://www.numbeo.com/cost-of-living/country_price_rankings?itemId=33 https://www.numbeo.com/cost-of-living/country_price_rankings... https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds https://en.wikipedia.org/wiki/List_of_countries_by_Internet_...
- sirn 6y agoI don't think this chart really tell much because most services are hosted in the US which some of these country have small or no direct link to (e.g. Thailand is 6th fastest in APAC on average speed, but the whole country has total of 30Gbps direct link to the US and pretty much have to route everything via HK or SG) which sometimes result in horrendous latency (~500ms) or speed (< 1 Mbps). It's fast at CDN edge where these surveys are taken, but page sizes still matter a lot.
- bityard 6y ago1. Not everyone in the world has a fast internet connection, or even a reliable one. Smaller pages have a better chance of making it through congestion or physical layer problems. 2. Even when speed is not an issue, many people are billed by the megabyte. My phone's data plan for example. I almost never use it for anything more than email and a handful of very trusted sites.
- m90 6y agoStylistic nitpick: don't use the word cancerous for things that don't make too much of a difference for anything but your "ethos". Real cancer has people die (animals too). Bloated websites might be annoying, but you will survive them even if your the 1337est hacker around.
- ajsnigrutin 6y agoThe problem with bloated website is, that the cumulative time lost while waiting for them to load is (for many) measured in many, many years. Pages like google/facebook/... optimizing load time by a couple of hundredths of a second, means years of real people time saved.
- m90 6y agoI know it sucks waiting for a website to load, but it's not like your life depends on it. You can still be an overall happy person while doing so, time is not "lost". Performance metrics are better when put into perspective.
- yellowapple 6y agoI can definitely imagine situations where being able to load a page quickly is indeed a matter of life or death. This is indeed part of the design rationale for the min css framework: https://mincss.com/index.html https://mincss.com/index.html > Min is used by over 65,000 people in 195+ countries, from North Korea to South Sudan to Mongolia to Somalia. Think your software is critical? Try a webapp keeping you alive in a warzone. Now, whether or not this actually happens is a good question, but it does seem like a plausible possibility.
- fctorial 6y ago> I can definitely imagine situations where being able to load a page quickly is indeed a matter of life or death. Can you share some such situations?
- 6y ago
- javierbyte 6y agoI hate how people have to use "cancerous" everywhere. Out of respect please use a different word.
- poorman 6y agoHopefully the creator has plans to automate the Github issue verification process.
- nazgulnarsil 6y agoI want to blacklist sites over a certain threshold. Is there an easy way to do that?
- forgotmypw17 6y agoShameless plug: My page, a fully-featured message board with tagging and stats, private key based accounts, and optional JavaScript features, the homepage is much smaller :)
- stjo 6y agoDon't forget to plug your page at the end so we can check it out :D
- forgotmypw17 6y agoI thought that is what profile is for?
- crazygringo 6y agoI don't mind highlighting and curating small sites for fun, that's neat. But calling larger sites a "cancerous growth on the web" just feels immature to me. Everything is just cost/benefit. There's no need to bring a black-and-white fanatical exaggerated mindset to it. You can celebrate something you like without having to make the alternative a disease, sheesh.
- Aeolun 6y agoWith all due respect. Modern news websites are a disease, and I find it pretty hard to disagree with the nomer cancerous growth since the behavior is spreading, and normalized by these websites. There is zero benefit to me in loading 20mb of garbage just so I can read 10kb of text.
- fizwhiz 6y agohyperbole much?
- SulfurHexaFluri 6y agoYes news sites are the worst of the bunch but then we get people complaining about full web apps using JS when there is no real alternative.
- Aeolun 6y agoI mean, I agree full web apps are annoying to some extend, but if you’re loading a whole application in a few MB that actually seems kind of reasonable.
- from 6y agoThe problem is that sites that really had no business being "web apps" have turned into these monstrosities. The new Reddit and Youtube are great examples of this. The old versions worked just fine, but for some reason they were replaced with all Javascript versions that perform much worse.
- 6y ago
- mintone 6y agoI believe this is placing emphasis on entirely the wrong thing. Page size does not matter. Render time/time 'til functional does. Stripe.com is 1.2MB fully loaded but is pretty much all non blocking so it feels as fast as a very small site. By the time you've scrolled to the bottom of the homepage it's loaded >2MB. The convert pretty well, and my experience is that Stripe knows what they are doing better than most. So what should we be optimising for? Total page size? or a lightning fast experience with non-blocking content which can be as big as we require? IMO developers need to optimise for building fast sites, not light ones for the sake of being light.
- tonymet 6y ago1.2mb will only be fast on fast hardware and a fast network. You’re not accounting for p90 load times. Targeting small page size is a better indicator of audience wide performance
- pketh 6y agoyar, maybe it should've been about js size, ideally closer to the 200kb-of-js club
- yellowapple 6y agoI'd be down for that, but without the "k" :)
- Aeolun 6y agoMaybe we should optimize for both? Small page size is irrelevant if the loaded js renders the page unuseable for seconds, but the same thing is true on slower connections if you have to load tons of data in the first place.
- manjana 6y agoWould love to see a 1MB club for websites where there was a requirement they would have to make use of both FA, CSS & JS all at once. Or perhaps a 1MB SPA club. This is interesting though. Wonder what the average newly founded website sits at these days.
- divbzero 6y agoI like the use of CSS variables for the gray bars: width: calc(var(--data-size)/1000 * 100%);
- alphachloride 6y agoExisting search engines should add a query term to filter by page size.
- ravenstine 6y agoIt would be useful to tag or categorize those links. I can't imagine I'm the only one who won't click on some domain I don't recognize that doesn't suggest its purpose.
- e12e 6y agoThanks, especially for: https://john-doe.neocities.org/ https://john-doe.neocities.org/ I'm just looking at modern front end web again (we're using react, ant - and I've stockholmed myself into considering react with tailwind as a "lightweight" alternative... Nice to be reminded about truly simple html+css).
- ezluckyfree 6y agoah I like this one, thanks!
- mattbk1 6y agoWhat's a good framework for building lightweight websites? Or am I better off just writing HTML?
- deergomoo 6y agoDepends what sort of website really. If it’s best described as an app, Svelte seems good. Rather than having a big feature-filled runtime it does most of its work at compile time, so your bundle is almost always much smaller than something like React or Vue. If it’s just a static or almost static content I’d lean more towards just plain HTML, maybe with a little server templating.
- boplicity 6y agoHere's a common example, from a FAANG company: 72mb and 367 requests to display around 2,000 characters of text. Maybe double that if you count the "hyperlinks." Single page applications are horrible, and oh-so-common. https://imgur.com/a/v2rud7T https://imgur.com/a/v2rud7T
- deergomoo 6y agoThey really don’t have to be. Unfortunately a lot of them are just built really badly, by people with fast hardware and gigabit networks. With good code splitting, which is supported basically out of the box by Webpack and all the big front-end frameworks, I would argue a well-written SPA transmits less data in the long run than a fully server-rendered app. The initial payload is bigger by a few hundred KB sure, but after that: - Like server rendered pages, you still only load pages on demand, thanks to code splitting - Unlike server-rendered pages, you can cache everything except the data that changes, because it’s JavaScript not HTML. Yes you’re still making a request for fresh data on every page load, but while the code is cached you need only download the raw data itself. You’d have to be really clumsy to send a JSON payload bigger than a full HTML document containing a rendered representation of the same data. Of course, this only really applies to apps. Static or infrequently changed content, you’re better off either server rendering or just serving static files. You can also make the argument that it would be more efficient to serve mostly static HTML, with the bare minimum JavaScript required to fetch new data, but ultimately everything is a trade off :)
- scoot 6y ago72 millibits doesn't sound feasible for even the most minimalist of websites. ;) Seriously though, this isn't just a "grammar" thing. If you don't know the difference between millibits and megabytes, you probably shouldn't post on the subject of page size (or anything else relating to bandwidth consumption / network performance).
- stjo 6y agoI understand what you are trying to say - proper use of units is important, especially on a technical topic. The SI[0] is simple, everybody can take a look and understand it in a minute and never make a mistake again. But you really don't need to be so condescending. I still hate it when people flag comments like yours because maybe it sounds "offensive" or something, but you can improve your tone too. [0] - https://en.wikipedia.org/wiki/International_System_of_Units https://en.wikipedia.org/wiki/International_System_of_Units
- phkahler 6y agoCan't they automate this?
- idlewords 6y agoThe submissions page for this project is 1.8 MB, which seems kind of against the spirit of the endeavor.
- mNovak 6y agoHow much of these bloat libraries / frameworks does the browser cache, vs how much is downloaded fresh each time (looking across multiple sites)? Are there no tools to extract only the portions of js / css etc that your site actually uses, and just host that mini package yourself?
- arendtio 6y ago1MB seems to be a bit much... A few years ago I wrote a little blog software which is based completely on JS functionality (including i18n and page transition animations) and doesn't work without it. So much so that no search engine ever finds the posts (my mistake, if you would do it right, that should not be a problem nowadays). And yet, loading a page is less than 1 MB. In fact, loading the HTML and JS only, the page would fit in 100kb. The Webfonts are responsible for most of the traffic.
- globular-toast 6y agoInstead of being an absolute number it should be a ratio of useful information/size, or a signal to noise ratio. It's quite hard to calculate in general, but it could probably be done by rendering the page something like Firefox's reader mode and taking that as the signal and the rest as the noise.
- mnsolo 6y agoUsing the phrase "cancerous growth" is really poor form. Do you really think a 300ms page load resembles someone fighting for their life?
- pippy 6y agoThe culture change around the importance of performance is frustrating, new developers all seem to love their massive JavaScript libraries. Giving a trivial function such as search box on a webpage or some animation results in a convoluted 10MB JavaScript monster from hell. If they run into anything remotely challenging they'll simply add a library to do it for them creating more bloat. It used to be the opposite. When asked 'why not just some jQuery and DOM'? they'll reply it's too hard. React, webpack, node etc are great tools but they need to used carefully.
- that_guy_iain 6y agoFor most apps that I've use, jQuery and DOM would be able to do it, just no where near as well as react or vue. We're building web apps that are highly responsive with lots of UI effects. Even when it seems like there isn't much FE code going on, you'll normally find that majority of it is now done with preloading and XHR calls to give a smoother feeling. As long as a site fully loads within 2 seconds then I'm ok with that.
- SulfurHexaFluri 6y agoReact/vue/etc are not massive libraries. The problem usually comes from websites loading 5 versions of jquery and then 30 ad network scripts. And yes, doing anything mildly responsive with jquery is too hard. And not in the "I don't know how to do this" way. Its just a huge waste of time. What takes 100 lines of jquery code can be done for free with jsx. Usually jquery sites settle for sub optimal UX because its too hard to do the things react sites do.
- pippy 6y agoYes, what I was alluding too was that new tooling tends to make it easier for client resources to explode out of control. Don't get me wrong, jsx is great. but it should be used in the right place.
- Drew_ 6y ago> Giving a trivial function such as search box on a webpage or some animation results If you want great UI and UX, these are anything but trivial. This is why taking an off the shelf solution is preferable to reinventing the wheel in the pursuit of marginal improvements of speed (not mentioning 3rd party solutions are often still faster than what you could whip up in a day or 2).
- gitgud 6y agoI guess the leader is missing "packet.city" an entire website in a single TCP packet weighing in at 1.2kb Site: http://packet.city/ http://packet.city/ Source: https://github.com/diracdeltas/FastestWebsiteEver https://github.com/diracdeltas/FastestWebsiteEver
- chacha2 6y agoTakes the same 1 second to load that every website takes.
- gitgud 6y agoYeah agree, I only mentioned it facetiously to make fun of the idea of a list ranked by download size. CDN's, network speed, server load, page render time, all have a greater effect than the fractions of kilobytes that differentiate these sites...
- Semiapies 6y agoLoud sound warning would be nice.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- codingdave 6y agoI checked out a Wordpress site I run, and it comes in at 374K, when I have put zero effort into optimizing it. I feel like 100K would be a far more meaningful bar to set for this kind of collection.
- slmjkdbtl 6y agoMy theory is more stuff almost directly means less user experience. More stuff always requires more design knowledge, which is an extremely scarce resource.
- seanwilson 6y agoHere's my example of a non-trivial product landing page weighing in at 0.3MB transferred: https://www.checkbot.io/ https://www.checkbot.io/ Includes analytics, chat client, big product screenshot, theming and payment integration, so you can still do a lot well within 1MB.
- keb_ 6y agoThanks for the example. Looks awesome! Great work.
- mcdevilkiller 6y agoIt's really really good, congrats!
- imperialdrive 6y agoKUDOS - That's pretty darn impressive alright.
- sr1 6y ago0.006MB on brave :)
- deleted 6y ago[deleted]
- bob1029 6y agoJust checked our newest Blazor server-side web administration site in chrome devtools. 12 requests total, 322kB transferred (914kB uncompressed, so either way), finish in 991ms. Request was made between Texas and AWS us-east-1. Server running on a T3a instance. This is .NET Core 3.1 on Windows Server 2019. Of the 322kB, blazor.server.js is 39.2k and our JS interop shim is 3k. This represents all that is required to communicate between server and client. The rest of the static source is ace code editor, bootstrap, jQuery and open iconic. All remaining interactions happen as deltas over the websocket connection. Every day that I work with Blazor, I am further convinced that it is the only way to build our web applications moving forward. I don't have a good answer for Blazor server side in mass-scale public-facing scenarios (a la Netflix), but anyone can come up with an edge case to poke holes. Our 'internal' dashboards are actually accessible from the public web and we have not experienced any DDoS or other performance incidents. If something does come up, I will just pop the VM over to the internal network & require VPN access. That said, I really prefer accessing Blazor server side apps as directly as possible due to the latency concern.
- ksec 6y ago> Blazor Does that mean LiveView? I guess we need a term for that since every framework is using a different name for it.
- tester756 6y agoThat's pretty interesting So, instead of sending tons of js on the client side that does the job, let's connect via websocket to the server and let the server return HTML with new content dynamically, yea?
- bob1029 6y agoCorrect. The way Blazor produces DOM updates is pretty interesting. There was an excellent NDC talk that does a deep dive on how all of the internals work: https://www.youtube.com/watch?v=dCgqTDki-VM https://www.youtube.com/watch?v=dCgqTDki-VM The amount of javascript interop that I have to maintain in order to support a very complex Blazor application is somewhere around 200 lines at the moment.
- koehr 6y agoI love the idea and I think it is a very reasonable, although generous limit. Excessively generous, as @yellowapple called it, maybe. But I am indeed surprised to find not only tiny blogs and personal homepages on this list, but also government (gov.scot, gov.uk) and other resource intensive pages. Despite all that, I propose an additional, even more exclusive club, because the internet needs a break. I propose 250kb compressed first-load size.
- IceHegel 6y agoUnpopular opinion: I agree that all else equal a smaller bundle is better, but I don’t think “cancerous growth” gets at the core of why bundle sizes are growing. Some part of the growth is bloat(analytics frameworks, janky animations, needless SPAs), but another factor driving bundle size is the fact that the raw web is mostly unaesthetic and unnatural to use, HN excepted. The DOM being what it is, you need a lot of code to make it look like a native app, and I think it’s a noble goal to get as close as possible to native even if bundle sizes grow.
- notJim 6y agoI wish sites like this could take a positive tone instead of a negative one. Referring to sites that don't conform to your pet preferences as cancerous is deeply off-putting to me.
- toast0 6y agoGrowing without bounds is kind of a defining trait of cancer. It seems pretty apt to me, although it's certainly also hyperbolic.
- Legion 6y agoThis reminds me of people who buy powerful machines, then run the most threadbare Linux environment possible and freak out anytime the machine's RAM and CPU aren't completely idle. I do miss the lightweight early/mid 90s web sometimes, but I have no interest in artificial constraints that treat smallness as a virtue in and of itself.
- kerryoco 6y agoguilty as charged
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- jameslk 6y agoUnpopular truth: Lowering page weight doesn't often help web performance. https://www.speedshop.co/2015/11/05/page-weight-doesnt-matter.html https://www.speedshop.co/2015/11/05/page-weight-doesnt-matte... > Bandwidth is not the problem, and the performance of the web will not improve as broadband access becomes more widespread. > The problem is latency. Most of our networking protocols require a lot of round-trips. Each of those round trips imposes a latency penalty. Latency is governed, at the end of the day, by the speed of light. Which means that latency isn’t going anywhere. Of course, this will get downvoted on an all-text forum. That won't make it less true.
- franciscop 6y agoCongrats on the launch! I've been wanting to do this forever, in fact still own 100kb.org which sits there unused in my cemetery of domains (working on other stuff!). As others say 1MB feels too generous.
- justiceforsaas 6y agoGuys, add a search box where people can enter their site & see "if they quality". If they don't, and enter their site again (and are <1MB), maybe you can add them in a "Recent improvers" list. I think this will motivate even more websites to participate.
- mod 6y agoHopefully on-topic: Can anyone recommend a drop-in, minimal stylesheet that will make basic HTML (without classes/ids) format well on both web and mobile? In particular, by default stuff is really small on mobile screens, you have to zoom around. Basically bootstrap, but more lightweight and without the effort of learning all the classnames etc.
- account42 6y ago> In particular, by default stuff is really small on mobile screens, you have to zoom around. That's just because mobile browsers are intentionally broken by default. All you need to get them back to sanity is the following element in your <head>: <meta name="viewport" content="width=device-width, initial-scale=1">
- 8589934591 6y agoI use hugo theme (even) - https://themes.gohugo.io/hugo-theme-even/ https://themes.gohugo.io/hugo-theme-even/ which seems pretty decent in terms of performance. There's some heavy loading of fonts and js, but it still comes down below 1Mb. Maybe you can derive some inspiration from it.
- mod 6y agoThat's nice, thank you.
- ghostpepper 6y agoIronically this site is taking upwards of a minute to load
- amw-zero 6y agoUsing a large amount of memory is totally fine for an enterprise SaaS app that a user is going to spend multiple hours a day in. There isn’t a one-size-fits-all web. Not every app is a blog or serving text content.
- psyklic 6y agohttps://restofworld.org/ https://restofworld.org/ initially loads <1M. But when you scroll down, it balloons to 3M as it loads more images. Should that count?
- skavi 6y agobeautiful webpage either way, and remarkably small for all the media it includes.
- every 6y agoNot much interested in arbitrary size limits. Far more interested in the content/size ratio. Especially if given the option to see more and weightier stuff if interested. My favorite example, that I use daily, is: https://text.npr.org/ https://text.npr.org/
- m463 6y agotext.npr.org - wow!
- rawoke083600 6y agoWould be awesome to see a breakdown of the tech on the sites. I just checked my "svelte site", data transferred is 1.1Mb. The biggest hog seems to be Google-Ads(I'm sorry)
- system_liaf 6y agoAny other Indian website in the list other than Zerodha.com?
- kerryoco 6y agoto make the 'small impact' much bigger - can someone turn this list into a search engine ?
- scottisbrave84 6y agoThis is a youtube dl production.
- k_sze 6y agoI have a blog generated using Pelican, using a slightly modified version of the pelican-bootstrap3 theme. This makes me feel pretty guilty when I realize that my blog is loading 118.18 kB of minified (!!) css, and almost 200 kB of web fonts, even though the front page of my blog still doesn't exceed 1MB overall. (And I actually don't like the current theme of my blog that much anyway. I have a hard time picking a clean, "brutalist" theme.)
- marcan_42 6y agoKeep in mind that this might discriminate against CJK pages. While it is trivial to design a beautiful webpage in 1MB for a Western audience including CSS design and western fonts, a single CJK compatible webfont (one style/weight) is 500kB-1MB. My blog is pretty lightweight, but I use Japanese in the about page, and that font on that page blows everything else out on download size. I could subset it just for that line, but consider sites containing entirely CJK content...
- jaclaz 6y agoIt's a refreshing initiative, personally, since a few years I am using the DOOM as unit of measure for bloated websites: https://twitter.com/xbs/status/626781529054834688 https://twitter.com/xbs/status/626781529054834688
- ay 6y agoI wonder if this is possible to write an extension that would allow to allocate a user-defined “data volume budget” to a site when the browser starts to load it, and hard-cut the process after this budget has been exhausted, and render the page using whatever it managed to download.
- XCSme 6y agoThis is interesting, but maybe instead of hard-cut maybe we could serve different website versions depending on the budget (eg. the same way we do with srcset for images). Client requests page with 500kb budget? Send text-version with tiny images. Client requests page without any budget? Send full rich version, with full-res images.
- deleted 6y ago[deleted]
- phazy 6y agoOne truly useful service. I would love a Search Syntax feature for Google or DDG where one could specify the maximum size of the showed sites. This would definitely improve the results as in many the cases the most useful resources are text-only.
- chiefalchemist 6y agoI agree. Too much bloat. Too much using a Technology X hammer when a screwdriver is what's need. That said, the metric here is too blunt, too broad. 1) We need to call out avoidable bloat. A simple example: too often I'll visit a site where say the full-hero image is full width and full height. The problem is the same 300-500k+ image that's served to desktop is served to mobile. No media queries (if they're using background-image), no sizes and srcset if it's an image tag. 2) It's about expectations. Some site are naturally image heavy (e.g., photography). Within reason, that's acceptable. Some use of lazy load is better than paging, and such. 3) And do we throw the baby out with the bathwater? If a site is slightly bloated but accessible, I think there should be redeeming points for that. That is, you had X or Y amount of resources and you made #a11y a priority, at say the expense of trimming some bloat. I'm okay with that.
- imtringued 6y agoIs there an award for the opposite? Sites using more than 3 GB per visit? I'd win that one.
- sparker72678 6y agoBack in my day we did our websites in 5k. https://the5k.org https://the5k.org
- tukinaf 6y agoOn Bear Blog all the blog pages are roughly 4kb. https://bearblog.dev https://bearblog.dev
- daotoad 6y agoAnyone remember the5k? https://the5k.org/ https://the5k.org/ In my day, we'd tie an onion to our belt.
- pyuser583 6y ago1MB is several novels. That being said, one of the top sites is text.npr.com. It’s cool NPR has that (from an accessibility standpoint), but it shouldn’t get any awards for compact design.
- deleted 6y ago[deleted]