Essentially, the idea is that web developers could proactively create .ZIP files of various page resources (images, CSS, JS, etc), and include in their page a special <link> tag pointing to that “package”. Smart, elite browsers (like FF 3.7!?) would grab this resource package, unzip and cache the resources, and ostensibly then know how to skip trying to download them from their normal references in the rest of the HTML page. The idea is of course the all-important, oft-mentioned “reduce HTTP requests down to the most absolute minimum possible” rule that we all have blazened into our psyche.

Wait, you mean you don’t agree with HTTP request reduction?

On it’s surface, I don’t disagree with “minimize HTTP requests”. Certainly that’s a good and very important goal. If you needlessly create additional requests because you are ignorant or lazy and fail to employ even simple strategies (like image spriting, for instance), you are asking to crash your server(s) when your traffic increases.

But I believe there’s a paranoia spreading in the UI development and production community that the reduction of HTTP requests is penultimate and more important than any other strategy, to the exclusion of alternative perfectly reasonable practices for UI delivery optimization.

For instance, you hear people all the time say, “concat all your JavaScript into one file” for production. But is this really the right approach? I won’t go into the details here of why I disagree with this as a blanket approach, as I cover that fully in this post, but suffice it to say, I think we must balance HTTP request reduction paranoia against some other sanity checks.

So what’s wrong with resource packaging?

I have a number of issues with this idea. Let me lay them out for you:

In reality, what I’m most worried about is that this’ll be seen as the silver bullet and just deployed in widespread and often under-optimized ways, and will propogate what I think is a dangerous anti-pattern: People are so paranoid about HTTP request overhead (because let’s face it, we all think our site will get slashdot’d or hit digg.com homepage so we better be ultra-micro-optimized for millions of hits per minute!) that they’ll just default to putting everything in one resource package.

When that seems to work well in their dev environment, they’ll just roll that out and blindly think it’s ok. When you give people a dangerous amount of rope, it’s hard to not expect at least a good number of people will hang themselves with it.

Remember the good ol’ days, when people created full-page flash sites, and when you visited the site, you sat and mindlessly watched a preloader animation while megabytes of content were all loaded at once? Oh, that was fun. I miss those days.

No, wait! I don’t miss that at all. Actually, I love that now we as a collective community realize that a critical part of user-experience is initial page loading behavior. I love that Google is going to start ranking pages based on how well they load. This is a healthy, even if slightly uncomfortable, nudging in the right direction.

But worse yet, if abused (either intentionally or not), I think this pattern will have worse overall performance than if people had just left their sites as they currently are.

Compare this type of approach to say someone taking more targetted/focused approaches to UI optimization. For instance, you could use LABjs for loading scripts in parallel with each other and the rest of the page resources… or use spriting… or how about css concatenation?

Each of those techniques is more narrow in focus and has much less potential for going wrong when employed, in terms of both pattern and practice. But one big single “solution to rule them all” has both enough upside and downside that I fear it could go seriously off track if used wrongly.

Aren’t YOU just being paranoid or pessimistic about web developer ignorance?

In addition to the potential improper usage patterns, I also think there are tangible issues that the proposal and Souders’ post don’t address, at least not completely:

1. Relying on a technique which only works (in any forseeable future) in one (or a couple at best) browser(s) will promote yet another anti-pattern… optimizing for a subset of browsers and ignoring performance in other browsers.

   I know there’s lots of people out there who find it vogue to discard performance in IE and say “well, the deserve what they get for using a crappy browser.” But I don’t think that’s productive or realistic. Wouldn’t our time be better spent finding (and educating about!) new ways (like LABjs, spriting, css concatenation) to optimize the UI performance that will improve things in practically all browsers?

   Doesn’t that serve the web community better than just myopically focusing on one (admittedly growing) segment that uses a bleeding-edge browser version and implements a new feature idea before it’s even really a standard?

2. What about resources that are CDN’d? Sure, you host some of your resources locally, but hopefully you are moving toward putting more and more of your stuff remotely, out on the edge, via CDN’s. There’s no doubt this is a powerful technique, and is only going to increase in importance.

   And forget CDN’s (at least technically) for the moment. I’ve never once rolled out a site where I didn’t link to at least one or a couple of remote resources. For instance, I use Google Analytics on all my pages, I often use an AddThis social badge script (and images), Google Groups forms and images, etc, etc, etc. What should I do with all these non-local page resources?

   So do you really even have that many resources locally that it makes sense to package? And what if people employ another anti-pattern and start hosting and packaging locally what could have otherwise been better hosted remotely (CDN or not) and shared globally? Are we going to keep relying on browsers to get smarter and smarter, enough that now they can resolve all these local vs. remote/CDN versions of files in the Package Manifest for us and choose the correct ones?

   I get scared when I start thinking about the browser trying to be smarter than I am about how it optimizes UI delivery performance.

3. What about parallel downloading? If you load a single file and it’s 1 MB in size, the browser will likely download that thing byte-by-byte, serially. At least until we get to using BitTorrent for our page resources!

   But wait, what if you downloaded 3 files instead? It’d download in roughly 1/3 the time, right? That’s cool. Now, that math doesn’t stretch on forever… obviously there’s a point where the overhead of HTTP Requests starts to degrade the power of parallel downloading. But there’s got to be some balance, some sweet spot between 1 file and 100 files?

   And I bet that number varies from site to site. For some, maybe it’s 2. For others, maybe it’s 4. So this is one more variable that web deployment engineers have to experiment with and figure out the black magic of what’s best for their site. Again, I bet most will end up punting on multiple resource packages and will just use one file. I doubt this will be a good thing for most sites.

   Remember this (pessimism or realism): if figuring out what’s best is not intuitive, most won’t do it.

Here’s the bottom line: Resource Packaging sounds good in theory. But I suspect the practice of it will be quite flawed, and we’ll have yet another dimension of suckiness out in the UI delivery world that we’ll all have to wade through and educate on how to get it right.

Ding!

Wait, I just thought of something! While we’re at the business of packaging things up to reduce requests… how about we JUST deliver a zip file to the browser, which includes everything, even the HTML for the page?

In fact, does it even need to be a ZIP file? What about if we could figure out a special file format (which I’m sure wouldn’t ever get bogged down in proprietary rights/trademarks or disagreements over specification), and in that way we can make that single file really optimized (“compiled”), and the browser could just get really smart about “executing” our page for us? We’d achieve the all-imporant single-page, single HTTP-request “golden ratio”.

And for all those old, busted, non-conforming (non-bleeding-edge) browsers, we’ll just ask users to install a plugin to assist the browser in processing the page. People like plugins, right?

Oh, wait. Nope. We’ve tried that before. Many times. It was called Java. Then it was called Flash. Now it’s called Silverlight or JavaFX. And thankfully we’ve evolved to a higher level of consciousness. Or so I hope.