关于网页内容加速黑科技的趣谈

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

成都创新互联是一家集网站建设,南涧企业网站建设,南涧品牌网站建设,网站定制,南涧网站建设报价,网络营销,网络优化,南涧网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

点击链接的同时复制链接并在新的 tab 页中打开。可以看到，尽管先点击的是链接，但渲染更快的却是新 tab 中打开的页面。

有一说一

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

这个伟大又古老的特性，常常被开发者们有意无意地忽略了。多数提高加载性能的建议都归结于一点，即“展示你所拿到的东西” —— 别怕，千万不要傻傻等待一切加载完成之后再去展示内容。

GitHub 当然是关注性能的，所以他们使用服务端渲染。但在同一个 tab 下浏览页面时，他们用 JavaScript 重新实现了导航(navigation)功能，类似下面这样：

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

这违反了规则，因为在 page-data.inc 下载完成之前什么事情都没干。而服务端渲染版完全不会这样囤积内容，其内容是流式的，这样就要快得多了。就 Github 的客户端渲染来说，很多 JavaScript 代码完全减慢了渲染过程。

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

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