When lazyloading iframes does (not) work (automatically)

WordPress has made some good progress to speed up site rendering the last couple of years and part of this is thanks to images and iframes having the “loading” attribute with value “lazy”, telling browsers these can be loaded later allowing other (more important) assets to take priority. Especially iframes can consume a lot of bandwidth (think embedded Google Maps or one or more YouTube videos), so the performance impact of lazyloading those can be very significant.

Unfortunately one cannot always rely on WordPress core to automatically make sure there is no performance penalty from stuffing your site with iframes. Here is a non-exhaustive list of when iframes will still delay your site:

  1. WordPress core does not always add the loading="lazy" attribute;
    1. if loading="eager" is set (which means load asap)
    2. if no width & height are set (as lazyloading iframes without those could cause layout shifts)
  2. Firefox (and some less important browsers) does not support lazyloading iframes even if loading="lazy" is set
  3. iframes in or near the “above the fold” part of a page are loaded immediately, even if loading="lazy" is set

Conclusion; show restraint when adding iframes; adding an image of Google Maps which links to (a separate page with) Google Maps is almost always as informative and the performance benefit of using an image instead of an GMaps iframe is huge. And when using iframes then consider using alternative solutions to avoid the performance impact (for YouTube you might want to give WP YouTube Lyte a try).

My iFrame usability-gaffe (dommigheid met iFrames)

A couple of days ago I created a small survey to see what people consider sexism (a hot topic currently in the local press and online). For that purpose I embedded a Google Docs Form in an iFrame in a HTML-page on my own site. While following up on the results as they got posted, I noticed a significant amount of respondents were male and aged below 15. Weird, as I had expected that group to be somewhat absent from the results and as the next age-group, 15-20, was indeed barely present. What the heck was happening? My stupidity, that was what was happening!
A long time ago I wrote about problems with iFrames and (simple) solutions for some of those issues on this blog, and more specifically:

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no?

And that was exactly what was happening; after having filled in the first, long page of the Google Docs Form, respondents clicked on “Continue” and -depending on the screen resolution- all they saw was a “Submit”-button and not the questions (age, gender and optional e-mail) before that were hidden from view. How utterly stupid of me, especially as I created a small JavaScript thingie, frameMagic.js, to fix just that problem. I implemented frameMagic.js (and made a small change in there for it to work on iFrames without an id) so the number of male participants aged under 15 should drop considerably as. And I guess I’ll have to do some math to make the results less skewed.
(in Dutch: door een stomme technische fout van mij en mij alleen, is er een significant aantal antwoorden op de “Korte zomerjurkjes-seksisme-enquête” toegekend aan de categorie “man van jonger dan 15 jaar”. Het probleem is rechtgezet en ik zal de antwoorden op een correcte manier  herwegen om min of meer relevante dingen te kunnen zeggen over de resultaten.)

Iframe sandboxing support coming soonish

Did you know you can limit the damage an iframe can do by adding the “sandbox” attribute? And that you can add a value to that attribute to loosen your grip if you choose to do so?
I remember reading about this a couple of years ago or so, but forgot as  support for this html5 spec was limited to Chrome (Apple added support in Safari as well). But while investigating a problem a WP DoNotTrack-user was facing, I re-discovered iframe sandboxing (it effectively stopped the javascript-based tracking inside the iframe) and noticed that support for it is to be included in Internet Explorer 10 and that Mozilla is finally working on an implementation as well.
So yeah, the option to sandbox iframe’s pointing to blacklisted (or non-whitelisted) hostnames will probably be in a future version of WP DoNotTrack. Stay tuned!

Avoid iframe-scrollbars with squeezeFrame.js

I know, this seems to have become an obsession of mine, but here I am again with a follow-up on my iframes-tips blogpost. You might remember I advised against disabling scrollbars on iframes, because;

Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs, depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size).

But what if you could resize (generally: zoom out) the iframe-content to perfectly fit the available width and height, thus avoiding vertical and especially horizontal scrollbars? Well, that is exactly what squeezeFrame.js tries to do (using css zoom and -moz-transform:scale in Firefox)! Just include the javascript-file in the iframe-content page and set a few options if you want to change the default behavior (which is: zoom in/out for width only, max. + or – 5%).
squeezeFrame.js was tested successfully in Firefox 3.6, IE6, Safari4 and Chrome4, but does not work in Opera 10.5. More info (including some “known issues”) can be found on the demo-page and in the javascript-code off course.
As always; reply in the comments or contact me if you find bugs or have problems.

Fix iframe-positioning problem with frameMagic.js

A short followup on my previous post about iframes; as I happen to like simple drop-in solutions, I updated the javascript that handles the ‘blank 2nd page in an iframe bug’ to automagically work upon inclusion in the html.
So if you happen to have problems with the positioning of 2nd (or later) pages in iframes (due to the top part of the iframe not being visible in the ‘viewport’), just upload frameMagic.js to your webserver and add the following to the head of your html to ease your iframe-blues;

<script type="text/javascript" src="path/to/frameMagic.js"></script>

Optionally you can specify which iframes are to be treated this way (excluding the other ones) by doing

<script type="text/javascript">
var fM_conf="iFrame1,iFrame3";

You can find more information and examples on http://futtta.be/frameMagic.

5 tips to tackle the problem with iframes

Iframes have always been frowned upon by web-purists (confession: myself included). But things are never black and white and sometimes iframes can be the best solution for a problem (you could substitute “‘iframes” with “Flash” in the previous 2 sentences, but that’s another discussion). So here are 5 quick tips which might lessen some of the SEO- and usability-problems associated with the use of iframes;

1. Google loves doesn’t hate iframes done right!

Although Google is rather vague about the subject, iframes and SEO do not have to be mutually exclusive. But you will have to make sure it’s your main page that shines in search results, not the iframe-content. The main page (where the iframes are defined) has to be more then a mere placeholder for one or more iframes. Migrate as much information (titles, description and other text) from the iframe-content to your main page, which should describe what goes on in the iframe(s). Use the iframe title-property and insert alternative content between opening and closing iframe-tags. A quick example:

<h2>Calculate your mortgage rate</h2>
<p>Calculating your mortgage rate was never easier; just enter the loan-amount and the duration below!</p>
<iframe src=”http://page.url/iframe-container-page1″ …  title=”Calculate your mortgage rate here”>Your browser does not seem to handle frames properly, but you can calculate your mortgage rate <a href=”http://page.url/iframe-container-page1″>here</a></iframe>

2. Own the stage

Avoid visitors viewing the iframe-content out of the context of the main page (e.g. because they followed a link in search-results). Add javascript to the iframe-content to check if it is accessed stand-alone and redirect to the main page (or explain and provide link to the main page) if that is the case.

if(self.location==top.location) top.location.replace('http://contain.er/page-url/here');

3. Don’t draw blanks

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no? The (hackety-hack) solution; tell the browser to scroll to the top of the iframe each time a new page in it is loaded, by calling the function below (with the iframe id as parameter) when the iframe’s onLoad event fires:

var firstrun = new Object();
function frameMagic(el) {
if (typeof firstrun[el] === ‘undefined’) { firstrun[el]=true; }
else { document.getElementById(el).scrollIntoView(); }
<iframe id=”iframe” onLoad=”frameMagic(‘iframe’);”>

Update: the above code has been updated heavily, check my frameMagic.js blogpost

4. Your users really do need scrolling=”auto”!

Help your visitors access all iframe content no matter what configuration they’re using: don’t disable the iframe scrollbars! Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size). Instead define a reasonable iframe-width and height, make the iframe-content width flexible (fluid) and let the browser decide if a vertical scrollbar is needed.
Update: squeezeFrame.js might be a solution to your scrollbar-woos

5. Smart sizing without scrollbars

If you really really really don’t want scrollbars, if you want your iframe to adapt to the size needed by the iframe-content automatically and if you’re not afraid to experiment; there are some nifty javascript-solutions that allow the iframe-content to communicate the required height to the main page. Check out Framemanager (stand-alone, has some issues though) and the JQuery-postmessage iframe-example (which does everything in javascript, which isn’t really ideal from an accessibility point of view).
Conclusion: iframes aren’t necessarily evil (either), but you’ll have to make a small effort to render them somewhat SEO- and user-friendly.

Google inadvertently kills Talk badges with x-frame-options

Disaster has struck e-civilization; Google Talk chatback badges (as seen in the right column on this very blog) are broken! The small iframe remains grey in Firefox, but with some scrolling the following message can be seen:

This content cannot be displayed in a frame
To protect your security, the publisher of this content does
not allow it to be displayed in a frame.
Click here to open this content in a new window

Googling that error-message brings up a blogpost that explains what is going on: the http response-header of the page in the iframe includes “x-frame-options: sameorigin“. And that directive tells most modern browsers not to display the page in the iframe (because it is not embedded in a page of the same origin), to protecting you from possible clickjacking.
x-frame-options was introduced by Microsoft in IE8’s and seems to be implemented in Safari 4 and Chrome 3 as well. Firefox on the other hand hasn’t included this feature (yet?), but I got the error message thanks to the great Firefox NoScript security-extension which -somewhat reluctantly- provides “bullet parity” with IE8’s security features this way (you can stop NoScript from doing this by setting “noscript.frameOptions.enabled” to “false” in about:config).
But back to the root of this problem: Google is breaking their own Talk chatback badge by adding “x-frame-options: sameorigin” to the response headers. Weird huh?