Median webpage size was 2.3 MB in July(httparchive.org)
httparchive.org
Median webpage size was 2.3 MB in July
https://httparchive.org/reports/state-of-the-web
37 comments
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.
From the graphs it looks like Websites size increases 4-fold every decade.
So do screen resolutions, and when you include images and video in the website size it seems reasonable they'll be getting bigger.
So do screen resolutions, and when you include images and video in the website size it seems reasonable they'll be getting bigger.
>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).
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.
Hence bigger websites.
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.
Hence bigger websites.
No one was talking about web pages in this thread.
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.
yeah, I could see that.
web3.js is a super bloated library and will be added more frequently unless a team does a more optimal version from scratch
https://github.com/ChainSafe/web3.js/issues/1178
web3.js is a super bloated library and will be added more frequently unless a team does a more optimal version from scratch
https://github.com/ChainSafe/web3.js/issues/1178
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.
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.
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.
That assumes a linear growth. Within such a short timeframe, most progressions appear linear.
> From the graphs it looks like Websites size increases 4-fold every decade. So it will be 8 MB in 2030, and 16 MB in 2040
You mean 32MB 2040?
You mean 32MB 2040?
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).
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).
Every time someone brings up https://motherfuckingwebsite.com I like to bring up
https://bettermotherfuckingwebsite.com
And
https://evenbettermotherfucking.website
And
https://thebestmotherfucking.website
https://bettermotherfuckingwebsite.com
And
https://evenbettermotherfucking.website
And
https://thebestmotherfucking.website
Wait a minute. Is the side-loaded page content also included - ads, gifs, pictures from 2nd und 3rd party domains for example?
Probably; a more detailed report [1] seems to suggest so anyway. Remember it includes "vulnerable JS libraries", probably fetched from 3rd party services.
[1] https://httparchive.org/reports/page-weight
[1] https://httparchive.org/reports/page-weight
Ha! You need to visit the 1Mb Club site: https://1mb.club/
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.
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.
Ongoing related thread:
A 14kb page can load much faster than a 15kb page - https://news.ycombinator.com/item?id=32587740 - Aug 2022 (174 comments)
A 14kb page can load much faster than a 15kb page - https://news.ycombinator.com/item?id=32587740 - Aug 2022 (174 comments)
Is this with or without media? Because images take up the majority of page size.
It includes media, see the more detailed report here: https://httparchive.org/reports/page-weight
Thanks, it's the complete page size.
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
What happened at the end of 2018 that caused (a) a near-4x explosion in size, and (b) mobile page size to overtake desktop size.
New tracking library / framework releases?
New tracking library / framework releases?
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.
You're right, my mistake. Ignore OP.
What happened at the end of 2018
Apple moved their entire line of laptops to 'Retina' displays?
Apple moved their entire line of laptops to 'Retina' displays?
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)
(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)
Thanks everyone who helps to keep this metric down.
EPUB with images: 1.7MB
Plain text version, compressed with xz: 1.1MB