Fix handling NOSCRIPT and IMG tags with JS-based lazy-loading

[westonruter]

When analyzing sites using Image Prioritizer in HTTP Archive, I came across some cases that hadn't been accounted for.

Tags inside NOSCRIPT

First of all, any tag which appears in a NOSCRIPT should always be excluded from visiting by any tag visitor. For example:

<noscript>
	<img src="https://example.com/pixel.gif" alt="" width="1" height="1">
</noscript>

This was always showing up as:

<noscript>
	<img data-od-unknown-tag src="https://example.com/pixel.gif" alt="" width="1" height="1">
</noscript>

Image Prioritizer adds the data-od-unknown-tag attribute to any visited tag IMG which is not located in URL Metrics. However, such an IMG can never be added to URL Metrics since it is not located in the DOM.

This PR skips over visiting any tag which is inside of a NOSCRIPT element.

Such NOSCRIPT tags are often found with JS-based lazy-loading implementations.

JS-based Lazy-Loading

On quite a few sites I found JS-based lazy-loading causing problems with Image Prioritizer. In particular, the Avada theme's Fusion Images lazy-loading functionality replaces srcset with data-srcset but it doesn't change the src, for example:

<img
	src="https://example.com/foo.webp"
	data-orig-src="https://example.com/foo.webp"
	width="1000"
	height="800"
	class="lazyload wp-image-1"
	srcset="data:image/svg+xml,%3Csvg%20xmlns%3D%27http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%27%20width%3D%271000%27%20height%3D%27800%27%20viewBox%3D%270%200%201000%20800%27%3E%3Crect%20width%3D%271000%27%20height%3D%27800%27%20fill-opacity%3D%220%22%2F%3E%3C%2Fsvg%3E"
	data-srcset="https://example.com/foo-200x91.webp 200w, https://example.com/foo-300x136.webp 300w, https://example.com/foo-400x181.webp 400w, https://example.com/foo-600x272.webp 600w, https://example.com/foo-768x348.webp 768w, https://example.com/foo-800x362.webp 800w, https://example.com/foo-1024x463.webp 1024w, https://example.com/foo-1200x543.webp 1200w, https://example.com/foo-1536x695.webp 1536w, https://example.com/foo.webp 1920w"
	data-sizes="auto"
	data-orig-sizes="(max-width: 767px) 100vw, 1920px"
>

This was resulting in an erroneous preload link being added, in particular the imagesrcset is pointing to a data: URL:

<link data-od-added-tag rel="preload" fetchpriority="high" as="image" href="https://example.com/foo.webp" imagesrcset="data:image/svg+xml,%3Csvg%20xmlns%3D%27http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%27%20width%3D%271000%27%20height%3D%27800%27%20viewBox%3D%270%200%201000%20800%27%3E%3Crect%20width%3D%271000%27%20height%3D%27800%27%20fill-opacity%3D%220%22%2F%3E%3C%2Fsvg%3E" media="screen and (min-width: 783px)">

So this PR adds checks to make sure that if an IMG has such a srcset it is also excluded from processing.

In a future PR we could consider undoing such JS-based lazy-loading, rewriting data-src to src, data-srcset back to srcset and so on, and then to process the IMG as normal. This would have a dramatic improvement to LCP especially when the such JS-based lazy-loading is being done for images in the initial viewport, especially for an IMG which is the LCP element. See #1746.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: westonruter <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[westonruter]

Well, there could be something to optimize. We can't preload the URL, but we could still add fetchpriority=high to the IMG.

[westonruter]

As noted below, this may be too conservative. We could still process this IMG. It's just we would skip any parts related to preloading the src or srcset.

[westonruter]

I'm bumping this to the next release.