很好的理由为什么不在页面内容中使用Iframe [英] Good Reasons why not to use Iframes in page content
问题描述
好的，我正在寻找一些很好的理由，不要在页面内容中使用iFrames。我的朋友为我们的聊天室设置了一个iFrame并加载了一个html页面，而不是仅仅使用 ajax 来加载需要的参数并且长时间轮询请求。一旦我们有了我们的参数，我们就可以用我们的内容填写一些div。
我最大的理由
-
为什么要同时加载两个页面
需要更多编码才能注入iFrame >
有谁知道可能会出现的其他可能的冲突和问题吗？我知道，一段时间后，iFrames被认为会被弃用，然后他们跳回到网站。
ps我不确定这是否应该在SO或MSO中，如果需要的话，我可以将其移动
来源： http://www.rwblackburn.com/2012/07/iframe-evil/
因此，看起来每一份工作我都在做，同一个话题就出现了。有人会说，只是使用iFrame。然后，我需要走旧的疲惫之路，为什么这不是一个好主意。
那么，这篇文章对我来说有点功利。我希望在一个地方放下所有原因，iFrames不是一个万能的解决方案，这样我可以在未来节省一些时间，只需将人员指向此URL即可。因此，当我细化这些要点时，我可能会更新这篇文章。如果你喜欢，请随意使用这个帖子来达到同样的目的，并且请将我错过的任何建议或积分发布到我的Twitter帐户（@rwbDev），如果我在这篇文章中添加了一点，我一定会相信你。
现在，让我清楚一点。 iFrame确实有一个有效的目的。我实际上多次使用iFrames，并取得了巨大成功。问题在于人们倾向于使用它们来避开糟糕的体系结构，或者只是简单地解决问题。根据我的经验，这通常只是在一个更大的问题上交易一个小问题，往往不是不必要的折衷。我将在下面介绍这两点。
对SEO不利。这是避免使用iFrames最常见的原因之一。一些搜索引擎可能在iFrames中引用的页面上遇到困难。这对网站或网页的搜索排名有多大影响尚不完全清楚。然而，我所讨论过的大多数专家都认为这肯定会有一些影响。看看这个有趣的表单帖子。有关SEO如何工作的详细信息以及这样的设计决策的影响，我会建议查看seomoz.org。这当然不是一个问题，如果SEO不是您的网页或应用程序的关注。例如，需要登录的应用程序（无论如何，搜索引擎都无法访问登录背后的所有页面）。
*注意（2013年6月6日添加）：最近的测试显示，搜索引擎实际上可能会跟踪iFrame中的链接。这意味着iFrame的SEO影响远远小于过去的影响。目前尚不清楚是否没有影响，不同的搜索引擎在这方面可能会有不同的表现。
链接/书签除非您介绍额外的JavaScript，用户将无法直接获得链接到iFrame内的链接。这包括有人可能通过电子邮件发送给朋友，书签或搜索引擎结果中出现的页面的链接。想象一下你的用户转到你的页面，并且一些内容在一个iFrame中。他们点击iFramed内容中的链接。如预期的那样，该内容将保留在iFrame内。现在，您的用户可以在iFrame中找到他们已浏览的内容，并希望将其发送给朋友。但是在他们的浏览器中复制URL不起作用，那只会将该朋友发送到初始页面，原始内容显示在iFrame中。有些脚本可以解决这个问题。我已经实施了几次自己（在我没有选择的情况下）。但是，这些经常会引入一些自己的问题，并且经常会遇到跨浏览器兼容性问题。通常它也是正确的。同样，根据您的站点或应用程序的需求，这可能不是问题，但这对大多数站点来说都是一个大问题。
调试困难。 这是人们经常忽视的一个。如果你有一个健壮的应用程序，其中包含复杂的jQuery，Ajax和其他很酷的东西 - iFrames可以使调试更加困难。错误是发生在外部页面还是框架内的页面？浏览器开发人员工具可以帮助解决这个问题，但即使这些工具并不总是清楚在处理iFrame时出现的问题。当页面位于iFrame中时，您可能会惊讶地发现一个错误的复制频率，但在iFrame之外加载时工作得很好。这是任何网站的问题。但对于广泛使用iFrame的网站尤其如此。对于一个系统来说，移动的部件越多，诊断问题就越困难。
没有真正的性能提升。偶尔我会找到想要使用iFrame的人，因为他们觉得这会增加他们网站的性能。他们通常会这样认为，因为这样可以避免在网站分页时不得不重新加载站点的页眉/页脚/菜单。往往不是，反之亦然。事实上，根据我的经验，与修复应用程序的体系结构相比，它从来没有带来性能上的提升。首先，考虑浏览器会缓存图片，CSS和JS文件。所以无论如何这些都不会重新加载每一页。但更重要的是，正在思考这些问题的人们往往将iFrames看作是穷人的AJAX。但是，iFrame分页的内容几乎总是比真正的AJAX调用更重要，它使用XML或JSON来加载和刷新页面内容的一小部分。
它很难保持稳定。我的一个大型网站广泛使用iFrame。我不确定NDA在哪里适用，因此我不会链接到他们的网站以保证安全。他们经常使用它们，并且拥有所有的脚本和花哨技巧（理论上）可以避免使用iFrames的普通缺点。然而，由于iFrame的大量滥用和过度使用，仍然存在频繁出现在他们的网站上的问题和错误。在论坛，LinkedIn，Twitter等网站上也发现了频繁的客户投诉，这些问题是由他们造成的。刚刚我跳到他们的网站，并在几分钟内发现一个页面，由于iFrame问题给我一个错误。这些都是聪明的人，他们很了解iFrame的问题。然而，几年后，即使他们继续与它搏斗。当iFrames被滥用，就像他们在这个网站上一样，没有多少花哨的脚本可以完全解决将不可避免地会出现的问题。
Ok so I am looking for some good reasons as to not use iFrames in page content. My friend who is set on using an iFrame for our chatbox and loading an html page instead of just using ajax to load the parameters that are needed and long polling the request. Once we have our parameters we then fill in some divs with our content.
My Biggest Reasons
Why load two pages simultaneously
More coding is needed to inject to the iFrame
Does anyone know of any other possible conflicts and issues that could potentially arise? I know that a while back that iFrames were suppose to be deprecated then they leaped right back up to websites.
ps I wasn't sure if this should go in SO or MSO if need be I can move it
Source: http://www.rwblackburn.com/2012/07/iframe-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.
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 know. 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. For 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 then 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.
Its 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.
这篇关于很好的理由为什么不在页面内容中使用Iframe的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
