Re: <img src="..." defer>

Hi, Jatinder.

I don't think it's valid to reject a feature because some developers might
misuse it. The script ASYNC attribute is a great example. Using ASYNC
incorrectly has a much worse impact than promoting an image, and yet ASYNC
exists primarily to improve performance. We didn't have to add ASYNC -
developers could have instead loaded a script asynchronously using
JavaScript, but it was added (IMO) to make it easier for devs, to make it
clearer, and to reduce inline script blocks scattered throughout the page.

-Steve



On Thu, May 23, 2013 at 2:27 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Steve,****
>
> ** **
>
> I understand your point. I just worry that it’s much easier for developers
> to incorrectly mark a certain resource as having the highest priority
> resulting in an overall poorer experience, than having a developer defer a
> resource resulting in a poorer experience. For example, if one is styling a
> background image with CSS, one may mark the image as having the highest
> download priority, but there may be a moment when a user may see the
> styling change on that image because the CSS came later. While the
> intentions were right, the result may not have been expected. On the other
> hand, ordering your markup appropriately and marking unnecessary resources
> as defer/delayload/lazyload is harder to get wrong (not impossible). For
> your Airbnb example, if you truly want to get that image down first, the
> example you gave is the way to go.****
>
> ** **
>
> The browser does its best to download all resources as quickly as
> possible. Telling the browser what resources to download lazily, and also
> not block the window load event on for those resources, seems like an
> easier, and mostly very effective, model. ****
>
> ** **
>
> Thanks,****
>
> Jatinder****
>
> ** **
>
> *From:* Steve Souders [mailto:souders@google.com]
> *Sent:* Wednesday, May 22, 2013 8:21 PM
> *To:* Jatinder Mann
> *Cc:* Jake Archibald; public-web-perf@w3.org
>
> *Subject:* Re: <img src="..." defer>****
>
> ** **
>
> Hi, Jatinder.****
>
> ** **
>
> Browsers are built to work best across *most* websites. But that doesn't
> mean their behavior works best across *all* websites. When the default
> behavior hurts a website's performance, it's good to think about what
> alternatives exist for site owners. ****
>
> ** **
>
> In this example Airbnb would be better off if the huge image was
> downloaded in parallel with the JS & CSS. That would slightly delay when
> the JS & CSS complete, but would greatly accelerate when the huge image is
> rendered. Without a way to promote the huge image's priority in markup, I
> would recommend that Airbnb load the huge image using JS at the top of HEAD
> (above all the scripts and stylesheets), and then swap it in on onload.
> That's not the end of the world - telling websites to load critical images
> dynamically at the top of HEAD. But it's not as clean as using markup.****
>
> ** **
>
> I mainly wanted to clarify that in fact the behavior being proposed,
> limited to just specifying 'delayload' for unnecessary images, does not
> produce the best performance in this case. ****
>
> ** **
>
> -Steve****
>
> ** **
>
> On Wed, May 22, 2013 at 5:15 PM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
>  We had spent some time discussing this issue at the *W3C Workshop for
> Performance. *Even if a developer wanted to specify that a single image
> be the highest priority download, I don’t believe most major browser
> vendors would respect that priority order over CSS and synchronous
> JavaScript. Seeing these are hints to the browser, we wanted to avoid
> having developers try to specify different classes of priority numbers for
> resources. For most web developers, it feels like the easiest thing is to
> specify resources that they know aren’t necessary for above the fold
> visuals.****
>
>  ****
>
> In your example, the best approach for developers is to mark all
> unnecessary resources for the above the fold visuals as ‘delayload’. This
> way all the important images, CSS, and JavaScript will be downloaded in the
> order the browser feels is most optimal. For example, a user agent may
> download in the following order: root document, CSS in document order,
> JavaScript in document order, everything else in document order,
> delayloaded resources in document order.****
>
>  ****
>
> Thanks,****
>
> Jatinder****
>
>  ****
>
> *From:* Steve Souders [mailto:souders@google.com]
> *Sent:* Wednesday, May 22, 2013 12:36 PM
> *To:* Jake Archibald
> *Cc:* Jatinder Mann; public-web-perf@w3.org****
>
>
> *Subject:* Re: <img src="..." defer>****
>
>  ****
>
> SHORT: We need the foil of "defer" so that image download priority is
> INcreased.****
>
>  ****
>
> LONG: ****
>
> I love the idea of being able to defer images, but that leaves images with
> only these two states:****
>
>     - *deferred*****
>
>     - *not deferred*****
>
>  ****
>
> So I have two choices: my images get loaded very late, or they get loaded
> late (because scripts, stylesheets, and fonts have a higher download
> priority in some major browsers). ****
>
>  ****
>
> *What if I have an IMG that I want to load at a higher priority?! *****
>
>  ****
>
> Here's a great example. Airbnb has a huge IMG that fills the background of
> the entire page. It's the very first IMG in the document. It's obviously
> critical to the UX. But, because of Chrome priorities, it gets loaded too
> late. In these WPT results<http://www.webpagetest.org/video/compare.php?tests=130515_TD_QYX-r%3A1-c%3A0&thumbSize=200&ival=100&end=visual> this
> huge image (the first IMG in the document!) gets pushed out to request #12
> and doesn't show up until 3.4 seconds into the page load.****
>
>  ****
>
> Instead, it would be better if this IMG was downloaded with equal priority
> to scripts & stylesheets, or at least higher priority than any other image
> (including CSS images). But, even if "defer" gets adopted, we'll still have
> no way to promote this IMG to get it to appear earlier.****
>
>  ****
>
> We need the foil to "defer" so that image download priority is INcreased.*
> ***
>
>  ****
>
> -Steve****
>
>  ****
>
>  ****
>
> On Wed, May 22, 2013 at 8:25 AM, Jake Archibald <
> jakearchibald@chromium.org> wrote:****
>
>  On Tue, May 21, 2013 at 9:09 PM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
>  Based on discussions with web developers, the attribute name ‘delay’
> doesn’t seem clear and can carry the wrong connotations that the attribute
> is slowing down the page load ****
>
>   …I recommend we instead use the attribute name ‘delayload’. This name
> is very clear that the attribute will delay loading the lower priority
> resource.****
>
>   ****
>
> I imagine developers will react the same to 'delayload' as they do to
> 'delay', although I'm just guessing.****
>
>  ****
>
> 'delayload' as in 'delay the load' sounds like the image may delay the
> loading of the page, when (in terms of the load event of the document) it
> does the opposite. ****
>
>  ****
>
> 'lazy' or 'lazyload' sounds more like it's only impacting the image,
> perhaps because it's an existing term and used frequently in relation to
> image loading.****
>
>  ****
>
>  Also, as XHRs can just be deprioritized through script and they are the
> only non-element on the list, I recommend we just remove them.****
>
>   ****
>
> +1****
>
>   ****
>
>  ** **
>