Do we need a tracking bug for this when there's no specification yet?

Is there even a new specification issue regarding iframes (and other elements loading remote resources)? It looks like the outcome of https://github.com/whatwg/html/issues/2806 was only lazy loading for <img> elements, in the end.

(In reply to Anne (:annevk) from comment #1)

Do we need a tracking bug for this when there's no specification yet?

I assume, lazy loading for iframes will eventually also be specified. So either this bug should be kept open or closed for now and be reopened once specified in order to implement it.

Sebastian

Now that we triage by severity, setting this bug's priority to P2 to represent near-term backlog status. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

FYI https://github.com/whatwg/html/pull/5579 has now landed.

Shipping in Safari TP 151:
https://webkit.org/blog/13093/release-notes-for-safari-technology-preview-151/

Enabled lazy iframe loading by default (252848@main)

So probably [parity-safari] as well.

The Performance Impact Calculator has determined this bug's performance impact to be none. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

I do not agree with the previous comment.
Iframes are used on majority of websites and may have a significant performance impact depending on what is loaded in the iframe.
It is a very real problem if those iframes contain videos or animations in carousel or slider elements.
See new calculation below.

The Performance Impact Calculator has determined this bug's performance impact to be high. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: [x] Windows
×3 [x] macOS
×3 [x] Linux
×1 [x] Android
×1.5
Impact on browser: Causes noticeable startup delay
+5
Page load impact: Some
+5
Websites affected: Major
×5
[x] Able to reproduce locally
×2
[x] Bug affects multiple sites
×2
[x] Multiple reporters
×1.5

I would ask if the priority or severity can be increased, in respect to my previous comment.

How much startup delay does it cause?

What is the specific amount of page load impact the lack of this feature is causing?

What websites are using this feature?

How are you reproducing this locally?

Thanks.

https://almanac.httparchive.org/en/2022/css is an example page that loads a LOT of embedded Google Sheets charts in iframes with loading=lazy so that, browsers that support this, will only load the content needed near the viewport.

On Chrome this loads 1.7 MB of resources for the above the fold content (6.3 MB uncompressed). As you scroll down it loads more as needed. This is similar in Safari Technology Preview.

On Firefox this loads 32.06 MB of resources for the above the fold content (110.82 MB uncompressed) as it loads the whole thing (though this is with the default Disable Cache option ticked, it's a lot less than that with that unticked as there's a lot of duplication in these as a lot of the same JS is reused in each graph).

As well as downloading all that extra stuff, the browser has to process it, which could cause other performance issues.

I also got a complaint about this from a Firefox user: https://github.com/HTTPArchive/almanac.httparchive.org/issues/1822

Initial implementation for <iframe loading=lazy>

Unimplemented details: (X = should definitely do before ship)

• Window load should not wait for in view lazy loading iframes
  (Chromium fail, WebKit pass)
  X Parse-time referrer policy is not used
  (Chromium pass, WebKit pass)
  X Lazy loading multiple times
  (Chromium pass, WebKit pass)
  (We also pass some other WPTs other engines do not too already)

WIP. TOOD:

• Decide if we want this patch to do "everything" or just initial impl
• Decide if we want to ship this patch or land behind pref (depends on above)
• Update WPT expectations
• Cleanup code (review/help opinions please, see todo comments)

Intent to prototype and ship: https://groups.google.com/a/mozilla.org/g/dev-platform/c/s-Ssm1n14TU

https://hg.mozilla.org/mozilla-central/rev/13cc00766986
https://hg.mozilla.org/mozilla-central/rev/3fc6753d925a
https://hg.mozilla.org/mozilla-central/rev/77f05957a4fc

\o/ Great work, canadahonk!

Release Note Request (optional, but appreciated)
[Why is this notable]: New web platform feature
[Affects Firefox for Android]: Yes
[Suggested wording]: Lazy loading iframes are now supported (<iframe loading=lazy>). Lazy loading iframes are only loaded when visible, so non-critical iframes can load later when needed to speed up initial page loads, reduce initial network usage, etc.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading

Added to Fx120 nightly release notes: https://www.mozilla.org/en-US/firefox/120.0a1/releasenotes/

Sorry, this just got delayed a cycle due to some bugs found in nightly. Dianna, could you remove from release notes please? Thanks!

np, done! will this remain nightly only or will it simply be backed out? I ask because we can add this as a nightly only relnote if needed.

Thank you! This is remaining nightly only for now, not backed out.

MDN docs work for this can be tracked in https://github.com/mdn/content/issues/29780#issuecomment-1786311439. At this point the expectation is that this will actually release in 121 so I'm just doing some tidy up of the existing docs in preparation for the next version.

As few questions:

• Should this issue be closed (i.e. should it be reopened)?
• My understanding is that any iframes that are lazy loaded are ignored for deciding whether to fire the Windows load event - right?
• The docs indicate that images downloaded lazily still require JavaScript to be enabled as some kind of anti-tracking mechanism. Is this (still) true, and if it is, is it also true for iframes?

I am planning for this to be shipped in 121, providing no other regressions/bugs are found in the mean time.

1. This bug is remaining mostly untouched, see the enabling bug - Bug 1860729.
2. This is expected but we may not do this correctly yet, we fail the WPT along with Chromium. (This is not blocking shipping it.)
3. Yes, scripting needs to be enabled for both images and iframes.