Re: [ResourcePriorities] Only specify lazyload on img

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.

> 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.

> 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.

>> >> svg
>> >>
>> >> This doesn't even fetch anything.
>> >
>> > Maybe not that specifically, but there are a bunch of things in SVG that
>> > could use it. I think they have their own <script> tag for instance.
>>
>> Indeed, but we should look at those separately. Many of the above
>> caveats apply to the various svg features too.
>
>
> Fair point.
>
> Another option is to drop SVG for Level 1 along with audio/video. It's
> probably a marginally useful case to optimize right now. We can focus on the
> big wins first, then add additional stuff later.

I think we can generally treat SVG as HTML. I.e. SVG images can have
the same behavior as HTML images. SVG scripts the same behavior as
HTML scripts etc. I think the SVG and HTML groups have generally
worked towards converging behavior between the two languages anyway.

/ Jonas

Received on Wednesday, 26 June 2013 01:23:28 UTC