iframe标签在网页中可以创建一个内嵌框架，通过指定src属性来调用另一个网页文档的内容。和frameset一样，用它来对网页结构进行拆分以使网页的某些部分保持公用，但绝对frameset对整个网页进行框架结构的拆分来说，iframe愈加灵活，可以内嵌到网页的任意地方。由于iframe使用上的这个特点，在一些网页中得到了大量运用，也导致了一些不适宜的滥用。爱易网任务室将分析一下iframe这个网页元素常见的几种使用方式。

1. 制造“无刷新”呼应页面组件，作为异步交换数据的一种处理方案。这是晚期不使用Ajax来异步发送请求的一种替代方法，通过在页面上设置不可见的iframe元素，并将其src属性指向需求发送请求的页面地址来发送请求，同域下可以再对前往的页面进行DOM解析来获取数据。另外一个好处在于绕开了Ajax的沙箱安全模型，可以顺利发送跨域请求获得数据，只是这种情况下取不到iframe的document对象。由于它的这个特点，在某些需求跨域请求数据的网页中仍然有使用。这种无刷新是指在数据交换过程中父页面不刷新而继续对用户操作保持呼应，实际进行数据交换而被锁定的是父页面上内嵌的iframe页面。这个内嵌iframe页面依据需求设置为可见或不可见都可以，并不会影响父页面中的其他元素对用户的呼应。这种效果类似Ajax的无刷新，但可以看出其机制是完全不同的。即便Gmail作为Ajax使用的典范，也结合了很多iframe来实现其优越的功用与用户体验。
2. 优化页面的一种方式。使用iframe可以并行加载脚本，处理加载缓慢的第三方内容如图标和广告等的加载问题。Google的广告平台AdSense即通过iframe在用户的站点上投放广告分享收益，查看分析国内门户首页上的广告代码也能看到这类技术。也可用隐藏的iframe在网络压力较小的时候来预加载比较大的文件到缓存，以便其他页面使用。预加载的概念可以用firebug分析google首页，在body标签里可以看到：
   

   onload=”document.f.q.focus();if(document.images)new Image().src=’/images/nav_logo4.png’”

   这样一句代码，加载的图片nav_logo4.png在首页并没有用到，但搜索结果列表等其他页面使用此图片的时候只需求从缓存读取，不需求重新下载了。

3. 作为针对IE6浏览器中浮动层遮不住select控件和flash元素的一种修正(hack)方式。Web2.0时代lightbox（又或thickbox）技术以它良好的体验与清新的视觉感受成为一种流行效果。这种技术实际上是用一个绝对定位的浮动层覆盖到原有页面上，用以呈现文本信息、图片、表单或其他任意页面元素，替代了晚期web开发中常使用弹出浏览器窗口或者浏览器本身的音讯、输入控件来与用户进行交互的方式。旧无方式中，弹出新窗口的脚本经常会被浏览器的广告拦截系统拦截，而浏览器本身的音讯控件由于会打断浏览器进程，导致浏览器中本页面以及其他通过多标签进行浏览的网页全部被锁死而遭到用户体验研讨者的诟病。作为对本人有严厉要求的一线web前端开发人员，在动手实现lightbox效果的过程中一定会遇到这个问题，绝对定位的层在IE6中遮盖不了网页上的select控件和flash，即便款式设置较高的z-index值也无济于事。这是由于select元素在IE6中是一个窗体级别的元素，它的优先级大大高于其他所有的html标签，只要同样窗体级别的iframe才能遮住它。因此开发者们研讨出，把浮动层放到iframe中，或者在浮动层中放置一个iframe就可以处理此问题了。所幸此问题在IE6当前的IE升级版本中得到了修正，但对于还拥有50%+市场占有率的IE6来说（统计截至发文时间），这个处理方案仍然有理想意义。

除了以上三种使用，对于iframe元素也常见一些不恰当的运用。例如在页面中嵌入过多的iframe框架，通过指定框架外链接标签的target属性在点击时来更新iframe，这种用法和frameset类似，达到共用导航的目的。初衷是好，但其中的弊病也毋庸置疑。这样会导致一个页面请求过多，上文所提及的雅虎团队《Best Practices for Speeding Up Your Web Site》一文中就明确优化页面需求“使iframe的数量最小”，归纳了其三种弊病：

1. 即便内容为空也会形成资源损耗(包括客户端、服务器端)；
2. 阻滞页面onload事件触发（“Blocks page onload”，又有译作“会阻止页面加载”，此处存疑）
3. 没有语义（SEO是网站营销的重要组成部分）

在XHTML1.0的下一个版本HTML5中，由于frameset标签对网页可用性方面产生的负面影响，没有对它提供支持，这也从侧面说明一些问题。

另外，由于内嵌的iframe不能自动顺应其内部内容大小，为了保持页面显示的完整性，还需求编写一段JavaScript脚本来依据iframe内容的变化即时调整其大小。分散的多个请求再加上需求JavaScript脚本来修正更添加了多iframe页面系统运转的风险。那么，有没有什么好的方法能保持部分页面内容公用呢？服务器端早就给我们提供了处理方案，ASP中的include，PHP中的require方法，都是用来包含一段已有的代码到程序中，这样同样能实现页面的某个部分（如导航菜单、页脚）公用，但是运转之后作为一个完整的页面输出，无效地减少了客户端请求，同时也不存在iframe的高度自顺应的问题。