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

Wrt "having it take up most of the above-the-fold space": This image is the
first IMG in the page with this markup: height="700" width="1600", so the
signal is pretty strong even before layout.

I thought about 3rd parties abusing this "promote" IMG attribute, but
wasn't too concerned because 3rd party image requests happen late in the
download cycle.

3rd party gets into a page via a snippet that the owner has inserted.
Images can be a part of that via IMG, SCRIPT, and IFRAME:

   - If the snippet contains an IMG and the 3rd party tries to sneak in the
   "promote" attribute, the website owner can simply remove that attribute
   when the paste the snippet into their page.
   - The more typical case is when the snippet contains a SCRIPT SRC, and
   that script fetches images (ads, etc.) and those images might have the
   "promote" attribute. But those image requests don't happen until *after*
   the script has been requested, parsed & executed. By that time the other
   high priority items have already been slotted in the download queue, so
   it's possible these 3rd party image requests might get queued up before the
   site's normal IMG requests, but not before the site's scripts, stylesheets,
   and "promoted" images.
   - Sometimes the snippet is an IFRAME, and the iframe's contents might
   contain "promoted" images. But again, those images won't be requested until
   after the iframe's contents are fetched & parsed, and by that time the site
   owner's priority resources are already queued up. Furthermore, we could do
   something where iframe subresources have a lower priority. (I thought some
   browsers already did that.)

This is a little different from "nice" in that the person who matters the
most (the site owner) has first dibs on what is done initially. 3rd parties
only get a foothold if the site owner allows it, and even then they're
delayed by at least one roundtrip for a script or iframe to load.

I would love it if the browser was smart enough to automatically determine
which resources were most important, but that's hard. I think site owners
could benefit from being able to give the browser hints about what they
think is important - for images, scripts, stylesheets, fonts. The browser
could use this additional information, but also discount it if it seems
spurious (too many promoted images, etc.) or limit it (only promote the
first N images which would likely be from the page's markup).

-Steve



On Thu, May 23, 2013 at 4:35 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> The problem with the "having it take up most of the above-the-fold space"
> signal is that's post-layout. In the AirBnb case, that's problematic since
> we want to determine these fetches pre-layout during preloading and fetch
> the huge image at the same time as fetching high priority resources like
> stylesheets and scripts.
>
> My main concern with a high priority attribute (as opposed to lower
> priority), is that prioritization is often contextual. You may have
> different parts of the document coming from different sources, and what's
> "important" to one is not necessarily important in the global context.
> AIUI, this is basically the reason that unix nice allows all users to lower
> their priority, but you need special perms to increase your priority. In
> the web context, I'd be concerned about third-party ads getting injected at
> high priority, since the ad owners might think they're important, but
> within the global document they're not necessarily important.
>
> I posed this concern to Dr. Barth just now, and he pointed out that the
> DOM is a tree, so document authors have the ability to say that part of the
> document is lower priority, and even if elements within that subtree try to
> increase their priority, that should be contextual to the subtree. This
> might be a reasonable way to address my concern. AIUI, preloaders can
> maintain enough state about the tree (I think Firefox's speculative parser
> has access to the complete tree) to provide good enough heuristics about
> the tree state to determine appropriate priority levels.
>
>
> On Thu, May 23, 2013 at 3:06 PM, James Simonsen <simonjam@google.com>wrote:
>
>> FWIW, I'd rather not add an "urgent" attribute.
>>
>> In the airbnb case cited, the page has already provided sufficient signal
>> to the browser that the picture is important by putting the image at the
>> top of the file and having it take up most of the above-the-fold space. In
>> this case, Chrome has outsmarted itself by demoting it and that's something
>> they (I) should fix.
>>
>> Unless there's really a compelling case for listing resources out of
>> priority order, I don't think we need a new attribute. The browsers just
>> need better scheduling heuristics.
>>
>> James
>>
>>
>> On Thu, May 23, 2013 at 2:42 PM, Steve Souders <souders@google.com>wrote:
>>
>>> 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****
>>>>
>>>>   ****
>>>>
>>>>  ** **
>>>>
>>>
>>>
>>
>