本篇文章接上一篇继续分析浏览器web渲染相关内容，但是更侧重优化工作。当然，主要还是基于X5来分析

上一篇文章我们主要是从浏览器内核的线程角度来分析相关工作的，对整体流程没有宏观清晰的分析，这次我们从宏观到微观，从整体到局部，来进行分析和探究可以优化的地方。

首先，一个网页的加载，需要什么工作呢？

这个工作可以分为三部分：云(云端)、管(传输链路)、端(客户端)，从云经过管传到端，然后经过加载解析排版渲染，从而完成网页从请求到呈现的工作(当然，我们这里没有涉及协议的分析，实际上根据协议不同，这个传输可能是多次传输)。

数据到端之后，又经过以下过程，才最终显示出来：

在这个过程中，我们怎么衡量性能呢？

固然，我们有诸多浏览器提供的API，这些API能让我们获取到较多信息并且记录上报：

但是这些具体数值表达的含义有限，并且他们实际上也不等于用户体验。

所以，找到一个科学并且可以检测的标准，并且这个标准可以和用户体验有正相关关系，这个是至关重要的。

目前这个标准是首屏时间(就之前自己的了解，具体的还区分首屏展示时间和首屏可交互时间，但是这里讲师不做区分，就下文提供的测算方法而言，显然这里指的是首屏展示时间，另外，展示后到用户的第一次操作都会有一个至少1s的延时，毕竟用户手指按下的动作是会比较慢的，这个时间js的交互都能完成了，所以首屏展示时间更加重要–from dorsywang)

那么首屏时间怎么测量呢？

拿摄像机快速拍照测量的。这个答案可能有些吃惊，但是目前X5内核业务的相关开发人员的确就是采用这种方式测算的，通过高速相机不断拍照，然后辅助图像识别，判断首屏是否已经加载完成，最终再通过人工回归校对。
因为如果采用程序检测的话，基本上都会对过程本身造成一定的影响，所以没有采用这种方式。
当然，通过摄像+图像识别的这种方式也是有一定的弊端，比如说，假设首屏有一个图片，而图片的加载通常比较慢并且不影响css、js的加载，这个时候直接通过图片识别的话就可能会有一定的误判。

知道了怎么测算，那么接下来分析影响这个指标的一些原因：

  • 资源阻塞内核线程

我们知道，一般情况下，css和JS是阻塞页面的，当然也会对首屏时间造成影响。

对这个问题，X5内核有关键子资源(阻塞资源)缓存，这里的关键资源，指的是内核经过统计判断得出的业务常用的关键子资源。

当然，这个统计也可能缺乏一定的准确性，所以相关团队也正在推进这方面的内容规范化(比如写入Web App Manifest)

  • 中文Layout的时间过长

这个问题我之前没有听说过，但是的确是这样子，实际上，浏览器在绘制文字的时候经历的过程非常的多，其中有一个环节是找到文字的宽度和高度(因为在英文状态下，每一个字符的宽度是不同的，所以每一个字符都要查找，但是英文总共只有26个字符)，而中文由于字符比较多，常用得就有6000多个，完整的更是有2万个以上，所以这个过程需要花费更多的时间。

为了解决这个问题，X5内核考虑到中文文字几乎都是等宽等高的，所以这个过程对一个文字串来说只需要查询一次即可，实际上是节约了这个环节。

  • 首次渲染太慢

为了解决这个问题，可以采用先绘制首屏的方式，这个也就是基于第一篇文章中讲到的浏览器的分块渲染机制

  • 一次解析内容过多

采用首屏探测机制，优先解析首屏内容。

另外，这里可以前端配合去做首屏优化：

在首屏的位置插入首屏标签，内核解析到标签后立即终止解析并且排版上屏

1
<meta name=‘x5-pagetype’ content=‘optpage'>

然后在首屏分界的地方：

1
<first-screen/>

有了这，可以专门去优化首屏标签之前的内容(这个标签前尽量展现耗时少和不需要阻塞解析的资源)。

另外，X5内核也提供了主资源预拉取的接口，并且考虑到预拉取的cookie问题，还提供了preconnect预链接。
TIP:主资源中关联的子资源预拉取不用主动调用

  • 预先操作

另外为了提供更加极致的优化，X5内核(QQ浏览器、手Q Webview)还提供了如下诸多预操作：

  • 在”黏贴并转到”之前就开始进行网络请求和预渲染
  • 经常访问的站点可以预解析DNS
  • 点击地址栏时进行搜索预连接
  • 点击链接时，先预链接，再做跳转。
  • ……

其他方式优化

实际上上文主要讲了客户端方面的优化工作，实际上对于”云”、”管”两端，还是有很多优化工作可以讲的，但是由于这个和前端关系不是特别密切，我挑一部分讲一讲。这些在我们前端做个人项目的后台时候也可以参考

后台提速
  • 直接使用IP，节省dns的查询时间
  • 维持长连接
  • HTTP1.1启用包头节省
  • 服务器缓存
  • 文本资源压缩传输GZIP(6)
  • 图片尺寸压缩、图片质量压缩、支持webp和sharpp/hevc格式。
降低网络时延
  • 就快接入和就近接入

在选择接入点的时候，如果采用就近接入，可以保持路由稳定，有利于负载均衡，并且实现简单，便于维护。但是也有一定的缺点：经验判断，准确度不够高 ； 无法自动切换路由。

相比较而言，选择就快接入，是一个能够提效的方式。

内容防劫持

运营商劫持对我们来说已经是不陌生的话题了，但是X5内核有一个比较新的防劫持手段，就是客户端和云加速服务器同时采用轻量级http加密，虽然这种方式普适性不强，但是的确可以解决腾讯自身业务的防劫持问题。

QUIC和http2

QUIC 基于UDP的协议通讯方式，有这些优势：

  • 延迟少
  • 前向纠错
  • 没有**线头阻塞[注1]**的多路复用
  • 通信通道的定义基于ID而不是IP+端口，使得切换网络后继续转发链接成为可能

——————

注1：线头阻塞：

——————

附1: 带宽和延迟对网页加载的影响：