[HN Gopher] Two Years and over 700 Websites Later
___________________________________________________________________
Two Years and over 700 Websites Later
Author : bradley_taunt
Score : 110 points
Date : 2022-07-18 14:14 UTC (8 hours ago)
(HTM) web link (1mb.club)
(TXT) w3m dump (1mb.club)
| freediver wrote:
| You may want to consider dropping the criteria to 64k (if it
| can't fit in a RAM of c-64, it is bloated!). There are sites in
| your index like:
|
| https://www.pe-we.com/mengenal-kelebihan-dan-kekurangan-asur...
|
| that look like content marketing blogs also running google
| anayltics. Not sure if that was in the spirit of the project.
| vanderZwan wrote:
| I think arguably it was, if we assume we want to target the
| worst offenders, which are exactly those types of webpage.
|
| I'm sure there are other list sites for the truly "spartan web"
| peanut_worm wrote:
| > Total size of all member websites combined: 169.4 MB
|
| Apparently that is comparable to a single page load of digital
| ocean's blog
|
| https://news.ycombinator.com/item?id=32076634
| capableweb wrote:
| Did you try loading https://www.digitalocean.com/blog yourself
| and measure it? I just did, and saw it pulled down 4.28MB worth
| of stuff, which is way too high for a blog, but nowhere close
| to 169MB. Maybe there was a bug and they fixed it quickly?
| hombre_fatal wrote:
| If I load it in Safari and scroll to the bottom, it reports
| 27MB transferred with a 110MB total (decompressed) payload.
|
| Looks like an error since most of the transfer is large JSON
| files that seem to be duplications of all of the content on
| the blog, but I only glanced.
| 300bps wrote:
| What frameworks are everyone using to achieve small and fast page
| size?
| nelsonfigueroa wrote:
| Similarly, there's also https://512kb.club/
| harryvederci wrote:
| Proud member[0] of the 250kb club here, 1mb is bloat! :-D
|
| [0]https://250kb.club/withoutdistractions-com-cv/
| 8organicbits wrote:
| A quick check on pagespeed[1] gives me great performance numbers.
| Here is largest contentful paint (desktop):
|
| www.google.com 4.3 seconds (yikes...)
|
| 1mb.club 1.2 seconds
|
| (edit)
|
| news.ycombinator.com 0.7 seconds
|
| t0.vc 0.2 seconds
|
| tutor.0b.ee 0.3 seconds
|
| [1] https://pagespeed.web.dev/
| frontrowseat wrote:
| My next side project, this gave me the goal/hope to keep it under
| 1mb just to be in this club! The internet is too bloated these
| days, and I swipe away if it takes even a few seconds to load a
| webpage. We can all do a little better for our users
| xigoi wrote:
| 1MB is a low bar. Depending on what kind of project it is, you
| can go for way less.
| denysvitali wrote:
| <link rel="stylesheet" type="text/css"
| href="https://thebestmotherfucking.website/main.css">
|
| And you're done :)
| oefrha wrote:
| 1MB pages are _performance-oriented_ now. Apparently this isn't a
| parody.
|
| https://idlewords.com/talks/website_obesity.htm:
|
| > Today's egregiously bloated site becomes tomorrow's typical
| page, and next year's elegantly slim design.
| coffeeblack wrote:
| I remember 100kB as the upper limit for pages, but that was a
| time when internet connections were measured in kbps. So 1MB
| sounds reasonable.
| _Algernon_ wrote:
| >I shouldn't need sled dogs and pemmican to navigate your
| visual design.
|
| This was great. Thank you!
| bombcar wrote:
| As speeds get higher the amount of data that can "slip in"
| during the expected latency gets larger and larger. If your
| round-trip latency is 400 ms or whatever, why not have 1MB as
| your page if that comfortably fits into that latency?
| oefrha wrote:
| Complex web apps aside, the average page today doesn't have
| more information than five years ago. There's nothing useful
| to slip in.
| xigoi wrote:
| You know mobile data is a thing?
| whoibrar wrote:
| Glad to see this project grow, made my first pull request here :)
|
| Occasionally, I would go there and checkout random peoples blogs
| and its surprisingly how much great it can be. Some sites look
| good and are surprisingly fast. I love this collection.
| philliphaydon wrote:
| I just scrolled the list and saw craigslist.org, visited it, and
| its 2.3mb?
|
| Aren't the sites meant to be under 1mb?
| Minor49er wrote:
| When you submit a site, you also provide its Pingdom results
| from this link, which may be different from the in-browser
| experience:
|
| https://tools.pingdom.com/
| tambourine_man wrote:
| For folks who started web dev in the 90s, with 9600 and 1440kbps
| modems, 1mb seems way too much.
|
| Probably not always accomplishable with the high res hero imagens
| and videos we need these days, but we should strive for a web
| that's instant. There's no reason we should be waiting for a page
| to download and render with the bandwidth and hardware available
| today.
| jl6 wrote:
| A page with a big image should still be able to quickly load
| the important parts (text and layout) and then have the big
| image finish loading in parallel.
| chubot wrote:
| 1 MB is even too big for an image. Most 1 MB images won't
| suffer quality loss when viewed on typical devices when they
| are 100 KB or even 60 KB.
|
| And they should definitely be minimized for mobile devices
|
| I'd say that the only way a single web page should be 1 MB is
| if it has 10 or more images, which of course can be useful.
| hypertele-Xii wrote:
| > typical devices
|
| If you need to design for today, that's fine.
|
| If you're designing for the future, well, already pushing
| 4K. Your "looks just fine on most devices" image is gonna
| look like an eye-squintingly tiny compressed-to-hell JPEG
| from 1992 in a decade or two.
|
| Think about music. "Sounds good on most devices (earbuds at
| the time)" caused an entire generation of music to be mixed
| to shit. You expect everyone to remaster?
|
| My own website doesn't qualify because I have gallery pages
| with multiple 1MB works of art. I hope my works can be
| appreciated in the future, on better devices. If that
| excludes me from a tiny ring of web designers essentially
| running an ad hoc demoscene competition for who can make
| the prettiest page in 1MB, so be it.
| bombcar wrote:
| The number of massive 5+ MB images I've been able to shave
| down tremendously by doing no more than using
| https://tinypng.com is absolutely frightening ...
| vanderZwan wrote:
| Were all of those images transparent? As in, did they
| even _need_ to be PNGs?
| bombcar wrote:
| Many were JPGs (the "site" is unfortunately named based
| on originally being used for PNG mainly) - but yes, many
| were not transparent but were deemed to need to be PNG
| because it is "better".
|
| Made even more headway on some of the ones we could
| control by using SVG instead (images that are basically
| text shouldn't be PNG _or_ JPG).
| tambourine_man wrote:
| Exactly
| chubot wrote:
| Yeah I thought that was 1 MB per SITE, but it's 1 MB per PAGE
| which is WAY too big! I don't want to load that on my phone
|
| I just checked and my home page is 3,575 bytes, which is 280x
| smaller than 1 MB: $ curl
| https://www.oilshell.org | wc --bytes 3575
|
| The longest article on the site is ~5200 words, and less than
| 57KB, or 17.6x smaller: $ curl
| 'http://www.oilshell.org/blog/2022/03/backlog-arch.html' | wc
| --bytes 56672
|
| http://www.oilshell.org/blog/2022/03/backlog-arch.html
| pSYoniK wrote:
| neat command! my homepage works out to 3,121 bytes and the
| longest article is 21,164. Never knew it's that small..
| speedgoose wrote:
| I just did a fast.com speed test on my phone with 2 bars out
| of 4 of 5G and I have 400 Mbps.
| rustyminnow wrote:
| Neat! I just did a fast.com speed test with 3/4 bars of 4G
| and got 60 Mbps!
|
| I didn't do a speed test, but I spent the weekend in an
| area where I was getting 1 bar and probably 5 Mbps if that.
|
| 5G coverage even when poor, is optimal conditions - not
| baseline.
| speedgoose wrote:
| The future is exciting (and warm)!
| hdbdhzuwb wrote:
| That is just counting the markup you deliver for those
| requests, not your style and JS bundles, which I don't think
| is the spirit of the post.
| notriddle wrote:
| Or images. On pages like https://bors.tech and
| https://foodpartners.us the "bloat" is all images. The
| images are bigger than they were in the 1990's because they
| look better, even if you don't think they communicate more
| "information" people may still want them.
| nine_k wrote:
| I suppose that most of the time the culprits are not
| excessively heavyweight assets.
|
| Number one culprit is client-side rendering. Don't deploy an
| SPA where a statically rendered page suffices. Don't delay
| rendering until your whatever other JS loads. Use fewest
| trackers of lightest weight.
|
| Somewhere distant second places would be asset download times
| (CDNs help), TLS handshake times (don't overload your server),
| complicated CSS that prevents fast rendering, etc.
| DrBazza wrote:
| Many media websites are now so full of cruft, the actual text
| of the story is barely a few Kb, and the other multi-Mb
| assets are videos, video adverts, trackers, javascript cruft,
| unoptimized css, unomptimized images, "infinite scroll", and
| god knows what else.
|
| The irony is lost on these companies that if the page doesn't
| load quickly enough I and many other people navigate away
| before half the cruft that pays for the page has loaded....
| cercatrova wrote:
| You're in the minority. Apparently those types of websites
| generate much more revenue [0]:
|
| _I spent 3ish years making these kinds of websites
| (specifically those click bait-y "Can you name these
| Canadian snack foods??" quiz sites). They generate _a lot_
| more revenue. Like more than double.
|
| Digital publishing's main business model is paying as
| little as possible for 1 click and monetizing that click as
| much as possible on the other end. The sales "funnel" isn't
| a funnel here, its just two steps "1. Show link to article
| . 2. Show ads."
|
| Now if you're an organic heavy site like NFL.com, you get
| plenty of free clicks just by reposting articles to social
| media. Its more important to keep your brand strong with a
| couple of small, highly paid ad units.
|
| But if you're just an average publisher, you gotta
| literally pay for attention. It turns into a game of
| spending $1.00 for an ad on
| Facebook/Tabola/Outbrain/Snap/etc and trying to make $1.30
| when they land on the page.
|
| Long term bet IMO is still high quality organic content
| makes more profit, but you can still make a lot with 3-4
| engineers and average-ish content._
|
| [0] https://news.ycombinator.com/item?id=32133656
| Siilwyn wrote:
| With proper srcset and sizes attributes, that serve compressed
| images in a modern image format you'll usually get below 1MB.
| dimmke wrote:
| I'm really proud that two websites I designed and built are on
| that list, but especially proud of https://foodpartners.us/ which
| unlike a lot of the sites isn't a blog but is a full brochure
| style website for a business that would normally load many MB of
| crap if built by a normal agency.
| smingo wrote:
| Elegant.
| tut-urut-utut wrote:
| Wow. It's great, you have a reason to be proud.
|
| Clean, to the point, light, crazy fast, zero bloat, no external
| trackers. And it looks nice.
|
| The only thing I don't like are the banners that waste precious
| vertical space when seen on a 14" laptop, but can't blame you
| for that, given how prevalent it is nowadays.
| dimmke wrote:
| There is one external tracker - Google Analytics. But blocked
| obvs if you use uBlock etc...
|
| I also designed and built this site in 2016 - over half a
| decade ago and it still looks and feels modern. It's an
| interesting look at how web design trends have slowed down
| from how things went from 2000-2010 to 2014-Present.
| me_smith wrote:
| Nice website! Light and concise.
|
| This is probably a me problem but I read "Southeast" as
| Southeast Asia. Not the Southeast region of the U.S. I kept
| scrolling down and got confused for a second while it hit me
| what "Southeast" actually meant.
|
| Edit: thinking about it a little more, it might be because I
| live on the west coast and think of Southeast Asia food more
| than Southeast US food.
| drewzero1 wrote:
| I'm impressed by how 'normal'/modern some of these sites
| (including the Food Partners one) look for how small they are!
| My sites are small, but they also look like they were made in
| 2000.
| frittata wrote:
| Very nice. Is it wordpress?
| dimmke wrote:
| Yes
| gadders wrote:
| Snappy website.
|
| I also find it amazing to read about businesses that I had no
| idea existed.
| sonofhans wrote:
| You should be proud! That's an excellent website. It's clear,
| usable, attractive, light, fast, informative, and obvious. A
| wild outlier, in other words :)
| enraged_camel wrote:
| I like the clean design, but the marketing copy could use
| work. For example, "We're the leading southeast new business
| specialists" doesn't mean a lot, and also has a typo (region
| names should be capitalized).
| dimmke wrote:
| Fixed that, thanks!
| rozenmd wrote:
| I shipped a ~8KiB status page app last week, it's still early
| days, but even with the features I have planned I doubt the size
| will be above 10KiB.
|
| With frameworks like Remix it's easier than ever to write React
| and ship pure HTML/CSS.
| bob1029 wrote:
| I've been making complex biz admin websites for a few years now
| that fit in under 20kb (uncompressed) by cheating a little bit
| with web sockets and js eval. Blazor server-side is a pretty good
| approximation for what my technique looks like today.
|
| These websites are not the most accessible if we are factoring in
| network and platform concerns. But, they are by far some of the
| fastest (non-static) web experiences I have ever been responsible
| for. For employees in the same state as our datacenter, "instant"
| is really the best way to describe most interactions. We also use
| things like in-process SQLite for all of our persistence, so
| latency between button click & updated DOM is about as low as you
| could ever hope for.
|
| I think having lightweight & _fast_ web experiences is the key to
| building a successful technology business. When your customers &
| employees have to wait _seconds_ for each interaction to "come
| back", they are going to have way more time to think about
| competitors and spending their time/money/attention elsewhere.
___________________________________________________________________
(page generated 2022-07-18 23:01 UTC)