Hacker News Reader

Comment by dmethvin | Hacker News Reader

I know it's awfully tempting to obsess on something that is easy to measure, like file size. I also know it's tempting to imply things like "twice the file size means twice the page load time". But it's not true. It's NOT true.

Look at this video at 6m30s: http://channel9.msdn.com/Events/Build/2012/3-132

Productively optimizing a web page is no different than optimizing any other code. If you want to know why a web site is slow, profile it or run it through a tool like webpagetest.org. Don't just set off to rewrite all your loops to run backwards, or eliminate function calls, or reduce the amount of this or that without any understanding of the result.

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.

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.

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.

> 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.

Look at this video at 6m30s

What does that video possibly prove? That if you compare completely different sites, you can't use reductionist measures of individual attributes to compare speed? Is there anyone on HN who actually doesn't already know that? This is asking which of a collection of mystery vehicles is the fastest by engine size, and then revealing that one is a dump truck, one a train, and the other a motorcycle, with results that should surprise no one.

The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion. It is pretty much part and parcel that such a person is going to minimize elements, CSS, images, and scripts in such a case, and aren't simply going to replace jQuery with something like this and assumes that it will make everything fast.

The reality of something like jQuery, like Ruby on Rails or MongoDB, is if you start with it you'll likely be stuck with it. You can't simply make a full site and run it through the profiler and swap out components without significant rewriting.

> Is there anyone on HN who actually doesn't already know that?

I see a lot of discussion here based on the premise that this smaller script will make a big difference in overall page load time. It's why the audience in that video was leaning towards the site with the most JavaScript being the slowest. The first benefit listed on the minified.js page is "Minified is smaller!" so exactly what benefits does "smaller" imply?

> The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion.

I agree, and creating your own homebrew framework for a large project in a holistic fashion has its own pitfalls. Especially if you've never done it before.

"Smaller" on a slow connection does make a big difference. That's almost everyone, everywhere.

My phone is fast enough that the difference between 4KB of data and 80KB is not huge.

With all due respect: Not everyone else's phones are.

I don't believe you actually read the context of my comment.

I actually believe that I did. I understood the point you were making, and I'm pointing out that while your devices don't have that constraint, others may, depending on your target audience.

There are endlessly discussions on here whether to go with an app or web, with many favouring the app angle because of endemic performance issues on the web when you're running on an ultra-low power mobile device.

The web is often death by a thousand cuts. Every decision by itself may seem small, but the end result is an unenjoyable, inefficient, battery-sucking result that leads people to abandon the web.

Unless you're being targeted as a potential customer or a member of the audience, your mobile performance is irrelevant. What is relevant is that the majority of the devices being used to access sites don't have the performance of mid-high end models.

Which commonly used phone models are that far behind the iPhone 3Gs?

The common phone is a sub-$100 Nokia or nothing at all?

Even in the US there's something like 10% of people with no cell phone at all, and 50% with "smartphones" which is a very broad spectrum ranging from crap to significant household purchases before considering "data plans" are optional and also range from crap to good.

Even non-phone connection quality can be terrible - I rarely find myself on public or hotel wifi with actually good connections. The difference between 200kb of JavaScript and 10kb can often be measured in seconds.

I contest the assertion that we are talking about almost everyone everywhere at this point.

Reply on news.ycombinator.com