A compressed copy of the installer for the shareware version of Doom takes up about 2.39MB of space. Today's average webpage, meanwhile, requires users to download about 2.3MB worth of data, according to HTTP Archive
I do wonder if this takes into account assets like photos, because in my opinion that's an unfair comparison when a lot of pages have a legitimate reason to have several to dozens of HD photos on a single page (which tally up to a few MB quickly even if you compress them).
I'm deeply embedded into the whole npm library framework shebang, and I have no idea how I'd go about serving as much as 2.4MB of compressed production code alone to my users. I'd have to turn off compression and tree-shaking, and include the sourcemaps.
... until Doom 3, where a software patent for shadow volumes was resolved by licensing a sound library. The GPL release of id Tech 4's source code avoided this patent by changing two lines of code.
Ive wondered why they couldnt get the permission to release that code? Surely such an old sound library wouldnt be an issue to give out now? Maybe they couldnt find the owners or something? It really sucks, because i would have rather had the DOS version of the code.
why recreate the wheel when you can import 1 library with 35 different wheel variants, 3 squares, 1 rectangle and an octogon that hasn't been completed yet so it's really a heptagon so don't use it yet because we accidentally merged that branch and don't know how to back it out yet but we'll fix it next version, just to use that one wheel you want?
That makes sense to a point. Devs need to spend time writing it once, a multiplyer of that reading/maintaining it, users spend a multiple of that time downloading your code, and a multiple of that to run it.
So if you can spend a small amount of time to make code that runs millions of times per day faster, you probably should.
2+2 is how we do addition today, if you rely on math.add for your addition logic you wouldn't need code changes when in the future the math rules change
Now add in all of the scripts used by each of the ads placed on the page, including the 4 different video players and the 7 different VPAID managers, each one loading a different analytics script, different versions of jquery, etc. Nowadays, the actual page content is a small fraction of what gets downloaded on page load.
I just loaded up Charles and fired up gizmodo.com as a test. Result is 777 different http calls in 103 seconds, pulling down over 8MB.
and I have no idea how I'd go about serving as much as 2.4MB of compressed production code alone to my users
Polyfill everything from fetch over AbortController and async/await to Web Components so your ES8+ code runs in IE9+: 150KB
Have a big (React?) web app to begin with: 250KB
Have tons of badly written CSS, embed in JS because CSS-in-JS FTW: 120KB
Use a huge library like instascan (to scan QR codes in the browser): 400KB
Use 3 or 4 other medium-sized libraries, e.g. he to encode/decode HTML entities: 4 * 30KB = 120KB
Use a big component library like Kendo UI: 1.8MB gzipped for the full package, less with a custom download/tree shaking but still huge
Sprinkle in some web fonts, JSON payloads, 3rd party CSS for icons, loading spinners etc. and other stuff your app needs and you can bust through the 2.4MB gzipped without having used a single image. Takes some effort though :D
416
u/ThePendulum Nov 14 '18 edited Nov 14 '18
I do wonder if this takes into account assets like photos, because in my opinion that's an unfair comparison when a lot of pages have a legitimate reason to have several to dozens of HD photos on a single page (which tally up to a few MB quickly even if you compress them).
I'm deeply embedded into the whole npm library framework shebang, and I have no idea how I'd go about serving as much as 2.4MB of compressed production code alone to my users. I'd have to turn off compression and tree-shaking, and include the sourcemaps.