Checkbox to turn off lazy load for iframes

[BlogAid]

I posted about this in the Alpha/Beta RC and was told to add a filter and given code. The original post was ​lazy load iframes will break sites with ads.

There are ZERO non-techie site owners who can add this code.

Native lazy-loading of iframes is going to break sites that run ads from 3rd party agencies that have their own way of doing lazy load on them.

We need a simple checkbox to turn this "feature" off.

I don't consider this a feature request. I consider it a bug in WP 5.7 that will break sites. But because my original post was closed immediately to comments, I opened another and was told to report it here as an enhancement request.

If WP wonders why more non-techie site owners don't get involved in testing and reporting - this is why. We get blown off.

do you have any idea how many site owners depend on the money they make from running ads on their sites to feed their families? This is not at all a trivial matter to my clients and followers and to ad agencies they partner with.

I'm listing it as a major bug, not an enhancement or feature request.

[johnbillion]

Thanks for the report. Can you provide a bit more information please?

• Which ad network are you using? Are you using a plugin provided by the ad network?
• How are the iframes placed onto the page? Are they added directly inside the post content when an editor writes a post? Or are they added automatically?
• What exactly breaks in this situation? Could you provide some technical details about the error?
• Do you have an example URL that shows the problem?

Thanks in advance

[SergeyBiryukov]

Just adding a missing forum post link to the ticket description that may (or may not) provide more context.

• ​lazy load iframes will break sites with ads
• ​lazy load iframes needs simple way to turn it off

[BlogAid]

Thank you so much for the quick reply.

Below are the answers to your questions.

• Which ad network are you using? Are you using a plugin provided by the ad network?

I do not run ads on my site but 80% of my clients do and they use a multitude of ad agencies such as

• Mediavine
• AdThrive
• Ezoic
• Monumetrics

• How are the iframes placed onto the page? Are they added directly inside the post content when an editor writes a post? Or are they added automatically?

The ads are placed there by each ad agency's own mechanism and delivered via 3rd party over their own CDNs. It's all automated

• What exactly breaks in this situation? Could you provide some technical details about the error?

I don't have technical info at this time, but can get it. I do site speed work for these clients and have been told explicitly by the ad agencies that we can use lazy load for image, but not for iframes, as the ads are in iframes and they have their own lazy load mechanism in place.

• Do you have an example URL that shows the problem?

Yes, here is a link to one of my client's posts that runs ads from Mediavine ​https://ladyleeshome.com/mediterranean-stuffed-peppers/

I realize there is code that can be added to turn off both lazy load for images and iframes.
But NONE of these non-techie bloggers can do that themselves, nor should they have to.
WordPress needs to make these features options with a simply way to turn them off.

WordPress is insanely late to the game with lazy load. either all the browsers already do it and/or site owners with fully optimized sites already have ways to do lazy loading that work better than the WP or browser way that we can fully control. And there are solid reasons why we need to have total control over it - like this ads in iframes situation.

I appreciate your speedy help with this, as I will be telling my clients and saying publicly not to update to WP 5.7 until we have a way to address this that the site owner can easily do themselves.

And THIS is why we can't tolerate auto updates for major releases. We need an easy way to turn that off too.
Again, WP is late to the game on this and folks with optimized sites already have their own control over this.
It needs to be an option, not mandatory.

[sabernhardt]

Usually someone makes a plugin to undo new features easily, but I don't see one targeted specifically for the iframes yet. ​Disable Lazy Load removes loading="lazy" from images, too.

[BlogAid]

You've got to be kidding me. THIS is why end users don't get involved with WP dev - because we get blown off.

So, non-techie site owners, many of whom are on fully managed hosting, are supposed to have their sites auto update, them have a surprise break that directly impacts their revenue stream, then wait for some random dev to make some random plugin to fix the issue WP caused, even when WP was told about it beforehand?

[johnbillion]

@BlogAid The main consideration here is how the iframes from the ad networks are inserted onto the page. ​From the announcement post, the change that is being made in WordPress 5.7 only affects:

• iframes within post content (the_content)
• iframes within post excerpts (the_excerpt)
• iframes within text widgets (widget_text_content)

If the iframes from the ad networks are inserted via another means, for example directly onto the page, then there is no cause for concern. If you could test this on your pre-production environments to determine if there is indeed a problem that would be very helpful. Thanks!

[BlogAid]

I've been working through one of my clients who is with one of these ad agencies, but have contacted the agency directly to get more technical input on how they insert ads and to do the pre-production testing. I have given them this Trac ticket to reply to directly too.

I have no idea if any of the other ad agencies use the same methods, but this is the biggest one, and we'll see what they say.

I'm wondering why there is so much resistance to simply making lazy load an option that we can control. I offer speed services and I can't even get a good read on testers for sites due to the lazy element being generically applied to all images now, even those that are on the screen and should be exempt from the lazy tag being added to them.

[johnbillion]

I guess the honest answer to why there is no option to switch this off is that a non-technical user won't be able to make an informed decision about whether this setting should be on or off.

I have a suspicion that the way the ad networks you mention load iframes onto the page on a WordPress site means they won't be affected by the lazy loading changes in 5.7. Do let us know once you've investigated and heard back from the ad networks and we can go from there.

[BlogAid]

@johnbillion I appreciate your reply - but non-techie does not equate to uninformed. I have hundreds of non-techie clients making $3k-$20k/mo who are non-techie. But they are educated in what is going on with their sites and in full control of their optimization.

There is zero reason why WP cannot make this a checkbox option. Sure, go ahead and turn it on by default for uninformed users, just give those of us in the know an easy way to turn it off.

I'm fighting this same type of battle with hosts, cPanel, Cloudflare, Imunify360 who makes the rules for ModSecurity, and other vendors who think they know what's best - and usually is for uninformed site owners. But their generic "help" trashes my fully optimized client's sites. At least they give us a way to turn those things off. I just wish all of them would announce their changes. I involuntarily donate up to 20 hours a week chasing down where these surprises came from and getting them turned off. Every vendor is working in isolation and it causes chaos for someone like me who has to make all of the puzzle pieces fit together.

[BlogAid]

The two big ad agencies that most of my clients are with replied with this:
"WordPress lazy loading will only affect the initial markup before our ads have been loaded -- it does this through PHP, so it’s done before the JS is added to the page. Since all the iframes our script wrapper inserts on to pages are dynamically loaded via Javascript, ads will load after WordPress adds the lazy loading attribute, this shouldn't impact ads."

So, they are only affected by any type of optimization plugin that also uses JS for lazy loading of iframes.

Some of the smaller ad agencies do not use these best practices, and likely will be impacted. I'll advise any folks using those agencies to check with them for what to do since there seems to be no chance of WP making this an easy option to turn off.

[jorbin]

@BlogAid Thank you for bringing this up and for checking with your client's ad partners.

The reason that there is hesitation to add an option is that adding an option goes against the ​WordPress Philosophies which specifically state "Decisions not Options".

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

This philosophy point is fairly influenced by the writing of Havoc Pennington, the two essays of value here are ​https://ometer.com/preferences.html and ​https://ometer.com/free-software-ui.html

That said, we absolutely should make sure this feature doesn't break sites. Are you able to point to an example of this actually breaking a site, or are your concerns purely hypothetical?

I'll also point out that this code only affects iframes with both a height and width param.

I did check the ​ezoic plugin and it doesn't seem to be inserting and iframe's server side. I also checked the link to your client's site and it doesn't have any iframes that would be affected.

[BlogAid]

@jorbin Thank you for the extra info and clarity on the decision made. I educate site owners as I do their site audits so they can see how plugins and other choices made impact the site and cause conflicts. Agreed that most site owners are not involved in their own optimization and either hire out fixes or have managed hosting. I make a good living cleaning up after both of those.

Until today, all I could get from any agency was that no other iframe lazy load should be used. I believe they finally did the confirmation testing because of this ticket.

There are two versions of Ezoic, with and without their paid speed up option. I don't know how that differs from what you checked, but guessing it also has JS lazy load or similar. There are several other smaller ad agencies that I didn't list.

I've reached out to folks who are with the smaller ad agencies. They are not my clients, so I don't have direct contact with them. We need confirmation from the agencies that they have actually tested the functions. I have worked on those sites and the way the ads was done was a real mess and my clients removed them. So, I don't know if I will get an answer/confirmation about them prior to WP 5.7 rolling out next week.

More than anything, I appreciate getting replies here and folks willing to investigate. I'm doing my best to keep my clients ahead of curves and issues and it's not fun to be blown off without even having the issue looked into - by the ad agencies or by WP. Thanks to everyone in the thread for taking the time!!

[davidbaumwald]

@BlogAid I'm not sure if it's still helpful to you, but I was able to get quick approval on a new plugin that disables lazy loading for iframes altogether. The plugin is at ​https://wordpress.org/plugins/disable-lazy-loading-for-iframes/.

There's no checkbox, but activating/deactivating the plugin serves the same purpose.

[BlogAid]

@davidbaumwald Thank you very much for creating a specialized plugin for this. I'll definitely make note of it for the folks who are on ad agencies that we have not been able to test yet so they will have it handy, if needed.

[antpb]

Thanks @davidbaumwald for the suggested plugin. As this is solved by that plugin and not really a fit for Core, I'm going to close this out to keep our backlog of tickets true.