
The average size of Web pages is now the average size of a Doom install - Ovid
https://mobiforge.com/research-analysis/the-web-is-doom
======
jessriedel
I'm skeptical that developers talking to each other about how bad web bloat is
will change anything. They will still face the same incentives in terms of ad
revenue, costs of optimization, etc.

Here's a random idea that might have more potential: create an adblocker
browser plugin that also colors URLs based on how slow they are expected to
load, e.g., smoothly from blue to red. The scores could be centrally
calculated for the top N URLs on the web (or perhaps, an estimate based on the
top M domain names and other signals) and downloaded to the client (so no
privacy issues). People will very quickly learn to associate red URLs with the
feeling "ugh, this page is taking _forever_ ". So long as the metric was
reasonably robust to gaming, websites would face a greater pressure to cut the
bloat. And yet, it's still ultimately feedback determined by a user's revealed
preferences, based on what they think is worth waiting how long for, rather
than a developer's guess about what's reasonable.

~~~
Razengan
I think a more radical departure is needed. It's about time to acknowledge
that the web is increasingly being used to access full-blown applications more
often than "webpages."

Web browsers have more or less become mini operating systems, running
elaborate virtual machines. There's way too much complexity for everyone
involved — from web devs and browser devs to the users and the people who
maintain the standards, then there's the devs who have to make native clients
for the web apps — just to deliver products that don't have half the power of
OS-native software. Everyone has to keep reinventing the wheel, like with
WebAssembly, to fix problems that don't have to be there in the first place,
not anymore:

Thanks to smartphones, people are already familiar with the modern concept of
the standalone app; why not just make downloading an OS-native binary as easy
as typing in a web address, on every OS?

Say if I press Cmd+Space on a Mac and type "Facebook" in Spotlight, it
immediately begins downloading the native OS X Facebook app. The UI would be
described in a format that can be incrementally downloaded, so the experience
remains identical to browsing the web, except with full access to the OS's
features, like an icon in the Dock and notifications and everything.

TL;DR: Instead of investing resources in browser development,
Android/iOS/OSX/Windows should just work on a better standard mechanism to
deliver native apps instead.

~~~
abiox
> Android/iOS/OSX/Windows should just work on a better standard mechanism to
> deliver native apps instead

one might imagine that after these competing and incompatible native apps
become a headache for crossplatform pursuits, a new platform will emerge that
provides a uniform toolset for developing (mostly) native-platform independent
applications.

perhaps this toolset will utilize a declarative system for specifying the user
interface, and a scripting system that is JIT'd on each platform.

~~~
arcticfox
Magic! We could even have standardized links between the apps, and companies
that specialize in finding content no matter what app it's in.

I think you're on to something...it could be huge... Heh.

~~~
TeMPOraL
> _I think you 're on to something...it could be huge... Heh._

Could be. Sad that it isn't. Think how awesome it would be if app developers
actually cared about interoperability instead of trying to grab the whole pie
for themselves while giving you a hefty dose of ads in return. This is mostly
the fault of developers, but the platform itself could help a lot if it was
more end-user programmable. You'd have at least a chance to _force_ different
apps to talk to each other.

~~~
bendbro
He's being sarcastic. Links are literal web links and the Company he's
referring to is Google.

~~~
TeMPOraL
Yes, I know. And I'm trying to subtly point out that it doesn't even work on
the web, because it got fucked up by cowboy companies who ignore standards and
do whatever they like to get easier $$$.

------
snowwrestler
The Doom install image was 35x the size of the Apollo guidance computer.

Thirty-five times! Apollo software got us to the moon. Doom wasted millions of
man-hours on a video game.

My point of course is that these comparisons are not actually that
illuminating.

Are web pages much heavier than they need to be? Yes. This presentation very
capably talks about that problem:

[http://idlewords.com/talks/website_obesity.htm](http://idlewords.com/talks/website_obesity.htm)

Does comparing web pages to Doom help understand or improve the situation? No,
not any more than comparing Doom to Apollo memory size helps us understand the
difference between a video game and a history-altering exploration.

~~~
harryf
> Are web pages much heavier than they need to be? Yes

What about the question "do web pages work any better than they did in 2007?"
when we were using full page reloads and server side logic instead of
Javascipt tricks.

I see so much basic brokenness on the web today from the back button not
working to horribly overloaded news websites with mystery-meat mobile
navigation I find myself wondering what have we really achieved in the last 9
years? This stuff used to work

~~~
untog
I think you are looking at the past through incredibly rose-tinted glasses.
The web has been a mess for a long time, and we used to have to make sure our
computer was set to 800x600 and we were using Internet Explorer 6 in order to
even use it.

~~~
coolsunglasses
>make sure our computer was set to 800x600

Thaaaaaaaat's nonsense. I had relatively high-res CRTs (1600x1200) in the late
90s and early 2000s.

My father and I were able to get by with Netscape Navigator and Firefox for
quite awhile as well.

~~~
soperj
Firefox was released in November 2004.

~~~
dice
The initial release of Phoenix was in 2002. Many long-time Netscape/Mozilla
users (myself included) switched very early on.

~~~
coolsunglasses
I remember even relatively computer un-savvy folk in '98 having 1024x768
monitors.

------
robotnoises
Before everyone jumps onto the JQuery/Bootstrap/etc sucks bandwagon, just a
reminder that the minified jquery from cdnjs is 84.1kb. Bootstrap is 43.1kb.

If you want your page to load fast, the overall "size" of the page shouldn't
be at the top of your list of concerns. Try reducing the # of requests, first.
Combine and minify your javascript, use image sprites, etc.

~~~
r1ch
That's still 84 KB of highly compressed javascript code to parse and execute.
Even on a 4.4 GHz CPU core and a cached request, jquery takes upwards of 22ms
to parse - that's just parsing - not even executing anything! Now add a bunch
of other frameworks and utility scripts and your 100ms budget for feeling
"fast" is gone before you even reach the HTML content.

~~~
dclowd9901
How long does it take you to start Word versus loading Google docs?

Has everyone gone insane? The web is absolutely incredible and JavaScript is
absolutely killing it as a portable application language. Remember the dark
days of flash? Stop complaining.

~~~
supergauntlet
This is disingenuous - he's obviously referring to image and text articles,
not complicated web apps. Obviously such a website is going to take longer to
load, just as complex native applications take a while to load. But to claim
that because Word takes a while that it's okay that A WEBSITE WITH LITERALLY
JUST TEXT AND IMAGES is 18 megs big and takes 6000 ms to load is fucking
stupid.

~~~
TeMPOraL
Also, Word takes a while to _load_ , but then works fast and is responsive -
as well-written native apps are by default - and doesn't suck up your system
resources. Something which can't be said about many websites "with literally
just text and images".

~~~
Skinney
You're comparing a well-written native app with a poorly written website. I'm
currently working on a web-app that requires an about 600kb (minified, yes I
know) app.js file.

It takes a while to load (not really, 100ms + download), but after that it is
silky smooth due to client side rendering (faster than downloading more html)
and caching.

On the most demanding page, heap usage is a little more than 20mb.

Sure, there are a lot of websites which are slow and huge memory hogs. But
that goes for many native apps as well.

------
K0nserv
Quite happy with my own web page/blog. Pages hover at around 10kb, 30kb if I
include some images. I think the page size can be attributed a lot to there
being no JS except for GA.

I have taken a lot of inspiration from
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/) and
[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)

Of course the size will differ depending on the site's purpose, but I feel
like most web pages could stand to loose a lot of weight.

EDIT: I have a guide to setup a similar blog/site here[0]

0: [https://hugotunius.se/2016/01/10/the-one-cent-
blog.html](https://hugotunius.se/2016/01/10/the-one-cent-blog.html)

~~~
nickpsecurity
That loaded SOOO fast on mobile with no delays or scrolling problems. Great
job!

Note: Might try it with NoScript later. Always a good indicator of...
something...

~~~
K0nserv
Fun story about NoScript. I used to use AMP[0]. But I reverted that for two
reasons.

1\. The size of their js is ~170kb roughly 17 times larger than most of my
pages.

2\. It loads from a 3d party domain which means that NoScript/uBlock Origin
users will see a blank white page.

The project does impose some constraints that will help reduce page weight and
increase page speed, but for my page sizes it's ridiculous to use their JS.

0: [https://www.ampproject.org/](https://www.ampproject.org/)

~~~
nickpsecurity
The site certainly loaded fast. Never heard of them before. Thanks for the
link.

------
Tenhundfeld
Interesting comparison, if a bit arbitrary. It raises a couple of questions
though.

1) How do the numbers come out when you exclude images?

It's valid and good to know the total sizes, including images, but that can
hide huge discrepancies in the experienced performance of a site.

For example, a page with 150KB of HTML/CSS/JS and a single 2.1MB hero image
can feel very different from a page with 2MB of HTML/CSS/JS and a few 50KB
images.

If we're just interested in total bandwidth consumption, then sure, total size
is a good metric. If we're interested in how a user experiences the web,
there's a lot of variability and nuance buried in that.

2) What device and methodology were used to take the measurements?

In this age of responsive design, CSS media queries, and infinite
scrolling/deferred loading, it really matters how you measure and what you use
to measure.

For example, if I load a page on my large retina screen and scroll to the
bottom, many sites will send far more data than if I load them on my phone and
don't scroll past the fold.

I only skimmed the article and didn't dig in to the references. These
questions may be answered elsewhere.

~~~
spiderfarmer
The speed index was invented for benchmarking this:
[https://sites.google.com/a/webpagetest.org/docs/using-
webpag...](https://sites.google.com/a/webpagetest.org/docs/using-
webpagetest/metrics/speed-index)

~~~
Tenhundfeld
Ah, very cool, thanks for sharing. I'm familiar with a lot of the tools for
evaluating the performance of a single site (e.g., that I'm developing), but
I'm pretty ignorant of the standard approaches for these types of larger scale
benchmarking projects.

~~~
artificial
If you're developing you may not be aware of Page Speed Insights, extremely
handy for SEO.
[https://developers.google.com/speed/pagespeed/insights/](https://developers.google.com/speed/pagespeed/insights/)

~~~
Tenhundfeld
I actually wasn't aware that the site could also perform the test, but the
Page Speed Insights Chrome extension is one of my go-to performance tools. The
output looks the same, though formatted a little better in some places. The
extension is nice though, because it lets you check private sites.

------
seanwilson
Lots of people are focusing on excessive JavaScript and CSS but these combined
are easily dwarfed by a single high quality image.

Try visiting Apple's website for example. I can't see how you can have a small
page weight if your page includes several images that are meant to look good
on high quality screens. You're not going to convince marketing and page
designers to go with imageless pages.

Doom's original resolution was 320x200 = 64K pixels in 8-bit colour mode. Even
an Apple Watch has 92K pixels and 24-bit colour (three times more space per
pixel) now, and a 15" MacBook display shows 5.2M pixels. The space used for
high quality images on newer displays is order of magnitudes higher to what
Doom hardware had to show.

~~~
spriggan3
> Try visiting Apple's website for example.

Indeed, right now on mobile the biggest asset on apple.com is a 1.7 MB
picture.

[http://images.apple.com/v/home/cm/images/heros/environment_e...](http://images.apple.com/v/home/cm/images/heros/environment_earth_day_large_2x.jpg)

The total size of the webpage being 2.5 MB.

------
Kurtz79
It is hardly surprising, considering that a single picture taken with an
average smartphone is probably already surpassing that by quite a bit.

Times change, and 20 years in tech is equivalent to several geological ages.

If anything, it cannot really be underestimated how some developers were able
to craft such compelling gaming experiences, with the limited resources
available at the time.

My personal favorite as "most impressive game for its size":

[https://en.wikipedia.org/wiki/Frontier:_Elite_II](https://en.wikipedia.org/wiki/Frontier:_Elite_II)

------
Jerry2
Maciej Cegłowski has a great talk/writeup on this very problem:

 _The Website Obesity Crisis_

[http://idlewords.com/talks/website_obesity.htm](http://idlewords.com/talks/website_obesity.htm)

Here’s the video of the talk if you prefer to hear him speak:
[https://vimeo.com/147806338](https://vimeo.com/147806338)

------
seagreen
Oh God.

Every discussion about the web will continue to be a mess until we clarify
what we're talking about.

Let's try rephrasing the title a couple times.

Rephrase 1: "The average size of a webapp is now the average size of a Doom
install".

Response: Interesting, but not bad! Heck, some webapps are games. "The average
size of a web game is now the average size of Doom" isn't a sentence that
damns the web, it's a sentence that complements the web! (or would if it was
true, and it might be for all I know)

Rephrase 2: "The average size of web document is now the average size of a
Doom install".

Response: Well this sucks (or would if it was true -- still we don't know).
Simple documents should be a few KB, not the size of a game.

Basically our terminology is shot to crap. Imagine if 19th century engineers
used the same word for "hand crank" and "steam engine". "Hand crank prices are
skyrocketing! What's causing this massive bloat!" Whelp, that could mean
anything.

The best solution: web browsers should enforce a clear distinction between
"web documents" and "web apps". These are two different things and should be
treated separately. This won't happen though, which leaves us (the rest of the
tech community) to explore other options . . .

~~~
nulltype
Web apps/documents both look pretty good compared to modern games, those
things are 100s of MB at least.

------
dreamlayers
In the late 00s I remember turning on an old computer with a 650 MHz Athlon
CPU and being surprised that web browsing performance in Firefox wasn't bad.
Now if I try that with a 1 GHz Pentium 3, performance is absolutely horrible.
Is this why?

~~~
fredley
This, and Javascript, and browser bloat.

~~~
zokier
Unless the browser ends up swapping a lot I doubt that browser bloat would
cause significant perceptible performance regressions compared to the quite
significant amount of optimization that has happened in the meanwhile.

------
spriggan3
The average data plan here is 10GB :

1,000,000 * 10 / 2250 = 4444 web pages a month

4444 / 31 = 143 web pages a day at most on mobile.

While it is somehow acceptable, I don't see data plans getting cheaper yet the
size of the average webpage is raising fast.

It doesn't seem like most websites have heavily invested in using HTML5
offline capabilities or actual mobile first design either, something easy to
check with chrome dev tools.

Also let's talk about ads : Polygon.com a site I visit often , first article
on the homepage with an Iphone 5 :

\- with ads/trackers 1.5mb \- without ads 623kb

More than half of the load is ad/tracking related. This isn't normal.

------
overcast
With the majority of users moving towards mobile, I really think this is an
issue, and I've been consciously building projects as lean as possible.
Removing bloated jquery libraries was a big one. With native calls like
document.querySelectorAll document.querySelector I've found I can 90% get by
without it. For the rest, using something like vue.js, and I've taken care of
all the dom manipulation, data binding, etc.

~~~
CaptSpify
I lived in $nowheresville, TN for a bit. This drove me insane. Sure, your
webapp works great in downtown SF, but try loading it with the spotty
connection the rest of the country has, not to mention the rest of the world.

One of the places I worked at had a computer hooked up to a ~800 kbps modem,
and would test all their web-pages on that. It was really eye-opening, and I
wish more companies would benchmark like that

~~~
mod
Chrome network tools has throttling that can simulate really shitty networks,
I use that a fair bit.

------
warriorkitty
Oh, you just want to add a class to the element? \ _adds whole jQuery\_ That's
what's wrong with the web.

Oh, and you need a loop? \ _adds underscore.js\_

~~~
swalsh
Imagine how fast the web would be if browser manufacturers could "approve"
frameworks, and store them as a "standard library" of sorts. A global cache.
Then you have ONE copy of jQuery for all sites on your machine.

Wanting to use a framework shouldn't be discouraged. The issue here isn't
developers trying to save time, the issue is the shitty tools.

~~~
toyg
Yeah, javascript historically lacks a stdlib and now it's so big that nobody
could probably agree on one. Chalk another one for "the road to hell is paved
with good intentions".

------
AndyKelley
I wanted to see how one of my personal projects compared, so I looked at
Groove Basin.

Groove Basin [1] is an open source music player server. It has a sophisticated
web-based client with the ability to retag, label, create playlists, stream,
browse the library, chat with other users, upload new music, and import music
by URL.

I just checked the payload size of a cold load, and it's 68 KB.

I'll just keep doing my thing over here.

[1]:
[https://github.com/andrewrk/groovebasin](https://github.com/andrewrk/groovebasin)

------
datalist
Not too long ago Medium pushed an "invisible" 1MB image to clients

[https://binarypassion.net/digital-
decadence-6ea59251d64d](https://binarypassion.net/digital-
decadence-6ea59251d64d)

and the video it refers to
[https://vimeo.com/147806338](https://vimeo.com/147806338)

~~~
damptowel
At my frst job I once had to fix a wordpress site that was 'too slow' which
loaded a 12MB 4k by 4k favicon. I kid you not. It also loaded jquery 4 times,
had about 20 unminified stylesheets linked in the header. When I told this to
my manager he told me 'oh but you only need to load that stuff once and then
its cached, so that can't be an issue'. I did not last long in that place. The
backend was even more of a wasteland.

~~~
datalist
A 16 megapixel favicon does sound scary.

------
stegosaurus
If web bloat is a problem, I don't think that looking at whether <insert
buzzword framework of CURRENT_YEAR> can be removed is the answer.

I suggest that at the moment, we have basically two camps of website, with
rough, fuzzy boundaries.

1\. A place where someone sticks up an insight, or posts a wiki page, or
whatever, to share some thought to others (if anyone actually cares). The
blogs of many users of HN. Hacker News itself. Wikipedia. The Arch Linux Wiki.
lwn.net. Etc. The sites are very roughly concerned with 'this is what I care
about, if you do, great, this is useful to you'.

2\. Commercial web sites that employ sophisticated means to try and enlarge
market share and retain users. AB testing. 'Seamless' experiences which are
aimed at getting more views, with user experience as an afterthought (a sort
of evolutionary pressure, but not the only one).

Complaining that camp #2 exists is strange. It's a bit like lamenting the fact
that chocolate bars aren't just chocolate bars, they have flashy wrappers,
clever ingredients, optimized sugar ratio, crunchy bit and non crunchy bit,
etc.

It works! A snickers bar is a global blockbuster, and 'Tesco chocolate bar' is
the functional chocolate bar that just does the job, but will never attain
that level of commercial success, it serves a different role.

\-----

My personal view:

Fundamentally what I want when we click a link from an aggregator, is an
'article.txt' with perhaps a relevant image or two. Something like
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/) maybe.

But if a site actually does that, a website like The Guardian, I'd fire up
wget, strip all the advertising, strip the fact it's even The Guardian, and
read it like a book. If everyone does it then no-one makes any money, site
dies.

So what we actually have is this constant DRM-style race to try and fight for
our brains to get us to look at adverts. It's not about jQuery, it's about
advertising, branding, 'self vs other' (the integrity of a company as a
coherent thing), etc.

I don't know what the answer is here. I think this is why I find concepts like
UBI so appealing - I find it kind of alarming that we seem doomed to infect
more and more of the commons with commercialization because we haven't found a
solution to keep each other alive otherwise.

~~~
RodericDay
I dig that you tie this domain-specific problem with that much larger social
issue.

~~~
stegosaurus
Thanks. I've been struggling a lot with life in general lately (depression,
etc), and it's nice to have some glimpse that someone else shares the view,
maybe.

I think we have a real issue at the moment with people funneling their efforts
into ways of dealing with issues at the micro level, rather than the macro
level. Local optima. Something like that.

It makes me happy to see the sort of political revolutions that the Internet
can bring about, but sad to see that we're still thinking so small. e.g. "Get
x into tech" rather than "Make it so that you don't need to be in tech to live
a decent life". That sort of thing.

------
forgotpwtomain
How about browser bloat? Each chromium tab on linux takes an extra ~50-150mb
depending on the site -- and I still have no idea what they need all of that
memory for...

~~~
r1ch
Mostly Javascript and caches.

------
dempseye
I once bought a pre-made landing page template with all kinds of whizz bang
Javascript libraries built in. The demo page was 4 MB. In the time it took to
strip all the trash out of the template I could have designed the page myself.
I'll never do that again.

I wonder how much of the problem is due to bloated templates.

------
skarap
Looks like most of the discussion here is on network traffic.

Minifying JS and CSS, compression, CDNs and caching won't keep your browser
from having to render all the stuff.

\---

The stewardess on a new jet airliner:

\- Ladies and gentlemen, welcome aboard of our new airplane. On the second
deck you'll find a couple of bars and a restaurant. The golf course is on the
third deck. You're also welcome to visit the swimming pool on the fourth deck.
Now - ladies and gentlemen - please fasten your seatbelts. With all this sh*t
we'll try to take off.

------
jordigh
Just to clarify, since I was confused (I remembered that Doom 2 was about 30
megs uncompressed, which websites are still a long ways from), this metric
appears to refer to the compressed size of the Doom 1 shareware distribution.

[http://www.doomarchive.com/ListFiles.asp?FolderId=216&Conten...](http://www.doomarchive.com/ListFiles.asp?FolderId=216&ContentsFolderId=216)

------
stepvhen
> Recall that Doom is a multi-level first person shooter that ships with an
> advanced 3D rendering engine and multiple levels, each comprised of maps,
> sprites and sound effects.

Doom isn't in true 3D, its an advanced raycasting engine. The levels are all
2D, there are no polygons, you can't look up and down. Doom has been ported to
a TI Calculator. Lets maintain some perspective here.

~~~
coldtea
> _Lets maintain some perspective here._

I see what you did here.

------
donkeyd
Visited a website a few days ago, which used 2048x1365 jpegs for 190x125
buttons. They had multiple buttons like this on multiple pages. I sent them an
e-mail about this, but I don't expect them to fix it.

------
kgr
Send “models” rather than code. Low-level code is relatively unexpressive,
contains considerable redundancy, and as a result, is relatively large. By
sending high-level models instead, which are then expanded on the client to
working code, application download size can be greatly decreased. Models
typically provide one to two orders of magnitude of compression over code.

This video shows how we do it:
[https://www.youtube.com/watch?v=S4LbUv5FsGQ](https://www.youtube.com/watch?v=S4LbUv5FsGQ)

This document gives some results (like a GMail client that is 100X smaller):
[https://docs.google.com/a/google.com/document/d/1Kuw6_sMCKE7...](https://docs.google.com/a/google.com/document/d/1Kuw6_sMCKE72Ut0EsoPNFr9YKDkaw6DIfCDgExYkS2k/pub)

------
collyw
I remember thinking years ago, that my CV in Word took up more memory than my
first computer (Acorn Electron 32kb ram). It amazes me that I used to play
Elete on that machine.

------
aorth
> The top ten sites are significantly lighter than the rest (worth noting if
> you want to be a top website).

Wow. That's nice to see actually.

~~~
faitswulff
I suspect that the top ten sites are lighter because they must perform under
load rather than being a top ten site because they load quickly, but it is
nice to see. Imagine the billions of man hours that would be wasted by
humanity waiting for the top ten sites to load.

------
jokoon
I just watched
[https://www.youtube.com/watch?v=Q4dYwEyjZcY](https://www.youtube.com/watch?v=Q4dYwEyjZcY)
this video about the early HTML standardization process, and it seems to
explain all the ills of HTML.

So indeed, there is a huge optimization opportunity of having a stricter error
model.

Also, I'm really wondering how much battery could be saved when surfing such
pages.

Also I'm sure there is a lot of potential going in the pre-parsed document
model. But that's a next level kind of engineering I guess.

------
jakobdabo
Yesterday I discovered that Twitter's HTTP headers alone are ~3500 bytes long
(25 tweets!) with several long cookies, custom headers and the Content
Security Policy[1] containing ~90 records. Is this considered normal nowadays?

[1]
[https://en.wikipedia.org/wiki/Content_Security_Policy](https://en.wikipedia.org/wiki/Content_Security_Policy)

------
imaginenore
For the last project I built the initial page load with the absolutely minimal
JS that was embedded into the page. Then it loaded the rest whenever it needed
it. My coworkers were shocked how quickly the page loaded.

It's actually better to show the user some progress bar, than the standard
browser's "Waiting for yoursite.com".

You can get away with a lot without jQuery, while still having clean-ish code.

------
alasano
I'm genuinely excited by ensuring great response times and minimal load on a
website.

Locally I see so many companies building good looking but horrendously
optimized websites for their clientele who don't know enough to ask for it.

The last company I worked at were building a local search engine and were
displaying thumbnails whilst loading full size pictures which were hot linked
from businesses websites. With an auto loading feature at the bottom of the
page by the php backend, an initial 5-6 Mb page load could turn into 30+ Mb
within a few seconds of scrolling. Add to this no gzipping and caching was not
properly configured either.

I tried my best to get some changes going but the senior (and only other) dev
wouldn't allow any modifications to the current system "for the moment". It
was a bit frustrating to see so many easy fixes ignored.

------
njharman
So, were can I play Doom in the browser?

~~~
Kristine1975
Here: [http://playdosgamesonline.com/doom-ii-hell-on-
earth.html](http://playdosgamesonline.com/doom-ii-hell-on-earth.html) (yes,
it's Doom 2, and yes it requires a fast machine since it emulates a DOS PC in
the browser)

~~~
nickpsecurity
I can't help but add that it's a DOS PC + a game that _still_ loads faster
than some web pages. At some point, even the apples to oranges comparisons
start saying something because it's glaringly obvious.

------
AdamN
The only real solution is a search engine that allows the end user to clip the
results based on the maximum size of the total page. I've often wondered why
Duck Duck Go doesn't do this as well as filter search results based on number
of ad networks used, etc...

------
perseusprime11
Enable Ghostery and load cnn.com and you will see why the web pages are so
heavy these days.

------
CaptSpify
disclaimer: my own blog -
[https://blog.thekyel.com/?anchor=Why_I_Block_Scripts_and_Ads](https://blog.thekyel.com/?anchor=Why_I_Block_Scripts_and_Ads)

I kept looking for a "minimal" blogging platform, but they all had too much
bloat/JS/etc. I guess minimal means different things to different people. I
ended up just writing my own. The biggest post I have is 7.41 KB.

I used to be interested in front-end design, but since it's the industry
standard to use $latest_framework, instead of tried and proven practices, I've
given up on that idea.

~~~
detaro
One extreme end of the scale ;)

I feel like investing a few hundred extra bytes on _some_ styling might be
worth it, a la
[http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)
vs [http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/)

~~~
CaptSpify
I'm of the mindset that our browsers are built backwards. For "content-
oriented" sites, we should present text, and give the users tools in their
browsers to present them as the user sees fit. Instead, we expect the site to
design it. Something like Firefox Reader View.

Some people may like bettermotherfuckingwebsite better, but I personally don.t

"presentation-oriented" sites are a different story, of course

~~~
detaro
Basic styles don't mess with Reader View or other customization, so I don't
see a large downside to include them, they just make it nicer for people not
using such tools.

Unless the point is to get people to use different tools?

~~~
CaptSpify
> Unless the point is to get people to use different tools?

Kind of. I dream of an Internet where people have their own CSS/styles, and
they can make it look how they want, rather than how the website wants it. I
think of it like this: I'm a linux guy. I want my tools to output plainly to
stdout. If I want to format them, I'll pipe them into my own formatting tools.
I wish websites worked that way as well.

------
bb85
> The top ten sites are significantly lighter than the rest (worth noting if
> you want to be a top website)

Isn't that that the top websites have a lot more ressources available to
improve asset management, cleanup and refactor?

~~~
tyingq
This set of benchmarks is often helpful:

[http://www.dynatrace.com/en/benchmarks/united-
states/](http://www.dynatrace.com/en/benchmarks/united-states/)

Particularly the "last mile" or "Chrome Homepage" tabs.

They cover the top websites, grouped into categories like "Retail", "Travel",
"Media", etc.

The disparity across competitors is pretty stunning, with some websites
getting close to 1 second to download/render a page, and others taking 6, 7, 8
, even 10 seconds. And these are all big, well known, companies.

And, for the most part, it all correlates very well to total page weight, and
total number of artifacts on the page (js/css/images/etc). There are some
exceptions, but it's a pretty strong correlation.

------
maerF0x0
This all comes down to cost. It is much cheaper to have "bloat" than it is to
pay devs to fix it. And customers find it much cheaper to deal with "bloat"
than to find smaller alternatives. Sure the average webpage is bigger than
doom, but the CPU in my phone is approximately 100x (times multicore too?)
than the 486 that ran Doom.

Sure, if man hours were free, we could trim it all down to (my rough guess)
about 1/10th the size. But at $100 or even $10 an hour its just not worth it.
Pay the GBs to your carrier, spend $50 more on a better phone.

~~~
niutech
It would cost no extra time if devs made websites from scratch with
performance in mind. Save optimized images, minify code as a build task, etc.

------
Joof
From this title; maybe hacker news needs a twitter?

Also: You can't use average page weight when you are just looking at the top
ten. That downturn could represent a single website; all others could be
increasing in size.

------
chowes
Wondering if an idea like this would work:

Bundlers like Webpack already import JS in a modular structure. I'm wondering
if we could do some profiling into popular npm module combinations (I know
many people using React + Lodash + Redux Router, etc), bundle them up, and
have Webpack load in those combos from a CDN via <script>?

Now this would probably require some work on webpack's end (the
__webpack_require__(n) would have to be some sort of consistent hash), but at
least everyone who blindly require('lodash') will see an improvement?

~~~
necessity
Web pages shouldn't need JS at all, except for the basic eye candy it was
originally used for, and most importantly shouldn't break without it. A web
page that doesn't work without JS is broken.

Web apps are another deal though.

------
jccalhoun
and the .kkreiger beta only uses 96k!
[https://en.wikipedia.org/wiki/.kkrieger](https://en.wikipedia.org/wiki/.kkrieger)

------
CM30
It's also about 2 times bigger than a lot of SNES and Mega Drive games. Or
about 4 times bigger than Super Mario World (512KB).

As for why it's getting so insane, probably either:

1\. Frameworks, since most people don't remove the code they're not using. For
Bootstrap or Foundation, that can be a lot of extra code.

2\. Content Management Systems, since stuff like WordPress, Drupal, Joomla,
any forum or social network script, tend to add a lot of extra code (more so
if you've added plugins).

3\. The aforementioned tracking codes, ads, etc.

------
hackertux
I also recommend
[https://news.ycombinator.com/item?id=10820445](https://news.ycombinator.com/item?id=10820445)

------
chasing
The only conclusion I can legitimately draw from this article is that in
twenty years a single web page will be larger than the 65GB Grand Theft Auto V
install.

------
systematical
Amazon isn't what I'd call "light" at 4.7 MB, but looking at my companies
market all the bigger players are way lighter than us.

------
sergiotapia
Arguably sites have been increasing in size for one simple reason: It directly
results in increased sales.

Everything is sales.

If cleaner, 'purer' sites made more money you bet the average web page would
be 10kb.

It's all about what translates to more sales. As such, you won't ever see a
return to more traditional websites. Look at Amazon with it's virtual dress
models, heavy as hell, but they most certainly land more sales.

~~~
niutech
Quite opposite. It is proved that longer page loading time is less conversion.

------
webscalist
What happened to semantic markups? In the name of rendering optimizations,
many web sites use css background image instead of <img>

------
apeace
This page clocks in at 935kb in my browser. According to this same page, that
is roughly the size of Sim City 2000.

------
intrasight
The publishers really have no incentive to address this until a critical mass
of users install adblock software.

------
ebbv
I would argue two things:

1) This is an irrelevant statistic.

2) Even if this were true it's not that big of a deal.

This is irrelevant because most people don't browse the average web page. They
browse the top few sites on the internet and that's it. A more relevant
statistic would be what have the sizes of the top 50 sites been over the last
15 years. I imagine they still may have grown on average, but download speeds
have also grown over that time. Especially on mobile.

Even if we accept the premise that web sites as a whole, including the most
popular ones are all growing and are now an average of 2.2MB each. Who cares?
2.2MB is nothing in 2016. Even on an LTE connection that's probably between 4
and 1.5 seconds to download the full page. And a lot of that size is probably
in ads, which nobody minds if they load last or not at all.

Lastly, this is a self fixing problem. If a site is too bloated, users will
stop going to it.

But I would propose that a lot of this increase in size is due to users
(especially mobile) having higher and higher resolution displays, which
necessitates higher resolution content, which of course is bigger.

~~~
Ruud-v-A
I care. I know a lot of people (here in western Europe) who are on a 1
GiB/month data plan. 2.2 MiB per page means that you can visit 15 pages per
day. Better think twice before you click a link.

Besides, 2.2 MiB for a page is pure bloat. Unless the page is heavy on images,
you can usually fit all of the content that matters in a tenth of the size. In
300 KiB you can fit a 500-word article with 160 KiB picture, a few webfonts,
headers/footers and stylesheets. Using a factor ten more is just ridiculous.

~~~
niutech
I would recommend using Opera Mini or GDrives Web Light
([http://gdriv.es/l/](http://gdriv.es/l/))

------
awqrre
It's initially cheaper to make larger web pages, you don't have to optimize
for size (most of the time it would probably execute faster if it was smaller
but probably not always). Some others make it larger on purpose for
obfuscation (like Google).

------
sugarfactory
Google developed SPDY, an efficient binary representation of HTTP messages.
Maybe they will do the same thing but for HTML. It would be much more
efficient if one could design a binary representation of HTML that can only
express well-formed HTML.

~~~
person15
[https://en.wikipedia.org/wiki/Binary_XML](https://en.wikipedia.org/wiki/Binary_XML)

------
bendbro
Why can't all these frameworks just be cached? If a cross site request to
cdn.com/react-v1.0.js is cached under cdn.com, at most one download will
trigger. That seems to solve the problem, but maybe I'm missing something.

~~~
bendbro
I've seen people mention that caching is broken since it only works when the
name and version are the same; however, I don't see how this is any different
than two packages of the same functionality being uploaded to an APT repo with
different names.

------
Khaine
Isn't the answer to just create a reasonable standard library for javascript
so people don't need to link in megabytes of frameworks

------
JoeAltmaier
...and my first computer had 128 _bytes_ of RAM. And a 300-baud modem.

~~~
NoGravitas
That's amazing, what was it? My first computer had 5K of RAM.

~~~
JoeAltmaier
Altair 8800, kit from MITS. And I wrote a game on it, using keyboard and
screen.

------
myared
GTA 5 is ~65GB in size. One day, web pages will be bigger than that.

------
jmnicolas
> The average size of Web pages is now the average size of a Doom install

It's not really surprising in a world where a graphical driver is > 100 MB
(Nvidia driver for Windows).

~~~
elsurudo
They mean the original Doom, which ran with a software renderer anyways.

------
NelsonMinar
Is there a Chrome extenson that shows the size of a web page? There's a good
one for page load time that I use, but I want kilobytes with and without
cache.

------
ivanhoe
Doom is not a good measure, when web pages become bigger and more bloated than
your average printer or scanner driver, then it will be alarming :)

------
LordKano
Great, another kooky unit of measure.

"This new re-design gets us down to 0.4 Doom installs without sacrificing any
of the visual elements."

------
thom
There's a reason that the economics of web development mostly work and the
economics of games development mostly do not.

~~~
thedevil
This probably requires more explanation.

------
qaq
Too bad we can not measure it football fields

------
tacone
But they load faster than Doom used to.

------
damon_c
In 20 years the average size of web pages will be the size of a Quake 3
install. This is progress.

------
jrl
This is one of the reasons why I love a simple website without too many
whistles and bells.

------
partycoder
For Internet 3 we should call John Carmack and put all of the internet in a
MegaTexture.

------
dclowd9901
Are we really complaining about webpage size when fully 30% of web traffic is
Netflix? This might be an unpopular opinion but websites are no longer just
html, css and js. They're full on applications with rich interaction and data
visualization. Call me when they're larger than an average modern native app
install.

------
brownbat
ronan has an account here, commented on this as it was developing a few months
ago:

[https://news.ycombinator.com/item?id=9981707](https://news.ycombinator.com/item?id=9981707)

------
hammock
Can anyone explain why a simple web page is so much bigger now than a whole
game?

~~~
robotnoises
Because we can! Games were slim back then because they had to be. Webpages are
fat now because our computers are fast.

Now, if a webpage were to approach the size of a contemporary game...

------
Shivetya
and here I remember that the PDF of the Turbo Pascal manual was so many
multiples of the compiler's size I needed a calculator to figure it out

------
flexterra
what is the average size of a native mobile app?

------
elcapitan
Doom would have been the superior solution to the World Wide Web.

------
pljns
The average Web page now does more than the average Doom install, I don't see
the relevance of this.

Although I get really annoyed when I visit a blog post whose page is 100x
larger than Dostoevsky's novels in .txt format. On my blog
([https://pljns.com/blog/](https://pljns.com/blog/)), JQuery and genericons
are often my largest file transfers, but I still clock under 500kb.

~~~
batat
[https://pljns.com/](https://pljns.com/)

> 40-pound jQuery file and 83 polyfills give IE7 a boner because it finally
> has box-shadow

[x] check

> You loaded all 7 fontfaces of a shitty webfont just so you could say "Hi."
> at 100px height at the beginning of your site?

[x] assuming 404'ed fontawesome as shitty webfont, check

> You thought you needed media queries to be responsive, but no

[x] check

> Your site has three bylines and link to your dribbble account, but you
> spread it over 7 full screens and make me click some bobbing button to show
> me how cool the jQuery ScrollTo plugin is

[x] check

Still pretty good site, but it's funny how accurately creator of
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/) has
described the situation with the modern web :)

~~~
pljns
These are all good points that I knew when I hastily pushed the site last
week. Still way under 1000kb!

Also, I said my _blog_ , but serves me right I guess ;-)

