[whatwg] Script preloading
bruno at hexanet.net
Thu Jul 11 17:25:44 PDT 2013
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.
Isn't the Pre-parsers/PreloadScanner's inability to take into account the
display[none:yes] factor be a potential significant blow to 'mobile'
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?
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.
On 7/11/13 8:23 AM, "Alex Russell" <slightlyoff at google.com> wrote:
>Here's the Plus URL without the googler cruft:
>On Thu, Jul 11, 2013 at 3:47 PM, Jake Archibald
><jaffathecake at gmail.com>wrote:
>> On 10 July 2013 17:37, Jake Archibald <jaffathecake at gmail.com> wrote:
>> > On 10 July 2013 16:39, Kyle Simpson <getify at gmail.com> wrote:
>> >> I personally don't care about scripts being discoverable by
>> pre-parsers. I
>> >> have done testing and am not convinced that something appearing
>> >> markup) leads to better performance than allowing my script loading
>> logic to
>> >> load things when I want, and just relying on the browser to do that
>> >> quickly as possible.
>> > Pre-parsers can kick in before a page is actually opened, but script
>> > be executed. Let me dig up some numbers on the benefits of this &
>> > back.
>> Here it is:
>> ~20% improvement.
More information about the whatwg