阅读 10989

报告老板,我的页面真的比竞品快!

| 导语 《孙子兵法·谋攻》:「知彼知己,百战不殆。」在和产品pk的时候,产品最经常的说一句话是,你看他们(竞品)都能实现,你为啥不能?你看他们(竞品)的速度怎么这么快,你看看你,为啥这么慢?

《孙子兵法·谋攻》:「知彼知己,百战不殆。」在和产品pk的时候,产品最经常的说一句话是,你看他们(竞品)都能实现,你为啥不能?你看他们(竞品)的速度怎么这么快,你看看你,为啥这么慢?每每遇到这样的责难的时候,我往往都只能陷入到沉思,我只能告知产品,我们的页面很快,真的很快,你看,我的报表。产品总是在这个时候说,不听不听,我不听。如果你不能拿出竞品的客观数据,那么,在产品看来这样的呓语只能是开发自己的寡妇心态。在每个无人的夜晚,遇到这个问题的时候,我不得不得默默的打开了浏览器。

所以,如何把监控做到客观,独立,第三方,就变得很重要了。

如何客观的监控页面的体验

首先,第一个来自灵魂的深思就是,如何客观的对页面体验进行评价?你说你的页面体验牛逼,你的页面体验就牛逼了么?你说竞品的页面不行,竞品的页面就真的不行么?每晚思及如此,我都默默的打开了浏览器。

对于页面的客观评价体系,有很多不同的说法,基于速度,基于错误率,基于SEO…,这么多的评价标准中,要怎么样,找到最能说明用户体验的指标?或者换句话来说,怎么样的指标是最能够表现用户真实的用户体验的?

从直觉上来说,一个页面的体验可以分成以下几个部分:

渲染体验

这个体验最直白,用户打开页面的耗时如何,用户花了多长的时间来打开你的页面。在页面的打开过程中,是一种什么样的体验?是白屏,是渐进加载,是菊花图,还是骨架屏?不同的体验体验,给用户的直觉感官是不同的,这些感官应该怎么样来客观评价?

交互体验

页面的各种交互是否能够及时?页面上的各个交互针对不同的人群是否兼顾?是否照顾了视觉障碍人群,是否考虑到了键盘党?各个交互是否符合浏览器预期?页面上的脚本是否使用了有危险的API?是否加载了太多的资源?

SEO

页面是否对蜘蛛友好?页面是否对于能够被正确的收入?

当然,上面列的比较简单,只涵盖了页面的一部分,但是,如上已经覆盖了很多我们平时需要关注的页面信息了,那么我们要怎么来获取和评价这些信息呢?

最简单的方法是,我们把浏览器的devtools打开,选中到performance tab,点击record。然后,我们就可以看到所有我们想要的数据了。那么问题来了,performance tab是怎么工作的呢?它是怎么拿到我们页面的各种渲染数据的呢?

浏览器的performance tab是怎么工作的?

一切的一切,都要以这个协议开始:chrome devTools protocol。 chrome会通过这个协议,把内核和浏览器的一些状态暴露出来。我们平时使用的performance tab的本质起始就是使用这个协议的一个美化了的查看器。performance里面还是有一些内容比较没有被充分展示,如果你想了解更多,更详细的内核信息,可以进入到以下的页面查看

chrome://tracing/
复制代码

点击record,你会看到如下的选择框。

这里将会允许你,更为详细的去定义,你想要监控和了解的内核内容。

嗯,这里有一点比较好,也是比较不幸的一点,这个tracing tab将会监控当前chrome 所有tab的渲染信息。所以,使用的时候,请务必小心。还有一个需要注意的点事,这个tracing的日志量多到爆炸,尽可能的选择较少的追踪项,这样,可以让你保护好你的内存条。:)
如果有时间好好研究一下,这个tracing出来的内容,你会发现,浏览器的运行,好像并不是你想象那样的。:)

当然了,除了使用这样的形式去使用chrome devtools protocol,我们还可以使用nodejs的来获取。毕竟,Anything that can be Written in JavaScript, will Eventually be Written in JavaScript。比较常见的nodejs的库有chrome-remote-interface(下文为了方便,简述为cri),当然,如果你说我不要,我不要js,那也不是不可以,在这里,自己选一个自己喜欢的实践吧。什么typescript,go, python,ruby都有,当然,还有,我们大家都喜欢的php。

好了,作为一个前端工程师,我们还是老老实实用nodejs吧,虽然,typescript很好,但是我选择js,我们来康康,我们要怎么把各种各样的工具,组合起来,使之成为一个能够被工具化使用的页面监控呢?

具体的cri使用,请参考这个wiki

工具化的页面监控

一切的一切,我们要有一个开启了debugger端口的chrome。这个简单,你可以用shell脚本,自己起一个,当然,我们还有更优雅的方式:chrome-launcher,有了它,在寂静无人的夜,你就再也不用自己写shell脚本来启动chrome了:)。

通过chrome-launcher,我们把chrome拉起来,然后得到了一个我们需要需要调试端口,然后,我们拿着这个端口,使用cri来获取我们需要chrome-debugger-Protocol,拿到了具体的Protocol之后,我们来康康,拿到的都是些啥东西:

{"pid":8784,"tid":8728,"ts":4123614461,"ph":"X","cat":"ipc,toplevel","name":"ChannelMojo::OnMessageReceived","args":{"class":50,"line":101},"dur":2,"tdur":1,"tts":22268542},
{"pid":8784,"tid":8728,"ts":4123615131,"ph":"X","cat":"toplevel","name":"MessageLoop::RunTask","args":{"src_file":"../../content/browser/renderer_host/media/media_stream_manager.cc","src_func":"SendMessageToNativeLog"},"dur":4,"tdur":4,"tts":22268810},
{"pid":8784,"tid":8728,"ts":4123615138,"ph":"X","cat":"toplevel","name":"MessageLoop::RunTask","args":{"src_file":"../../ipc/ipc_channel_proxy.cc","src_func":"Send"},"dur":8,"tdur":8,"tts":22268817},
{"pid":8784,"tid":8788,"ts":4123551336,"ph":"X","cat":"toplevel","name":"MessageLoop::RunTask","args":{"src_file":"../../base/trace_event/trace_log.cc","src_func":"SetEnabled"},"dur":130,"tdur":130,"tts":64927429},
{"pid":8784,"tid":8788,"ts":4123551358,"ph":"I","cat":"disabled-by-default-devtools.timeline","name":"TracingStartedInBrowser","args":{"data":{"frameTreeNodeId":101,"persistentIds":true,"frames":[{"frame":"7CB62147F076D4C38B128F711003B9E9","url":"https://www.huya.com/badaozongcai","name":"201905171157120c93bb02c2ca5f727133a5547b2a8d4000016f6b3731c1440","processId":5368}]}},"tts":64927451,"s":"t"},
复制代码

是不是觉得似曾相识,嗯,用chrome save下来的profile.json和上面的内容的格式一模一样。那么,这一大坨json到底是啥意思呢?这个时候,我就要把我祖传的chrome tracing event format的文档给你掏出来了。我相信,等你看完之后,你一定会,大吼一声,卧槽,这是什么鬼!这么诘屈聱牙的文档,简直了。浏览器的底层运行原理是非常复杂的,不同的类和组件的调用,使得追踪浏览器事件变成了一个不是这么容易的事情。当然,如果,想要图文并茂的了解浏览器的运行原理,请参考《life of a pixel》

如果是我们想要程序化,工具化的去监控和管理浏览器的底层渲染行为,我们只能从上面厚厚的trace event log里,把我们需要的内容剥离出来,进行统计分析。这时候,我们会就想呀,有没有大神把这个事情给做了呀,我们这种小弟,观摩学习一下就好?

答案是,当然有啦!google chrome团队,自己就开源了一个基于typescript的分析工具Lighthouse,能够帮助我们快速的进行页面的质量分析。

Lighthouse是什么

lighthouse 是这么介绍自己的:

Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.

在我看来,Lighthouse更像是一个google推行标准的衡量器。让广大的开发同学知道什么是好,什么是不好,在茫茫的人海中,找到对的那个人。

Lighthouse的工作原理

与其让我重复一遍上面的内容,还不如康康Lighthouse自己是怎么说自己的工作原理的:

依照上图和前文,我相信大家已经对于Lighthouse是怎么执行的,有了非常深刻的理解了,通过github上Lighthouse的readme,我相信,大家也能够非常容易的把Lighthouse跑起来了。这里就不赘述了。无非就是npm install, npx lighthouse 诸如此类。

等我们把lighthouse跑起来之后,我们就可以得到下面这样的一个报告:

我们除了会使用到Lighthouse提供的这些评价标准和评价体系,更多的时候,会使用到属于我们自己的评价标准和评价体系。这个时候问题就来了,我们要怎么对Lighthouse进行二次开发?我们怎么基于Lighthouse做一个属于我们自己的标准衡量器?

Lighthouse的二次开发指南

在开发之前,我们先了解基本流程,从上图,我们可以清楚的得知Lighthouse的工作流程如下:

+--------------+      +-------------+        +------------+       +-------------------+
|              |      |             |        |            |       |                   |
|  connecting  +----->+  collecting +------->+  auditing  +------>+ report generation |
|              |      |             |        |            |       |                   |
+--------------+      +-------------+        +------------+       +-------------------+
    建立连接             收集日志              分析,审计               生成报告
复制代码

了解了流程,我们再来了解一些基本概念,在Lighthouse里面,有如下几个特别重要的概念:

  • Driver: 连接器,是前文说道的cri。用来链接和获取chrome devtools Protocol
  • gatherers:采集器,对trace event log进行分类收集
  • audits:对收集到的日志进行审计,最后给出出分数。
  • metic:对日志内容进行分析和计算。一般是被audts调用的工具类

好了,知道了,以上这些内容,你就可以自己来搞一个Lighthouse了,正常来说,一个优秀的框架设计,都是会留有插件机制的,能够让我们非常优雅的,无侵入的把我们的逻辑添加到框架的逻辑体系中去。Lighthouse也不例外。当然,如果你说,不要,我不要,我要硬核魔改,让它变成我自己的崽,下文也会给出一些指南。

插件化的开发方式

在开发插件之前,我们需要知道,我们这个插件的结构是怎么样的。先俩简单的看一下:

-
|-your_audit.js
|-plugin.js
|-package.json
复制代码

只需要三个文件,就可以自行实现一个lighthouse的插件了,是不是很简单!!!

package.json是一个npm包的必备文件,我们需要把package.json中的main指向,我们的plugin.js。

作为一个plugin,你只是需要暴露以下一个对象即可:

//plugin.js
module.exports = {
  audits: [{
    path: 'path/to/your/aduit',
  }],
  category: {
    title: 'My Plugin',
    description: 'my plugin.',
    auditRefs: [
      {id: 'your_audit', weight: 1}, //这里需要注意,id和文件名一直
      {id: 'meta-description', weight: 1}, // lighthourse的默认审计项目
    ],
  },
};
复制代码

然后,在audit文件里,你可以自己定义你自己的审计规则,就像下面这样:

//my-audit.js
const Audit = require('lighthouse').Audit;

class myAudit extends Audit {
  static get meta() {
    return {
      id: 'my-aduit',
      title: '展示的title',
      failureTitle: '未通过的时候,展示的文案',
      description: '补充的一点的描述内容',

      // 你所需要的收集内容
      requiredArtifacts: ['LinkElements'],
    };
  }

  static audit(artifacts) { // 上面指定的内容,将会被传递到这个函数中
   // 处理你的逻辑
    return {
      score: 0, // 外显的分数以及决定是否算通过
      displayValue: '显示的内容',
    };
  }
}

module.exports = myAudit;
复制代码

在执行lighthouse命令的时候,我们需要这样来明文指示我们要用的plugin:

npx lighthouse https://example.com --plugins=my-plugin --view
复制代码

然后,lighthouse就会去node_modules里面去寻找,你要使用到的lighthouse plugin。

lighthouse官方自己给了一个插件的demo,大家可以自行参考一下。里面还有plugin的效果图。

上面可以看到,开发一个plugin是很简单的。但是呢,我们也很明显的发现一个问题,这个plugin的机制有点弱,好像只能就已经收集到的信息进行审计级别的重写,并不能捕获更多的数据,然后来定义自己想要的内容。

其实吧,如果,只是想自己定义一个属于自己的评价体系,做到这一步,已经够了,毕竟lighthouse的articles给的也挺多。基本上,你能想到的常用的内容,都有。如果想知道所有的articles都有啥,请看这里。如果你想更多的了解插件的开发内容,可以参考这里

对于我们这种,向来都不喜欢被约束的人而言,这么点东西,就想打发我,不行!作为一个成年人,作为一个半夜打开浏览器的男人,我都要!ok,那么我们来看看,我们怎么硬核的二次开发,把lighthouse变成我们自己的崽。

魔改源码

Lighthouse的源码写的很规整,加上typescript的加持,非常好读,同时大量的注释,更是如有神助。

在对lighthouse进行二次开发之前,我们需要知道lighthouse的源码结构是怎么样的。如下所示(为了不浪费篇幅,把一些和魔改无关的逻辑去掉了):

——
├─assets
├─build
├─clients // 浏览器中的展示逻辑
│  └─extension // 扩展
├─docs // 文档
├─lighthouse-cli // 命令行工具
│  ├─commands // 命令
│  └─test 
├─lighthouse-core // 核心逻辑
│  ├─audits
│  ├─computed
│  │  └─metrics
│  ├─config
│  ├─gather
│  │  ├─connections
│  │  └─gatherers
│  ├─lib // 工具库
│  ├─report // 报告生成器
│  │  └─html
│  │      └─renderer
│  └─test // 测试用例
├─lighthouse-logger // 日志收集
├─lighthouse-viewer // 报告渲染工具
└─types // 类型文件
复制代码

从上文所描述的内容中,我们已经知道了lighthouse的一些基本的内容和结构,所以我们可以很容易的从目录结构中,看出我们需要修改的内容,一般是围绕在Lighthouse-core的逻辑中。整体文件看起来好像比较多,但是呢,其实核心逻辑,其实还是比较集中。在Lighthouse-core。
整体的调用关系如下图

好像很复杂,重新整理了一下如下:

从调用链,我们可以很清楚看到前文提到的connecting->collecting->auditing->report generation的过程,其实基本上根据函数名,大家都能够分析出函数的内容。大家按照自己的需要,切进去魔改就好了,想改啥都行。

说实话,Lighthouse的整体设计还是很不错的,加上typescript的加持,整个代码的可读性还是很强的。其实基于plugin的机制,基本上已经可以满足大家的各种需求了。如果真的有一天,已经到了,必须要修改源码的地步了,希望上述内容能帮助到大家。

如何做到更加客观?

好了,基于上文的魔改,我们已经得到了一个属于我们自己的lighthouse和我们自己的审计规则。但是,在你电脑上跑出来的数据,并不真实,并不能代表广大的人民群众。所以,我们需要做以下的工作:

  • 云端部署

把我们的服务部署在云端的机器,直接接受外部网络环境的洗礼。同时限制硬件素质,保持一个比较贴近现实的机器水平。

  • 多地部署

在天津,上海,广州等多个节点进行部署,看看地理位置因素,到底会给页面带来多大的影响。

  • 多时运行

一天在不同的时间段内执行,看看不同的时间里,随着网络流量的周期变化,你的页面在哪个时间最糟糕?当然,这里还有一个更为重要的作用,就是,抽查页面的可访问性,页面是不是挂了?让你成为最早知道页面完整信息的人。

  • 多次运行

多次执行取平均值咯,去除单一缓存的影响。

基于这种考虑,我们开发了leadership,可以同时对比多份报告,云端运行。

完成了如此种种,我终于才能够在寂静无人的夜,比较客观公正的对产品说,我的页面真的比竞品的页面快!你看,这是我的报告!


关注【IVWEB社区】公众号获取每周最新文章,通往人生之巅!

关注下面的标签,发现更多相似文章
评论