In Defense of the iFrame

Like Comic Sans, the iframe is one of those things we just know we’re supposed to hate, even if we’re not sure why. We get swept up in a collective prejudice so old we don’t think to question it. If you Google “iframes are good” (go ahead, I’ll wait), the top titles returned are things like “Are iframes considered ‘bad practice’?”, “The iFrame is Evil!”, and “4 Reasons You Need to Stop Using iFrames.” One programmer on Stack Overflow wished to know whether using an iframe qualified as “a disaster” that would put him in poor standing with his boss.

Just to clarify, we’re talking about a HTML element here, not a zero-day exploit. Comic Sans, often described as “the most hated font in the world,” is also just a tool that has come under fire for having been misused. Comic Sans was developed by Microsoft for child-oriented contexts like comic strips and birthday cards, but when adults started using the font on legal documents and gravestones, the public directed its outrage at the typeface rather than at the people misusing it.

Because the iframe is germane mostly to web designers and developers, the story of its undeserved infamy will take a bit more to unpack, but we feel it’s worth telling. Exago clients have the option of using iframes to embed the solution into their host applications, and it’s not uncommon for us to get questions about this practice during product demos. Finding the right BI solution is hard enough without misinformation thrown in the mix, so we’re going to address those iframe myths here.



What is an iFrame?

An iframe or “inline frame” is an HTML element that allows you to embed one document or page in another. iFrame code remains distinct from that of the host page, so its text will not, for example, adopt the host page’s font upon embedding. Interacting with a link or object within an iframe also does not affect the host page. Perhaps you’ve experienced this while reading articles with embedded videos linking to other videos. No matter how many links you click on, you’ll still be in the middle of your original article on gardening, though at this point you may be watching a completely unrelated video about migratory bird patterns or something. That’s because you’re interacting with embedded content! Chances are good you use iframes all the time without knowing it.

Now, it’s important not to confuse iframes with frames, also known as framesets. Framesets have been unfashionable for a long time now and were officially deprecated in 2014 with the initial release of HTML 5, though most browsers still support them. Framesets are used to place documents alongside each other in the same browser window such that no one document takes priority over any other. This can cause a whole host of issues, and it’s possible that some users who denounce iframes are in fact recalling frameset behavior.


iframes and framesets.jpg


Why Do iFrames Get a Bad Reputation?

Both framesets and iframes were released as part of HTML 4 in 1997, back when we used AOL and were just getting used to unusual fonts like Comic Sans, which had come out only three years earlier. It was a time of exploration and experimentation, so of course we made mistakes. These days, framesets are rarely encountered in the wild, and iframes quietly go about their cross-domain business without drawing attention; but our aversion lives on.


iFrame Myths

Below is a list of common misconceptions concerning iframes. We’ll take time to address each one generally and also discuss how it affects embedded BI like Exago in particular.

  1. iFrames are bad for SEO.

Search engines use programs called crawlers (or “spiders”) to comb through search results for identifying information, and they completely ignore iframes. To them, iframes are other pages that just happen to be making a guest appearance on the host page; they don’t count as part of the host page’s content. So, the only way iframes can be bad for SEO is if your host page has no content of its own and is instead just a container for an iframe, in which case crawlers will have a hard time ranking its relevance to a search. This, however, would constitute a failure in implementing iframes rather than a failure of the element itself. As a general rule, you can avoid this one pitfall by making sure your host page at least describes the content in the iframe.

Of course, web applications are generally password protected, so SEO isn’t a priority in the embedded BI world.


  1. iFrames make it hard to share links and store bookmarks.

While the URL of the embedded page isn’t as easy to snag as the host page’s URL, it’s not too hard to acquire. In both Chrome and Firefox, simply right-clicking on the iframe content will give you the option to “View Page Source.” Selecting that option will open a new tab showing the host page’s HTML, and a quick search for <iframe> brings you to the source URL. It’s not terribly efficient, but it will do in a pinch.

Once more, this concern doesn’t really apply to web-based BI. Exago uses folders instead of bookmarks for keeping track of reports, and access to those reports is managed on the backend.


  1. iFrames complicate debugging.

The theory is that if you run into a javascript error when your page is loading, it will be difficult to determine whether the source of the problem is inside the iframe or external to it. This may be true in rare cases, but it’s generally easy to tell based on graphical anomalies and error messages. If you’re unsure, you can always nab the iframe’s source URL and load it in a new browser tab to see if the problem reoccurs.

Because BI applications are inherently complicated, they usually come with debugging tools built in, not to mention technical support. At Exago, if a client is having difficulties with anything related to reporting, we help them get to the root of the problem.


  1. iFrames fail to improve performance.

This misunderstanding boils down to misuse as well, or perhaps a false expectation. Web developers sometimes try to improve a page’s performance by using iframes to get around reloading image-dense headers and footers as visitors browse from page to page. Placing a logo in an iframe will do little to improve performance, however, since the browser already caches such things. Some have also noted that iframes are slower than content refreshed using AJAX, which is like saying that sending someone a letter through Google Drive is less efficient than sending it through Gmail. Sure, you can use Drive to tell your significant other to remember milk on the way home, but that’s really not what it’s for. AJAX, which stands for Asynchronous JavaScript And XML, is expressly for refreshing page content without reloading it, and it does this very well.

So when Exago clients decide how to embed the solution, they choose based on their business needs. As of v2017.2, host apps can embed using either iframes or the JavaScript API; one is optimized for simplicity, the other for speed. Those appications unlikely to embed more than one instance of Exago BI per page opt for the iframe, which is easier to implement. Those planning to embed Exago BI multiple times per page go with the JavaScript API, which provides faster loading of report execution and design sessions after the initial session has been established. It all comes down to finding the right tool for the job.


  1. iFrames cause browser errors.

This is also likely a relic from Web 1.0 days. Back in the mid-90s, browsers were still working out the kinks in handling framesets, so there were a lot of disturbances. The iframe, by virtue of its subordination to the host page, was in part responsible for helping alleviate these kinds of browser problems. Nevertheless, people confused iframes with framesets and have since associated iframes with broken browsers. Today, iframes are old news from a coding perspective, and most browsers support them, though they may differ slightly in their methods.



  1. iFrames have bad UX.

Once again, the crime here is in execution. Let us be reminded that “Comic sans doesn’t disappoint people; people disappoint people,” and the same holds true for iframes. In the hands of the unskilled, iframes can indeed be irritating to interact with. One byproduct of the poorly executed iframe is the dreaded double-scrollbar.




There are, fortunately, a number of ways around this unsightliness. There are also ways to avoid generating a seemingly blank iframe when the user links from the bottom of a long page to a short page, another faux pas committed by rookie web developers. In essence, any early iframe UX problems have since been solved.


  1. iFrames are unresponsive to resizing.

Nope, that one’s been solved too. But yes, it’s very frustrating when developers don’t adjust their CSS to enable iframe fluidity. Our UI designer is assiduous about accommodating screen/window size, so we’ve got that covered.


  1. You can’t manipulate the content of an iframe.

This one is actually true! Unless the iframe content belongs to the same domain as the host page or another domain you also control, that content is “untouchable.”

With embedded BI, however, you control both the host frame (your proprietary software) and the iframe content (the BI platform). Exago gives its clients full access to the API, complete control over CSS and language files, and the ability to add extensions to the running state. In this case, the iframe acts as a partition between your code and Exago’s code, minimizing the risk of contamination, which brings me to my next point.


  1. iFrames pose a security threat.

There are indeed loopholes that can be exploited if the iframe content shares a domain with the host page, but if these frames source different domains, neither is able to access the other’s code or DOM without express consent. DOM stands for Document Object Model—think of it as the page’s central nervous system. The reason pages from separate domains cannot access each other’s DOMs by default is because of something called the same-origin security policy, which exists to keep disparate DOMs safe from one another. Safely opening up communication between domains is possible using Cross-Origin Resource Sharing (CORS), but this requires extra setup.

In sum, cross-domain iframes provide an additional layer of security and same-origin iframes aren’t any less secure than eschewing iframes altogether. Because you’ll have full control over your BI software, both same-origin and cross-domain iframes are safe options; our clients use both!


  1. There are better alternatives to iframes.

iFrames really are the best at doing what they do. Though a client-side framework like AJAX could supplant the iframe, as in Exago's JavaScript API, doing so adds backend complexity, introducing a tradeoff in developer investment. Our iframe embedding option isn't going away anytime soon, because if we can give clients even a little more security using cross-domain iframes, we’ll do it. Our end users build rockets and do brain surgery, so stakes are high.


If you have an iframe concern that we failed to address here, feel free to leave us a comment! Otherwise, we hope you can forgive both Comic Sans and the iframe for their users’ trespasses.



Authored by
Nicole Hitner
Content Strategist
comments powered by Disqus