Yeah, but God has an unfair advantage by being all-seeing and all-knowing. If they had to include 100 shady trackers like the rest of us do, it would be much higher.
From the graphs it looks like Websites size increases 4-fold every decade. So it will be 8 MB in 2030, and 16^H^H32 MB in 2040. On my current connection that only takes around 4 seconds. Its better than what i feared.
>So do screen resolutions
Maybe on phones but not on laptop. Resolutions went down after like 2009.
I have a 14+ year old laptop with a WUXGA (1920x1200) screen. That is similar to FHD but 16:10 not 16:9 so its a bit higher that FHD (which is the standard today).
And now, a little more than a decade later, 4K and 5K monitors and laptops (2x pixel density at some sort of scaled display resolution in a lot of cases) are common. A new Macbook has a screen resolution of 3456x2234 native pixels, which is the same as CSS pixels if you're not using display scaling. That's very close to ~4 times as many pixels as your old FHD laptop. Web developers will often send 2x pixel density images to browsers, especially on mobile, if they've not put the time in to optimize what they're sending based on media queries or client hints.
The default for a laptop and even for a desktop monitor today is still 1920x1080.
Yes the rage has been extended to way higher resolutions than 10 or 15 years ago but only the higher-end devices actually use them.
If you go in an office building FHD screens are the norm maybe 2 of them. The average user who doesn't care about specs of his laptop and doesn't have a ifruit product as status symbol (or because hes trapped in the fruit ecosystem) will have a 1920x1080 screen laptop.
It doesn't matter what the default is. When you make a website you need to make it work for everyone, including people at the edges. That means delivering something that works on a 'retina' display, which means using high resolution assets.
Web devs should be building sites that deliver the best assets for the users device, but they often don't and just send the giant images and let the users browser scale them down to fit.
There is a limit to what the human eye can see. 8K is overkill when sitting across a room and may not even be justifiable sitting 2 feet away with a screen size of less than 32 inches.
Although I'm kinda worried about the size, I'm more worried about the quantity of Javascript (or whatever client side language of the moment) and CSS will we run.
Luckily it's very easy to avoid these "web3 dapps" (sigh). And if you don't, an extra megabyte of JavaScript junk seems like a minor problem compared to the usual crypto user experience of losing all your money and/or becoming a cultish bore.
fortunately there are many other crypto user experiences that don't require cultish fealty to a project or token
ready contract data from the nearest node is a pretty benign and common aspect of what web3 inclusion in a site does. just accessing variables and constants in a cloud data store that can be read for free.
The second-last comment on that issue is pretty clear:
The issue with the lib is its non-treeshakeable nature. It should be rewritten using ES6 modules.
That doesn't seem so hard, unless I'm missing something. Certainly shouldn't need a full rewrite from scratch.
My point is, it's not just about bloat and having too many features (which are very hard problems to fix); it's often low-hanging fruit that isn't being picked.
Hmm, even my personal website hovers around 1 MB per page (though with resources being cached, it's more like 50 KB per page), it's definitely easy for page sizes to creep up on you when you're not paying too much attention.
That said, about 100 KB of that is the Material Icons font (given that I started making it with an older library that still used icon fonts) which doesn't really compress at all, since the whole site with no caching but compression means transferring over just around 300 KB, almost half of which is the fonts.
But if you wanted to make a minimalist page with web-safe fonts, minimal interactivity and simple styling? I bet you could get decent results, along the lines of this (some profanity on the page): https://motherfuckingwebsite.com/ (or one of the dozens of other sites, that gradually add more styling and other elements)
However, once you add any of the larger popular frameworks/libraries to your project, the actual app sizes can grow by quite a bit, for example the most comprehensive comparison that I can find (from 2020) being: https://medium.com/dailyjs/a-realworld-comparison-of-front-e...
Many would say that it's definitely worth it, given how any of these frameworks can make development a bit more easier/structured, though I doubt everyone would necessarily agree (e.g. the complexity of Angular and even React, as well as the fast pace at which they evolve and change).
Probably; a more detailed report [1] seems to suggest so anyway. Remember it includes "vulnerable JS libraries", probably fetched from 3rd party services.
My own site returns a page 42.8 KB in size (27.6 KB HTML, 13.8 KB image), which loads in 128mSec, and there are actually quite a few smaller sites than mine.
most of the images I see on websites are as useless for visitors as javascript animations and tracking. Nothing new tho, think about pulp fiction vs precious classics reissues
Careful, you might be looking at the graph of Sample Size in URLs scanned, not total kilobytes. There were more samples because they incorporated a new URL list around then. There is a size jump, but it is "only" from 1.2Mb to 1.6Mb on mobile around that time.
This is most likely just a bias in the sample, rather than actual increase in the median page size on the web as a whole.
(increases in median size are highly correlated with the sudden jumps in the # of pages indexed, so they likely started covering different subsets of the web that have a different distribution of page sizes)
EPUB with images: 1.7MB
Plain text version, compressed with xz: 1.1MB