Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LCP element + facaded iframe #6529

Open
DahmaniAdame opened this issue Apr 1, 2024 · 4 comments
Open

LCP element + facaded iframe #6529

DahmaniAdame opened this issue Apr 1, 2024 · 4 comments
Labels
lcp priority: medium Issues which are important, but no one will go out of business. type: enhancement Improvements that slightly enhance existing functionality and are fast to implement

Comments

@DahmaniAdame
Copy link
Contributor

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, that iframe 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.

@piotrbak
Copy link
Contributor

piotrbak commented Apr 1, 2024

@DahmaniAdame just to clarify the expectations:

  1. iframes won't be processed
  2. images used as placeholders for iframes (YouTube and the future ones) will be processed as regular images

If that's expected, I can see potential problem with pre-warmup as we're not applying YT feature there.

@DahmaniAdame
Copy link
Contributor Author

DahmaniAdame commented Apr 1, 2024

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.

@piotrbak
Copy link
Contributor

piotrbak commented Apr 1, 2024

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?

@DahmaniAdame
Copy link
Contributor Author

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.

@piotrbak piotrbak added type: enhancement Improvements that slightly enhance existing functionality and are fast to implement priority: medium Issues which are important, but no one will go out of business. lcp labels May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lcp priority: medium Issues which are important, but no one will go out of business. type: enhancement Improvements that slightly enhance existing functionality and are fast to implement
Projects
None yet
Development

No branches or pull requests

2 participants