Hi @hanopcan
I can confirm the issue but it isn’t really a bug. It is kind of incompatibility but mostly related to the very essence of how embeds are working and what lazy load does by design.
When you use such embed, there’s a script executed which creates an iframe markup and there are some JS scripts used. Those scripts are adding “event listeners” to certain events – such as e.g. clicking on a link – and the links are handled through this scrips.
JavaScript has this very specific trait that makes it extremely “sensitive” to DOM (or, in other words, page markup so to say) changes.
Now, when Lazy Load for iframes is enabled, the content of that iframe is loaded with a delay so this often may result in the fact that at the moment aforementioned JS is trying to “hook up” to it, that content simply doesn’t exist, which can then break functionality of that JS.
It isn’t quite unexpected and while it doesn’t really happen “always” (it really depends on a lot of additional factors such as what JS is used, how it relates to the loaded content and so on), that’s also why there are additional configuration options in Lazy Load settings to allow disabling Lazy Load for certain types of content or exclude some elements from Lazy Load.
—-
In this case, solution is to
– either disable Lazy Load for iframes by unchecking “iframe” checkbox on “Smush -> Lazy Load” page (this way images and other types of content can still be lazy loaded)
– or to exclude such embeds specifically by adding following to the “Classes & IDs” option in “Smush -> Lazy Load” page
.wp-embedded-content
The second solution would let you keep lazy load enabled even for iframes but would just exclude embeds from it – meaning embeds would work fine and any other iframes (like e.g. video iframes) would still be lazy loaded.
Best regards,
Adam