What do you consider a reasonable page size?

[Dreamwings]

Most of us don't think about it, but our sites take up space, in fact quite a bit if we don't pay attention to compression. I sort of recently realized "Hey, this might actually be important if I want to properly optimize it for internet connections that aren't as good as mine" and realized quite a few of my pages can end up taking up 9-10MB (mostly due to audio files, removing those and it usually cuts down to around 1-3 MB). Some graphics heavy pages like my about page take up 5MB even with no audio. Now, ofc today we do live in the modern age so maybe this is more understandable, and it's definitely less than a lot of other more modern sites. Mayhaps that wouldn't matter too much to most people if they have an average internet connection. But I still like to make my site somewhat accessible to older computers and alternate browsers. Some things I can't avoid like the lack of const, CSS animations, and complex flexboxes. But still. I'd like the old toaster a poor netizen is running to not combust as soon as it lands on my site (at least not immediately. Not until they can take in it's beauty before everything freezes and it's stuck emblazoned on their monitor.).
So I am curious what other people of the forums have to say on the topic, hence this post. How big are your sites pages and how much is too much to you? Or do you not even think about it and put whatever? Is optimizing filesize even important in 2024? 

[Memory]

i don't pay attention to page size at all! i do some image compression so i don't use up all my storage but i don't bother optimizing my pages at all. 1GB of free neocities storage goes a long way, i'm only at 64.3% even with 2000+ images. i dont know how you measure page size besides the size of the html file now i'm curious!

i've got a couple slowish-loading pages because they're packed with biggish images - my tiled backgrounds pages and some of the bits in my halloween vault for example - but i don't think it would surprise anybody  to the point of inconvenience that a page full of 100+ images loads kinda slow.

i think professional + commercial + public service websites should be as accessible and speedy as possible, but my website isn't any of those so i care not ! it works for me, and im the one who's visiting it most of the time, so it's all good. 

[Memory]

I think that optimizing our websites for older browsers and people with weaker internet connections should be a requirement, seen as an accessibility issue and not an afterthought. coming from somebody who has struggled months on end sometimes with connectivity on his computer, it is always nice when the site i'm visiting considers potential low loading speeds and respects my time.

This make some of your webpages visitors experiences nicer, and your own storage capacity will thank you, too. My host has a limited disk plan for webmasters with them and this has forced me to work within those constraints, meaning my website is lightweight and easy to move around as i've tried to save as much space as possible. i'm sure the only thing really increasing my webpages size is the images, and even those are compressed.

To try and answer your question, though .. it's when the graphics themselves are the size of an entire website, that it starts to get seriously bad!

[Slix]

I also don't look at page size itself, but I do try to make my site load as quickly as possible on just about any hardware/browser that can load it (which is a lot of them, I test on old Macs quite often too!). I don't have a lot of large images on a single page anywhere, and the only page that has larger images are actually shown as thumbnails (for the wallpapers page) so you have to click on each one to see the full image.

[cindy]

Google has a tool called PageSpeed Insights that can help determine how fast or slow your page is loading and (maybe) give tips on best practices for how to fix it.

For me it didn't really give any tips but it was worth seeing how it was slowed down and I realized on my own it was the music file slowing it down. I compressed the music file by quite a bit and also offered ogg format (which is more efficient than mp3) and that alone reduced the pageload of the LCP (largest contentful paint) on Insights from 4.9s to 0.7s.

Anyway, I don't suggest you have to do every single thing it warns you about, but it can be good to check out to get some quick insight (🥁) on how your page performs.

[Dreamwings]

Thank you for all of the responses so far! ^^ (though if anyone else has other thoughts than keep them coming) Definitely going to have to get to work at some point on squishing down some of the big .pngs and .gifs into .jpegs and .webps.

i dont know how you measure page size besides the size of the html file now i'm curious!

If you open the developer tools of your browser and go to Network (or the equivalent), and then hard refresh (so that it redownloads all the assets rather than using cached versions), there is a counter somewhere on the network panel that will show how much is being downloaded.

Google has a tool called PageSpeed Insights that can help determine how fast or slow your page is loading and (maybe) give tips on best practices for how to fix it.

For me it didn't really give any tips but it was worth seeing how it was slowed down and I realized on my own it was the music file slowing it down. I compressed the music file by quite a bit and also offered ogg format (which is more efficient than mp3) and that alone reduced the pageload of the LCP (largest contentful paint) on Insights from 4.9s to 0.7s.

Anyway, I don't suggest you have to do every single thing it warns you about, but it can be good to check out to get some quick insight (🥁) on how your page performs.

OOoh cool. I'll have to go into my server config and unblock googles bots for a second (made it so that it and a few other bots would redirect to a 10 GB file, mostly intended for scrapers  ) but yeah, I'll try that and some of the compression techniques you did on your audio files. I don't think I need to have full 320kbps mp3s and oggs if only about maybe 1/20th of visitors can actually tell the difference and of those only 1/3rd are actually paying attention.

[cindy]

(made it so that it and a few other bots would redirect to a 10 GB file, mostly intended for scrapers  )

Delightfully devilish, Dreamwings! 
I didn't even know you could do something like that!

[Dreamwings]

Delightfully devilish, Dreamwings! 
I didn't even know you could do something like that!

Yeahhh.   If you have your webserver selfhosted you can do a lot of different little tricks like that, since everything does have to go through the software before it can get to anything else. Could be simple cosmetics like removing the file extension at the end or redirection corrections or funny things like this. I followed this tutorial for Nginx and there is this other version of the same general idea for Apache2. I also considered redirecting it to rickroll as well but I thought clogging up the scrapers for a bit would be funnier.

[cairo]

...things I can't avoid like the lack of const, CSS animations, and complex flexboxes. But still. I'd like the old toaster a poor netizen is running to not combust as soon as it lands on my site (at least not immediately. Not until they can take in it's beauty before everything freezes and it's stuck emblazoned on their monitor.).

I've found that expressing myself through a webpage is equal parts obsessing over small details and ultimately accepting that I can't design for 100% of hardware/browser combos. The artist in me is very free with the size of initial concepts.. but the programmer in me is always keeping at least loose track of where the storage is sitting. I love ultra-compact 1MB (or less!) pages + sites, but my own design process involves lots of dynamic visuals and motion- so I'd struggle with lightweight constraints all the time.

i think professional + commercial + public service websites should be as accessible and speedy as possible, but my website isn't any of those so i care not ! it works for me, and im the one who's visiting it most of the time, so it's all good. 

Personal site projects are absolutely the ones we ourselves would want to most visit :)

[Memory]

I've found that expressing myself through a webpage is equal parts obsessing over small details and ultimately accepting that I can't design for 100% of hardware/browser combos. The artist in me is very free with the size of initial concepts.. but the programmer in me is always keeping at least loose track of where the storage is sitting. I love ultra-compact 1MB (or less!) pages + sites, but my own design process involves lots of dynamic visuals and motion- so I'd struggle with lightweight constraints all the time.

That makes sense! I think this is the part where you as the programmer have to decide if you'd rather dive into the stuff newer hardware offers, but sacrifice some accessibility to those with older technology and shorter connections, or if you'd prefer to fully lean towards making it accessible but lose or compromise with aspects of the original concept.

It's about having a balance of the two, but i'd have to admit that i like working within constraints that make things a little more compatible and teach me shortcuts. You won't believe how many little tricks people used back then for saving storage. that being said, sites pushing browsers to their limits are also fun in their own way ..

Which, i'd like to also mention how charming your site is, since this thread is what made me come across and visit it! it has a magic to it that i haven't seen anywhere else. i think the artistic vision really benefits from making use of modern tech than the former.

[xwindows]

I dislike technology industry's number-racing gambit; so I consider it important to have a fixed target that's good enough and do not change. Letting one's page size goal shift year-over-year with no inhibition is actually a main root cause of websites' obesity crisis worldwide.

Even that today "it's 2025", my rule of thumb is my webpages (1) ought to have a reasonably-fast load time (i.e. around half-minute or less) under the connection speed equivalent to my first broadband Internet experience. (256 kbits/sec ADSL with ~22 KiB/sec download rate; the state of cyberspace I lived through in 2007)

This means I try, very, very hard (and mostly succeed) at making my each of webpage stay below 2/3 MiB mark; no matter that it was my software site, or my art site-- both of which are hand-coded and illustrated myself (2) to make it so.

They're also usable slower speed like GPRS (~6 KiB/sec download rate) and dial-up (~3 KiB/sec download rate) too, but it would now be up to the visitor to disable things in his browser to make the site comfortable to surf; like disabling images, disabling styling, or both. (3) So what I do to accomodate such more-extreme scenario is just making the site remain usable even when everything were stripped down to the bare HTML. (Hint: Test your site in traditional text mode browser; if your site remain useful there, you're good in this aspect)

Mayhaps that wouldn't matter too much to most people if they have an average internet connection.

Not all "average" are equal. Even the allegedly "first-world" country like USA, average speed in urban area there is actually few-order-of-magnitudes different from, say, rural America. And it's definitely different here in an allegedly "third-world" country I'm typing this from too-- vary wildly from 1 Gbit/sec GPON FTTH I have at home, to something comparable to 128 kbit/sec downlink when I sit at a crowded library in the same city. (Around 7800-fold difference, if you think about it)


(1) Baring some specfic kind of content that have special requirements; like an entry page of video podcast (contains video), or a panorama viewer (contains huge images).

(2) Which means I actually can paint my illustrations explicitly to be compression-friendly, or to make its composition gel well with any specific repeating/tiling technique used on my page design to reduce total image files size used.

(3) Disabling script is not applicable, since no script is used in the first place.