RE: [ResourcePriorities] Only specify lazyload on img

In today's conference call, we spent most of the time discussing this spec. We want the lazyload attribute to be a means for developers to give the browser a hint in determining the priority in which resources are downloaded. This work shouldn't be limited to just visible or above/below fold resource, but to better help the browser prioritize work when there is resource contention. James took an action here to update the spec with additional examples other than the one it has on above/below fold images.

To better help decide which elements to support, we're going to update the spec to explain the lazyload behavior for each element. Ideally, developers can use lazyload on all elements capable of downloading a resource as a uniform way to convey to the browser that download priority can be reduced when there is contention. If there is an obvious reason why an element shouldn't be included, we can choose to not include it in the spec. Though, I think there is an argument that all elements capable of downloading a resource should support this for uniformity and giving the browser better information on developer intent.

The working group also wanted to understand if the behavior to not block the load event for lazyload resources will be a problem for developers. Whereas before developers could trigger scripts off the window.onload and know when resources are available, with lazyload resources, not all resources may be available by the time window.onload fires - which of course is the performance improvement of allowing scripts to run sooner and not be blocked by lower priority downloads. However, this does mean developers will need to register an onload handler for lazyload elements that they're interested in tracking. Is this a reasonable expectation? On the call, no one felt that it was too onerous. This becomes interesting for <script lazyload>, as your synchronous script would need to check if the lazyload script had loaded through an onload handler on that script element.

Thanks,
Jatinder

From: James Simonsen [mailto:simonjam@google.com]
Sent: Wednesday, June 26, 2013 9:51 AM
To: public-web-perf
Subject: Re: [ResourcePriorities] Only specify lazyload on img



On Tue, Jun 25, 2013 at 7:27 PM, James Simonsen <simonjam@google.com<mailto:simonjam@google.com>> wrote:

On Tue, Jun 25, 2013 at 6:22 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
On Wed, Jun 26, 2013 at 2:09 AM, James Simonsen <simonjam@google.com<mailto: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