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

Mon Jul 15 00:42:54 PDT 2013

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?

If javascript can't be as truly fast a native apps:
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
It seems that for frequently visited sites and frequently accessed libraries
across websites, the whole parse/evaluation time, could be cut 'partially',
yet very significantly, just like opcode does for php.
And make CDN libraries even more useful and relevant that way. Or is this
wildly nuts? In which case no need to answer.

Bruno

From:  Andy Davies <dajdavies at gmail.com>
Date:  Saturday, July 13, 2013 5:55 AM
To:  Bruno Racineux <bruno at hexanet.net>, WHATWG List <whatwg at whatwg.org>
Subject:  Re: [whatwg] Script preloading

> On 12 July 2013 01:25, Bruno Racineux <bruno at hexanet.net> wrote:
>> On browser preloading:
>> 
>> There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
>> PreloadScanner and "responsive design" for mobile. Responsive designs
>> mostly implies that everything needed for a full screen desktop is
>> provided in markup to all devices.
>> 
> 
> The pre-loader is a tradeoff, it's aiming to increase network utilisation by
> speculatively downloading resources it can discover.
> 
> Some of the resources downloaded may be not be used but with good design and
> mobile first approaches hopefully this number can be minimised.
> 
> Even if some unused resources get downloaded how much it matter?
> 
> By starting the downloads earlier, connections will be opened sooner, and the
> TCP congestion window to grow sooner. Of course this has to be balanced
> against visitors who might be paying to download those unused bytes, and
> whether the unused resources are blocking something on the critical path from
> being downloaded (believe some preloaders can re-prioritise resources if they
> need them before the preloader has downloaded them)
> 
> Although we talk about *the preloader*, it's worth remembering different
> browsers (and versions) have different preloading approaches - compare the
> connection view charts (at bottom of page) for www.channel4.com
> <http://www.channel4.com>  in Chrome, Firefox and IE10 and you'll see subtle
> differences:
> 
> Chrome http://www.webpagetest.org/result/130713_0J_PC1/1/details/
> Firefox http://www.webpagetest.org/result/130713_P2_PBZ/1/details/
> IE10 http://www.webpagetest.org/result/130713_9A_PBW/1/details/
> 
> 
>> 
>> Isn't the Pre-parsers/PreloadScanner's inability to take into account the
>> display[none:yes] factor be a potential significant blow to 'mobile'
>> performance.
>> Use case: What if I have a set of images in an element set as
>> display:none; only designated to be show on desktop or tablet screens and
>> not on mobile phone?
>> 
>> What if I have an inline script in that node?
>> 
>> 
>> Isn't the PreloadScanner loading a lot more than I need, a problem here?
> 
> Challenge with this approach is the browser has to build the render tree
> before it can decide whether to download a resource i.e. download HTML, parse
> it, build a DOM, download CSS, parse it, build CSSOM, then build render tree.
> 
>  
>> 
>> In addition to the need to preload, with responsive design taken into
>> consideration, and for lack of not being able to remove part of the <body>
>> before the browser parses the document. I see an increasing potential need
>> for the ability to indicate to the browser not to load selective assets
>> before DOMReady and suppress such preload.
>> 
> 
> The proposed lazyload attribute should help here
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.
> html 
> 
> Yoav Weiss has raised the idea of being able to use media queries with scripts
> and other resources too.
> 
> Responsive design is young, I think we still have a lot to learn and it's
> going to take a while before we really understand what features we need.
> 
> Cheers
> 
> Andy