Hacker News Reader

Comment by paulsutter | Hacker News Reader

There's only one way to make a tiny page that loads super fast - and that's to make every single decision with an eye towards efficiency.

People who say "hey, what's an extra 30KB for one library? It's only like 10x larger" will tend to reach a similar conclusion at every decision point. And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency.

I'm not saying this project is an important breakthrough, but I definitely applaud the effort. I've always been surprised at the large size of jquery. I'd love to see a benchmark for runtime performance, including a comparison of parsing time and a benchmark of common operations.

View on HN

> There's only one way to make a tiny page that loads super fast - and that's to make every single decision with an eye towards efficiency.

That sounds dangerously like premature optimization. For example, why spend the time creating optimized image sprites if it turns out they don't contribute significantly to load time? It's better to spend development time doing something else.

> And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency.

By using the word "bloat" it sounds like you're talking about bytes. Again, byte counts often aren't always the main culprit in slow loading of web pages. Synchronous scripts and/or 302 redirects can be much worse, for example. Don't start with the premise that the bytes are the problem and do a lot of work to reduce them, only to find out it isn't the problem. Profile the page load and see what is really the problem. Then fix that.

But the reality is, everyone that visits your site already has jQuery in their cache, because the common cdn sources are so ubiquitous, this making this 4k library actually add to your page load footprint. Using the most common, most likely to be a cache hit library is more efficient than using the smallest.

People need to stop saying this.

Please elaborate.

One thing... Mobile Safari didn't use to cache anything over 15KB uncompressed. http://www.phpied.com/iphone-caching/

(No idea about more current versions of iOS or browser-caching on other mobiles OSs.)

It's a reasonable point. Given the vast array of jQuery versioning across just the top thousand web sites, it's very plausible a user will not have each one of those cached, and then a lot of sites vary on what cdn (if not local) they're using.

I would be willing to bet that among just the top 1,000 sites, a user would be required to have 25 to 30 copies of jQuery cached to cover all the sites.

Reply on news.ycombinator.com