RE: Packaging resources in HTML files

James,

Thanks for your thoughts and thorough response. Regarding your points below:
1. While I understand that there is some level of separation between
specification and implementation, HTML is a standard which exists for a
practical reason. Additionally, it has become standard to package resources
in any development language (Java resource bundles, .Net resource bundles
,etc.). I see no reason why Web development should be an exception to this
practice. HTML should adapt to what the market needs.
2. I may not have been clear about "addressability" --> The "archive" file
could contain an index file (as the first deflating file) that would contain
the list of URLs it resolves. This allows for both backward compatibility
and no changes to URI scheme.
3. While I understand that CSS and Javascript files may be combined, I also
believe that people are continuously relying on the ever-advancing and
evolving javascript toolkits (Dojo, JQuery, etc.). This normally translates
to downloading at least one more compressed javascript file and one or more
CSS file, additional to your own. Just those add up to 4 download requests,
and with toolkits like Dojo which sometimes load "on demand", you may
actually have more. Finally, the only way to "combine" imagery is using
sprites, which is far from being easy to implement (due to cross-browser
implementation issues), or do I consider it to be "standard", and many
websites require a significant amount of images for their complex designs. 

Yaron Golan
Xennex, Inc.

-----Original Message-----
From: Justin James [mailto:j_james@mindspring.com] 
Sent: Monday, July 06, 2009 5:19 AM
To: 'Yaron Golan'; public-html@w3.org
Subject: RE: Packaging resources in HTML files

Yaron -

I think that it is an interesting idea on the surface, but the more you
scratch at it, it looks less and less like a workable idea. First and
foremost, the majority of the issues that you cite are not within the realm
of things that HTML as a specification is responsible for. For example, what
does HTML have to do with specifying how resources are transmitted "on the
wire"?

The biggest problem that I foresee, though, is "addressability". Let's
pretend for a moment that all of the JavaScript came packaged up like this.
How will you refer to it? Some sort of special URI scheme that points to a
location within the package itself? You certainly would not have *any* kind
of backwards compatibility with older browsers.

Finally, within the situation that you discuss, if the person developing the
Web site has enough control over the external resources that they could be
packaged up into one file on the server, I have to wonder why that isn't
happening to begin with. It seems perfectly sensible to me that there is
nothing preventing you from combining all of your JavaScript files into one
resource, and all of your CSS into one file, which would *slash* the number
of files to be downloaded. Furthermore, sensible ordering of the items
within the page would make the page start to render faster. Sure, it's nicer
to work with separate files, but I would think that given the circumstances,
combining the CSS and JS into one file each at *deployment* time would be a
reasonable approach.

J.Ja

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Yaron Golan
> Sent: Saturday, July 04, 2009 5:51 AM
> To: public-html@w3.org
> Subject: Packaging resources in HTML files
> 
> One of the most annoying problems I’ve had to deal with (other than
> cross-browser compatibility) with web-based product development has
> been
> page load time optimization. When we first completed the development of
> our
> homepage it was full of references to an additional 60 resources which
> included Javascript, CSS, and image files. All and all it took it about
> 7-8
> seconds to load on screen (on a good day), and we were pretty unhappy.
> 7
> seconds, I was told by our SEO expert, was your average window closing
> time
> – basically that’s how fast a user closes the window if he or she fails
> to
> see anything interesting or, in our case, anything at all.
> 
> I don’t quite know what brought me to thinking about this yesterday,
> but
> somehow packaging came to mind. A significant draw on the load time had
> to
> do with the browser having only a limited amount of threads used to
> download
> resources (this is IE6 and 7, and FireFox 3, so it may have improved at
> this
> point), each requiring a full cycle of HTTP requests. With Javascript
> and
> CSS files, there was also a matter of compression (for those of us who
> refuse to use mod_gzip, etc.). All we really had to do here was to set
> up an
> incrementally deflating resource package that the browser would load
> from
> the server – which would include all of this junk, and you’d basically
> be
> looking at a couple of HTTP requests at best, both of which could be
> run in
> parallel.
> 
> A package file could be designed to contain the following:
> 1. The index file – containing the list of URLs which this package file
> resolves (what files are in here and need not be loaded directly)
> 2. Javascript files – in order of loading
> 3. CSS files – in order of loading
> 4. Imagery
> 
> Now, with a simple tag like <resource src=”…” />which would be easily
> added
> to your whole site, you could basically resolve most of the requests to
> it.
> Once the browser encounters this tag under <head> it would start
> loading it
> (during its loading process) and could cache all files unpackaged like
> it
> does when it grabs files today. Existing tags (like img, link and
> script)
> could be resolved by pretty much matching the URL with the index file.
> A
> simple application could build the package file for you, and one could
> use
> LZH for the incremental compression. It’s really as simple as that!
> 
> Now, why is this good for the world? here’s several ideas:
> • Browsers could load all resources in one quick request. One DNS
> resolution, one socket open, one HTTP request. Easy.
> • Files would always be compressed – No need for special settings on
> server
> side, like mod_gzip or mod_deflate.
> • Servers and proxies would have a significantly lower load, and could
> easily cache one file here.
> • Even if the server doesn’t support it (read: no resource tag) – the
> Mobile
> industry could reduce their bandwidth costs – Mobile browsers could
> gather
> all resource URL requests into one, which they would request from their
> mobile provider (already saving some bandwidth). The provider would
> grab the
> original set of resources, compress them on the fly, and send them over
> the
> air. Images could be adapted to mobile device size, and all script and
> css
> files would be reduced in size!
> • Resource packages can be built specifically for a client – the
> identifying
> server could then grab other versions of the package (you could have
> one for
> mobile and one for normal browser, for instance) and return those,
> instead!
> • No need to change your existing codebase — and this is a big one!
> Other
> than adding the resource tag, everything else would work and this would
> comfortably be backwards compatible (All your existing HTML are belong
> to
> you!).
> 
> Some questions and answers:
> • Do we only have one resource file? – No, you can have multiple, but
> don’t
> hit the same brick wall again.
> • What do I do with external imagery or dynamic sites? – You can have
> several package files for the “basics” (your site template or
> frequently
> used resources) and have everything else loaded normally. If the
> browser
> supports it, there’s really no reason why not to!
> • Do we need to store all resources in the file? — No, you can have
> some of
> them in there and some of them accessed directly by your browser.
> Thoughts? Ideas?
> 
> For quick reference, here’s a bunch of links that discuss the issue
> with
> multiple HTTP requests and optimization:
> •  14 rules for fast web pages
> –http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html
> •  Optimizing Page Load Time –
> http://www.die.net/musings/page_load_time/
> •  Combine Images to Save HTTP Requests
> - http://www.websiteoptimization.com/speed/tweak/combine/
> 
> – Yaron
> 
>

Received on Monday, 6 July 2009 01:21:50 UTC