Live data from Hacker News

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

mobiforge.com

61–70 of 467 posts

Re: The average size of Web pages is now the average size of a Doom install

#61

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.

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.

Re: The average size of Web pages is now the average size of a Doom install

#62

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 an…

The speed index was invented for benchmarking this: https://sites.google.com/a/webpagetest.org/docs/using-webpag...

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.

Re: The average size of Web pages is now the average size of a Doom install

#65
post #49

Earlier quoted context omitted.

I would say that a possible solution is also to better rank websites that mention the checksums of their external resources and make web browsers keep them in cache much longer... if pretty much every website uses jQuery, perhaps we should ship jQuery with the web browser?

Common libraries and frameworks are usually loaded from a CDN. These should stay in the browser's cache for some time.

Only if everyone is using the same CDNs :)

Re: The average size of Web pages is now the average size of a Doom install

#66

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\

Element.classList doesn't work in IE9 or below.

Array.forEach doesn't work in IE8 or below.

Fetch API for ajax isn't in any version of IE or Safari, or any mobile browser apart from Chrome for Android.

And so on.

It's not so much that front end devs are lazy, but more a case that building a set of polyfills for each and every browser support problem is actually hard. "just use jQuery" gets around the problem. I think most developers want to write better code, but most projects don't have the development bandwidth for them to do things better.

Re: The average size of Web pages is now the average size of a Doom install

#67

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\

I am not JS dev, but... At this point there should be tree shaking / dead code removal for JS widely deployed. Why it is not? I know that dynamic nature of JS causes some of it, but most code out there is not that dynamic. How good is Google's Closure compiler?

Re: The average size of Web pages is now the average size of a Doom install

#68
post #49

Earlier quoted context omitted.

I would say that a possible solution is also to better rank websites that mention the checksums of their external resources and make web browsers keep them in cache much longer... if pretty much every website uses jQuery, perhaps we should ship jQuery with the web browser?

Common libraries and frameworks are usually loaded from a CDN. These should stay in the browser's cache for some time.

Yeah, but per domain. Unless you use something like cjdns, if you end up with static.yourlovelydomain.com, the resource's going to get downloaded from scratch at the first attempt. If we had checksums attached to resources, there'd be provably no point bothering to download them in many cases.
Post reply on HN