iframe 被认为是“不好的做法”吗？ [关闭]答案

【问题标题】：Are iframes considered 'bad practice'? [closed]iframe 被认为是“不好的做法”吗？ [关闭]
【发布时间】：2010-09-26 15:18:51
【问题描述】：

在某个地方，我发现使用 iframe 是“不好的做法”。

这是真的吗？使用它们的优点/缺点是什么？

【问题讨论】：

标签： html iframe standards

【解决方案1】：

与所有技术一样，它也有起有落。如果您使用 iframe 绕过一个适当开发的网站，那么这当然是不好的做法。但是有时 iframe 是可以接受的。

iframe 的主要问题之一与书签和导航有关。如果您使用它只是在您的内容中嵌入一个页面，我认为这很好。这就是 iframe 的用途。

但是，我也看到过 iframe 被滥用。它永远不应用作您网站的组成部分，而应作为网站中的一部分内容。

通常，如果您可以在没有 iframe 的情况下执行此操作，那是一个更好的选择。我相信这里的其他人可能有更多信息或更具体的示例，这一切都归结为您要解决的问题。

话虽如此，如果您仅限于 HTML 并且无法访问 PHP 或 ASP.NET 等后端，有时 iframe 是您唯一的选择。

【讨论】：

" 如果您仅限于 HTML 并且无法访问 PHP 或 ASP.NET 等后端，有时 iframe 是您唯一的选择" ...那不是真的。您可以通过 jquery ajax 获取数据，然后使用该数据填充 div，从而在页面中嵌入外部内容。
@developer747 - 如果外部内容由于same origin policy 而位于另一个站点上，这将不起作用。在一些不明显的情况下，远程站点可能支持JSONP；但可能不会。
我觉得 iframe 没有以前的框架集那么有用，因为用户无法调整 iframe 的大小 - 但我不会将框架集用于手册，因为它不再存在于 html5 中.示例：Game maker manual
应该提到的是，iframe 是目前定义嵌套 CSS 范围的唯一方法。它们将内部标记、布局、样式和 Javascript* 与外部文档隔离开来，这在许多用例和应用程序中都很有用。 *如果内部文档与外部文档共享源，则Javascript不是孤立的；另一方面，来自不同来源的文档仍然可以使用window.postMessage() 进行通信，例如实现协作 iframe 自动调整大小。
The iFrame Is Evil! 也可能有帮助

【解决方案2】：

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

用作标准页面元素...它们很好，因为它们是一种将内容分隔到多个页面的简单可靠的方法。特别是对于用户生成的内容，将内部页面“沙箱化”到iframe 中可能很有用，这样糟糕的标记不会影响主页。不利的一面是，如果您引入多层滚动（一层用于浏览器，一层用于iframe），您的用户会感到沮丧。正如 adzm 所说，您不想使用 iframe 进行主要导航，而是将它们视为文本/标记，相当于嵌入视频或其他媒体文件的方式。

对于脚本背景事件，通常选择隐藏的iframe 和XmlHttpRequest 来加载当前页面的内容。不同之处在于iframe 会生成页面加载，因此您可以在大多数浏览器的浏览器缓存中前后移动。请注意，到处使用XmlHttpRequest 的Google 在某些情况下也使用iframes 来允许用户在浏览器历史记录中前后移动。

【讨论】：

我认为值得一提的是，iframe 可用于将域中的页面嵌入到另一个域中的页面中。如果嵌入式页面想通过 cookie 跟踪用户并保留来自主机域的信息，那么您唯一的选择是使用 iframe，因为 JS 在主机域的控制之下。
@NicholasLeonard 一个很好的例子是，您可以使用它们来强制基于本地存储的页面缓存，方法是使索引页面成为检测子页面是否在本地存储中的脚本。然后，如果它存在，则从 localstorage 中 document.write ，如果不存在，则将 iframe 添加到该子页面。在该子页面中，有一个脚本将子页面 HTML 元素的 outerhtml 存储到本地存储中。使用此方法的一个非常好的理由是它允许您添加加载屏幕。
我不同意，但是我不能反对它，因为它是一个重要的 POV。

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

在许多情况下与他们合作后，我真的开始认为 iframe 是 web 编程中 goto 语句的等价物。也就是说，通常要避免的事情。在站点内，它们可能会有些用处。然而，跨站点，除了最简单的内容之外，它们几乎总是一个坏主意。

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

如果用于活动内容 - 承载脚本的框架 - 则存在（不同的）跨域脚本限制。有些可能会被黑客入侵，但很少会始终如一。而且，如果您的框架内容需要交互，那么超出框架就很难做到。

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

因此，尽管它们在网站中偶尔有用，但它们并不适合混搭。您可以更好地查看真正的门户和 portlet。更糟糕的是，它们是每个网络爱好者的宠儿——许多技术经理都将它们视为解决许多问题的方法。事实上，他们创造了更多。

【讨论】：

【解决方案5】：

根据我的经验，iframe 的一个积极方面是在调用第三方代码时，这可能涉及调用调用 a 的 javascript 具有 Document.write(); 命令。您可能知道，由于解析方式（DOM Parser 等），这些命令不能被异步调用。这方面的一个例子是http://sourceforge.net/projects/phpadsnew/ 我已经使用 iframe 来帮助加速我们的网站，因为有多次调用 phpadsnews 并且网站在继续呈现页面的不同部分之前正在等待响应。使用 iframe，我能够允许站点呈现页面的其他部分，并且仍然异步调用 ppads 的 Document.write() 命令。防止和js锁定。

【讨论】：

【解决方案6】：

iframe 肯定有用途。您还会如何将天气网络小部件放在您的页面上？唯一的另一种方法是获取他们的 XML 并对其进行解析，但是当然你需要条件来抛出相关的天气图形......这并不值得，但如果你有时间的话会更干净。

【讨论】：

【解决方案7】：

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

如果您允许用户在 IFrame 内导航，则链接和书签将无法按预期工作（因为您为外部页面的 URL 添加了书签，而不是 iframe 的 URL）。

【讨论】：

不得不不同意......像这样的广泛评论根本不合格。

【解决方案8】：

值得注意的是，无论用户的互联网连接速度或 iframe 的内容如何，iframe 都会导致页面下载速度出现小幅（0.3 秒左右）但明显减慢。这不是您在本地测试时会看到的。实际上，添加到页面的任何元素都是如此，但 iframe 似乎更糟。

【讨论】：

为什么？一旦主页完成加载，他们是一种让 iframe 加载的方法吗？
我不记得他们为什么这么慢；一年前我正在研究这个。可能是因为浏览器基本上为每个 iframe 创建了一个全新的渲染上下文。至于让它们在页面加载完成之前不加载，您可以使用空白 iframe，然后在页面加载完成后设置 iframe 的 src 标签。但是请注意，即使是空白的 iframe 也会减慢您的页面渲染速度，但不会降低下载速度，因此对您的用户来说，速度仍然会慢一些。
相反，在提到速度和 iFrame 时，可能会考虑讨论 CDN（内容交付网络）。考虑到 iFrame 可以并行下载资源，因此可以提高速度（取决于浏览器）。这里至少还有一个与我的立场一致的参考资料。 developer.yahoo.com/performance/rules.html
@Strixy：您指定的 URL 表明 IFrame 成本很高，即使是空白也是如此。它建议尽量减少 IFrame 的使用。使用 CDN 加速您的网站与使用 IFrame 是正交的。 CDN 可能有助于降低使用 IFrame 的成本。但是，没有 IFrame 的 CDN 比 CDN 和 IFrame 要好。
@Strixy：如果你想并行下载资源，有更好的方法。旧的热点是通过 javascript 加载所有这些东西。新的热点是使用 Service Worker，它有效地允许您使用客户端逻辑直接管理用户代理加载、预加载和缓存站点资源的方式。另一个新热点是 http/2 推送，它允许您将资源发送到浏览器，而无需等待浏览器请求它们。然而，由于 http/2 缓存是在其他浏览器缓存之后检查的，因此它通常是一个糟糕的选择。

【解决方案9】：

当您的主页以 HTTP 协议加载并且您的部分页面需要以 HTTPS 协议工作时，iFrame 可以轻松击败 jsonp。

特别是，如果您的 dataType 不是原生 json 并且需要在服务器上翻译成 json 并在客户端翻译回例如复杂的html。

所以不——iFrame 并不邪恶。

【讨论】：

【解决方案10】：

它们还不错，但实际上很有帮助。前段时间我遇到了一个大问题，我必须嵌入我的 twitter 提要，它就是不允许 md 在同一页面上执行此操作，所以我将它设置在不同的页面上，并将其作为 iframe 放入。

它们也很好，因为所有浏览器（和手机浏览器）都支持它们。只要您正确使用它们，它们就不会被认为是一种不好的做法。

【讨论】：

【解决方案11】：

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

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

【讨论】：