3 ms·
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
by jiggawatts 2y ago
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!
- RGamma 2y agoSoo.. there should be a standardized web API for page content. And suddenly... gopher (with embedded media/widgets).
- Lex-2008 2y ago> "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!
- jcgrillo 2y agoIf your server renders the image as text we'll be right back down towards a kilobyte again. See https://www.brow.sh/ https://www.brow.sh/
- skydhash 2y agoI 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.