[wp-trac] [WordPress Trac] #52768: WordPress post URL oEmbed rendering blocked by iframe lazy-loading

[WordPress Trac]

#52768: WordPress post URL oEmbed rendering blocked by iframe lazy-loading
---------------------------+--------------------------
 Reporter:  SirStuey       |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  5.7.1
Component:  Embeds         |     Version:  5.7
 Severity:  normal         |  Resolution:
 Keywords:  needs-testing  |     Focuses:  performance
---------------------------+--------------------------

Comment (by SirStuey):

 I've been trying to dig up more about how Chrome treats iframe lazy-
 loading.

 https://web.dev/iframe-lazy-loading/

   The loading attribute affects iframes differently than images, depending
 on whether the iframe is hidden. (Hidden iframes are often used for
 analytics or communication purposes.) Chrome uses the following criteria
 to determine whether an iframe is hidden:

   * The iframe's width and height are 4px or smaller.
   * display: none or visibility: hidden is applied.
   * The iframe is placed off-screen using negative X or Y positioning.
   * This criteria applies to both loading=lazy and loading=auto


   If an iframe meets any of these conditions, Chrome considers it hidden
 and won't lazy-load it in most cases.


 That first clause is the culprit, caused by clip: rect(1px, 1px, 1px, 1px)
 leads Chrome (and Edge) to treat the iframe as intentionally hidden.

 clip is also deprecated, with clip-path the preferred replacement.

 I tested things locally via embed.php, replacing clip: rect(1px, 1px, 1px,
 1px) with various forms of clip-path.

 It's my understanding that clip: rect(1px, 1px, 1px, 1px) has no height or
 width given that all of the dimensions are with respect to the top left
 corner, and so I tried to approximate the same with clip-path inset
 values.

 clip-path: inset(0 100% 100% 0); clips the image from the right and
 bottom, resulting in 0 pixel width located at the top left of the element.

 This does not improve the situation, the issue is present and the iframe
 is not displayed. I thought the issue was due to clip being deprecated,
 but mimicking the same clipping behavior with clip-path causes the same
 iframe rendering issue.

 However, if the clipping path is modified. e.g. clip-path: inset(0 50% 50%
 0); , the browser produces the desired iframe display behavior. I tested
 this on desktop (Windows 10) and for Chrome. It does not seem to
 negatively impact other embed sources (e.g. YouTube), and I see the
 blockquote link fallback on page-load before it's quickly replaced with
 the iframe as expected. I have not tested on mobile, and I'm not certain
 what undesirable behaviors to look for.

 The problem is, if the iframe is hidden in most conventional ways, Chrome
 will treat it as hidden.

 It's unclear to me why different browsers or browser versions treat this
 differently, such as why is the hidden iframe is treated differently in
 Chrome for desktops vs. Chrome of mobile. But, unless the browser
 treatment changes, lazy loading conflicts with how the WordPress embeds
 are hidden by default.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52768#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform