数周前，在伦敦 Heathrow 机场等飞机的余暇中，我趁便处理了一些工作上的工作。不经意间发明 Github 在机能方面的一些问题，颇为诧异。经由过程新 tab 打开的页面，其加载速度竟然比直接点击链接打开的页面要快。

点击链接的同时复制链接并在新的 tab 页中打开。可以看到，尽管先点击的昵啻接，但衬着更快的倒是新 tab 中打开的页面。

有一说一

页面加载的时刻，浏览器会接收收集数据流，并将其输出(pipe)给 HTML 解析器，HTML 解析器再将数据输出到文档。这意味着，页面是边加载边衬着的。对于一个 100k 的页面来说，浏览器很可能在接收到 20k 数据的时刻就开端衬着出一些可用内容了。

// …一堆从新实现浏览器导航功能代码… 
const response = await fetch('page-data.inc'); 
const html = await response.text(); 
document.querySelector('.content').innerHTML = html; 
// …加载更多从新实现导航功能的代码…  

这个巨大年夜又古老的特点，经常被开辟者们有意无意地忽视了。多半进步加载机能的建议都归结于一点，即“展示你所拿到的器械” —— 别怕，切切不要傻傻等待一切加载完成之后再去展示内容。

GitHub 当然是存眷机能的，所以他们应用办事端衬着。但在同一个 tab 下浏览页面时，他们用 JavaScript 从新实现了导航(navigation)功能，类似下面如许：

这违背了规矩，因为在 page-data.inc 下载完成之前什么工作都没干。而办事端衬着版完全不会如许囤积内容，其内容是流式的，如许就要快得多了。就 Github 的客户端衬着来说，很多 JavaScript 代码完全减慢了衬着过程。

这里我仅仅只是拿 Github 举例子 —— 这种反模式在单页应用中比比皆是。

在页面之内切换内容可能确切有些好处，特别是存在大年夜量脚本的情况下，无需从新履行全部脚本即可更新内容。但我们可否在不放弃流的情况下完成如许的工作呢?我曾经常说 JavaScript 没有办法对流进行解析，但其实照样有的……

<iframe> 和 document.write 大年夜法

// 创建 iframe: 
const iframe = document.createElement('iframe'); 
 
// 添加到 document 中 (记得隐蔽起来): 
iframe.style.display = 'none'; 
document.body.appendChild(iframe); 
 
// 等待 iframe 加载: 
iframe.onload = () => { 
  // 忽视其他 onload 操作: 
  iframe.onload = null; 
  // 添加一个虚拟标签: 
  iframe.contentDocument.write('<streaming-element>'); 
  // 引用该元素: 
  const streamingElement = iframe.contentDocument.querySelector('streaming-element'); 
  // 将该元素大年夜 iframe 中掏出，并添加到文档中: 
  document.body.appendChild(streamingElement); 
  // 写入一些内容 —— 这里应当是异步的: 
  iframe.contentDocument.write('<p>Hello!</p>'); 
  // 持续写入内容，直到完成: 
  iframe.contentDocument.write('</streaming-element>'); 
  iframe.contentDocument.close(); 
}; 
 
//  iframe 初始化 
iframe.src = '';  

固然 Hello! 是写到 iframe 中的，但它却竽暌箍如今了父级的 document 中!这是因为解析器保护了一个 敞开元素栈(stack of open elements)，新创建的元素会被压入栈中。就算我们把 <streaming-element/> 元素移出到 iframe 外面也不影响，就是这么率性。

　　推荐阅读

　　改区域就真的能增强路由器的Wi-Fi覆盖吗？

比拟之下无线路由器厂商给出的方檀卷更直接更有效了，今朝市场上各类“穿墙王”路由器确切有着比通>>>详细阅读

本文标题：关于网页内容加速黑科技的趣谈

地址：http://www.17bianji.com/lsqh/37898.html

 1/2    1