7 ms·

I know it's comparing Apples and Oranges, but: "War and Peace" by Tolstoi is 1.9 MB. A Twitter profile page is 2.5 MB, and that is already optimized (Posts belo

I know it's comparing Apples and Oranges, but: "War and Peace" by Tolstoi is 1.9 MB. A Twitter profile page is 2.5 MB, and that is already optimized (Posts below the fold are not loaded). Websites are bloated - so I am glad the ethical aspect is getting more and more into the focus.

okaleniuk 7y ago
I have a rule of keeping every page on wordsandbuttons.online under 64KB. And no dependencies so, apart from occasional pictures from wikimedia, no other hidden costs for the visitor. The number is of course arbitrary, but surprisingly it's usually quite enough for a short tutorial or an interactive explanation of something. And I don't even compress the code or the data. Every page source is human-readable. So it is possible to have leaner Web. it just requires a little bit of effort.
- Nyandalized 7y ago
  With the help of transport compression like gzip, the total size can still be reduced by almost the same amount even if you don't minimize it.
  - mr__y 7y ago
    That's obviously true, however a minimized version will require less memory and slightly less cpu-cycles* to compress and, on the client side, it requires slightly less resources as well I do realize how insignificant difference that would be * then again not much of a difference since the DOM tree itself would consume orders o magnitude more mem.
    - hinkley 7y ago
      Probably not less memory. zlib is based on a design that dates back to an era where you might only have 250-350 kilobytes (not a typo) of RAM to work with, and it was never really extended beyond that. It has a window it keeps in memory and if your file is longer than that window, you hit peak memory and stay there (you might actually hit that window immediately. I've forgotten how that part works, but some chunks of memory are pre-allocated).
      - masklinn 7y ago
        That's really DEFLATE, the sliding window of standard deflate is 32KB. Both compression and decompression have some overhead (compression more so as you might want to have index tables and whatnot to make finding matcher faster) but even with the worst possible intention there's only so much overhead you can add.
        hinkley 7y ago
        Level 9 uses 128k, if memory serves. We’re talking about HTTP here, and gzip is the only reliably available compressed transport encoding. On the plus side, because it is so resource constrained you have had it on your phone for ages, and might even see it on IoT devices.
        masklinn 7y ago
        > Level 9 uses 128k, if memory serves. That's probably a misunderstanding or misremembering: the DEFLATE format can only encode distances of 32K (the proprietary DEFLATE64 allows 64K distances but not everything supports it).
  - vardump 7y ago
    I once wrote (maybe 15-20 years ago?) an html output processor that tried to make it more compressible while still producing the exact same output. It did things like removed comments, transformed all tag names to lower case, sorted tag attributes and canonicalized values, collapsed whitespace (including line feeds). And some more tricks I've forgotten (some DOM tree tricks, I think), mainly to introduce more repeated strings for LZ and unbalanced distribution (=less output bits) for Huffman. In other words, things that help gzip to compress even further. Output was really small, most pages were transformed from gzipped sizes of 10-15 kB to 2-5 kB without graphics. The pages loaded fast, pretty much instantly, because they could fit in the TCP initial window, avoiding extra roundtrips. Browser sent request and server sent all HTML in the initial window even before the first ACK arrived! I might have tweaked initial window to 10 packets or something (= enough for 14 kB or so), I don't remember these TCP details by heart anymore. I wonder if anyone else is making this kind of HTML/CSS compressability optimizers anymore. Other than Javascript minimizers.
    - barryvan 7y ago
      They are! Around five years ago I wrote a CSS minifier (creatively called CSSMin, available on GitHub, and still in use at the company I work for) which rewrote the CSS to optimise gzip compression. Although it never really took off, I think that some of the lessons from it have been rolled into some of the more modern CSS optimisation tools.
      - vardump 7y ago
        It's important to understand minimizing does not necessarily produce the most compressible result. You need to give LZ repeating strings as much as possible while using as few different ASCII characters as possible with as unbalanced frequency distribution as possible.
        hinkley 7y ago
        I wrote (well, expanded) a similar tool for compressing Java Class files. I had a theory that suffix sorting would work slightly better because of the separators between fields, and it turned out to be worth another 1% final size versus prefix sorting.
  - masklinn 7y ago
    If your page is static, it's even worth trying something like zopfli or advancecomp to maximise compression ratio in ways too expensive to do "online".
- hinkley 7y ago
  Have we provided any tools that managers are capable of using to see page weight and explore on their own? Or are we making graphs and showing them charts? Maybe we are missing a plugin with a mileage gauge.
  - pflenker 7y ago
    As an Engineering Manager I had Engineers showing me graphs and charts, but I also know how to look up things on my own. But I don't think either case is wide spread.
    - hinkley 7y ago
      The fact that you are on hacker news suggests you are the Engineer turned Manager instead of tech enthusiast who went to business school. Yes? People are a little more reliable when they have the option to figure things out for themselves. I’m not sure entirely why that is. But if pressed, I’d conjecture it’s something to do with not wanting to be seen asking subordinates stupid questions, to the point of preferring to be ignorant or half blind instead. “Keep silent and let them suspect, or speak and remove all doubt.”
ozim 7y ago
Imagine "War and Peace" being written without descriptions of characters or places, just bland facts about what happened. It would probably go under 60KB! Damn this Tolstoi guy put in so much fancy descriptions and dialogs in there, we could do better!

okaleniuk 7y ago

I have a rule of keeping every page on wordsandbuttons.online under 64KB. And no dependencies so, apart from occasional pictures from wikimedia, no other hidden costs for the visitor. The number is of course arbitrary, but surprisingly it's usually quite enough for a short tutorial or an interactive explanation of something. And I don't even compress the code or the data. Every page source is human-readable. So it is possible to have leaner Web. it just requires a little bit of effort.

Nyandalized 7y ago
With the help of transport compression like gzip, the total size can still be reduced by almost the same amount even if you don't minimize it.
- mr__y 7y ago
  That's obviously true, however a minimized version will require less memory and slightly less cpu-cycles* to compress and, on the client side, it requires slightly less resources as well I do realize how insignificant difference that would be * then again not much of a difference since the DOM tree itself would consume orders o magnitude more mem.
  - hinkley 7y ago
    Probably not less memory. zlib is based on a design that dates back to an era where you might only have 250-350 kilobytes (not a typo) of RAM to work with, and it was never really extended beyond that. It has a window it keeps in memory and if your file is longer than that window, you hit peak memory and stay there (you might actually hit that window immediately. I've forgotten how that part works, but some chunks of memory are pre-allocated).
    - masklinn 7y ago
      That's really DEFLATE, the sliding window of standard deflate is 32KB. Both compression and decompression have some overhead (compression more so as you might want to have index tables and whatnot to make finding matcher faster) but even with the worst possible intention there's only so much overhead you can add.
      - hinkley 7y ago
        Level 9 uses 128k, if memory serves. We’re talking about HTTP here, and gzip is the only reliably available compressed transport encoding. On the plus side, because it is so resource constrained you have had it on your phone for ages, and might even see it on IoT devices.
        masklinn 7y ago
        > Level 9 uses 128k, if memory serves. That's probably a misunderstanding or misremembering: the DEFLATE format can only encode distances of 32K (the proprietary DEFLATE64 allows 64K distances but not everything supports it).
- vardump 7y ago
  I once wrote (maybe 15-20 years ago?) an html output processor that tried to make it more compressible while still producing the exact same output. It did things like removed comments, transformed all tag names to lower case, sorted tag attributes and canonicalized values, collapsed whitespace (including line feeds). And some more tricks I've forgotten (some DOM tree tricks, I think), mainly to introduce more repeated strings for LZ and unbalanced distribution (=less output bits) for Huffman. In other words, things that help gzip to compress even further. Output was really small, most pages were transformed from gzipped sizes of 10-15 kB to 2-5 kB without graphics. The pages loaded fast, pretty much instantly, because they could fit in the TCP initial window, avoiding extra roundtrips. Browser sent request and server sent all HTML in the initial window even before the first ACK arrived! I might have tweaked initial window to 10 packets or something (= enough for 14 kB or so), I don't remember these TCP details by heart anymore. I wonder if anyone else is making this kind of HTML/CSS compressability optimizers anymore. Other than Javascript minimizers.
  - barryvan 7y ago
    They are! Around five years ago I wrote a CSS minifier (creatively called CSSMin, available on GitHub, and still in use at the company I work for) which rewrote the CSS to optimise gzip compression. Although it never really took off, I think that some of the lessons from it have been rolled into some of the more modern CSS optimisation tools.
    - vardump 7y ago
      It's important to understand minimizing does not necessarily produce the most compressible result. You need to give LZ repeating strings as much as possible while using as few different ASCII characters as possible with as unbalanced frequency distribution as possible.
      - hinkley 7y ago
        I wrote (well, expanded) a similar tool for compressing Java Class files. I had a theory that suffix sorting would work slightly better because of the separators between fields, and it turned out to be worth another 1% final size versus prefix sorting.
- masklinn 7y ago
  If your page is static, it's even worth trying something like zopfli or advancecomp to maximise compression ratio in ways too expensive to do "online".
hinkley 7y ago
Have we provided any tools that managers are capable of using to see page weight and explore on their own? Or are we making graphs and showing them charts? Maybe we are missing a plugin with a mileage gauge.
- pflenker 7y ago
  As an Engineering Manager I had Engineers showing me graphs and charts, but I also know how to look up things on my own. But I don't think either case is wide spread.
  - hinkley 7y ago
    The fact that you are on hacker news suggests you are the Engineer turned Manager instead of tech enthusiast who went to business school. Yes? People are a little more reliable when they have the option to figure things out for themselves. I’m not sure entirely why that is. But if pressed, I’d conjecture it’s something to do with not wanting to be seen asking subordinates stupid questions, to the point of preferring to be ignorant or half blind instead. “Keep silent and let them suspect, or speak and remove all doubt.”

ozim 7y ago

Imagine "War and Peace" being written without descriptions of characters or places, just bland facts about what happened. It would probably go under 60KB! Damn this Tolstoi guy put in so much fancy descriptions and dialogs in there, we could do better!