Integrate Embed Optimizer with Optimization Detective to skip lazy-loading LCP embeds

[westonruter]

Feature Description

The Embed Optimizer (#888) plugin improves performance for the majority of embeds by lazy-loading them so they don't impede page loading when not in the viewport. However, if they are in the initial viewport the lazy-loading will actually hurt performance by potentially delaying LCP. Any embeds which do not appear in the initial viewport should be excluded from lazy-loading. This can't be done reliably server-side, for example core uses a counter to skip lazy-loading the first N instances. However, Optimization Detective (#869) is built to be able to detect which elements are in the initial viewport so that they can be properly optimized. What is needed is for Optimization Detective to expose an interface for other plugins to hook into the optimization process so that, in the case of Embed Optimizer, it can actually reverse the lazy-loading which it blindly applied server-side for the in-viewport embeds.

Alternatively, the server-side logic for Embed Optimizer could be modified when Optimization Detective is also running to not immediately make the embeds lazy-loaded, but rather to instead mark the embeds with an attribute for the lazy-loading to be applied during post-processing, that is, on the output-buffered page which the HTML Tag Processor iterates over.

[felixarntz]

@westonruter Regarding what you mentioned in #1046 (comment), I think we need to be careful about this one.

Per #1059, it looks like we're already planning to publish Embed Optimizer. But if we do that and later introduce a dependency to Optimization Detective, we would create the sub-par experience for end users that we wanted to avoid per the discussion in #1046.

How much effort would it be to make this change? Could we potentially hold off publishing Embed Optimizer until Optimization Detective exists? We could make it a dependency from the start.

Alternatively, we would need to do the same treatment with Embed Optimizer: Hold off promoting it to a larger audience (via Performance Lab) until the dependency setup is in place.

cc @adamsilverstein

[westonruter]

@felixarntz The situation here is a bit different in that Optimization Detective isn't a requirement for Embed Optimizer, but it is rather a suggestion to achieve yet better performance. If someone has embeds and they aren't in the initial viewport, then they can use Embed Optimizer without any downsides. So I see Optimization Detective as not being a hard dependency.

[felixarntz]

@westonruter Thanks for clarifying. As long as we reflect that on the technical side as well (Optimization Detective should never be an actual plugin dependency for Embed Optimizer), that sounds good to me. So I guess, if a site also has Optimization Detective, the Embed Optimizer plugin would just become more reliable? :)

[westonruter]

@felixarntz Yes, that's right. It's a suggests rather than a requires in Composer parlance. Even if we did actually make it an actual dependency we could keep the current behavior so that the sub-optimized logic continues to run when Optimization Detective isn't active.

[felixarntz]

@westonruter

Even if we did actually make it an actual dependency we could keep the current behavior so that the sub-optimized logic continues to run when Optimization Detective isn't active.

Would that be possible? I am under the assumption that WordPress core will not load the plugin if a dependency is missing - but that may not be the case, I haven't tested it.

[westonruter]

@felixarntz Yes, that was an aspect of Plugin Dependencies that was pulled out for 6.5. Initially it would check at runtime for every request if the dependencies are satisfied. But that caused a performance problem. Now the check is only done on the Plugins screen, and it doesn't deactivate a dependent plugin when the dependency is missing, as seen in this screenshot: