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

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<mailto: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<mailto:souders@google.com>]
Sent: Wednesday, May 22, 2013 12:36 PM
To: Jake Archibald
Cc: Jatinder Mann; public-web-perf@w3.org<mailto: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<mailto:jakearchibald@chromium.org>> wrote:
On Tue, May 21, 2013 at 9:09 PM, Jatinder Mann <jmann@microsoft.com<mailto: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