Hacker News Reader

Comment by GrumpySloth | Hacker News Reader

That's only doable with a text-centric website. I'm currently finishing a photography section for my personal website, and the gallery pages are several hundred kBs in size, while single photo page is almost 1MB in size (provided you load it on a 28" screen; browser will load smaller variants on smaller screens). Most of that weight is the thumbnails (and almost-full-size photo in the latter case). The only JS I have is 6 lines (before minifying) on single photo pages which allow you to go to next or previous photo with keyboard arrows. I don't use any CSS frameworks, just a single hand-written CSS file. I don't have any tracking, analytics, social media features or anything of this sort.

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.

View on HN

Even for media focused websites, this 14KB rule is probably still worth following.

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.

Even if not media focused, Is 14KB possible with modern web JavaScript frameworks? Asking as someone who builds only text focused web applications with very little vanilla JavaScript if absolutely necessary.

Is there number, data, lab test session that proves it's worthwhile ? I sometime feel like these are all KPI detached from conversion but since it can be measured we do measure it.

You can easily do a very simple test yourself to see whether (and in which cases) this is worthwhile:

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

Have U seen, lite.cnn.com

https://text.npr.org/ as well

that's what this blog post is about isn't it?

No, it's not.

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.

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

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

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.

> 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?

It will vary between industries and target markets. The best thing to do is a/b test it by synthetically giving your customers a slow loading page and seeing how it affects your metrics. I’ve only worked one place that was brave enough to do this and client loading speed was highly correlated to conversion rate.

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.

Omg just disabling custom fonts in Firefox speeds up the internet so much!

I wish I could do this without breaking all the obnoxious sites that use fonts for icons.

Someone should invent an HTML tag for putting images on a page.

I'm using icon font to show a grid of icons, where each icon can be clicked to toggle it "on" or "off". Example: https://i.imgur.com/EHYHVDw.png

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.

i too use an icon font, but if you want images you should use a spritemap. it shouldn't be sluggish.

I write a framework, not an app. In any event, I need to allow others to style my icons with their own colors. Hence I use a font. Is there a way to use SVG sprites or something, while also letting people control the stroke color with css? Seems yes: dont put CSS in the svg. But why not just use a font?

https://stackoverflow.com/questions/37940282/changing-the-st...

Yes, you can even put `color: currentColor` in your SVG file and then color it exactly the same way as your fonts (it'll use the current text color).

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.

If you can create a customized font file that is tiny and only has the icons you actually use, sure.

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.

SVG with <use> tags should work perfectly.

A lot of icon frameworks are moving to SVG embedded on the page. Better usability - compared to the lazy fontawesomes out there.

Fontawesome is also available as SVG.

I just accept some things break for icons, but hovering over usually shows what the button is.

The only annoying thing about turning off fonts is the weird settings ProtonMail and GitHub use.

https://prnt.sc/zoPQiiPKIeZy

Thanks for the tip! For others wondering how you can do this, go to Settings -> Fonts -> Advanced, and uncheck "Allow pages to choose their own fonts...".

Or use uBlock Origin, which will allow you to re-enable fonts if disabling them breaks a site.

I wish you could do this with Brave (without uBlock Origin).

After reading this fine tip, I did the same thing. Thank-you for the suggestion.

For others wondering how:

about:config

gfx.downloadable_fonts.enabled (set to to FALSE)

how do you disable fonts? Plugins?

Can check the comment from hiyer, that's all I did. Just be aware sites that use fonts for icons will look a bit weird.

uBlock Origin has that option.

about:config gfx.downloadable_fonts.enabled (set to false)

What's the substitute to not using custom fonts? Or is there a better way to load it? I'm having a hard-time convincing our brand team to defaulting to a system font.

For most things just using the user's configured font is almost as good, if not better. For cases where you really want to make something stand out custom fonts can be nice but you can also try using "font stacks" that the user has already installed.

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.

> In general I recommend using the default font for "body text" because you know it is something that the user finds easy to read.

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

Convince the brand team to pick a couple fallback system fonts and swap the brand font in after it has loaded. You will have a bit of content reshuffling no matter what you do but it's better than the alternative. There are directives to do this in pure CSS but I seem to remember they had some unfortunate implementation bugs so when I did this it was easier to do it in JS.

There is some interesting things you can do with font-display and other css properties. E.g hide text for up to 100ms, if custom font has loaded swap to it, if not use fallback font.

https://simonhearne.com/2021/layout-shifts-webfonts/

1MB per photo is massive. Its easy to compress photos down to 100KB or less.

This is simply false, even if you mean using AVIF.

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.

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

> and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p)

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

In the experimental Document-Policy HTTP header, "bpp" does seem to signify bytes per pixel.

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.

I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate

Downsize the 3000x2000 to the dimensions it will be displayed at and you will be able to go below 100KB.

What if it will be displayed at 3000x2000? I mean that's the whole conversation here, we're talking about images that are the focus point of the page.

Yes, then 100KB is usually not enough.

I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.

You replied to a thread about a photography website. I don't think 720p images are the norm for that use 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.

3000x2000 basically means "fullscreen on a retina display @ full resolution". You can only reasonably show one picture like that at a time. So it's completely OK to have the currently displayed picture at that resolution/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.

I know lazy loading is in vogue, but as a user it only ever seems to create problems for me. I’d much rather the website download all the images ahead of time on page load, so I don’t have to wait for full quality versions each time I full screen a different image.

This is the restaurant equivalent of : "We are at an all you can eat buffet, let me take 10 plates even if I only realistically will eat 4, so that if I want any more I don't have to stand up again".

While the other way (loading each image as you view them, or lazy) is functionally equivalent to waiting in line for each separate dish, which isn't quite so fun.

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.

Wat.

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.

Bandwidth is extremely carbon intensive. Someone viewing a couple of few 25MP images online could use 20g to 100g of CO2 (depending on compression).

We create 40kg of CO2 a day each through our diet, transport, consumption and other energy use. The idea we need to target our energy burden on Internet routers is absurd.

I lament the day this becomes policy to regulate average internet usage due to a few religious fanatics who fail to understand that higher levels of CO2 enrich the Earth, and that science has been sabotaged to suit political ambitions fueled by fear porn.

14 tons per year is pretty high. Most calculators estimate my usage at 6 tons per year.

The US average is 15 metric tons and that's production-based, ie counting exports and not counting imports. If you count imports and stop counting exports it would be higher. Now the US does rank highly in this measure but that's also where the 'typical' HN reader is. The typical reader is also well off which can make a huge difference(flights etc).

And how much carbon would they use having those photos printed out and mailed to them to look at?

Given that they could be streaming 1080p video instead, I think viewing a few photos is a relatively harmless hobby

Physical item that can be looked out for 20 to 50 years vs a digital image. Not the same thing.

The bandwidth used for single images is dwarfed... massively by streaming video content... I don't think it's a use case that is worthy of excessive time/effort to optimize for size because of bandwidth cost/effects.

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.

Source ?

https://www.emergeinteractive.com/insights/detail/does-irres...

In the US as of 2020, it was 3KG CO2 per GB Data.

I don't agree with the reasoning presented. It takes the estimate for the amount of energy that it takes to run the internet infrastructure and clients (141GW * 8765h in a year = 1235865 GWh), divides it by the amount of data transferred yearly (241 billion GB) and gets to 5.12kWh/GB.

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.

The website usage on the client side is more to do with resource usage. Unnecessary usage of Javascript is often what makes websites laggy.

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.

I agree with this. I was disagreeing with the statement

> Bandwidth is extremely carbon intensive.

and the reasoning that supports that statement.

If people used less bandwidth, less new equipment would be bought to serve the increasing demand. Less bandwidth = Less carbon.

Maybe, or maybe the new equipment is much more efficient than the one it's replacing. It sounds true, but you can't really tell if it is or not, and really my annoyance is in saying it costs any estimated amount of energy, or carbon, to transfer 1GB of data. It does not, the transfer itself is basically cost-less. What costs money is running the infrastructure that makes it possible, and that's much harder to measure.

What matters is the marginal consumption. It should be really small. Averages don't mean much. I can download one GB of Data for almost free, I doubt I would burn 3 kg of CO2 doing that

And who pays for that?

If it’s an illustrative photo for an article, sure.

If it’s a gallery photo for a site promoting a photographers skill or library, nah…

Its best to have a compressed low res thumbnail that you can click to open the full resolution file in another tab imo

That 1MB is the full resolution image you open in another tab.

In that case, it shouldn't be counted into the webpage weight.

Wondering how. The banner image won't be displayed by Facebook or Twitter unless it's 1200x650 in size.

Webp could be worth trying. Stripping metadata also. If staying with jpg - Jpgoptim could help.

I done photos larger than that at closer to 50KB with AVIF. 100KB with JPEG should be doable.

> That's only doable with a text-centric website

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.

Optimize your images ( use imgix by example or thumbor ( open source version) . Lazy load the images below the fold. For the images above the fold, use 103 Pre Hints headers ( as well as for your css and js). Make sure to inline your critical css . Use http2. Your website won't be much lighter ( picture will be ), but it will be way faster.

I dont really think it matters as long as all resources are present to layout the site (html, css, synchronous js). As long as the img tag have width and height specified so they dont cause a reflow when loaded, i dont think it matters if they load a little later.

Tell me you didn't read the article without telling me you didn't read it.

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.

I don't think a site where the key content is large (relative to text) can be expected to deliver that content super fast.

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.

Maybe it was [blurhash](https://blurha.sh/)?

Inlining the blurhash script so that the blurred image is in the first paint will eat up about 2kb, but then you're good to go. I did it for this little demo: https://codesandbox.io/s/inline-blurhash-y4b0wj?file=/pages/...

Even for text-centric sites fitting everything in 14kB is not always feasible if you use custom fonts. My site is text- and math-centric, but it uses some fonts (Crimson + bold and italic variants, plus the KaTeX fonts used for math). Each font is about 30kB big for a total of 180kB.

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

>so I'm not willing to give up the fonts

Visitors will simply block them :)

Could you share your website? I've recently finished my own hobby photography website and it's great to see similar projects.

>the gallery pages are several hundred kBs in size

The HTML itself is several hundred kB? Something’s very wrong there…

No, the whole page, i.e. HTML + CSS + photo thumbnails etc. It's dominated 90+% by the photo thumbnails, which is expected.

Once JPEG XL is widely supported those photos could be significantly smaller.

That's correct, but it's important to keep in mind that JPEG XL is tuned for high quality images. If your baseline is heavily compressed JPEGs or AVIF images, switching to JPEG XL might save you nothing at all. However, if you're starting from 4+ MB high resolution JPEGs, and looking to save bandwidth while keeping the same quality, JPEG XL is vastly superior to anything else (including AVIF and WEBP).

JPEG-XL is not really any better than WEBP. You need to be using AVIF "significantly smaller", just a shame that Google's online AVIF compressor sucks so-much (Wrong compression mode and uses the AV1 default artifact blending (Chroma Sharpening which is not really sharpening or even just for Chroma but actually sets the artifact blending. 0 is default for AV1 and tries to hide all artifacts, increasing to 3 which shows all artifacts).

Reply on news.ycombinator.com