W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2013

[minutes] Web Performance WG Teleconference #110 2013-06-26

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 26 Jun 2013 23:10:45 +0000
To: "'public-web-perf@w3.org'" <public-web-perf@w3.org>
Message-ID: <39ccbd5a4b954163b882df56cc9f23fd@BLUPR03MB065.namprd03.prod.outlook.com>
Meeting Summary:



1.     Resource Priorities - lazyload attribute

The working group felt that lazyload attribute is quite useful as a means for developers to give the browser a hint in determining the priority in which resources are downloaded. This work isn't limited to just visible or above/below fold resource, but to better help the browser prioritize work when there is resource contention. The editors will update the spec to include examples other than above/below fold example which touches mostly on visible or not visible resources.



We also felt that we should support lazyload for all elements capable of downloading a resource, as a uniform way to convey to the browser that download priority should be reduced. If there is an obvious reason why an element shouldn't be included, we can choose to not include it. The editors will update the spec to break out each element separately (e.g., the visibility recommendation doesn't apply to audio, so the audio section should call that out).



The working group 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 use the window.onload event to trigger calling any script, with lazyload, one has to register an onload handler on the <script lazyload> to know when it truly has loaded. Per discussion, this seems like a reasonable pattern.



IE11 Preview supports Resource Priorities at the connection management layer. If there is a connection contention, IE will give available TCP connections or will give a more optimized TCP connections if there is a choice between available connections to resources that don't have the "lazyload" attribute. IE11 hasn't yet implemented not blocking the load event, or the application level priority changes (don't fetch the lazyload resource until all other non-lazyload resources have started their fetches) yet, as there is still much discussion here on this emerging standard.



2.     TPAC Registration

Registration for TPAC 2013 has now opened up: https://www.w3.org/2002/09/wbs/35125/TPAC2013/. Please sign up!






W3C Web Performance WG Teleconference #110 2013-06-26



IRC log: http://www.w3.org/2013/06/26-webperf-irc



Meeting Minutes: http://www.w3.org/2013/06/26-webperf-minutes.html



Attendees

Philippe Le Hegaret, Jatinder Mann, James Simonsen, Rob Dickenson, Aaron Heady


Scribe

Jatinder Mann



Agenda

1.     Discuss Resource Priorities

--------------------------------------------------------------------------------



Minutes:


Resource Priorities

James: At Velocity, people loved this attribute. For example, Amazon liked the idea of never loading some resources that have been lazyloaded and are not visible.

Jatinder: James, so would you never kick off the resource if it's not visible? Typically, resource are fetched in the early stages of loading a page, formatting and layout information wouldn't come in until later.

James: I think we would put it on a queue and if the resource hasn't been fetched and we now know the formatting/layout information, we won't kick off the resource until its visible.

Jatinder: I do think we still need to work out what this attribute means for <script>. Currently we were leaning towards not blocking the window onload event for lazyload scripts. However, does this mean a developer will need to register an onload handler on each script element to know when to execute the script? Or do we create a new event that indicates when all resources (including lazyloaded resources) has been loaded?

James: I think the pattern where developers add load events to each <script lazyload> is reasonable.

James: That's especially the case if we don't ever fetch a resource because we know that it's not visible. If we add a special event that fires for all resources, including lazyloaded resources when they are loaded, that event may never fire.
... I think developers will use the pattern of adding an onload handler on the lazyloaded resource if they want to know when it's loaded.

Jatinder: On the topic of when the element is visible on the screen, if we were to fetch the resource only when it was visible, they may be a delay before the user sees it, which may be an even worse experience. Most browsers have a render region that's greater than the window size. We should leave the definition of 'visible' loose here so that the browser can fetch the resource before the user is able to scroll to it.

James: I completely agree. I think we should keep this loose enough that the browser will fetch by the time it's in the rendered region.

Jatinder: I also don't think we should specify the exact algorithm here, especially if there are future optimizations browser vendors want to make on the render region.
... On the topic of visibility, not all resources are visible resource, e.g., Audio. The purpose of this attribute is really to help the browser better organize the priority in which it downloads resources, so I don't think this is necessarily tied to visibility. I like the concept that we have one attribute that we can add to all elements capable of downloading a resource to indicate that this is a lower priority download.

,,, we should consider each element on its own merit, and pull them if we don't think they should use this attribute.

James: I agree with that as well.
... I think we should add additional examples to the spec to make it clear that there are other cases covered here as well, not just above vs. below the fold.
... I like the idea of leaving the exact algorithm that the browser uses off the spec, so to allow the browser to adapt.

Jatinder: I also agree that this should only be a hint.

Philippe: If we don't have any normative requirements, then what are we going to test? I think the spec should have some normative statements.

Jatinder: If we add the behavior that lazyload doesn't block the window load event, that should be a normative requirement to test.
... I think we need to do a few updates the spec: add additional examples that aren't related to above/below fold, add separate sections for each element type and define the expected behavior, and clarify loosely correlate visibility here.

Philippe: There has been quite a bit of interest for an element visibility definition for Web Drivers, requestAnimationFrame, and possibly others. We spoke about this in the past.

Jatinder: Yes, ad vendors would be interested as well. Today they use a series of different techniques for each browser to determine if their ad is more than 50% visible. I can propose a specification here if there is interest.
TPAC

Philippe: TPAC registration has opened today. Please feel free to register for our event.
... Also, we can start publishing draft specs now in this working group as the charter has been updated.

<plh> https://www.w3.org/2002/09/wbs/35125/TPAC2013/
IE11 Release Preview

Jatinder: IE11 Release Preview was released today. It supports Navigation Timing L2 and also an implementation of lazyload in the connection management layer. I'll send a separate email that details the changes.
Received on Wednesday, 26 June 2013 23:14:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 26 June 2013 23:14:01 UTC