Re: [whatwg] Script preloading: Browser Pre-compiled Scripts Cache?

On 7/15/13 6:12 AM, "Yoav Weiss" <yoav@yoav.ws> wrote:

>On Mon, Jul 15, 2013 at 9:42 AM, Bruno Racineux <bruno@hexanet.net> wrote:
>
>> Taking about "executing script as quickly as possible" (threads from
>>1012
>> which I missed and tried to glanced through just get better educated
>>about
>> previous conversations).
>>
>> Wouldn't browsers be able to store "pre-parsed/compiled' scripts in a
>> separate "byte code" cache,
>> with scripts promoted to the sticky cache based on their access
>>frequency
>> (up to cache expiration)?
>> Say similarly to the way Fusion Drives or Seagate Adaptive Memory SSHDs
>> work.
>>
>> i.e. Why do we have to keep re-parsing and re-evaluating the very same
>> scripts, especially CDN libraries and social apis largely shared among
>> websites, over and over?
>>
>>
>>
>I've raised some similar concerns and made a possibly unrealistic proposal
>to resolve them at the Extensible Web mailing list[1]
>I believe some form of JS code "installation" so that it can be used
>across
>sites would provide a major performance boost, if it can be done in a
>secure way, without throwing URLs under the bus. It will enable users to
>avoid re-downloading frameworks and polyfills again and again for each
>site
>they visit, and will also enable browsers to optimize these frameworks'
>generated machine code.
>
>[1] http://lists.w3.org/Archives/Public/public-nextweb/2013Jun/0050.html
>
It goes beyond frameworks if based on pure 'access frequency'.

For example, a site backend you use daily or you favorite web app would be
also benefit.
Including the G+, Twitter and Facebook site's scripts, Map APIs, Google
News, or whatever you access most frequently from your machine.

And I am not thinking 'installation' or 'packages' in the sense that you
expressed.
That was my early thinking too, but say Google providing jQuery and all
the hosted APIs preloaded in Chrome seems too difficult to handle, due to
versioning aspects as well as limited scope.

To be truly worth, it needs to be broad, based on access frequency by urls.

Browsers already have a way to tell what your top sites are. Doing it for
scripts doesn't seem too far fetched from there. And top sites can be used
as additional priority factors.

Received on Monday, 15 July 2013 21:38:49 UTC