Re: [ResourcePriorities] Only specify lazyload on img

On Tue, Jun 25, 2013 at 3:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jun 25, 2013 at 10:27 PM, James Simonsen <simonjam@google.com>
> wrote:>> embed
> >> iframe
> >> object
> >>
> >>
> >> These can create nested browsing contexts. It seems like it would cause
> >> various complications if these can be lazy-loaded. They are complicated
> as
> >> it is.
> >
> >
> > I'm more interested in the usefulness than the complexity. If a page has
> a
> > bunch flash players below the fold, it seems useful to skip initializing
> > them if the user never scrolls. I think the usefulness is there. It's up
> to
> > us to deal with the complexity.
>
> I generally agree.
>
> Though I'll warn that loading of browsing contexts is incredibly
> complicated, not fully understood by anyone I've ever met, most likely
> differs in important ways between all implementations, and the spec is
> unlikely to match anyone.
>
> Here be dragons!
>

No argument here.


>
> >> link
> >>
> >> It has been proposed that an attribute be added to stylesheet link to
> not
> >> block execution of scripts. However, the spec doesn't address that.
> >> "lazyload" also seems like the wrong semantic -- a link element is
> always
> >> invisible, and the proposed attribute is more like <script async> i.e.
> fetch
> >> now but don't block scripts.
> >
> > Yeah, I'm not sure what the use case is on this one. I'd love to hear it
> if
> > someone has one.
> >
> >> 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.

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.

Keep in mind use of lazyload is strictly optional and developers can force
something to load by removing the attribute at any time.


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

James