Not for the whole web page, obviously. But you should still be aiming to maximize the impact of that first 14KB.
Ideally you want to deliver enough for the first layout and paint, so that someone can quickly see the frame of the webpage and then you want to minimize the amount of visual changes caused by subsequent data. Ideally the first 14KB should be enough to do the final layout. It might not have any images, but the dimensions of images should he hardcoded in the html or css so the layout won't reflow as the images come in.
Maybe it's worth putting in placeholder colors behind the images that complement the general color scheme of the image and make the load less virtually jarring?
And if 14KB isn't enough for the final layout, the bytes need to be prioritized for "above the fold", to maximize the chance that any layout changes happen off screen where the user hasn't had time to scroll to yet.
This block post is perhaps a little absolutist in it's title. But the advice seems useful for everyone and people shouldn't give up just because there is no way they could possibly make their pages small enough.
In your browser, open dev tools, go to the network tab and enable throttling. For fun, set it all the way down to GPRS speed.
Next, refresh that blog, you'll nearly instantly see the web page.
Then, refresh the HN home page, quite quickly, you'll see the list of articles in a bare-ish HTML page and a little later it becomes pretty when the CSS is loaded.
Finally, open any modern news site, since a news site is supposedly text-centric, it should be a fair comparison. I picked CNBC and it took 30 seconds for the first text to become readable.
I live in a country with ubiquitous broadband and near full coverage of 4/5G mobile internet, so for my country, this is a non-issue. Because of this, one of our most popular news sites takes nearly a minute to become readable at GPRS speeds. When I visit more rural areas in other European countries, this leads to me being unable to visit most web sites that were made for my country and it's extremely frustrating. Especially if you're in a bind and quickly want to find some information, because Google also takes ages to load over slow internet and is nearly unusable (and so is DDG, in case you want to try an alternative).
edit: No, it's not. It deals with TCP window but in no way does it deal with customers conversion, retention rates and all those things.
Those metrics would only be meaningful if the average visitor knew how fast websites and computers can be, and if there are well-known alternatives to your site. Having standards is preferrable to aiming for mediocrity imho.
YouTube probably has decent retention rates but it's a bloated pile of UX hell that people use for a lack of alternatives. Maybe that's why Google manages to make it even worse over time without realising they're digging a second Mariana trench of quality.
Of course visitors don't care about commercial and marketing metrics.
They clearly rely on other metrics to decide whether or not visit or stay on a site. And my question still stands: who has numbers or data that show that those 14kb pages perform better in regard to the commercial metrics than heavier pages ? And I mean in the field data, not a synthetic test.
A trivial search will find you tons of heavily reviewed research that shows web page performance directly impacts e-commerce conversion/sales and this is widely known in the industry. This article laid out a solid technical explanation for why staying under 14kb can have substantial improvements in performance. You refusing to see the connection there, or are you disputing it?
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...
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.
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.
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".
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.
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.
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.
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.
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.
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.
If it’s a gallery photo for a site promoting a photographers skill or library, nah…
Yeah if you're trying to fit the WHOLE web page into 14kb.
But you can get ALL the text there and have the images load in after. The first time I used a the static site generator Gatsby I was super weirded out by the blurry image that showed up upon first load of an Img. It will quickly resolve into a full quality image, ofc, but the point is a relevant metric is also time to first contentful paint.
Also the JS will load the rest of your pages while you're idling on the first page, so that's nice. It's not just good enough to have lazy-loading content, your strategy will have to change depending on how users use your site. Let's say 99% of people scroll to the right in a circular gallery of pictures. You should only really load pictures to the right.
The point is to have your initial page load under 14kB to get the most utility out of the initial TCP window size. It doesn't say you need to have an entire site fit into 14kB.
With GZip compression you could easily get a 50-60kB HTML document under 14kB. In 50kB you can easily have OpenGraph metadata, links to alternate representations (RSS etc), link/script tags for external styles and scripts, some base level inline CSS, and some actual useful content. In your initial 14kB sent over the line you can tell the consumer everything they'll need to load the rest of the page's content.
If the content is a blog post or news article it would not take too much effort to fit all of the text content into 50-60kB and progressively enhance it with CSS and JavaScript with minimal content repaints. A few lines CSS in a style tag will give you perfectly readable text content and allow for images and such to load without repaints.
Even an image gallery can have a useful 14kB initial load with img tags containing a height and width and single line of CSS to give them some default background color or pattern before an image loads. Even if you want to do a bunch of stupid effects that can all be done with JavaScript loaded after the initial small TCP window loading.
The idea is to give a browser something useful in the brand new connection so it can start loading and rendering. If the first few packets contain a usable scaffold of a larger more involved page, even users with shitty connections can have something besides a blank page to look at. Done right they could have an actual useful page even if none of the extra content loads.
However, quickly loading the bulk of the website and perhaps having a placeholder for the image that has yet to load will still make the site better. I remember seeing something that allowed you to create really blurry placeholders that are tiny, but I can't find it now.
I would like to improve, but I feel like the fonts are essential for the look and feel, so I'm not willing to give up the fonts, so I guess the ~200kB is the lower limit for me.
(Of course, the fonts are cached on the next page load, so my site does load very fast after opening the first article. Only thing that bothers me is the layout jump-around due to font
Visitors will simply block them :)
The HTML itself is several hundred kB? Something’s very wrong there…
So if even a personal site being done with no deadlines, no pressure from management to include analytics etc. can't do it, because it wants to display a bunch of photos, then I don't think we can expect "web-scale" websites to achieve it.