Re: [whatwg] Script preloading

> Pre-parsers can kick in before a page is actually opened, but script cannot be executed. Let me dig up some numbers on the benefits of this & report back. But logically, [parse html]->[load script] is always going to be faster than [parse html]->[parse inline script]->[execute inline script]->[load script]. And I imagine, more bytes and complex.

That they *can* do that is not sufficient proof that in the real-world, it actually does speed up page loads. In my testing, the way I do script loading, annotating scripts in the markup and then doing my normal script loading did not, on average, provide any noticeable speed up.

But anyway, this is a moot discussion, because I already conceded that if we want a solution that helps markup-only advocates, that's fine. <script preload> does that. Why are we going to keep arguing that point?

No matter how that plays out, it doesn't change the fact that I need a solution which works for on-demand loading long after page-load, where what was or wasn't in the markup during that magical "not rendered yet" state is completely irrelevant.

I feel like we're on a merry-go-round the last few years where someone says "but, look, this is better in markup at page-load" and then I say "whatever, fine, but it doesn't help on-demand" and then we go back around to "no no, this is better for page-load".

I don't consider this an either/or proposition. You have your thing you care about, I have my thing I care about. Both should be important.



> If it's something likely to be used later you're better off loading it with the page. Waking up the radio on a mobile connection is slow and uses battery. Having said that, there's nothing in either of the original proposals that prevents adding scripts dynamically. It's the more complex option if you want more complex behaviour.

This is a big over-simplification of the scenarios involved. Sure, in general, you want to minimize waking the radio back up, but if there's 10% of script code I need to render the page initially, and 90% of my code is needed later (or maybe, conditionally, never at all), it's not supportable performance-wise to say "well, just slow down the initial page render for that 90%".

We have the techniques of post-loading and on-demand loading for a reason, and there are cases where you can prove, through testing, that doing dynamic loading after page-load is objectively better than slowing down the initial page load. Not only *can* you prove it, I have proven it on my own sites. Time and again.

I'm sure there are ALSO cases where requesting everything at once is better. But there is no proof yet presented that always requesting everything all at once is always, unconditionally, the best option. If you have such evidence, and can prove that 100% of sites/apps which use on-demand loading are "doing it wrong", please present that evidence.

Short of that evidence, I live in a world that accepts that sometimes one is better, sometimes the other is better. And I want a solution that equally empowers both sides of the coin, not just one.


---------------------

I'm going to stop this email here, and reply with another reply regarding your request for use-cases detail. That one is going to be QUITE long.




--Kyle

Received on Wednesday, 10 July 2013 19:01:25 UTC