Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



Don’t forget that also 1MB of JavaScript is much much more heavy on the client than 1MB image


Indeed, but you also get more bang for your downloaded buck.

My toy project https://k8.fingswotidun.com/static/ide/?gist=ad96329670965dc...

Gives you an emulator, an 8-bit AVR Assembler, and an IDE for just over 500k transferred. Almost all of it JavaScript.

Using math.js is by far the heaviest part but at least your Asm already knows things like solarMass and planckConstant :-). CodeMirror comes in second heaviest but for user-experience-per-byte you're always going to be streets ahead of a gif.


True, but clients can opt to not load (or lazy-load) images without too much adverse effect. JS-heavy sites often completely break without JS.


Yours is an exception to the rule - in 99% cases for 1MB of JS you get 1 MB of ads/tracking code.


> Indeed, but you also get more bang for your downloaded buck.

Yet this is most times used to load React to make a button clickable.


At the risk of over-complicating things, perhaps there could be limits per resource type. 10Mb of images might be reasonable (e.g. for a photojournal), but only 128KB of JS, and 128KB for everything else. Something along those lines.


Yeah I was surprised they included pictures in the limit at all -- I mean, sometimes, you need those pictures, and for them to load slower is less important so long as you don't need them to navigate the page.


Well if you need them you can't be a part of this 1MB club.

It's not a bad thing, it's just a thing.


If you were able to calculate the space in the document flow for those images, I'm fine with the lazy loading. I hate when the page text appears rendered long enough that I start reading, but then lazily loaded items cause the flow to rearrange the text so that I lose my place.


I imagine it should be pretty easy with javascript to set up dummy images, and replace them... probably also doable in pure css, just make them a block element or something, with a set size...


You don't have to imagine everything. Normally the lazy-loaded image should be seeded with transparent SVG that as the same dimension. It's a solved problem.


I miss lowsrc. It had a point.


Wasn't this what progressive jpeg was invented for?


I’m not surprised. The whole point of it is that you can reasonably load it over 3g.

If you have a few megs of images that never show up because they take too long to load, there is no point.


You dont really need full size/resolution images on a web page.


You people are why some sites have ugly blurry logos/images on my 4k screen


more the fault of the site devs for not using css media queries, or svg ;p


Does getting in the club assume you have a low resolution screen?

SVG only works in a few places.


You do for full width retina images on 1440p+ monitors.


Yeah true but even with small images, you can hit that cap quickly.


You could use SVG images.


Check out this app: https://webide.se/?disable=fonts,discoveryBar

It's over one hundred thousand lines of JavaScript code minified and Gziped into a 300KB bundle which should fully load in about 300ms on a decent computer.


That took 4000ms on a phone.


Which is still rather fast. Starting an IDE like Visual Studio on my desktop takes longer.


4+ seconds is hardly "rather fast", and being faster to start than Visual Studio is hardly glowing praise.


What hardware/tools did you use to measure?


It was about the same for me, and I used a simple stopwatch. Stopped the watch as soon as I saw anything on the page. I am on a fairly fast network, too


For me it wasn't a second on a Honor 10


> I feel like the 1MB limit is excessively generous, especially for text-only pages.

No kidding. I just checked and the average text-only page on my blog well under 100kb. Even the image-heavy front page is under 1MB...


I was pleasantly surprised to find the same!

Even the page where I used images came in at juuuust about the limit -- to the point where you'd have to make a ruling of whether the rest of the page gzipped counted because over the wire was technically <1MB but it was just above after decompress. The site does specifically say "downloaded", haha


Personally, I stuck to the 40K best practice recommendation for the basic web page as a target, which was in place when I started. Modified to up to 140K including webfonts. Notably, this is without images.

(This is a flexible target, depending on the complexity of a page. E.g. for a "bloated" page, a fully styled video display for competition winners showing 200+ entries and 280+ individual videos in categorized views is about 250K, including a few images, two and a half font families and the Vimeo Player SDK, but excluding the load of any external video streams. However, with compression we still manage the 140K mark.)

Then reality hits: Client insists on a full-width photographic hero image as it's still 2014. Usual controversies about a full-size intro video (autoplay, of course), we must have this highly intrusive chat asset installed, etc, etc… – And we easily blow the 1MB limit.


Something about all pages being under limit the limit instead of every page being under the limit changes the exact meaning to something that I cannot agree with. Which was the meaning I replied below and then wrote this after realizing you might of meant every when you wrote all.

Lets say you write a daily blog. A single A4 of text contains on average 3000 characters, your posts average slightly above that by being 4000 characters. How long until the text content alone is above the 1MB limit.

https://dictionary.cambridge.org/grammar/british-grammar/all...


I doubt you can find a single text blog on a specific topic that wouldn’t be improved by limiting it’s total text to 1MB.

Being more verbose is generally just poor writing. Now, using a separate website per topic seems like a silly limitation, but the more topics being discussed the less relevant the discussion.


Yeah, I did mean "every" rather than "all", as you put it. Though both would be interesting.


I think an onload limit is much more useful than file size.

A 700kB JavaScript page can take up to 10 sec. to render on older mobile devices. And a 500kB image can contain megapixels which will slow down non-PGU browsers.

Personally I always go for a max 2 sec. limit on all devices.


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


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


500kb is even crazy imho, unless you need to display media formats


Next level: The 1MB Quine Club.


Tiddlywiki


Do they check the 1 MB limit?


Looks like they do yes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: