11 ms·

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

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.

hcarvalhoalves 4y ago
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.
- worldofmatthew 4y ago
  1MB per photo is massive. Its easy to compress photos down to 100KB or less.
  - NavinF 4y ago
    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.
    - worldofmatthew 4y ago
      Bandwidth is extremely carbon intensive. Someone viewing a couple of few 25MP images online could use 20g to 100g of CO2 (depending on compression).
      - ChrisRR 4y ago
        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
        worldofmatthew 4y ago
        Physical item that can be looked out for 20 to 50 years vs a digital image. Not the same thing.
      - ttoinou 4y ago
        Source ?
        worldofmatthew 4y ago
        https://www.emergeinteractive.com/insights/detail/does-irresponsible-web-development-contribute-to-global-warming/ https://www.emergeinteractive.com/insights/detail/does-irres... In the US as of 2020, it was 3KG CO2 per GB Data.
        cosarara 4y ago
        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.
  - habibur 4y ago
    Wondering how. The banner image won't be displayed by Facebook or Twitter unless it's 1200x650 in size.
    - worldofmatthew 4y ago
      I done photos larger than that at closer to 50KB with AVIF. 100KB with JPEG should be doable.
    - tomschwiha 4y ago
      Webp could be worth trying. Stripping metadata also. If staying with jpg - Jpgoptim could help.
  - bigiain 4y ago
    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…
    - kjkjadksj 4y ago
      Its best to have a compressed low res thumbnail that you can click to open the full resolution file in another tab imo
      - innocenat 4y ago
        That 1MB is the full resolution image you open in another tab.
        xigoi 4y ago
        In that case, it shouldn't be counted into the webpage weight.
  - bscphil 4y ago
    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 https://0x0.st/o9x5.png JPEG (200 KB): https://0x0.st/o93i.jpg https://0x0.st/o93i.jpg AVIF (100 KB): https://0x0.st/o9xC.avif 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 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.
    - worldofmatthew 4y ago
      I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.
      - bscphil 4y ago
        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 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.
      - IMTDb 4y ago
        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.
        Wowfunhappy 4y ago
        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.
- philliphaydon 4y ago
  Omg just disabling custom fonts in Firefox speeds up the internet so much!
  - blep_ 4y ago
    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.
    - tastemykungfu 4y ago
      A lot of icon frameworks are moving to SVG embedded on the page. Better usability - compared to the lazy fontawesomes out there.
      - manmal 4y ago
        Fontawesome is also available as SVG.
    - cuu508 4y ago
      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 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.
      - 8n4vidtmkvmk 4y ago
        i too use an icon font, but if you want images you should use a spritemap. it shouldn't be sluggish.
        4y ago
- ta-run 4y ago
  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.
  - lexicality 4y ago
    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.
  - smoe 4y ago
    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/ https://simonhearne.com/2021/layout-shifts-webfonts/
  - kevincox 4y ago
    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.
    - nirimda 4y ago
      > 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".
thethirdone 4y ago
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.
- panzerboiler 4y ago
  Maybe it was [blurhash](https://blurha.sh/ https://blurha.sh/)?
  - andrewingram 4y ago
    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/_document.js https://codesandbox.io/s/inline-blurhash-y4b0wj?file=/pages/...
julienmarie 4y ago
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.
phire 4y ago
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.
- johnchristopher 4y ago
  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.
  - soperj 4y ago
    that's what this blog post is about isn't it?
    - johnchristopher 4y ago
      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.
      - alpaca128 4y ago
        > 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.
pabs3 4y ago
Once JPEG XL is widely supported those photos could be significantly smaller.
- worldofmatthew 4y ago
  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).
- bscphil 4y ago
  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).
adsweedler 4y ago
> 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.
rustybolt 4y ago
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
- aaaaaaaaaaab 4y ago
  >so I'm not willing to give up the fonts Visitors will simply block them :)
bawolff 4y ago
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.
aaaaaaaaaaab 4y ago
>the gallery pages are several hundred kBs in size The HTML itself is several hundred kB? Something’s very wrong there…
- yakubin 4y ago
  No, the whole page, i.e. HTML + CSS + photo thumbnails etc. It's dominated 90+% by the photo thumbnails, which is expected.
darekkay 4y ago
Could you share your website? I've recently finished my own hobby photography website and it's great to see similar projects.
giantrobot 4y ago
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.

hcarvalhoalves 4y ago

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.

worldofmatthew 4y ago
1MB per photo is massive. Its easy to compress photos down to 100KB or less.
- NavinF 4y ago
  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.
  - worldofmatthew 4y ago
    Bandwidth is extremely carbon intensive. Someone viewing a couple of few 25MP images online could use 20g to 100g of CO2 (depending on compression).
    - ChrisRR 4y ago
      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
      - worldofmatthew 4y ago
        Physical item that can be looked out for 20 to 50 years vs a digital image. Not the same thing.
    - ttoinou 4y ago
      Source ?
      - worldofmatthew 4y ago
        https://www.emergeinteractive.com/insights/detail/does-irresponsible-web-development-contribute-to-global-warming/ https://www.emergeinteractive.com/insights/detail/does-irres... In the US as of 2020, it was 3KG CO2 per GB Data.
        cosarara 4y ago
        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.
- habibur 4y ago
  Wondering how. The banner image won't be displayed by Facebook or Twitter unless it's 1200x650 in size.
  - worldofmatthew 4y ago
    I done photos larger than that at closer to 50KB with AVIF. 100KB with JPEG should be doable.
  - tomschwiha 4y ago
    Webp could be worth trying. Stripping metadata also. If staying with jpg - Jpgoptim could help.
- bigiain 4y ago
  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…
  - kjkjadksj 4y ago
    Its best to have a compressed low res thumbnail that you can click to open the full resolution file in another tab imo
    - innocenat 4y ago
      That 1MB is the full resolution image you open in another tab.
      - xigoi 4y ago
        In that case, it shouldn't be counted into the webpage weight.
- bscphil 4y ago
  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 https://0x0.st/o9x5.png JPEG (200 KB): https://0x0.st/o93i.jpg https://0x0.st/o93i.jpg AVIF (100 KB): https://0x0.st/o9xC.avif 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 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.
  - worldofmatthew 4y ago
    I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.
    - bscphil 4y ago
      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 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.
    - IMTDb 4y ago
      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.
      - Wowfunhappy 4y ago
        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.
philliphaydon 4y ago
Omg just disabling custom fonts in Firefox speeds up the internet so much!
- blep_ 4y ago
  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.
  - tastemykungfu 4y ago
    A lot of icon frameworks are moving to SVG embedded on the page. Better usability - compared to the lazy fontawesomes out there.
    - manmal 4y ago
      Fontawesome is also available as SVG.
  - cuu508 4y ago
    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 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.
    - 8n4vidtmkvmk 4y ago
      i too use an icon font, but if you want images you should use a spritemap. it shouldn't be sluggish.
      - 4y ago
ta-run 4y ago
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.
- lexicality 4y ago
  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.
- smoe 4y ago
  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/ https://simonhearne.com/2021/layout-shifts-webfonts/
- kevincox 4y ago
  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.
  - nirimda 4y ago
    > 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".

thethirdone 4y ago

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.

panzerboiler 4y ago
Maybe it was [blurhash](https://blurha.sh/ https://blurha.sh/)?
- andrewingram 4y ago
  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/_document.js https://codesandbox.io/s/inline-blurhash-y4b0wj?file=/pages/...

julienmarie 4y ago

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.

phire 4y ago

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.

johnchristopher 4y ago
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.
- soperj 4y ago
  that's what this blog post is about isn't it?
  - johnchristopher 4y ago
    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.
    - alpaca128 4y ago
      > 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.

pabs3 4y ago

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

worldofmatthew 4y ago
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).
bscphil 4y ago
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).

adsweedler 4y ago

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

rustybolt 4y ago

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

aaaaaaaaaaab 4y ago
>so I'm not willing to give up the fonts Visitors will simply block them :)

bawolff 4y ago

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.

aaaaaaaaaaab 4y ago

>the gallery pages are several hundred kBs in size The HTML itself is several hundred kB? Something’s very wrong there…

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

darekkay 4y ago

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

giantrobot 4y ago

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.