5 ms·

> the longest post on my site, takes 92 KiB instead of 37 KiB. This amounts to an unnecessary 2.5x increase in load time Sure, if you ignore latency. In realit

> the longest post on my site, takes 92 KiB instead of 37 KiB. This amounts to an unnecessary 2.5x increase in load time Sure, if you ignore latency. In reality it's an unnecessary 0.001% increase in load time because that size increase isn't enough to matter vs the round trip time. And the time you save transmitting 55 fewer KiB is probably less than the time lost to decompression. :p While fun, I would expect this specific scenario to actually be worse for the user experience not better. Speed will be a complete wash and compatibility will be worse.

jsnell 2y ago
That size difference is large enough to make a difference in the number of round trips required (should be roughly one fewer roundtrip with any sensible modern value for the initial congestion window). Won't be a 2.5x difference, but also not 0.001%.
- BugsJustFindMe 2y ago
  You don't need a new roundtrip for every packet. That would be devastating for throughput. One vs two vs three file packets get acked as a batch either way, not serially. Also when you get to the end, you then see > The actual savings here are moderate: the original is 88 KiB with gzip, and the WebP one is 83 KiB with gzip. In contrast, Brotli would provide 69 KiB. At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, one just has a bunch of extra overhead added for the extra JavaScript fetch, load, and execute. The time saved here is going to be negligible at best anyway, but there looks to be actually negative because we're burning time without reducing the number of needed packets at all.
  - jsnell 2y ago
    Those numbers are for a different page. For the original page, the article quotes 44 kB with this method vs. 92 kB for gzip. > At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, What? No, they absolutely don't transmit the same number of packets. Did you mean some other word?
    - codetrotter 2y ago
      They were probably thinking of the max size for packets in TCP, which is 64K (65535 bytes). However, Ethernet has a MTU (Maximum Transmission Unit) of 1500 bytes. Unless jumbo frames are used. And so I agree with you, the number of packets that will be sent for 69 KiB vs 92 KiB will likely be different.
      - deleted 2y ago
        [deleted]
    - mananaysiempre 2y ago
      I expect what GP meant is the default TCP window size, so in a situation where bandwidth costs are dwarfed by roundtrip costs, these two cases will end up taking essentially the same time, because they will incur the same number of ACK roundtrips. Don’t know if the numbers work out, but they at least sound plausible.
      - BugsJustFindMe 2y ago
        Yes, sorry
      - jsnell 2y ago
        No, there is no way the numbers would work out to the same number of roundtrips. The sizes are different by a factor of 2.5x, and the congestion window will only double in a single roundtrip. The only way the number of roundtrips would be the same is if both transfers fit in the initial congestion window.
- pierrec 2y ago
  Interesting, how does that add a round trip? For the record here's what I believe to be the common definition of an additional "round trip", in a web development context: - client requests X - client gets X, which contains a reference to Y - therefore client requests Y So you're starting a new request that depends on the client having received the first one. (although upon closer inspection I think the technique described in the blog post manages to fit everything into the first response, so I'm not sure how relevant this is)
  - jsnell 2y ago
    Unless a resource is very small, it won't be transmitted in a single atomic unit. The sender will only send a part of it, wait the client to acknowledge having received them, and only then send more. That requires a network roundtrip. The larger the resource, the more network roundtrips will be required. If you want to learn more, pretty much any resource on TCP should explain this stuff. Here's something I wrote years ago, the background section should be pretty applicable: https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-downloads/ https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-do...
  - crote 2y ago
    In reality it's more like: - client requests X - server sends bytes 0-2k of X - client acknowledges bytes 0-2k of X - server sends bytes 2k-6k of X - client acknowledges bytes 2k-6k of X - server sends bytes 6k-14k of X - client acknowledges bytes 6k-14k of X - server sends bytes 14k-30k of X - client acknowledges bytes 14k-30k of X - server sends bytes 30k-62k of X - client acknowledges bytes 30k-62k of X - server sends bytes 62k-83k of X - client acknowledges bytes 62k-83k of X - client has received X, which contains a reference to Y - therefore client requests Y It's all about TCP congestion control here. There are dozens of algorithms used to handle it, but in pretty much all cases you want to have some kind of slow buildup in order to avoid completely swamping a slower connection and having all but the first few of your packets getting dropped.
    - deleted 2y ago
      [deleted]
deleted 2y ago
[deleted]
Retr0id 2y ago
Why is there more latency? Edit: Ah, I see OP's code requests the webp separately. You can avoid the extra request if you write a self-extracting html/webp polyglot file, as is typically done in the demoscene.
- BugsJustFindMe 2y ago
  It takes more time for your message to get back and forth between your computer and the server than it takes for the server to pump out some extra bits. Even if you transmit the js stuff inline, the op's notion of time still just ignores the fact that it takes the caller time to even ask the server for the data in the first place, and at such small sizes that time swallows the time to transmit from the user's perspective.
  - Retr0id 2y ago
    Here's a demo that only uses a single request for the whole page load: https://retr0.id/stuff/bee_movie.webp.html https://retr0.id/stuff/bee_movie.webp.html It is technically 2 requests, but the second one is a cache hit, in my testing.
    - BugsJustFindMe 2y ago
      That's fine, but if you're evaluating the amount of time it takes to load a webpage, you cannot ignore the time it takes for the client request to reach your server in the first place or for the client to then unpack the data. The time saved transmitting such a small number of bits will be a fraction of the time spent making that initial request anyway. That's all I'm saying. OP is only looking at transmit size differences, which is both not the same as transmit time differences and also not what the user actually experiences when requesting the page.
- purplesyringa 2y ago
  Hmm? I'm not sure where you're taking that from. The webp is inlined.
jgalt212 2y ago
I have similar feelings on js minification especially if you're sending via gzip.
edflsafoiewq 2y ago
Well, that, and there's an 850K Symbols-2048-em%20Nerd%20Font%20Complete.woff2 file that sort of drowns out the difference, at least if it's not in cache.
- lxgr 2y ago
  Now I got curious, and there's also a 400 kB CSS file to go with it: https://purplesyringa.moe/fonts/webfont.css https://purplesyringa.moe/fonts/webfont.css I'm not up to date on web/font development – does anybody know what that does?
  - bobbylarrybobby 2y ago
    It adds unicode characters before elements with the given class. Then it's up to the font to display those Unicode characters — in this case, based on the class names, one can infer that the font assigns an icon to each character used.
    - lxgr 2y ago
      That makes sense, thank you! So the purpose is effectively to have human-readable CSS class names to refer to given glyphs in the font, rather than having stray private use Unicode characters in the HTML?
      - lobsterthief 2y ago
        Yep This is a reasonable approach if you have a large number of icons across large parts of the site, but you should always compile the CSS/icon set down to only those used. If only a few icons, and the icons are small, then inlining the SVG is a better option. But if you have too many SVGs directly embedded on the site, the page size itself will suffer. As always with website optimization, whether something is a good option always “depends”.
        lifthrasiir 2y ago
lxgr 2y ago
That's certainly reasonable if you optimize only for loading time (and make certain assumptions about everybody's available data rate), but sometimes I really wish website (and more commonly app) authors wouldn't make that speed/data tradeoff so freely on my behalf, for me to find out after they've already pushed that extra data over my metered connection. The tragedy here is that while some people, such as the author of TFA, go to great lengths to get from about 100 to 50 kB, others don't think twice to send me literally tens of megabytes of images, when I just want to know when a restaurant is open – on roaming data. Resource awareness exists, but it's unfortunately very unevenly distributed.
- k__ 2y ago
  We need a MoSh-based browser with gopher support.
  - nox101 2y ago
    and you'd need AI to tell you whats in the pictures because lots of restaurant sites just have photos of their menu and some designer with no web knowledge put their phone number, address, and hours in an image designed in Photoshop
    - tacone 2y ago
      You're in for bad luck. Some time ago I tried some photos of pasta dishes with Gemini and it could not guess the recipe name.
      - mintplant 2y ago
        I've found Gemini to be pretty terrible at vision tasks compared to the competition. Try GPT-4o or Claude-3.5-Sonnet instead.
- zamadatix 2y ago
  There is an interesting "Save-Data" header to let a site know which makes sense to optimize for on connection but it seems to be Chrome only so far https://caniuse.com/?search=save-data https://caniuse.com/?search=save-data I wish there was a bit of an opposite option - a "don't lazy/partially load anything" for those of us on fiber watching images pop up as we scroll past them in the page that's been open for a minute.
sleepydog 2y ago
Seriously, if you're saving less than a TCP receive window's worth of space it's not going to make any difference to latency. I suppose it could make a difference on lossy networks, but I'm not sure.
- lelandfe 2y ago
  If the blob contains requests (images, but also stylesheets, JS, or worst case fonts), it will actually instead be a net negative to latency. The browser's preload scanner begins fetching resources even before the HTML is finished being parsed. That can't happen if the HTML doesn't exist until after JS decodes it. In other words, the entire body has become a blocking resource. These are similar conversations people have around hydration, by the by.
  - rrr_oh_man 2y ago
    > These are similar conversations people have around hydration For the uninitiated: https://en.m.wikipedia.org/wiki/Hydration_(web_development) https://en.m.wikipedia.org/wiki/Hydration_(web_development)
fsndz 2y ago
exactly what I thought too
zahlman 2y ago
Actually, I was rather wondering about that claim, because it seems accidentally cherry-picked. Regarding that post: > This code minifies to about 550 bytes. Together with the WebP itself, this amounts to 44 KiB. In comparison, gzip was 92 KiB, and Brotli would be 37 KiB. But regarding the current one: > The actual savings here are moderate: the original is 88 KiB with gzip, and the WebP one is 83 KiB with gzip. In contrast, Brotli would provide 69 KiB. Better than nothing, though. Most of the other examples don't show dramatic (like more than factor-of-2) differences between the compression methods either. In my own local testing (on Python wheel data, which should be mostly Python source code, thus text that's full of common identifiers and keywords) I find that XZ typically outperforms gzip by about 25%, while Brotli doesn't do any better than XZ.
- lifthrasiir 2y ago
  XZ was never considered to become a compression algorithm built into web browsers to start with. Brotli decoder is already there for HTTP, so it has been proposed to include the full Brotli decoder and decoder API as it shouldn't take too much effort to add an encoder and expose them. Also, XZ (or LZMA/LZMA2 in general) produces a smaller compressed data than Brotli with lots of free time, but is much slower than Brotli when targetting the same compression ratio. This is because LZMA/LZMA2 uses an adaptive range coder and multiple code distribution contexts, both highly contribute to the slowness when higher compression ratios are requested. Brotli only has the latter and its coding is just a bitwise Huffman coder.
oefrha 2y ago
It’s not just decompression time. They need to download the whole thing before decompression, whereas the browser can decompress and render HTML as it’s streamed from the server. If the connection is interrupted you lose everything, instead of being able to read the part you’ve downloaded. So, for any reasonable connection the difference doesn’t matter; for actually gruesomely slow/unreliable connections where 50KB matters this is markedly worse. While a fun experiment, please don’t do it on your site.
- robocat 2y ago
  Other major issues that I had to contend with: 1: browsers choose when to download files and run JavaScript. It is not as easy as one might think to force JavaScript to run immediately as high priority (which it needs to be when it is on critical path to painting). 2: you lose certain browser optimisations where normally many things are done in parallel. Instead you are introducing delays into critical path and those delays might not be worth the "gain". 3: Browsers do great things to start requesting files in parallel as files are detected with HTML/CSS. Removing that feature can be a poor tradeoff. There are a few other unobvious downsides. I would never deploy anything like that to a production site without serious engineering effort to measure the costs and benefits.
hot_gril 2y ago
I wish ISPs would advertise latency instead of just bandwidth. It matters a lot for average users, especially now that bandwidth is generally plentiful.

jsnell 2y ago

That size difference is large enough to make a difference in the number of round trips required (should be roughly one fewer roundtrip with any sensible modern value for the initial congestion window). Won't be a 2.5x difference, but also not 0.001%.

BugsJustFindMe 2y ago
You don't need a new roundtrip for every packet. That would be devastating for throughput. One vs two vs three file packets get acked as a batch either way, not serially. Also when you get to the end, you then see > The actual savings here are moderate: the original is 88 KiB with gzip, and the WebP one is 83 KiB with gzip. In contrast, Brotli would provide 69 KiB. At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, one just has a bunch of extra overhead added for the extra JavaScript fetch, load, and execute. The time saved here is going to be negligible at best anyway, but there looks to be actually negative because we're burning time without reducing the number of needed packets at all.
- jsnell 2y ago
  Those numbers are for a different page. For the original page, the article quotes 44 kB with this method vs. 92 kB for gzip. > At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, What? No, they absolutely don't transmit the same number of packets. Did you mean some other word?
  - codetrotter 2y ago
    They were probably thinking of the max size for packets in TCP, which is 64K (65535 bytes). However, Ethernet has a MTU (Maximum Transmission Unit) of 1500 bytes. Unless jumbo frames are used. And so I agree with you, the number of packets that will be sent for 69 KiB vs 92 KiB will likely be different.
    - deleted 2y ago
      [deleted]
  - mananaysiempre 2y ago
    I expect what GP meant is the default TCP window size, so in a situation where bandwidth costs are dwarfed by roundtrip costs, these two cases will end up taking essentially the same time, because they will incur the same number of ACK roundtrips. Don’t know if the numbers work out, but they at least sound plausible.
    - BugsJustFindMe 2y ago
      Yes, sorry
    - jsnell 2y ago
      No, there is no way the numbers would work out to the same number of roundtrips. The sizes are different by a factor of 2.5x, and the congestion window will only double in a single roundtrip. The only way the number of roundtrips would be the same is if both transfers fit in the initial congestion window.
pierrec 2y ago
Interesting, how does that add a round trip? For the record here's what I believe to be the common definition of an additional "round trip", in a web development context: - client requests X - client gets X, which contains a reference to Y - therefore client requests Y So you're starting a new request that depends on the client having received the first one. (although upon closer inspection I think the technique described in the blog post manages to fit everything into the first response, so I'm not sure how relevant this is)
- jsnell 2y ago
  Unless a resource is very small, it won't be transmitted in a single atomic unit. The sender will only send a part of it, wait the client to acknowledge having received them, and only then send more. That requires a network roundtrip. The larger the resource, the more network roundtrips will be required. If you want to learn more, pretty much any resource on TCP should explain this stuff. Here's something I wrote years ago, the background section should be pretty applicable: https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-downloads/ https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-do...
- crote 2y ago
  In reality it's more like: - client requests X - server sends bytes 0-2k of X - client acknowledges bytes 0-2k of X - server sends bytes 2k-6k of X - client acknowledges bytes 2k-6k of X - server sends bytes 6k-14k of X - client acknowledges bytes 6k-14k of X - server sends bytes 14k-30k of X - client acknowledges bytes 14k-30k of X - server sends bytes 30k-62k of X - client acknowledges bytes 30k-62k of X - server sends bytes 62k-83k of X - client acknowledges bytes 62k-83k of X - client has received X, which contains a reference to Y - therefore client requests Y It's all about TCP congestion control here. There are dozens of algorithms used to handle it, but in pretty much all cases you want to have some kind of slow buildup in order to avoid completely swamping a slower connection and having all but the first few of your packets getting dropped.
  - deleted 2y ago
    [deleted]

deleted 2y ago

[deleted]

Retr0id 2y ago

Why is there more latency? Edit: Ah, I see OP's code requests the webp separately. You can avoid the extra request if you write a self-extracting html/webp polyglot file, as is typically done in the demoscene.

BugsJustFindMe 2y ago
It takes more time for your message to get back and forth between your computer and the server than it takes for the server to pump out some extra bits. Even if you transmit the js stuff inline, the op's notion of time still just ignores the fact that it takes the caller time to even ask the server for the data in the first place, and at such small sizes that time swallows the time to transmit from the user's perspective.
- Retr0id 2y ago
  Here's a demo that only uses a single request for the whole page load: https://retr0.id/stuff/bee_movie.webp.html https://retr0.id/stuff/bee_movie.webp.html It is technically 2 requests, but the second one is a cache hit, in my testing.
  - BugsJustFindMe 2y ago
    That's fine, but if you're evaluating the amount of time it takes to load a webpage, you cannot ignore the time it takes for the client request to reach your server in the first place or for the client to then unpack the data. The time saved transmitting such a small number of bits will be a fraction of the time spent making that initial request anyway. That's all I'm saying. OP is only looking at transmit size differences, which is both not the same as transmit time differences and also not what the user actually experiences when requesting the page.
purplesyringa 2y ago
Hmm? I'm not sure where you're taking that from. The webp is inlined.

jgalt212 2y ago

I have similar feelings on js minification especially if you're sending via gzip.

edflsafoiewq 2y ago

Well, that, and there's an 850K Symbols-2048-em%20Nerd%20Font%20Complete.woff2 file that sort of drowns out the difference, at least if it's not in cache.

lxgr 2y ago
Now I got curious, and there's also a 400 kB CSS file to go with it: https://purplesyringa.moe/fonts/webfont.css https://purplesyringa.moe/fonts/webfont.css I'm not up to date on web/font development – does anybody know what that does?
- bobbylarrybobby 2y ago
  It adds unicode characters before elements with the given class. Then it's up to the font to display those Unicode characters — in this case, based on the class names, one can infer that the font assigns an icon to each character used.
  - lxgr 2y ago
    That makes sense, thank you! So the purpose is effectively to have human-readable CSS class names to refer to given glyphs in the font, rather than having stray private use Unicode characters in the HTML?
    - lobsterthief 2y ago
      Yep This is a reasonable approach if you have a large number of icons across large parts of the site, but you should always compile the CSS/icon set down to only those used. If only a few icons, and the icons are small, then inlining the SVG is a better option. But if you have too many SVGs directly embedded on the site, the page size itself will suffer. As always with website optimization, whether something is a good option always “depends”.
      - lifthrasiir 2y ago

lxgr 2y ago

That's certainly reasonable if you optimize only for loading time (and make certain assumptions about everybody's available data rate), but sometimes I really wish website (and more commonly app) authors wouldn't make that speed/data tradeoff so freely on my behalf, for me to find out after they've already pushed that extra data over my metered connection. The tragedy here is that while some people, such as the author of TFA, go to great lengths to get from about 100 to 50 kB, others don't think twice to send me literally tens of megabytes of images, when I just want to know when a restaurant is open – on roaming data. Resource awareness exists, but it's unfortunately very unevenly distributed.

k__ 2y ago
We need a MoSh-based browser with gopher support.
- nox101 2y ago
  and you'd need AI to tell you whats in the pictures because lots of restaurant sites just have photos of their menu and some designer with no web knowledge put their phone number, address, and hours in an image designed in Photoshop
  - tacone 2y ago
    You're in for bad luck. Some time ago I tried some photos of pasta dishes with Gemini and it could not guess the recipe name.
    - mintplant 2y ago
      I've found Gemini to be pretty terrible at vision tasks compared to the competition. Try GPT-4o or Claude-3.5-Sonnet instead.
zamadatix 2y ago
There is an interesting "Save-Data" header to let a site know which makes sense to optimize for on connection but it seems to be Chrome only so far https://caniuse.com/?search=save-data https://caniuse.com/?search=save-data I wish there was a bit of an opposite option - a "don't lazy/partially load anything" for those of us on fiber watching images pop up as we scroll past them in the page that's been open for a minute.

sleepydog 2y ago

Seriously, if you're saving less than a TCP receive window's worth of space it's not going to make any difference to latency. I suppose it could make a difference on lossy networks, but I'm not sure.

lelandfe 2y ago
If the blob contains requests (images, but also stylesheets, JS, or worst case fonts), it will actually instead be a net negative to latency. The browser's preload scanner begins fetching resources even before the HTML is finished being parsed. That can't happen if the HTML doesn't exist until after JS decodes it. In other words, the entire body has become a blocking resource. These are similar conversations people have around hydration, by the by.
- rrr_oh_man 2y ago
  > These are similar conversations people have around hydration For the uninitiated: https://en.m.wikipedia.org/wiki/Hydration_(web_development) https://en.m.wikipedia.org/wiki/Hydration_(web_development)

fsndz 2y ago

exactly what I thought too

zahlman 2y ago

Actually, I was rather wondering about that claim, because it seems accidentally cherry-picked. Regarding that post: > This code minifies to about 550 bytes. Together with the WebP itself, this amounts to 44 KiB. In comparison, gzip was 92 KiB, and Brotli would be 37 KiB. But regarding the current one: > The actual savings here are moderate: the original is 88 KiB with gzip, and the WebP one is 83 KiB with gzip. In contrast, Brotli would provide 69 KiB. Better than nothing, though. Most of the other examples don't show dramatic (like more than factor-of-2) differences between the compression methods either. In my own local testing (on Python wheel data, which should be mostly Python source code, thus text that's full of common identifiers and keywords) I find that XZ typically outperforms gzip by about 25%, while Brotli doesn't do any better than XZ.

lifthrasiir 2y ago
XZ was never considered to become a compression algorithm built into web browsers to start with. Brotli decoder is already there for HTTP, so it has been proposed to include the full Brotli decoder and decoder API as it shouldn't take too much effort to add an encoder and expose them. Also, XZ (or LZMA/LZMA2 in general) produces a smaller compressed data than Brotli with lots of free time, but is much slower than Brotli when targetting the same compression ratio. This is because LZMA/LZMA2 uses an adaptive range coder and multiple code distribution contexts, both highly contribute to the slowness when higher compression ratios are requested. Brotli only has the latter and its coding is just a bitwise Huffman coder.

oefrha 2y ago

It’s not just decompression time. They need to download the whole thing before decompression, whereas the browser can decompress and render HTML as it’s streamed from the server. If the connection is interrupted you lose everything, instead of being able to read the part you’ve downloaded. So, for any reasonable connection the difference doesn’t matter; for actually gruesomely slow/unreliable connections where 50KB matters this is markedly worse. While a fun experiment, please don’t do it on your site.

robocat 2y ago
Other major issues that I had to contend with: 1: browsers choose when to download files and run JavaScript. It is not as easy as one might think to force JavaScript to run immediately as high priority (which it needs to be when it is on critical path to painting). 2: you lose certain browser optimisations where normally many things are done in parallel. Instead you are introducing delays into critical path and those delays might not be worth the "gain". 3: Browsers do great things to start requesting files in parallel as files are detected with HTML/CSS. Removing that feature can be a poor tradeoff. There are a few other unobvious downsides. I would never deploy anything like that to a production site without serious engineering effort to measure the costs and benefits.

hot_gril 2y ago

I wish ISPs would advertise latency instead of just bandwidth. It matters a lot for average users, especially now that bandwidth is generally plentiful.