Image Prioritizer should be able to store the LCP (background) image URL for prioritization

[westonruter]

Feature Description

Optimization Detective detects the LCP element and stores its elementa metadata in URL Metrics. It stores aspects including XPath of the element, the boundingClientRect, and the intersectionRatio. It does not, however, store the actual image URL associated with the LCP element. Instead, at runtime it determines the image URL by inspecting the element at the given XPath at runtime. For IMG elements, this means extracting the src and srcset attributes to populate in the preload link. For elements with CSS background images (e.g. the Cover block or Group block), it parses the image URL out of the inline style attribute. However, this only works when the background image is defined inline. It is not able to discover background images defined in external CSS stylesheets or applied via inline stylesheets in style elements. For example, Twenty Thirteen's LCP element is the header#masthead element:

The background image is applied via the inline style rule:

<style type="text/css" id="twentythirteen-header-css">
.site-header {
	background: url(http://localhost:8888/wp-content/themes/twentythirteen/images/headers/circle.png) no-repeat scroll top;
	background-size: 1600px auto;
}
@media (max-width: 767px) {
	.site-header {
		background-size: 768px auto;
	}
}
@media (max-width: 359px) {
	.site-header {
		background-size: 360px auto;
	}
}
</style>

This means that Image Prioritizer can't add a preload link for this background image. I've seen this issue occur more frequently. To work around it, specific integrations would have to be worked out that look up whatever image URL is being emitted into the stylesheet via various PHP APIs for not only WordPress core but also various page builder plugins that also add background images like Divi and Elementor (for the latter, see POC plugin). This is not scalable, although adding a specific integration with the header image would make sense.

Nevertheless, the LCP metric data in the browser does include the URL of the image:

But I didn't want to store this and use it for preloading for two reasons:

1. A site builder could select a background image and then change it later, resulting in a period of time in which collected URL metrics could preload the stale background image instead of the new background image.
2. Someone could attempt to maliciously submit a URL metric including an LCP image URL which is extremely large and isn't actually the correct image, which would hurt performance.

Given the common occurrence for non-inline LCP CSS background images, it seems there should at least be a way to enable this, even if it isn't on by default. Worst case or the first point is that a stale URL would be preloaded while waiting for new URL metrics to be collected. For the second point, some safeguards should be put in place such as to only allow preloading image URLs on the same origin (or whatever CDN the site is using).

Aside on Randomness

To add an aside to the above first reason about a LCP background-image stored in URL Metrics becoming out-of-date, this possibility also exists in core when someone chooses the "Randomize Suggested Headers" option in the Customizer.

In the Gallery block, a user can select the "random order" setting, but since the IMG elements then we can still preload the LCP element's URL dynamically based on whichever URL is currently assigned to that IMG tag, although it's true that this IMG tag may no longer be the LCP element.

Nevertheless, I do not believe the random header (or random gallery order) to be a popular options. But it is something to keep in mind.

[westonruter]

It works! Getting close to code review: #1697

[westonruter]

Reopening because additional validation is needed which is being done in #1713