本篇文章接上一篇继续分析浏览器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: 带宽和延迟对网页加载的影响: