Re: [ResourcePriorities] Only specify lazyload on img

On Wed, Jun 26, 2013 at 4:27 AM, James Simonsen <simonjam@google.com> wrote:
>
>
> On Tue, Jun 25, 2013 at 6:22 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Wed, Jun 26, 2013 at 2:09 AM, James Simonsen <simonjam@google.com> wrote:
>> >> >> script
>> >> >>
>> >> >> This already has means to control when the script is executed (async
>> >> >> and
>> >> >> defer). Since scripts are invisible, lazyload seems like the wrong
>> >> >> semantic.
>> >> >> If the author wishes to load a script at a certain point, that is
>> >> >> possible
>> >> >> by creating and inserting a script at that point.
>> >> >
>> >> > The point is that it doesn't block the load event. You can specify
>> >> > everything in HTML, but not interfere with the critical path of the page
>> >> > load. An example use would be analytics, where it doesn't need to
>> >> > obstruct
>> >> > the page load and can load and run at an arbitrarily later time.
>> >>
>> >> If all lazyload does for script is to make it not the script not block
>> >> the "load" event, then it doesn't seem like 'lazyload' is the right
>> >> attribute. I.e. it seems like a bad for 'lazyload' to mean different
>> >> things on different elements.
>> >
>> >
>> > I guess I don't see them as that different. In general, I think "lazyload"
>> > means:
>> >
>> > 1. Don't block the load event.
>> > 2. Don't necessarily load immediately.
>> >
>> > I think you can apply that definition to both scripts and other types.
>>
>> As an implementor, I still have no idea how 2 for a script element.
>> The only thing I could see doing is "give the load a lower priority",
>> but that seems like a very different thing. Changing priorities of
>> loads is something that browsers can already do today, with the loads
>> of all resources. No need to mark something as "lazyload" for that. So
>> I don't think changing priorities counts as actually doing 2.
>
> I guess I'd specify it as waiting until after the load event.
>
>>
>> > After that, it's up to the browser to decide when is the right time to fetch
>> > them. For scripts, I think that generally means after the load event
>> > finishes. For "renderable" elements, that might mean when they become
>> > visible, or as part of prerendering offscreen content.
>> >
>> > I know that's a loose definition, but it's intentionally so. I think the
>> > flexibility in letting the browser analyze the situation is worth it. For
>> > example, if it's a long page and memory is tight or bandwidth is expensive,
>> > try to avoid loading things until they're likely needed.
>>
>> I don't think there's a lot of value in telling browsers "feel free to
>> optimize stuff here, we don't really know what optimizations you can
>> do, but you know, analyze things and do whatever you think will make
>> things faster".
>>
>> Browser implementors are people too :-) If we can't think of sensible
>> algorithms, then I wouldn't expect them to be able to. For images the
>> spec does suggest a very useful algorithm, not just "analyze and do
>> stuff faster". I suggest we do the same for other types.
>>
>> Another way to look at it is that each feature should have two
>> implementations in order for the spec to go to REC. If browsers aren't
>> actually implementing any smarts for delayed loading of scripts, then
>> the spec shouldn't get past CR.
>
>
> That's a good point.
>
> I'm just concerned about boxing ourselves into bad or mediocre algorithms. It'd be nice to have some room to improve it, especially since nobody is using lazyload yet and it's hard to know what's ideal.
>
> Maybe we can solve the testing problem by explicitly setting a few boundaries that we all must meet, but with some wiggle room in between those boundaries to experiment. That's a lot like how subresource loading works now, where we can play with priorities and queueing, but still meet the spec and pass the tests.
>
> For instance, you must not load a lazyload script prior to load event. Or you must not load an offscreen, lazyload image prior to load event. Or you must load a lazyload image that is onscreen. That gives us something useful to test, but doesn't force us to decide right now that you must load an image that would be in the viewport if the user pressed the "end" key or "page down" key.
>
> Also, I'm happy to include the ideas I had for Chrome in the spec, perhaps as non-normative sections. I don't think we have a lack of ideas for algorithms.

These all sound like good ideas.

/ Jonas

Received on Thursday, 27 June 2013 00:37:46 UTC