如何加速一个网站——web性能三方面[转载]

徐海蛟教学

Building a Shop with Sub-Second Page Loads: Lessons Learned
利用web缓存和NoSQL系统建立一个应对高访问量的快速网上商店。

• 用户满意度和转化率强相关（hard-wired），并直接影响利润。
  
  
  

如何加速一个网站

有三大驱动力影响网页应用的页面加载时间：

1. 后端处理：网络服务器需要时间来从数据库中加载数据和组装网页。
2. 网络延迟：每一个请求需要时间来从客户端传输到服务器再返回（请求延时）。考虑到平均一个网页需要超过100次请求才能完全加载，这就变得更重要了。
3. 前端处理：前端设备需要时间来渲染页面。

为了加速我们的网站，让我们逐个处理这三个瓶颈。

---

前端性能

• 前端性能的最重要因素是关键呈现（渲染）路径（critical rendering path - CRP）。它描述了浏览器对用户呈现页面的5个必要步骤：
  

  
  
  • DOM：当浏览器解析 HTML时，它会逐渐生成一个HTML标签的树状模型，名为文档对象模型（document object model - DOM）。它描述了页面的内容。
    
    
    

    html解析过程
    
    
    
    

    html解析时间
  • CSSOM：一旦浏览器接收到了全部的CSS，CSS 字节会转换为字符，然后转换为符号和节点，最后链接进树状结构上，称为CSS对象模型，它包含样式信息。
    
    
    

    参考： Google开发者--构建对象模型

  • Render Tree：CSSOM 和 DOM 是独立的数据结构，为了将DOM和CSSOM组合起来，浏览器构造了一个渲染树，它包含了页面内容和要应用的样式信息。
    
    
    
  • Layout：布局步骤计算显示在屏幕上的网页内容的实际位置和大小。
    
    
    
  • Paint：最后一步就是将布局信息逐像素点绘制到屏幕上。
    
    
    

    参考： Google开发者--渲染树构建、布局及绘制

• 单独的每一步都是相当直接的，是步骤之间的依赖关系使得事情变得复杂，并限制了性能。DOM和CSSDOM的构建通常具有最大的性能影响。
  下图展示了关键呈现路径以及用箭头表示的等待依赖关系：
  

  
  
• 在加载完CSS并构建完整的CSSOM之前没有东西会显示给客户端。因此，CSS被称为渲染阻塞，即CSS 被视为阻塞渲染的资源。

  参考： Google开发者--阻塞渲染的 CSS

• JavaScript（JS）更是雪上加霜，因为它可以访问和更改DOM和CSSOM。这意味，一旦一个脚本标签在HTML中被发现，DOM构建将会暂停并向服务器请求该脚本。一旦脚本被加载它也不能被执行，必须等到所有的CSS被获取并且CSSOM被构建完成。在CSSOM构建完成后，JS被执行，比如下面的例子，它会访问并修改DOM以及CSSDOM。只有这之后，DOM的构建才会继续，页面才会被展示给客户。因此，JavaScript是所谓的解析器阻塞。

  参考： Google开发者--使用 JavaScript 添加交互

Example of JavaScript accessing CSSOM and changing DOM:

<script>
   ...
   var old = elem.style.width;
   elem.style.width = "50px";
   document.write("alter DOM");
   ...
</script>

• 此外，JS甚至可以比这更有害。比如类似这样的jQuery插件，它将访问计算好的HTML元素的布局信息，然后开始一次又一次修改CSSOM直到它希望的布局。其结果是，浏览器不得不一次又一次重复JS的执行、渲染树构建和布局，用户只有等待这些操作完成才能真正看到显示。

• 为了优化CRP（关键呈现路径），有三个基本的概念：

  1. 减少关键资源数量：关键资源是那些页面首次渲染所需要的资源（HTML，CSS，JS文件）。通过使用内联CSS和JS来渲染网页上无需滚动即可见的部分（称为Above the fold，工具），这些能被极大地减少。更多的JS和CSS应当被异步加载。不能异步加载的文件可以级联成一个文件。
  2. 最小化字节数：CRP中加载的字节数可以通过删减和压缩CSS，JS和图片来大大减少。
  3. 缩短关键呈现路径长度：CRP长度是 为了获取所有关键资源从客服端到服务器的连续往返的最大数。减少关键资源以及最小化它们的大小（大文件需要多次往返获取）都可以缩短它。进一步，将CSS包含在HTML的头部，将JS放在HTML的底部也会有所助益，因为JS的执行将会阻塞于CSS的获取和CSSDOM的构建，无论如何也会阻塞DOM的构建。

• 此外，浏览器缓存也是非常有效的，应当始终使用它。它适用于全部三种类型的优化，因为缓存的资源不用再从服务器加载。

• CRP优化的整个主题是相当复杂的，尤其是内联，串联和异步加载可以毁掉代码的可读性。值得庆幸的是有很多伟大的工具乐意为你做这些优化，它们能被集成进你的构建和部署链。你应该好好地看看以下工具：
  • 性能测试（Profiling）：GTmetrix用来测量页面的速度， webpagetest用来分析资源，Google的 PageSpeed Insights可以生成针对你的网页如何优化CRP的具体提示。
  • 内联和优化（Inlining and optimization）：Critical可以很好地自动化内联第一眼可见区（above the fold）的CSS并异步加载剩余的。processhtml串联你的资源。PostCSS进一步优化CSS。
  • 删减和压缩（Minification and compression）：tiny png 用来压缩图片，UglifyJs和 cssmin用来删减，或者用Google Closure做JS优化。
• 使用这些工具并做一点必要的工作，你可以达到良好的前端性能。
  
  
  

  Google分析Insights

网络性能

• 当谈到页面加载时间时，网络延迟是最重要的因素，它也是最难优化的。但是在我们进入优化之前，让我们来看看一次浏览器初始请求的明细：
  
  
  
• 当我们在浏览器中输入https://www.thinks.com/然后回车，浏览器开始一次DNS查询来找到域名相应的IP地址。每一个独立的域名都需要一次查询。
• 收到IP地址后，浏览器发起与服务器的TCP连接。TCP握手需要2次往返（TCP快速打开只需要1次）。使用安全的SSL连接，TLS握手需要额外的2次往返（TLS False Start 或 Session Resumption只要1次）
• 初始连接之后，浏览器发送真正的请求并等待数据传回。这个第一字节接收时间（time to first byte）主要受到两方面影响：一是客户端和服务器的距离，二是服务器渲染页面所需要的时间（包括session查找，数据库查询，模板渲染等等）。
• 最后一步就是下载资源（这个例子中是HTML），潜在地需要多次往返。特别是新的连接，通常需要许多往返，因为最初拥塞窗口很小。这意味着TCP并没有在一开始就使用全部带宽而是随时间增加带宽使用（TCP congestion control）。传输速度受慢启动算法控制，该算法每次往返后增大一倍拥塞窗口直到丢包情况发生。因此，在移动设备和Wifi网络中丢包会产生较大的性能影响。
• 另一个需要记在心上的是：在HTTP/1.1下，你只能得到6个并行的连接（如果浏览器遵循原始标准只有2个）。因此，你最多只能并行请求6个资源。
• 为了得到一个网络性能对于页面速度的重要性的直观认识，httparchive 网站上有许多数据。例如，一般的网站要在超过100个请求中加载约2.5MB的数据。
  
  
  
• 所以网站用很多小请求来加载许多资源，但是网络带宽会不断增加。网络物理结构的演进会拯救我们，对不对？嗯，这不是真的。。。
  
  
  

  From  High Performance Browser Networking by Ilya Grigorik
• 事实证明，超过5Mbps再增加带宽对页面加载时间并没有多大影响。但是缩短个体请求延时压低网络加载时间。这意味着带宽成倍增长带给你相同的加载时间，而删减一半的延迟会让你的加载时间减半。
• 因此，如果延迟是网络性能的决定性因素，我们能对它做些什么呢？
  • 持久连接（Persistent connections）是必备的。如果你的服务器在每次处理请求后关闭连接，浏览器不得不一次又一次地重新执行握手和TCP慢启动，没什么比这更糟的了。
  • 避免重定向（Avoid redirects）避免可能的重定向因为它们会减慢你的初始页面加载速度。例如始终链接完整的url（www.thinks.com之于thinks.com）。
  • 如果可能的话使用HTTP/2。它配备了服务器端推送(server push)来对单个请求传输多个资源，报头压缩(header compression)来压低请求和响应的大小 以及 请求流水线（pipelining ）和复用（multiplexing ）技术在单个连接中发送任意并行请求。使用服务器推送，举例说就是，你的服务器可以在传输html之后紧接着就推送网站所需的CSS、JS而不需要等待真正的请求。
  • 设置明确的缓存头（caching headers ），为你的静态资源（CSS，JS，静态图像如logo）。这样你可以告诉浏览器缓存这些资源多长时间，何时再验证。缓存潜在地帮你节省了许多往返和字节下载。如果没有明确的头标签设置，浏览器会做启发式缓存（heuristic caching），这会比没有好但远不是最佳。
  • 使用内容分发网络（Content Delivery Network - CDN）来缓存图像，CSS，JS和HTML。这些分布式缓存网络能显著地减少你与用户的距离，从而快速传递资源。 它们还加速了你的初始连接，因为可以使用一个用户附近的CDN节点来做TCP和TLS握手。
  • 考虑使用一个小的初始页面、异步加载额外部分的方式，来做单页应用（Single-Page App）。这样你可以使用可缓存的HTML模板，在用户浏览过程中用小请求来加载动态数据并且只更新页面的一部分。
• 总的来说，当涉及网络性能时，有几个该做和不该做的注意事项，但是限制因素总是往返数和物理网络延迟的组合。征服这个限制的唯一有效办法是让数据靠客户更近。Web缓存正是这么做的，但它只适用于静态资源。
• 对于Thinks网站，我们遵循了上述方针，使用了Fastly CDN以及激进的浏览器缓存方案——即使对动态数据也是，并使用了一种新型的布隆过滤算法（Bloom Filter algorithm）来保持缓存数据一致。
  
  
  
  
  浏览器缓存（见上图）中对重复页面加载不能提供的请求仅仅是两个对谷歌分析API的异步调用和一个对初始HTML（从CDN中获取到）的请求。因此，重复页面的加载几乎是一瞬间。

后端性能

• 对于后端性能，我们需要考虑延迟和吞吐量。为了获得低延迟，我们需要最小化服务器的处理时间。为了维持高吞吐量和应对负载峰值，我们需要采用横向拓展（horizontally scalable）的架构。如果不考虑太多的细节——设计决策影响性能的空间是巨大的——这些就是最重要的组件和属性了：
  
  
  

  Components of a scalable backend stack: load balancers, stateless application servers, distributed databases
  • 首先，你需要负载均衡（load balancing）（例如亚马逊的ELB或DNS负载均衡）来分配传入的请求到你的多个应用服务器。它也应该实现自动伸缩（automatic scaling ）来在需要时产生额外的应用服务器，以及实现故障转移（failover ）来更换坏掉的服务器并将请求重新路由到健康的服务器。
  • 应用服务器应尽量减少共享状态（minimize shared state ）来让协同最小，并使用无状态的会话处理（stateless session handling）达到自由的负载平衡。此外，服务器应当保证代码和IO的效率来最小化服务器处理时间。
  • 数据库也需要承受负载峰值，实现尽可能少的处理时间。同时，它们也需要对模型建立和数据查询具有足够的表现力。目前有大量的可拓展数据库（特别是NoSQL），每个都有自己的一套权衡方案。更多细节可以看我们关于这一主题的调查和决策指导：NoSQL Databases: a Survey and Decision Guidance。
• Thinks 网上商店在Baqend上构建，它使用了如下的后端堆栈：
  
  
  

  Baqend’s backend stack: MongoDB as the main database, stateless application servers, HTTP caching hierarchy, REST and the JS SDK for the web frontend
  
  主要使用的数据库是MongoDB。为了维持我们即将到期的布隆过滤器（用于浏览器缓存），我们使用Redis因为它的高写入吞吐量。无状态应用服务器（Orestes Servers）提供了后端特性的接口（档案托管，数据存储，实时查询，推送通知，访问控制等）并处理动态数据的缓存一致性。它们从CDN得到请求，CDN也充当一个负载均衡器。网站前端使用一个基于REST API的JS SDK来访问后端，后端自动利用了完整的HTTP缓存层次结构（HTTP caching hierarchy）来加速请求，并保持缓存数据达到最新。

负载测试

• 为了测试Thinks网上商店在高负载下的表现，我们用了2个位于法兰克福的t2.medium型号的AWS实例上的应用服务器。负载测试的构建使用了JMeter，测试执行在IBM soft layer上的20台机器来模拟在15分钟内的20万用户访问以及网站浏览。20%的用户（4万）被配置成执行一个额外的支付过程。
  
  
  
• 我们发现在我们的支付实现中有几个瓶颈，比如我们不得不从库存的乐观更新（用findAndModify实现）切换到MongoDB的部分更新操作（inc）。但是在这之后，我们的服务器能够良好地处理负载，平均请求延迟为5ms。
  
  
  
• 所有负载测试组合起来产生了约1000万的请求，传输了460GB的数据，达到了99.8％的CDN缓存命中率。
  
  
  

总结

• 总之，良好的用户体验建立在三大支柱上：前端、网络和后端的性能。
  
  
  
• 前端性能在我看来是最容易实现的，因为已经有很好的工具和一堆容易遵循的最佳实践。但是仍然有许多网站没有遵循这些最佳实践，根本不优化它们的前端。
• 网络性能是页面加载时间最重要的因素，也是最难优化的。缓存和CDN是最有效的优化方式，但是即使是对静态内容也需要可观的努力。
• 后端性能依赖于单服务器性能和你在机器之间分配工作的能力。横向扩展特别难以实现，必须要在一开始就加以考虑。很多项目把可伸缩性和性能作为事后的想法，当它们的业务增长时遇到了大麻烦。

文献与工具建议

• 有许多关于网络性能和可扩展系统的好书。Ilya Grigorik 的High Performance Browser Networking几乎包含了一切你需要知道的关于网络和浏览器性能的知识，而且它的持续更新版本是免费在线阅读的！Martin Kleppmann 的Desining Data-Intensive Applications仍然是早期版本，但已跻身该领域内最好的书了。它涵盖了大部分可拓展后端系统背后的基础，非常详细。 Lara Callender Hogan 的Designing for Performance全是关于构建具有良好用户体验的快速网站，包含了许多最佳实践。

• 同时，网上也有许多值得考虑的优秀指导，教程和工具。从对初学者友好的Udacity课程Website Performance Optimization到谷歌的developer performance guide，以及许多分析工具如Google PageSpeed Insights, GTmetrix 和 WebPageTest。

未完

• Newest Developments In Web Performance —— Web性能的最新发展
  Accelerated Mobile Pages

其它

The Website Obesity Crisis
Chrome DevTools Overview