Median webpage size was 2.3 MB in July | Hacker News Reader

Median webpage size was 2.3 MB in July

httparchive.org

64 pointsnotpushkin37 comments

The King James Version of the Bible on Project Gutenberg – https://www.gutenberg.org/ebooks/10

EPUB with images: 1.7MB

Plain text version, compressed with xz: 1.1MB

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 it will be 8 MB in 2030, and 16 MB in 2040

You mean 32MB 2040?

That assumes a linear growth. Within such a short timeframe, most progressions appear linear.

No, that's an exponential growth

"4-fold every decade" is exponential, not linear.

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

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.

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.

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.

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 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.

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.

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).

Every time someone brings up https://motherfuckingwebsite.com I like to bring up

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

Yeah, I wonder what exactly they mean by external.

Typically anything not on the main domain

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.

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)

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?

What happened at the end of 2018

Apple moved their entire line of laptops to 'Retina' displays?

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.

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)

Thanks everyone who helps to keep this metric down.

Reply on news.ycombinator.com