[whatwg] Application deployment

[Russell Leggett]

>
> That is a performance killer.


I don't think it is as much of a performance killer as you say it is.
Correct me if I'm wrong, but the standard connection limit is two. It is not
as though every external file could be loaded at once. Additionally, as I
said, you could split resources into multiple archives to take advantage of
multiple connections, because they can be loaded asynchronously without
issue.  Remember, the use case for this would be when there are likely
dozens of different files that need to be loaded.

So you get nondeterministic load behaviour anyway. This is not good.


This is not so different than directly requesting a file from multiple tabs.
Let's say page 1 and page 2 each use the same image. If I load page 2 first,
it will go directly to the server. If I load page 1 first, page 2 will get
the image from cache.

Clearly, there are other ways of performing this task, but I think this way
is simple and I know that I would gladly accept it as a possibility. It
falls within the same realm that any caching behavior does. It is meant
purely for performance, but if you are relying on it for a given behavior
then you are on a road to trouble.

The archived resources should be static, and also available as individual
files. Pre-fetching them should only be used for performance gains, and if
it would not be performant, it should not be used. However, I think there is
a fairly wide range of sites or applications that could benefit from this
feature. If there are other ways of improving it, or making it work better
for certain edge cases, that would be great, but don't throw the baby out
with the bath water.

Off the top of my head, I can think of a couple of ways to refine the
feature and deal with the issues raised.

   - Only blocking the loading of files that could logically be inside the
   archive: if the archive is located at "/js/resources.zip", then the only
   files that should be blocked would have to be located under "/js". <img
   src="/images/lolcat.jpg"/> would not be blocked.
   - To go a step further, there could even be some kind of "pattern"
   attribute that would block the loading of files that matched a url pattern.
   For example, if the archive were located at "/", but had a pattern of
   "**.js,**.css,/images/*", only js, css, and files under the "/images"
   directory would be blocked.


On Tue, Jul 29, 2008 at 2:13 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett <
> russell.leggett at gmail.com> wrote:
>
>> Yes, the one major hang up that I foresee is how a browser should handle
>> asynchronous loading. How would it know the contents of the archive before
>> it loaded the archive so it did not try to load the same files directly? The
>> simple answer would be to load the archive(s) synchronously.
>>
>
> That is a performance killer.
>
> As for references in a different tab, if the separate tab/document did not
>> reference the zip archive first, it would operate as normal. It would check
>> the cache and then attempt to load. If the zip had been loaded from the
>> first page already, the file would be present in the cache, and if not, then
>> the browser would attempt to retrieve it from the server.
>>
>
> So you get nondeterministic load behaviour anyway. This is not good.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080729/47d687f5/attachment-0001.htm>