Web业务性能优化技术总结

小鱼儿 2022-09-30 03:56 134阅读 0赞

## 前言 ##

Web业务的性能优化是一个系统工程，既有深度，又有广度。以下所简称性能均特指Web业务性能。  
技术的广度上，主要从大背景下考虑到其各个相关方，基于共同的数据指标发掘和评估方案。  
技术的深度上是一个渐进和迭代的过程。可以从性能的本质展到目前各端的主要优化方向。

## 性能的本质 ##

性能的本质是**快速传播**, 要素是**内容(数据)和流程**，效果是：**完备、快速**。完备不是完整，而是接受的信息要一致，没有歧义。流程是内容处理的过程和方法。  
![process][]

流程从广义上看来源于后台服务器，以网络和客户端为媒介，以页面形式到达用户。落到各端，又可以再次细分为不同的内容和流程，层层拆解。  
性能优化就是保障快速传播内容，可以概括为四个流程和三类方法。其中四个流程是指:

*  衡量: 设定指标，建立监控。
 *  识别: 识别和梳理出整体到局部对各个层级的内容(数据)及流程。
 *  实施: 针对性的进行优化。
 *  评估和监控: 通过数据评估是否达成预期，并做定期监控。

各端实施前先理解全业务视角下的内容和流程，以及各自内部的内容和流程。以下为目前识别出的各端内容(数据)及流程:

<table> 
 <thead> 
  <tr> 
   <th>各端</th> 
   <th>内容(数据)</th> 
   <th>流程</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>整体</td> 
   <td>页面资源</td> 
   <td>后台服务 (图片服务) -&gt; 浏览器(客户端)</td> 
  </tr> 
  <tr> 
   <td>后台</td> 
   <td>页面资源<br>列表内容<br>页端接口<br></td> 
   <td>1.架构 (接入/Docker/爬虫/CDN)<br>2.发布上线流程<br>3.内容请求及响应流程(可继续细分, 涉及部署)<br>……</td> 
  </tr> 
  <tr> 
   <td>图片服务</td> 
   <td>图片</td> 
   <td>1.图片请求接口<br>2.图片上传发布<br>……<br></td> 
  </tr> 
  <tr> 
   <td>页端</td> 
   <td>主文档<br>静态资源<br>动态资源<br></td> 
   <td>1.前端渲染流程<br>2.模块加载<br>3.懒加载<br>4.统计打点<br>……</td> 
  </tr> 
  <tr> 
   <td>客户端</td> 
   <td>统计数据</td> 
   <td>业务逻辑</td> 
  </tr> 
  <tr> 
   <td>Web Engine</td> 
   <td>页面资源<br>后台响应数据<br>网络性能数据<br>统计数据</td> 
   <td>1.网络连接<br>2.加载、解析、排版、渲染<br>3.JS执行<br>4.业务功能 (广告过滤、后台省流省电、统计……)<br>……</td> 
  </tr> 
 </tbody> 
</table>

定义出各层各端的内容及流程后，就可以着手进行优化。

## 选择优化时机 ##

当我们发现一个问题点，如果确定是不是当时下手解决？　这个还需要在经验中总结提炼．目前总结的原则有两条:

*  优先解决关键路径上的问题．  
    
    
     *  如果解决的问题，不在关键路径上，收益的评估可能不准，如果上线了，其实际效果也往往会被低估．如CSSOM优化．
     *  对于不确定的问题，可以使用小步快走的方式，进行快速验证．如中转直连策略．
     *  避免微优化。微优化往往会掩盖一些更核心的问题。
 *  综合从各端和多维度考虑解决方案．  
    
    
     *  如果单从一端或一点考虑优化，容易出现边优化边引入问题的情况．这时可以通过开放讨论和实验室验证的方式减少影响．如页面之前一次主档精简．

## 性能优化方法 ##

性能的优化方法上可以概括为: **简(化,减法)、分(离)、预(处理)**三类。每一种方法都可以分别从内容和流程上展开典型的方法:

<table> 
 <thead> 
  <tr> 
   <th>方法</th> 
   <th>目标</th> 
   <th>内容侧</th> 
   <th>流程侧</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>简化</td> 
   <td>尽量少(小)，直至没有!!!</td> 
   <td>1.去除冗余信息 (请求头，内容…)<br>2.去除无用的CSS/JS等资源<br>3.压缩或裁剪<br>4.缓存及Combo可以减少请求<br>5.图片优化图片出口流量<br></td> 
   <td>1.去除不必要的处理和计算<br>2. 使用更好的处理算法 (查表)<br>3. 动态策略减少中转或直连请求<br>4. 不必要的业务逻辑<br>5. 后台优化存储及服务器布署<br>6. SPA或模板的应用<br>7.PRPL原则的应用</td> 
  </tr> 
  <tr> 
   <td>分离</td> 
   <td>区分不同属性，更加有针对性。</td> 
   <td> 动态内容与静态内容的分离<br>2. 首屏内容(资源)的分离<br>3. 主文档与正文内容的分离<br>4. 概要内容（包括低质量图片）与精细内容的分离 </td> 
   <td> 首屏渲染与懒加载<br>2. 同步请求改为异步请求<br>3. 前期不阻塞加载，中期不阻塞渲染<br>4.区分不同网络的优化 </td> 
  </tr> 
  <tr> 
   <td>预处理</td> 
   <td>重要的内容和事，提前准备。</td> 
   <td>1.预加载(主文档及子资源)<br>2.预下发</td> 
   <td>1.预热<br>2.预DNS解析<br>3.预连接<br>4.连接复用(包括HTTP2)</td> 
  </tr> 
 </tbody> 
</table>

## 技术演进和整合 ##

### 演进与迭代 ###

从性能优化上，虽然概括了四个过程和三类的手法，但整体却是一个由各端所在技术领域共同推动的迭代过程。  
首先各端的技术领域有很大的交集，大致可以体现为:  
![technology\_stack][technology_stack]

但是各端所在的技术领域都有不同的技术演进，各自又都有相应的解决方案，其中以前端和浏览器内核的发展最为活跃,且有各有明显的分段:

<table> 
 <thead> 
  <tr> 
   <th>端</th> 
   <th>技术要点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>后台</td> 
   <td>1.由于操作系统可以定制，一是借助Linux系统协议栈上的优化，包括HTTP2/QUIC，以及在TCP栈上的优化，二是改进TCP栈的性能、HTTPS的性能、通过改进压缩算法提高数据传输性能等。<br>2.使用更加精细化的架构和系统来承载服务，同样存在通过细化识别出优化点的过程，包括CDN的部署等。</td> 
  </tr> 
  <tr> 
   <td>页端</td> 
   <td>自Steve Souders以YUI为始，定制了一套相关的基础规则，包括了Head中的JS, CSS的位置，Cache、Cookies等，并且固化到了YSlow这个工具内。参考&lt;&lt;高性能建站指南&gt;&gt;。<br><br> 后面又基于Web App发展趋势而有了SPA (Single Page Application,也有称为模板页)模式。同时Responsive Web Design的提出，也有了一套相对应的优化策略。因为前端技术的发散和快速演进的特点，对于将工程化的需求更高。<br><br>FaceBook目前可以算是前端技术的领导者, 提出不少问题的前端技术方案，如Instant Article, Network Quality Classifier。特别是RN代表的native化方向，为前端技术应用带来了更大的空间。</td> 
  </tr> 
  <tr> 
   <td>浏览器</td> 
   <td>浏览器的发展前以Firefox和WebKit为马首，现以Chrome为主导。Chrome之前，浏览器侧重于H5/CSS3/JS等技术体系的支持。自Chrome始，除了继续将技术体系演进到Web Platform外，也再进一步将前端开发者的需求考虑到开发方向上来(见BlinkOn5资料)，以开发页面的真实需求驱动Web Platform发展，演进了PWA, AMP等技术，也提出RAIL模型，来统一页端和浏览器内核的目标。<br><br>在相同问题，Chrome和Facebook往往有不同的方案，比如AMP对应Instant Article, NQE对应Network Quality Classifier。与Facebook的Native化方向相比，Google则是以<b>PWA(Progressive Web App)</b>推动H5达成Native体验。<br><br><i><em>针对页端的YSlow, Chrome也在DevTools中提供更为强大的Audit (可以理解PageSpeed Insights增强版)，以及评价工具Lighthouse。</em></i><i>在网络的层面，和服务器不同的是，Chrome提出了HTTP2(SPDY)和QUIC (UDP)，解决网络上问题。</i></td> 
  </tr> 
 </tbody> 
</table>

从整体看浏览器和页端的技术演进，我们可以看到两个清晰的分段:

*  关注于单项(维度)技术的优化。往往可以从一个Check List的方式入手。比如: 优化点挖掘, 性能优化Check List。
 *  体系化、多维度的技术创新。PWA和RN都不能算是技术创新，因为他们背后的技术原型都存在很久了，但是他们经过体系化后，被赋予了一个大愿景，再被不断完善充实，解决一个普遍性的问题。  
    \*后台(服务器侧)因为个人能力和经验的限制，没有看到这个分界线。如果有，欢迎补充。

这两个分段基本也对应到目前性能优化的迭代阶段 (也可能各有若干迭代周期)：

*  基于现有技术架构进行各点(面)的优化。  
    
    
     *  这是最重要的基础，往往容易因关注新技术，而被忽略。从业务开发的角度，最好是从一开始就能应用工具和Check List不断纠偏。
     *  这一阶段的细化，可以参考: 项目总结 - 过程。
 *  应用体系化的技术改造，突破技术瓶颈。

## 技术整合 ##

虽然Facebook和Google Chrome在技术方向有不同的选择，这是他们作为技术领导者的责任。但是从Web业务上看，技术整合才是必然的，包括Facebook和Google。一个代表前端有控制更多的需求，一个代表Web平台，支持更多的控制，两者的目标并不冲突。  
从技术整合的角度来看，需要结合业务特点进行全局的技术方案评估和平衡。比如直出和前端渲染的选择，就还需要考虑到业务单位间的协作和运营的需求。

## SPA与模板页 ##

下面以SPA作为一个技术整合评估的示例。在实际业务场景，我们遇到了以下几种提法:

*  Single Page Application (SPA)
 *  本地模板页
 *  主文档缓存和\#版本  
    后者基本一致，SPA与他们的差别就在于可能不需要缓存来实现。所以后两者可以理解为SPA的一种收益较大的实现。

它们的收益来源于：

*  主文档缓存或本地模板页减少主文档请求和响应数据。
 *  第二次从页面内跳转到新的内容，可以复用当前运行环境，包括已经在运行的JIT Code, 已经解析完成的CSS Rule Set等。

它们也有缺点:

*  主文档缓存：考虑到改版， 需要使用条件请求，也就是仍然需要发送请求，只是响应在大多数情况会小很多。这个内核和页端配合可以解决，页端保证资源的一致性，内核则允许特定主文档后置验证。
 *  本地模板页: 同样是改版的问题，只能是由客户端自己管理了。另一个影响是性能数据可能无法正确收集。  
    两者是不是有绝对的性能优势还取决于页面的逻辑设计：即使主文档本地化了，正文内容还是需要的，它的发送时间和响应的性能就成了关键因素了。

另外，复用运行环境的收益可以再放大。比如以类似预热的思路，提前加载到空的WebView中，当实际需要请求时，通过\#版本的方式就可以完成了。

所以收益最大的方案是四端技术整合:

*  页端&后台: 完成动态数据和静态数据分离，提取出模板化的主文档，并设计启用304条件请求。
 *  页端: 同时支持?版本和\#版本，确保主文档和资源的一致性。
 *  内核: 允许特定域名下的主文档走后置验证，而不是前置验证。
 *  客户端: 利用预热的机制，建立一个空白WebView加载主文档。当用户需要打开页面时，切到已加载的WebView，并使用注入JS或\#版本加载正文内容，也可以通过JSSDK向外壳直接取数据。

## 性能优化的方向 ##

前面提到了目前可以确定的两个迭代阶段。我们现在还处于第一阶段。借助U4可以将性能优化推进到第二阶段，将各领域中体系化的技术加以评估、运用，　包括各端技术的深挖。  
再往前一步，未来的页面型态会不断细分，相关的技术也会各有差异。我们可以先从业务类型区分开始，针对性的演进跨端的体系化方案。

对页面分类，从性能优化角度看，最终以页面在Web Platform（浏览器内核）上效果来体现．所以采用对内容(数据)和流程(行为)细化最为合理：

*  资源数
 *  资源大小
 *  多媒体资源占比
 *  用户所处的网络环境
 *  后台服务器部署
 *  动态资源大小及占比
 *  JS执行时间占比
 *  渲染开销
 *  依赖于特定的技术
 *  ……

定出类型后，就可能对应运用简分预挖掘优化策略。

[process]: /images/20220708/59e89f4a230243b785c72554511a6c9c.png
[technology_stack]: /images/20220708/721a7b2b91a947609986b47c6b571ab1.png