Re: [ResourcePriorities] Only specify lazyload on img

On Tue, Jun 25, 2013 at 7:27 PM, 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.
>
>
>> > Keep in mind use of lazyload is strictly optional and developers can
>> force
>> > something to load by removing the attribute at any time.
>>
>> That a feature is optional immediately sets off warning flags to me.
>> It's generally an argument to remove a feature, not to add it.
>
>
> Perhaps I worded this poorly. I just mean that developers don't have to
> load things lazily, just like they don't have to make all of their scripts
> async. They can still tightly control the behavior if they need to.
>
> James
>