Open DahmaniAdame opened 6 months ago
@DahmaniAdame just to clarify the expectations:
If that's expected, I can see potential problem with pre-warmup
as we're not applying YT feature there.
Yes. Correct. It's conditional.
What is expected is if the iframe
is the LCP element, and if the preview image is activated on our side, then it will be processed.
At the same time, we need to have a backup LCP candidate reported so it fallback to it if the preview image is not used.
If that's expected, I can see potential problem with pre-warmup as we're not applying YT feature there.
There shouldn't be any need for applying the image replacement on SaaS.
The kind of iframe
covered will have an explicit width
and height
. That should be enough to assess if it's an LCP candidate or not without loading the actual iframe
content.
Behavior needs to be confirmed on SaaS.
What is expected is if the iframe is the LCP element, and if the preview image is activated on our side, then it will be processed.
When the preview image is enabled, wouldn't the element be just an image already?
When the preview image is enabled, wouldn't the element be just an image already?
Yes. The overhead will be minimal. If it's more convenient, why not.
In all cases, we still needs to identify the next LCP candidate to act as a fallback when the preview image is disabled.
Context
iframe
might be the most prominent element above the fold. Lighthouse currently ignores it as an LCP candidate and will pick the next candidate.If the
iframe
is facaded by WP Rocket, like a YouTube video when using the preview image sub-option, thatiframe
will become the LCP element.Expected behavior Facadable elements need to be reported but only processed by WP Rocket if the facade is applied.
Acceptance Criteria To be defined.
Additional information We will have more facades implemented in the future. The logic needs to be extendable to any supported facade other than YouTube.