311

Somewhere along the line I picked up the notion that using iframes is 'bad practice'.

Is this true? What are the pros/cons of using them?

meleyal
  • 32,252
  • 24
  • 73
  • 79
  • 1
    Also see [Mozilla's docs about embedding technologies.](https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Other_embedding_technologies) – djvg Mar 20 '23 at 13:07

11 Answers11

241

As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.

One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.

However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.

Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.

With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.

adzm
  • 4,148
  • 1
  • 27
  • 21
  • 24
    " if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option" ...thats not true. You can embed external content in your page by getting data via jquery ajax and then populating a div with that data. – developer747 May 02 '13 at 16:07
  • 58
    @developer747 - That won't work if the external content is on another site due to [same origin policy](http://en.wikipedia.org/wiki/Same_origin_policy). In some obscure cases, the remote site might support [JSONP](http://en.wikipedia.org/wiki/JSONP); but probably not. – Peter V. Mørch Jul 24 '13 at 09:00
  • 2
    I feel like iframes are a lot less useful than the former frameset because iframes cannot be resized by the user - but I wouldn't use a frameset for anything but a manual since it no longer exists in html5. Example: [Game maker manual](http://docs.yoyogames.com/) – Domino Feb 19 '15 at 14:31
  • 17
    It should be mentioned that iframes are currently the only way to define a nested CSS scope. They isolate the inner markup, layout, style, and Javascript* from the outer document, which is useful in many use cases and applications. *Javascript is not isolated if the inner document shares origin with the outer one; on the other hand, documents from different origins can still communicate using `window.postMessage()`, for example to implement collaborative iframe auto-resizing. – Tobia Mar 17 '15 at 14:19
  • 1
    [The iFrame Is Evil!](http://www.rwblackburn.com/2012/07/iframe-evil/) may help as well – DanielV Apr 14 '15 at 12:19
  • 1
    No. They're bad practice. They inhibit accessibility and automated testing and thus scalability. – uchuugaka May 02 '15 at 06:56
  • 2
    They are a tool, an NO tool is BAD practice, only developers code can be bad. They like every other tag when used in a practical way are invaluable in web development. they allow you to embed one document into another, usually from a dis-separate system. Like all tags, google and read about some bad implmentations, but there are no downsides to a proper implementation. Inhibit accessibility is complete and utter rubbish. I've used iframes creating sites for the blind society and they read them fine... #caseclosed – Dawesi Feb 12 '16 at 00:34
  • 1
    Tobia is absolutely right here. I'm currently working on some web app that requires CSS isolation. If you're familiar with Bower, it packages all your CSS into one file; if you call something that dynamically creates some CSS within a page using that main.css file, it could cause conflict. Therefore an iframe works nicely to separate the two, and I believe is a pretty good use of it. – Super Fighting Robot Apr 06 '16 at 13:47
82

They're not bad practice, they're just another tool and they add flexibility.

For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.

For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.

Tom
  • 10,689
  • 4
  • 41
  • 50
  • 11
    I think it is important to mention that iframes can be use to embed a page from a domain into a page from another domain. If the embedded page would like to follow users with cookies and keep that info from the host domain, then your only option is to use an iframe as JS is under the host domain's control. – Nicholas Leonard Feb 20 '10 at 05:09
  • @NicholasLeonard A good example is that you can use them to force localstorage based cache the page by making the index page a script that detects if the subpage is in localstorage. Then, document.write it from localstorage if its there, and if not add in an iframe to that subpage. In that subpage, have a script to store the subpages HTML element's outerhtml into localstorage. A REALLY good reason to use this method is that it allows you to add in a loading screen. –  May 05 '17 at 18:36
  • I disagree, *but* I can't downvote it, because it is an important POV. – victorf Jul 07 '17 at 19:00
33

It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.

On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.

Chris Van Opstal
  • 36,423
  • 9
  • 73
  • 90
20

Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.

Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.

If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.

If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.

So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.

user261975
  • 233
  • 2
  • 3
10

Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.

mel3kings
  • 8,857
  • 3
  • 60
  • 68
8

There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.

Community
  • 1
  • 1
djbryson
  • 81
  • 1
  • 1
6

The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.

If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).

JacquesB
  • 41,662
  • 13
  • 71
  • 86
5

When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.

Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.

So nope - iFrame is not evil.

Jeffz
  • 2,075
  • 5
  • 36
  • 51
5

They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.

They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.

Vlad
  • 795
  • 1
  • 12
  • 35
5

It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.

Brian
  • 25,523
  • 18
  • 82
  • 173
  • 1
    Why? And is their a way to make the iframes load once the main page is done loading? – Nicholas Leonard Feb 20 '10 at 05:12
  • 3
    I don't remember why they are so slow; I was researching this a year ago. Probably because the browser is basicaly creating an entirely new rendering context for each iframe. As for making them not load until page load completes, you can use a blank iframe and then set the iframe's src tag after page load completes. Note, however, that even a blank iframe will slow down your page rendering, though not the download, so things will still appear a bit slower to your users. – Brian Feb 20 '10 at 07:17
  • 3
    To the contrary, one might consider discussing CDN (Content Delivery Networks) when referencing speed and iFrames. Consider that the iFrame can download resources in parallel and therefore provide a boost in speed (depending on the browser). Here is at least one other reference that agrees with my position. http://developer.yahoo.com/performance/rules.html – Strixy Mar 18 '13 at 22:36
  • 2
    @Strixy: The URL you specify states that IFrames are costly, even when blank. It recommends minimizing the use of IFrames. Using a CDN to speed up your site is orthogonal to using IFrames. A CDN may help mitigate the cost of using an IFrame. However, CDN with no IFrame is better than CDN and IFrame. – Brian Mar 19 '13 at 12:58
  • @Brian Just thinking out loud and enjoying the debate here. I get the impression that it depends on how the iFrame is being used and for what purpose. Load time is calculated on the time it takes to download content as well as the time it takes to render. If you can download resources in parallel via an iFrame, would that not make up some of the loss of time in the render phase of that calculation, but only if the size of the data downloaded exceeds the time to render? So what are those times, I suppose would be the next direction for the debate, yes? – Strixy Mar 19 '13 at 20:04
  • 1
    @Strixy: If you want to download resources in parallel, there are better ways to do it. The old hotness is to load all that stuff via javascript. The new hotness is to use a Service worker, which effectively allows you to directly manage how the user agent loads, preloads, and caches site resources using client-side logic. The other new hotness is http/2 push, which allows you to send resources to the browser without waiting for the browser to ask for them. However, since the http/2 cache is checked *after* other browser caches, it's often a poor choice for this purpose. – Brian Apr 04 '19 at 14:47
  • @Brian Indeed. A lot has changed in the last 6 years. – Strixy Apr 24 '19 at 17:14
4

I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.

I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.

JacobE
  • 8,021
  • 7
  • 40
  • 48