News for hackers. Stuff that matters.
Re:Engineering for Slow Internet by RGamma on Friday May 31, 2024 @06:14AM (#40533231)
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols.

Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...

Re:Engineering for Slow Internet by chris_pie on Friday May 31, 2024 @06:48AM (#40533418)
Re:Engineering for Slow Internet by jiggawatts on Friday May 31, 2024 @07:02AM (#40533494)
The generalisation of this concept is what I like call the "kilobyte" rule.

A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb.

If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen.

Worse still, an uncompressed 4K still image is only 23.7 megabytes. At some point you might be better off doing "server side rendering" with a GPU instead of sending more JavaScript!

Re:Engineering for Slow Internet by Lex-2008 on Friday May 31, 2024 @09:23AM (#40534816)
> "server side rendering" with a GPU instead of sending more JavaScript

Some 7~10 years ago I remember I saw somewhere (maybe here on HN) a website which did exactly this: you gave it an URL - it downloaded a webpage with all its resources, rendered and screenshot'ed it (probably in headless Chrome or something), and compared size of png screenshot versus size of webpage with all its resources.

For many popular websites, png screenshot of a page indeed was several times less than webpage itself!

Re:Engineering for Slow Internet by jcgrillo on Friday May 31, 2024 @09:56AM (#40535232)
If your server renders the image as text we'll be right back down towards a kilobyte again. See https://www.brow.sh/
Re:Engineering for Slow Internet by skydhash on Friday May 31, 2024 @09:59AM (#40535271)
I read epubs, and they’re mostly html and css files zipped. The whole book usually comes under a MB if there’s not a lot of big pictures. Then you come across a website and for just an article you have to download tens of MBs. Disable JavaScript and the website is broken.
Re:Engineering for Slow Internet by RGamma on Friday May 31, 2024 @03:39PM (#40539377)
Soo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
Re:Engineering for Slow Internet by pgraf on Friday May 31, 2024 @06:42AM (#40533383)
Shouldn’t HTTP compression reap most of the benefits of this approach for bigger pages?
Re:Engineering for Slow Internet by LtWorf on Friday May 31, 2024 @10:36AM (#40535759)
Surely you're aware of gzip encoding on the wire for http right?
Re:Engineering for Slow Internet by RGamma on Friday May 31, 2024 @11:45AM (#40536612)
Sure, would be interesting to know how it would fare against purpose-made compression under real world conditions still...
Re:Engineering for Slow Internet by LtWorf on Friday May 31, 2024 @09:24PM (#40542058)
gzip is fast. And it was made for real world conditions.
Re:Engineering for Slow Internet by floam on Saturday June 01, 2024 @01:28PM (#40547544)
Brotli is a better example, as it was literally purpose made for HTML/CSS/JS. It is now supported basically everywhere for HTTP compression, and uses a huge custom dictionary (about 120KB) that was trained on simulated web traffic.

You can even swap in your own shared dictionary with a HTTP header, but trying to make your own dictionary specific to your content is a fool’s errand, you’ll never amortize the cost in total bits.

What you CAN do with shared dictionaries though, is delta updates.

https://developer.chrome.com/blog/shared-dictionary-compress... https://news.ycombinator.com/item?id=39615198

Re:Engineering for Slow Internet by LtWorf on Sunday June 02, 2024 @05:52PM (#40557441)
Is it supported by curl or any browser or no?
Re:Engineering for Slow Internet by floam on Monday June 03, 2024 @12:13AM (#40559261)
Every browser, curl yes.