值得注意的是，无论用户的互联网连接速度或iframe的内容如何，​​iframe都会导致页面下载速度变小（约0.3秒），但速度明显下降。在本地对其进行测试时不会看到此内容。实际上，对添加到页面的任何元素都是如此，但是iframe似乎更糟。

我已经看到IFRAME非常成功地应用为制作动态上下文菜单的简便方法，但是该Web应用程序的目标受众只是Internet Explorer用户。

我会说，这完全取决于您的要求。如果您希望确保页面在每种浏览器上都能正常运行，请避免使用IFRAME。如果您针对的是狭窄且知名的受众（例如在本地Intranet上），并且您发现使用IFRAME有好处，那么我认为这样做是可以的。

它们不错，但实际上很有帮助。前段时间我遇到了一个很大的问题，我必须嵌入我的Twitter提要，但它不允许md在同一页面上完成，因此我将其设置在另一个页面上，并将其作为iframe放入。

它们也很好，因为所有浏览器（和电话浏览器）都支持它们。只要您正确使用它们，就不能认为它们是不良做法。

当您的主页加载了HTTP协议，并且页面的某些部分需要使用HTTPS协议时，iFrame可以击败jsonp。

特别是，如果您的dataType不是本机json，则需要在服务器上将其转换为json，并在客户端上转换为例如复杂的html。

所以没有-iFrame不是邪恶的。

根据我的经验，在调用第三方代码时，iframe 的积极方面可能是调用一个具有Document.write();命令的javascript 。如您所知，由于解析方式（DOM解析器等），这些命令无法异步调用。例如http://sourceforge.net/projects/phpadsnew/我使用iframe来帮助加快我们的网站的速度，因为有多个调用phpadsnews的网站，并且该网站在继续进行渲染之前一直在等待响应页面的各个部分。使用iframe，我可以允许网站呈现页面的其他部分，并且仍然Document.write()异步调用phpads 的命令。防止和js锁定。

从可用性的角度来看，原始框架集模型（框架集和框架元素）非常糟糕。IFrame是后来的发明，它没有原始框架集模型那么多的问题，但是它确实有其缺点。

如果您允许用户在iframe中导航，则链接和书签将无法按预期工作（因为您将外页的URL标记为书签，而不是iframe的URL）。

在不了解其缺点的情况下使用它们是“不好的做法”。Adzm的帖子很好地总结了它们。

另一方面，Gmail在后台大量使用iFrame来实现一些更酷的功能（例如自动文件上传）。如果您知道iFrame的局限性，我相信您不会对使用它们感到困惑。

它们不是坏习惯，它们只是另一种工具，它们增加了灵活性。

用作标准页面元素...很好，因为它们是将内容分成多个页面的简单可靠的方法。特别是对于用户生成的内容，将内部页面“沙盒化”为iframe标记不佳不会影响主页面可能很有用。缺点是，如果您引入了多层滚动（一层用于浏览器，一层用于iframe），则用户会感到沮丧。就像adzm所说的那样，您不想将a iframe用作主要导航，而是将它们视为与视频或其他媒体文件的嵌入方式等效的文本/标记。

对于脚本化背景事件，通常在隐藏iframe和XmlHttpRequest加载当前页面的内容之间进行选择。两者的区别在于，会iframe产生页面加载，因此您可以在大多数浏览器的浏览器缓存中来回移动。请注意，XmlHttpRequest在各处使用Google的Google iframe在某些情况下也使用s，以允许用户在浏览器历史记录中来回移动。

在很多情况下与他们合作过之后，我真的开始认为iframe相当于goto语句的网络编程。即，通常应避免的事情。在站点内，它们可能会有所帮助。但是，对于跨网站而言，除了最简单的内容之外，它们几乎总是一个坏主意。

考虑可能性……如果用于参数化内容，它们已经创建了一个接口。在专业站点中，该界面需要SLA和版本管理-急于上线几乎总是被忽略。

如果用于活动内容（托管脚本的框架），则存在（不同的）跨域脚本限制。有些可以被黑客入侵，但很少会持续被黑客入侵。而且，如果框架内容需要进行交互，那么它将很难在框架之外进行交互。

如果与许可内容一起使用，则参与站点将需要在主机之间带外移动权利信息。

因此，尽管在站点内偶尔有用，但它们非常不适合混搭。您最好查看真正的门户网站和portlet。更糟糕的是，它们是每一个网络业余爱好者的宠儿-许多技术经理已经选择他们作为解决许多问题的方法。实际上，它们创造了更多。

iframe使用者肯定有用途。您还如何将天气网络小部件放在页面上？唯一的另一种方法是获取他们的XML并解析它，但是当然，您需要条件来抛出持久的天气图形...并不是很值得，但是如果有时间的话可以使它更干净。