- From: Bruno Racineux <bruno@hexanet.net>
- Date: Mon, 15 Jul 2013 14:38:30 -0700
- To: Yoav Weiss <yoav@yoav.ws>
- Cc: WHATWG List <whatwg@whatwg.org>, Andy Davies <dajdavies@gmail.com>
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