前言

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

性能的本质

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

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

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

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

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

选择优化时机

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

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

性能优化方法

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

技术演进和整合演进与迭代

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

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

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

• 关注于单项(维度)技术的优化。往往可以从一个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执行时间占比
• 渲染开销
• 依赖于特定的技术
• ……
  

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

奈斯