The iFrame Is Evil!
So it seems that every job I work on, the same topic comes up. Someone, at some point will say, “just use an iFrame for that”. Then I need to go down the old tired road as to why that would not be a good idea.
Well, this article is going to be a bit utilitarian for me. I hope to put down in a single place all the reasons iFrames are not a cure-all solutions so that I can save myself some time in the future and just point people to this URL. As such I may update this post on occasion as I refine these points. Feel free to use this post for that same purpose if you like, and please post any suggestions or points I have missed to my twitter account (@rwbDev), I’ll be sure to credit you if I add the point to this article.
Now, let me be clear. iFrames do have a valid purpose. I have actually used iFrames many times myself with great success. The problem is that people tend to want to use them to get around poor architecture, or as a simply fix to a problem. In my experience this usually just trades a small problem for a much bigger problem down the road, and more often than not it’s an unnecessary trade off. I will cover both these points below.
Now, let me be clear. iFrames do have a valid purpose. I have actually used iFrames many times myself with great success. The problem is that people tend to want to use them to get around poor architecture, or as a simply fix to a problem. In my experience this usually just trades a small problem for a much bigger problem down the road, and more often than not it’s an unnecessary trade off. I will cover both these points below.
The Problems with iFrame
First let me list some of the shortcomings of iFrames.
- Bad For SEO. This is one of the most prevalent reasons you will find for avoiding iFrames. Some search engines may have difficulties with the pages referenced within iFrames. How much this affects a site’s or page’s search ranking is not fully known, however most experts I have talked to agree that it definitely has some impact. Check out this interesting form post on the tropic. For detail on how SEO works and impacts of design decisions like this, I would suggest checking out seomoz.org. This of course is not an issue if SEO is not a concern for your page or app — or example an application which requires a login (all the pages behind the login are not accessible to the search engines anyhow).
* Note (added June 6th, 2013): Recent tests have shown that search engines may in fact follow links within an iFrame. This means the SEO impact of an iFrame is much less than it has been in the past. It is still unclear that there is no impact and different search engines may behave differently in this regards.
- Linking/Bookmarks. Unless you introduce extra JavaScript, the user will not be able to obtain a link directly to content within the iFrame. This includes links someone might email a friend, bookmarks, or pages that come up in a search engine result. Imagine your user goes to your page, and some content is in an iFrame. They click a link in the iFramed content. This content will stay within the iFrame as expected. Now, your users finds some content they have navigated to within the iFrame and would like to send it to a friend. But, copying the URL in their browser will not work — that would just send the friend to the initial page, with the original content displayed in the iFrame. There are scripts out there which can get around this. I have implemented these myself a few times (in situations where I had no choice). However, these often introduce some of their own issues and often have cross-browser compatibility problems. Often it is down right buggy too. Again, depending on your site or your application’s needs, this may not be an issue, but this is a big issue for most sites.
- Difficulty with Debugging. This is one which people often overlooked. If you have a robust application with complex jQuery, Ajax, and other cool stuff happening all over the page – iFrames can make debugging a problem much more difficult. Is the error happening in the outer page, or the page within the frame? Browser developer tools can help with this, but even those tools don’t always make it clear where the issue is when you are dealing with an iFrame. You would be surprised how often a bug can be replicated when a page is within an iFrame, but works just fine when loaded outside the iFrame. This is an issue for any site. But especially for sites that use iFrames extensively. The more moving parts there are to a system, the harder it is to diagnose a problem.
- No real performance gains. Once in awhile I will find someone who wants to use an iFrame because they feel it will increase their site’s performance. They usually feel this way because it will avoid having to reload the site’s header/footer/menu whenever the site paginates. More often than not, the reverse is true. In fact in my experience, it has never resulted in a performance gain when compared to fixing application’s architecture. First, consider that browsers will cache images, CSS, and JS files. So these will not reload with every page anyhow. But more importantly, people who are thinking along these lines are often looking at iFrames as if they are a poor man’s AJAX. However, the contents of an iFrame paginating is almost always going to be heavier than a true AJAX call which uses XML or JSON to load and refresh only a small parts of the page’s content.
- It's just plain difficult to keep stable. There is a large site from a former job of mine which used iFrame extensively. I am not sure where the NDA applies here, so I will not link to their site just to be safe. They use them often and have all the scripts and fancy tricks used to (in theory) avoid the normal drawbacks of using iFrames. However, there are still frequent problems and errors that pop up on their site because of the extensive misuse and overuse of iFrame. There were also frequent customer complaints posted on forums, LinkedIn, Twitter, ect, about the problem this caused them. Just now I jumped over to their site and within a few minutes found a page that gave me an error because of an iFrame issue. These are smart people who know the issues with iFrames well. Yet even they continue to wrestle with it, years later. When iFrames are abused like they are on this site, no amount of fancy scripting will fully resolve the issues that will inevitably arise.
Alternatives
So I have talked plenty about why you might not want to use an iFrame if you can avoid it. But how do you avoid it?
First, most of the time an iFrame can be avoided with simply architecting the site or application slightly better. Here are some resources you might want to look into:
- PHP: Take a look at the PHP Best Practices list on odi.ch. Specifically look at how he uses the “/parts” folder and implements MVC. Following a structure like this will often resolve many issues, including an inclination to use iFrame as a quick fix.
- Java: If you are working with a Java server, you might want to have a look at Spring and/or Apache Tiles. The first will introduce a popular MVC framework to your system, the second will introduce a framework for templatizing your site’s pages.
- .Net: (If anyone has any good references please send them to me on twitter, @rwbDev, and I will include them here)
- CFML: There are a few MVC frameworks you might want to look into. Two popular MVC frameworks are Mach-II and ModelGlue. Check them out. Also a great resource is Ray Camden (@cfjedimaster), he is a very responsive CF expert who is always willing to help someone out.
However, sometimes you run into situations which are not architectural. Maybe you have a perfectly robust architecture but still have a need to include sub-content inline within the page. In this case you should check out jQuery, and specifically the load() function:
This will have some of the same drawbacks as iFrames. Namely this content will not be visible to Search Engines either (and therefore not good for SEO) and will not be bookmarkable/linkable without extra code. However, this is a far more stable solution that I think you will find is easier to maintain and more flexible.
If neither of these solution help you, or for some reason are not feasible in your situation, feel free to send me a message (email or twitter – @rwbDev) and I would be more then happy to brainstorm some alternative solutions with you.
When to Use, or Not Use, iFrames
Perhaps in the future I will expand this section to provide a comprehensive check list. But for now, I do not think there are hard and fast rules around this per se. My suggestion would be to simply exhaust all other options first. Don’t just jump to the iFrame solution because it seems easy on the surface. Really challenge the assumptions and make sure there is not a better way.