前言

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

性能的本质

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

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

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

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

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

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

选择优化时机

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

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

性能优化方法

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

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

技术演进和整合

演进与迭代

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

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

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

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

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

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