6 ms·

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 imag

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 4y ago
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.
- tambourine_man 4y ago
  Exactly
- chubot 4y ago
  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.
  - bombcar 4y ago
    The number of massive 5+ MB images I've been able to shave down tremendously by doing no more than using https://tinypng.com https://tinypng.com is absolutely frightening ...
    - vanderZwan 4y ago
      Were all of those images transparent? As in, did they even need to be PNGs?
      - bombcar 4y ago
        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).
  - hypertele-Xii 4y ago
    > 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.
    - chubot 4y ago
      But (file) compression doesn't hurt the quality! At least not compared with post-production. An entire generation of music sounds like crap BOTH before AND after compression with mp3. e.g. Recent RHCP or Metallica records are squashed to hell if you whether you are listening to them on 1411 kbps CD or 128 kbps MP3. I'm not as familiar with image production, but if you think 100 KB is too small, then 200 KB is likely fine, and it's still many times smaller. Or make it 500 KB -- it depends highly on the image. I think the problem is that the way to use compression effectively is unfortunately not common knowledge and not really documented (maybe someone here has a good link)
nine_k 4y ago
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 4y ago
  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 4y ago
    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 https://news.ycombinator.com/item?id=32133656
Siilwyn 4y ago
With proper srcset and sizes attributes, that serve compressed images in a modern image format you'll usually get below 1MB.
chubot 4y ago
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 http://www.oilshell.org/blog/2022/03/backlog-arch.html
- pSYoniK 4y ago
  neat command! my homepage works out to 3,121 bytes and the longest article is 21,164. Never knew it's that small..
- speedgoose 4y ago
  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 4y ago
    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 4y ago
      The future is exciting (and warm)!
- hdbdhzuwb 4y ago
  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.
  - 4y ago

jl6 4y ago

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.

tambourine_man 4y ago
Exactly
chubot 4y ago
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.
- bombcar 4y ago
  The number of massive 5+ MB images I've been able to shave down tremendously by doing no more than using https://tinypng.com https://tinypng.com is absolutely frightening ...
  - vanderZwan 4y ago
    Were all of those images transparent? As in, did they even need to be PNGs?
    - bombcar 4y ago
      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).
- hypertele-Xii 4y ago
  > 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.
  - chubot 4y ago
    But (file) compression doesn't hurt the quality! At least not compared with post-production. An entire generation of music sounds like crap BOTH before AND after compression with mp3. e.g. Recent RHCP or Metallica records are squashed to hell if you whether you are listening to them on 1411 kbps CD or 128 kbps MP3. I'm not as familiar with image production, but if you think 100 KB is too small, then 200 KB is likely fine, and it's still many times smaller. Or make it 500 KB -- it depends highly on the image. I think the problem is that the way to use compression effectively is unfortunately not common knowledge and not really documented (maybe someone here has a good link)

nine_k 4y ago

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 4y ago
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 4y ago
  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 https://news.ycombinator.com/item?id=32133656

Siilwyn 4y ago

With proper srcset and sizes attributes, that serve compressed images in a modern image format you'll usually get below 1MB.

chubot 4y ago

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 http://www.oilshell.org/blog/2022/03/backlog-arch.html

pSYoniK 4y ago
neat command! my homepage works out to 3,121 bytes and the longest article is 21,164. Never knew it's that small..
speedgoose 4y ago
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 4y ago
  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 4y ago
    The future is exciting (and warm)!
hdbdhzuwb 4y ago
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.
- 4y ago