Re: Image sprites use cases

On Tue, Sep 1, 2009 at 6:29 PM, Pascal Germroth<pascal@germroth.name> wrote:
> Hallo,
>> On Tue, Sep 1, 2009 at 10:49 AM, Pascal Germroth<pascal@germroth.name> wrote:
>>> - - real attachments to websites, like emails. For example, the home page
>>> could attach the stylesheets and images, which speeds up loading even
>>> more since in one request you get everything without having to parse the
>>> page first. Other pages would refer to the files as usual, the browser
>>> would use the cached versions, or if you didn't visit the home page
>>> first, load them as needed. (Of couse, people would soon start attaching
>>> everything to every page...)
>>
>> That's a showstopper.  We *cannot* rely on people visiting the
>> homepage first; search engines direct you straight to the page you
>> want which can be deeply internal.  I want *all* pages to benefit from
>> this, so I'd have to 'attach' the files to *every* page, which defeats
>> a lot of the purpose.  Making them still be a separate resource lets
>> the browser decide that it's already cached the thing and ignore it on
>> subsequent page loads.
>
> Well, one could do both: attach resources directly, have a single
> multipart file with every resource linked to (instead of the ZIP file)
> and, for backwards-compatibility, seperate files.

That still means that you're pulling down all the resources on every
page request.  This isn't a good thing; it seems like it kills
caching.

> On tool support: It should be relatively easy to write an apache httpd
> extension which will create ZIP-files or multipart MIME files on the fly
> (cached, of course) off a folder (tree) or the manifest. This would be
> the easiest way for authors, since they would not have to manage the ZIP
> file and the "normal" tree of files.

Yeah, it should be pretty easy to do this.

~TJ

Received on Tuesday, 1 September 2009 23:35:34 UTC