1MB per photo is fine. It's the content after all.
Many sites today will load 10MB of JS and custom font crap alone, just to show a few paragraphs of text.
I don't think the point is the size itself, but it's the content vs. bloat ratio.
Many sites today will load 10MB of JS and custom font crap alone, just to show a few paragraphs of text.
I don't think the point is the size itself, but it's the content vs. bloat ratio.
Someone should invent an HTML tag for putting images on a page.
When I was implementing this, I initially experimented with the img tags – easy to implement, easy to have multi-color icons. But the grid can potentially have 100s of rows, potentially resulting in 1000+ of img tags. When testing with img tags, my site became noticeably sluggish (on a quick desktop PC). With icon fonts, the icon grid is basically lines of text, and the browser can render it with no noticeable performance impact.
https://stackoverflow.com/questions/37940282/changing-the-st...
But the "wrong tool for the job" point still stands, users with custom fonts disabled (for performance or accessibility reasons) will not be able to see your icons.
Why not? I don't know, you're asking the wrong person, I use a CSS font too. My reasons are (a) last time I looked into putting SVGs into a sprite-map to avoid 1000 HTTP requests it was a shitshow (not well supported), and (b) Chrome and other browsers would sometimes align the SVG on a half-pixel causes the edges to be a little blurry, whereas fonts get special treatment to ensure they are crisp. That was years ago tho.
The only annoying thing about turning off fonts is the weird settings ProtonMail and GitHub use.
For others wondering how:
about:config
gfx.downloadable_fonts.enabled (set to to FALSE)
In general I recommend using the default font for "body text" because you know it is something that the user finds easy to read. For headings, buttons and smaller strings of text you can be more creative but even then you can consider things like trying system fonts first and deferring the custom font load until after the content.
A lot of users don't know how to or can't change the default font. For instance, I have no idea idea how to change the default font on my phone, or even if I can. It's probably better to say "at least you know it's something that was selected to be at least tolerably usable by most people, which cannot be said of the design team's fancy spindly small-x font".
If it’s a gallery photo for a site promoting a photographers skill or library, nah…
1MB per photo is tiny when the photo is the content. You need ~100KB for a high quality 512x512 WebP. AVIF will be slightly better but still doesn’t have universal support.
We’ve had 4K (8MP) screens for a decade now and normal DSLRs shoot 25MP so you can zoom in.
In the US as of 2020, it was 3KG CO2 per GB Data.
You might argue that if people download more data, more equipment needs to run to enable it, but really all this energy consumption is happening regardless of my PC being idle or saturating its fiber pipes with torrents. If your website weights 14kb, all this same equipment needs to be on for my PC to load it.
You computer will normally down-clock (you can turn this off in the bios) when under lighter loads.The difference between a JS-free webpage and a bloated web page that uses multiple JavaScript with extra Javascript for ads and tracking could be around 10W/H to 40W/H on Desktops.
> Bandwidth is extremely carbon intensive.
and the reasoning that supports that statement.
Given that they could be streaming 1080p video instead, I think viewing a few photos is a relatively harmless hobby
edit: I'm not saying don't do it if you can get away with a smaller image dimension, or do basic optimizations... but if your concern is the environmental impact from a simgle high-resolution image from a photography site, you're putting the emphasis in the wrong place.
Here's a test case, using a moderate sized (3000x2000) image. Nothing ridiculously huge or anything, and it's not an especially complex image. I'm linking the best I can do for both JPEG (at 200 KB) and AVIF (at 100 KB). If you can create a passable versions of these images at 100 KB with either codec (or WEBP for that matter), please do show us how.
Original image: https://0x0.st/o9x5.png
JPEG (200 KB): https://0x0.st/o93i.jpg
AVIF (100 KB): https://0x0.st/o9xC.avif
Maybe JPEG XL will get us closer, but not all the way there, that's for sure: https://0x0.st/o9xd.jxl - JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.
In any event, I don't think the AVIF result at 250 KB is acceptable for photography either: https://0x0.st/o93a.avif - There's a ton of smearing and blurring that's very obvious when you're viewing the image at full size.
But all photo should be loaded at a much lower size, initially, and only downloaded at full size the the user puts them in full screen.
Maybe gallery sites could consider offering a preference to load all images upfront if you intend to view them all.
A good example would be housing sites, where viewing higher quality photos of each listing is a primary use case.
It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.
bpp = bits per pixel, not bytes. At 1080p, "0.05-0.1 bpp" is 13-26 KB. Much smaller than what you were testing. Might want to recheck your sizes, if you are actually looking at 0.5 bpp it would not surprise me at all that you found JPEG XL superior.
At very small sizes like 0.1 bpp the results are debatable, but I think AVIF is a pretty clear winner if you aren't too bothered by blurring. Samples at 0.15 bpp:
https://afontenot.github.io/image-formats-comparison/#air-fo...
https://afontenot.github.io/image-formats-comparison/#citroe...
https://afontenot.github.io/image-formats-comparison/#festa-...
Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-p...
I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel.
I could be wrong; my memory has faded. Please correct me if this is the case.