腾讯云前端性能优化大赛--首屏耗时优化Tips原创

嗯。啊，各位同学大家早上好，嗯。周六早上好啊，大家这么早来参来参加，我来听我这个前端性能优化的一个方案。嗯。然后我是结合自己的一些呃，工作上的经验啊，还有呃。互联网上提供的一些知识，来给大家做这个简单的技术分享。嗯，首先说一下，就是我们呃腾讯云前端性能监控IM在举办的前端性能优化大赛，目前还在报名中，大家可以去呃扫描右方的二维码去报名。嗯。嗯，互联网世界千千万万，然后大家我想在参加这个会议的同学，大部分都是啊前端同学，然后前端的话，呃，我们最关注的除了业务以外，还关注的是呃，我们自己前端页面的一个性能和质量，那我们今天这个课题主要是讲那个前端性能优化的一些方式啊，第一个问题就是啊，如何进行前端啊，如何衡量前端的一个性能指标。

啊，这个问题其实是我想在呃参参加同学大多大多数人心里都是有答案的，然后那我们重点是说啊，哪一个指标才是衡量前端性能的一个标准。然后第二个是呃，究竟我们的页面多快才能称作为快？嗯。页面性能的指标呢，有非常多，包括大家对。最了解的什么白屏时间啊，首充时间啊，FCP啊，FMP啊，LCP啊，F fid啊，电频词太多了，互联网水太深啊，一般人把握不住，所以我们就拿一些最常见的最实用的标准跟大家解析一下。呃，第一个就是这个图，想必大家基本上每个同学都见过。包括一个啊，我们简单从头往回看一下，就是包括呃，浏览器上一次浏览卸载的时间，就浏览器开始下载的时间，呃，重新向的时间啊，然后APP缓存的时间，DNS解析的时间，TCP连接的时间啊，Request包的时间，Response的时间。

还有浏览器处理这个包的时间，最后到呃，浏览漏的时间，这一个时间我们一般称为布图。那我们，呃。这个我这个文档是上面，呃，也会有详细的说明，后面这个文档我是做成一个可编辑的文档，然后我把这个文档发给大家，以后每个人也可以在上面把自己把你觉得对性能优化有帮助的一些点给列出来啊，直接补充在我们的文档里，大家一起共享，一起学习。啊，我我下面是有每个这个指标的一个说明，然后嗯。然后呢，这再写了一个get TIM的一个函数，这个函数里面我们会把所有的指标的说明跟计算给列出来啊，如果你自己页面里面有这样的诉求的话，也可以用这个函数。

然后IM里面我们，呃，上面我们是列了这么多指标IIM里面我们是怎么做的呢？呃，我们第一个关注点是页面加载瀑布图。因为加载瀑布图就是表示。就是对上面那个的一个属性的一个可视化的一个展示。嗯，然后我们可以看出来那个资源之间的一个呃加载顺序和依赖关系，来帮助我们大家了解每一个呃阶段大概花呃花费了多长时间，那我们页面性能的好坏呢，也可以轻松的从这个图里面看出来，我们从这个图里面看，首先是呃页面加载的一个DNS的时间，然后TCP的时间，然后呃，S。建立连接的时间，还有请求响应的时间，内容传输的时间，内容解析的时间，还有资源加载时间，最后是我们比较重要的一个首屏时间。然后这个图的计算公式呢，我也列在这个文档里面。呃，这里可以看到我们是对一个download的这个函数这个啊属性做了一个兼容，就是因为我们发现在的一些情况下会出现一个极大的赋值啊，所以我们取了一个平均的时间1070来给它赋值。

然后呃，前面看到有一个首屏时间，首屏时间是大家怎么理解呢？其实呃，我想大家在通过关键字首屏时间在谷歌或者百度搜索都能得到很多答案，然后我们是IM是怎么定义首屏时间呢？我们是认为啊页面打开一个。呃，用户打开一个页面，这个页面里面会有很多的盗变化，然后呃，这些盗墓变化如果是发生在首屏以内的，然后我们会把这个盗变化的一个趋势绘制一个呃，一个二维的图。当这个变化的一个个数达到最高点的时候，我们就认为首屏完成，嗯嗯，通俗的解释就是，如果你打开一个页面，这个页面的大多数元素在这个时时刻渲染完成，就是首屏完成。当然也有一些。

有也有一些那个，呃，团队或者给首屏的定义是全部可视化的元素渲染完成才是首屏完成，但这个实际上我们跟跟我们实际上开发业务是有一些区别的，比如说。有些页面会在呃，渲染完成以后，再加在动态加载一个广告挂件啊，那这样的话，这个广告挂件的时加载时间才变成了首屏完成的时间，这个所以我们认为是不科学的。呃，因为作为一个用户，我打开一个页面，我直观的感受到是我是页面的大多数的元素能够渲染完成，所以我们给首屏的时间的定义也是大多数元素渲染完成，因此我们用了一个动态变化的一个曲线，当这个曲线的最高点。就是元素渲染最多的这个点。我们认为是首完成。然后除此之外，我们还提供了一个两个属两个标签啊，两个那个的一个，呃属性，你可以在上添加这两个属性来标记某一个元素是首元素和不是元素。

啊，就就像我刚才举的广告挂件的例子啊，如果你这个挂件也是很复杂的，那有可能你这个挂件这一刻渲染的一个到变化会比之前的还要多，那会不会我们就误识别为这个挂件渲染的时间就是首屏的时间呢？也确实有这种可能，所以我们可以你可以通过s ignore first screening timing。来把这个元素标记为啊一个黑名单，那这样的话，这个元素的渲染时间就不会进入到我们的一个首屏渲染的一个计算里面。然后整体的计算流程我大概描述一下，就是首先用一个浏览器的属性叫music musician observer去监听各个的变化。然后呃，监听以后，把所有的节点和它的子节点的数量，还有它的啊，子节点的那个元素的指针都放在一个一个变量里面，然后我们会把这些呃。这些啊，Music的一个对象去进行便利，然后找出所有的元素点，还有我们打标签的那个点，包括呃呃，就是首屏元素标签点和忽略手屏元素那个标签点。

呃，然后再把那个需要标记的和呃非和排除这种非非平元素，然后再计算变化的一个一个变化趋势。然后除此之外，我们还要去判断这个元素渲染的时候是否在啊之内。渲染完以后，我们会绘制这样的一个图来计算你的首屏时间，首次节，然后呃。因为完成，因为加载啊，还有采样数量，还有三秒快开率等等一些一些元素。然后这里我也会把我也列出来了，就是啊，除了首屏时间以外，其他的一个啊，指标的一个计算方式。嗯，除了首屏以外，其实呃，业内谷歌给了一个比较好的一个方案，叫web vis webs我来读一下吧，就是谷歌给的定义是一个良好的网站的基本标准。嗯。原因是要过去要衡量一个网，一个好的网站需要使用的指标太多，像我前面讲的fcr，就是和一大堆指标那。

谷歌是希望能够简化这个学习，并且能够有一个通用化的标准，之前的话，呃，像首屏这个算法也是我们自己出的啊，然后有一些同事可能不认可这个算法。然后呃，包括有一，包括还有一些特殊情况，没有办法兼容。Vis其实是一个，等于是谷歌出了一个更标准的一个，呃，行业解决方案来给我们定义这个指标。然后Y的话一共是啊，我们在IM上面是一共是拿了三个指标出来，一个是C，一个是f fid，一个是CS，然后的源码里面是提供了五个指标，然后我们分别去带大家去简单了解一下。啊，第一个是CSCS是累积。布局一位。啊，就表示你这个页面的一个一个变化，一个一个布局的一个变化，举例子就是啊，如果大家是写过一些。

的一个一些react或者view的一些静态网站的话，静态页面的话就是会发现就是渲染HTML加载的时候是只加载了GS跟CSS，是没有倒元素的，然后倒元素，然后GS再去动态去渲染这些组件，这个会可能会导致一些变化比较大，而且假如说你有些元素啊，假如说你有些呃元素是通过接口拿到的，而且拿到之前没有一些占位符。这样也会导致这个C的值比较大。很常见的就是比如说你的页面里面有一个很大的一个啊，一个一个列表啊，这个长列表，你有没有做一个站位图。啊，然后那当然当拿到这个长列表的数据以后，再进行渲染，这个时候啊，页面上的很多元素都会由于由于这个长列表的渲染而进行而发生移位，所以这个这些就会导致CS的一个值变大，FCP的话是首首首次内容绘制啊可以。

有点跟我们之前就可以理解为是我们之前啊说的那个白屏时间是首次输入延迟，这个是在移动端会比较大家比较关注，就是你因为渲染的过程中，其实是占用了你的一个CPU的资源。那那假如说在页面渲染的过程中，因为你同时还有一些元素的加载啊，啊，还有一些啊JS的执行啊，那如果这个时候你在跟浏览器互动，比如说点一个链接啊，点一个按钮啊啊。如果浏览器是没有办法响应的，那我们就认为F还没有发生ID就是呃，当你。在页面加载过程中输入有。这个页面可以响应你的这个最早的这个时间点。LCP的话就是最大内容绘制，这个最大内容绘制啊，从名字大家可以理解出来，这个是就是你页面中的一些啊主要的元素绘制完成的时间啊，这个最大元素可能是一个图片，也可能是一个盗元素，也可能是一个视频，那大家是不是觉得这个FCP是不是跟我们前面啊，就是我们呃，IM定义的锁屏时间是比较接近的。

对，也确实是这样的，就是我们在实际的啊生产环境验证中也发现，就是我们自己啊，就是我们IM呢，计算出来的首屏时间跟这个LCP的，跟谷外的这个LCP的时间是非常接近的。那为什么我们暂时还没有用这个呃，LCP这个时间来取代我们自己计算的这个算法呢？因为我们这个算法毕竟是一个自己的算法，谷歌这个是一个公认的算法，为什么没有用呃谷歌这个算法来取代我们的算法呢？主要原因是LCP目前还有一些兼容性的问题。如果未来我们，呃，随着浏览，随着那个设备的厂商的一些演进啊，随着大家的。一个设备的一个呃升级，然后我们也会呃，逐渐会去用LCP这个算法去取代我们自己目前的一个首屏算法。还有一个FTTFB是一个浏览器接收到从服务器接收到第一个字节的一个耗时，这个主要是想来衡量一个服务器来去响应这个啊，你的请求的一个时。

刚刚啊，我们说到FCP，它就是一个，呃，用了一个performance observer的一个一个API，然后这个API还是有些兼容性的问题。那讲了这么多前端的一些指标，我们，呃，下面去进入到我们这节课的正题，就是前端性能优化有哪些手段，呃，最常规的，我觉得这个主要是前端同学都会了解过，雅虎军规一共出了30多条，就是关于各种各样页面优化的一个手段，当然雅虎军规是呃，几十年前，十几年前的一个产物了，有一些啊，有一些的方案可能也随着HR到来，随着浏览器性能的提升啊，也没那么。显得有的已经过时了，有的已经没有办法再有的现在的浏览器。有很发生了很大的变化，可能就没有那么适用了，所以这里，然后军规这30多条我就不详细讲了，如果大家有兴趣的话，可以点进去这里面啊，点这个文档的链接，这个文档里面有详细的对这个，然后军规的几十条的一些解释。

然后呢，嗯，我刚才说到雅虎军，给雅虎军规带来最大改变的其实是HTP。啊，所以如果你的项目里面还没有用HTP的话，我强烈建议你去试用一下，呃，因为使用方式也很简单，如果你是用自己是自己项目的话，就是N做一下升级，然后开启HHTP2就可以了，如果是你的公司，你你所在的企业还没用HTP2的话啊，那你就需要去看一下这个域名是在谁手手中掌控啊，是不是要开启啊，因为这个对浏览器性能的提升还是非常明显的。H2主要的提升在于什么呢？呃，我们在HTP1的时候有一个缺，主要的缺陷就是啊，连接没有办法复用，每次请求就是我每次发，因为HTP是完全无状态的，每次啊，我发一个请求都要经历一个三次握手和慢启动的过程中，那如果我们一个页面渲染过程中有非常多的小文件啊，或者是非常非常多的页面请求，那这HP1的一个缺陷会非常明显。

当HP1.1的时候，也加了一个啊live去解决这个连接复用的问题啊。假如说你页面上有大量的元素，这样会啊会。会做一个一个顺序加载啊，所以说浏览器也会给我们之前经常说到问到的一个面试问题，为什么要开多个域名，其实也是因为有这个浏览器的这个这个并发的限制，就是呃。包括之前移动，包括之前经常说到的一个切分域名的一个方式，也是也是因为这个原因，嗯，当然HP1还有一个就是一个对头阻塞，对头阻塞是它有一个很大的问题，就是啊，如果你浏览器的连接，如果你的设备的连接已经充被充分使用了，过程中如果第一个包阻塞了，会导致后面的资源全部都会阻塞，这也是HP1.1的时候那一个。

有很大的一个，呃，HP1.1的时候存在一个问题，这个问题啊，其实HP一直都没有解决，一直到HTP2的时候。才是才会才会有一个彻底的解决，然后我们之前在浏览器里经常看那个请求连接的时候，也会经常发现这些是一起的，然后这个这些结束完以后，下一波请求才发起。然后HP2的时候，HP2主要的优化就是改进传输性能，我们知道HP2有很多特点，这些啊特点面试的时候也会经常问，然后啊，当然我们主要关注的就是对性能的一个改进啊。H、它的核心目的是希望。嗯。一个目，一个用户跟一个呃，域名之间，或者一个网站之间只保持一个连接，这一个连接是一个管道，所有的需求都在这个管道里进行。所以它做了以下几种方式，包括最主要的就是基于流做做传输，因为之前HP1是一个基于成基于文本的一个格式。

然后基于流的核心呢，肯定还要用二进制的一个协议啊，最重最重要的也是被大家最乐道的是一个多复用。复用就是说一用一个管道可以发多个请求，然后还有下面还有就是对呃，HP请求的一个手部压缩呀，还有安全性的话，就是因为HTP必须用hps。还有server server push目前还是看起来还是比较用的比较少，比较鸡肋的一个功能。然后你看这HP2的一个连接的一个示意图，就是我服务器跟客户端之间就就只创建一个一个TCP管道，然后所有的所有的数据都是在这个管道里进行的。然后这里有一个H的一个例子，我也带大家看一下。左边是HTP去加载这个这个图片加载这可能有几百张图片。可以看到这里耗时。

然后右边是H2。可能有个五六倍的差距吧，就瞬间1.87秒就把这个后面渲染完成了。可以看到H对H1的一个性能提升还是非常大的。那这里也引申到一个，呃，我们开发前端同学开发的一个。一个思考。就是我们现在不光是H h2，而且还有5G的到来，其实很多很多技术，很多大家之前啊，竭尽全力想要解决的一些问题，随着技术的提升，其实已经没有那么重要了，所以我们更更多的作为一个前端同学，你可能更多的要关注一个市场的一个发展呀，包括自己的一个项目的一些架构啊，这些这些。呃，技术点的提升会对你整个项目的一个提升会是非常巨大的。

当然啊，刚才我展示那个图片是一个啊，是一个H1跟H2的区别，但我们在实际开发过程中也遇到一个问题，就是啊，如果是多图片渲染。然后iOS跟安卓也有一些区别，这个我举一个实际我们遇到的例子，就是我们之前做一个啊，一个一个。啊。一个送礼液，就是有很多礼品，很多礼礼物，然后可以给给主播去送礼。那这样的话，就所有的礼品礼物都是一个，都是一个图片。那这个时候啊，我们自己实际渲染的过程中发现啊，虽然已经开了H2，但是iOS上还是会出现一个短暂的延迟的问题，然后我们抓包发现啊。IOS在处理这个图片渲染的时候，会有一定会有一段时间阻塞，这个会导致一个小白屏。那为什么会发生这个问题呢？我们后面发现其实这个是一个浏览器调度的问题，这并不是一个呃，网络网络的问题啊，后面iOS升级不知道是否已经解决这个问题，如果大家有遇到的话，或者在大家有开发过程中有这种多图片渲染，也可以关注一下iOS跟安卓的差异。

然后H2，虽然刚才大家已经看到效果非常明显啊，也解决了我们实际中很多问题，但是啊，HR还是存在一些缺陷，就是它的底层毕竟还是TCP的。嗯。我们收到的一个多服用。在HR里面还是基于啊，还是基于TCP的，就是说一个域名下我们还要建立一个TCP连接，那这里啊，这这样就存在一个问题，就是如果这个连接有丢包的行为。那这一个连接就需要把这个连接就需要把这个这个丢包的数据进行重传。然后这个这个时候在在TCP协议里面就存在的问题，就是啊，我们在传这个过程中，后面所有的数据都被阻塞了。那这个这个协议这个问题是基于TCP协议没有解决的。我们看一下这个。

看下这个图啊，那H2没有办法解决问题，这个时候谷歌就做了一个啊，就是基于quick协议做了H3的一个方案，H3的在底层的，传输层在底层的啊，更底层的。就发生改变，它是用udp协议来去还去取代了之前的TCP协议。啊，我看我们来看一下那个H3协议的一个特点，第一个是底层采用了协议啊，通过用户通过在用户空间的quick协议来保证传输的可靠性啊，第二个引入了connection ID不再需要像TCB那样基于IP和端口进行绑定。支持连接迁移啊，这个有很大的，对移动端有很大的优势在于就是啊，你可能之前在用在用在用网啊，自己的4G或者5G网络，然后你可以呃，突然变到变了WiFi网络，这个时候连接是依然可以使用了。

然后第四。啊，第三个是头头部压缩的算法进行了一个优化。然后第四个就是那个quick协议里面是默认。有一个HTTS的一个解析的一个方式呢，可以那样这样的话建立连接是更快速的。嗯。这里我们主要是讲了那个HP协议的一个一个演进，所以如果大家目前最成熟的还是H2，然后大部分项目上如果有条件的话，尽量上就对项目提升还是非常巨大的。然后H3协议目前还是，呃，在一个发展阶段，很多项目也没有完全上，然后就是大家也可以去关注这个技术点，然后去看一下它的成熟度，后面有条件的话也可以进行改造。然后第二个就是图片压缩，图片压缩的话就是啊，我大家可以重点关注两种，两种图片格式，第一个是谷歌出的。第二个是呃，那出的一个呃AV。

Avf这两个都是啊，Avf其实是最近才出了，是其实比谷歌这个P要更更先进一些，它的压缩率还要更好一些。然后啊，至于它的具体特点呢，我也放了两两张图片啊，然后我们我们现在一起看一下吧，一起看一下这个。看下这个avf，这个可能很多同学并不知道这个图片格式。这里有两篇，一篇是一个国外的博主写的，一篇是张新旭写的。啊，先说一下AF的，它的兼容性目前不是特别好。嗯，可以看这张是一个F1的图片，它原始图大概两兆多，然后。哦。GPG的话是70多K，然后YP是四四十多K，然后AF是18K，这几个压缩以后都是看起来没有没有明显区别的。

然后因为我是投屏，我不知道大家目前看起来效果怎么样，但如果但是你应该是可以拿到这个文档的，你也可以点开这个文档的链接，去体验一下这个avf的这个一个强大的一个加速算法。然后之前有一个有一个美剧叫叫硅谷是吧，那个我不知道大家记不记得，就是里面那个主人公，他就是。他就写了一个音视频的压缩算法，然后就创业了一个公司，成功了，这个还是挺厉害，能写一个压缩率又高的，然后呃，又不失真的一种算法，这个还是还是很牛逼的。

然后呃，前面讲了几几种，先讲了HR，然后又讲了这个图片压缩，然后整体再还下面的话，我们去讲一个整个前端的一个架构，架构演进，就是说你也可以通过这种架构的升级来优化你整个页面的一个一个一个性能。嗯，我们最早其实都是CSRCSR，就是就客户端渲染，后端渲染，其是这个很常见，之前在时代还是或者是最早的更更原始的，大家直接写啊。直接写HTML加GS加CSS的时代啊，这个大部分都是客户端渲染的一个方式，后端渲染呢就是啊，首先我会加载HTML，然后这个HTML里面是包含很多到元素的，然后我们在加载GSJS里面可能是在动态加了一些元素啊，然后加载CSS去去渲染啊等等等等一系列操作。啊，这个时候这之前这个叫后端渲染就是CSR，然后CSR存在的问题就是嗯。

我的。嗯，在它存在问题就是。好像就是。还有什么问题了，我现在想一下，觉得好像虽然咱也没有很大问题。这时候很多很多事情都要放在J，放在JS里面去做，然后呃，然后这这个JS去，比如说我们去渲染一个数据，就要从服务端去请求这个数据，然后再渲染出来，那可能呃，所以大家觉得要不然这个事情是不是可以在服务端做，尤其是view跟direct出来以后，我们可以。用。我们就view跟react出来以后，带来给大家带来一个很大的变化，就是大部分人不写HT了。我们直接写这个组件，这个组件最终去渲染成一个页面出来，就是给我们带来一个很大变化，因为你没有发现我们现在HTML里面就是一个。就引入一个JS就够了。然后所有的酵母元素都是通过GS去实现。

所以所以在这个在在这个通过写组件去写页面的这个时代，我们存在的问题就是。你加载一个页面以后。这个页面是白的，它只有一个JSJS在执行的过程中才把这个页面渲染出来。对，这个这。VIVO跟react的时代，这种组件的时代，才是我们呃，CSR存在瓶颈的一个时代。于是大家就想到了服务端渲染，服务端渲染其实原理很简单，就是我们前面前面说了我们啊。啊，无论你是写还是写react，它都是需都是写组件，组件在渲染的时代，那我们考虑到是不是可以把组件的渲染放在服务端进行。这有什么好处呢？第一个就是减少了这种先加载一个空白的HTML，然后再去渲染这个中间这一段时间，那其实这个时段时间总体来说。可能如果在网络好的情况下不会太差。

那所以服务端渲染真正的优势是什么呢？真的优势是网络。就是。我的用户，你的用户千奇百怪，你的用户可能拿了一个4G的手机，拿了一个在一个偏远的网络，它离基站很远。那你想到如果我在服务端去把这个数据组装好，渲染出来，跟你在。啊，客户端我打开一个页面，再调JS，再调HTTP接口，再去拿到数据再渲染，比起来那肯定是总体来说服务端的啊，性能会比客户端好一点。所以其实S给整个行业带来的变革就是啊，我拿到。HTM是有数据的，是有一些状态的，可以把一些之前先渲染了，先抓好的数据去去塞在这个HTM2里面去返回，那这样的话去减少前面那个白屏的时间。这是啊，服务端渲染的一个优势。

嗯，服务端渲染的话就是啊，大家可以可以关注一个big的一个技术big，我们前面讲服务端渲染，它整个流程是大概是啊，我们把它分为七个阶段，第一个就是你发P请求到服务端，服务端拿到响应到数据。然后你的请求，然后分析这个请求，再根据用户的一些登录态呀，再根据一些用户的信息去把一些数据存储数据拿出来，比如说啊用户的，比如你页面里面有一些啊用户的信息，用户的姓名啊，这个用户你给他推荐的一个列表啊。等这些东西。然后服务端去把这个数据获取以后呢。提提前跟你的啊。你跟你的组件组装在一起，渲染成一个组装，拼装成一个HTML。所以服务端渲染的本质就是P。然后再发发给发送给客户端，客户端再把接触到HTL以后，然后再去把它给渲染出来啊，这是整个服务端渲染技术的一个路径，那这个路径存在什么问题呢。

就是在。三这个地方如果你的啊。接口，比如说我获得一个获取一个那个用户的一个，呃，好友列表，这个接口花了三秒。那是不是这个接口就成为你整个服务端渲染的瓶颈？那服务端渲染一定会比客户端渲染有优势吗？那从这里看其实是不一定的。后渲染的话，像最早的CSR时代，你可以拿到整个页面。整个页面你拿到，你拿到以后，然后你再动态，你再异步的去调这个用户的好友列表，然后再渲染出来。但在。啊，所以这个时候时间可能就是。前面这部分HTML渲染的时间可能就是一秒钟，那如果你这个接口是你的瓶颈，它有三秒的话，你是不是服务端渲染就至少是三秒以上。

对，大家可以理解这个这个问题了，所以这个时候big技术应运而生。Be呢，是是，呃是什么意思呢？就是说呃。我们来看这张这张图吧。就是我们是相当于是把用户的数据信息跟他的渲染信息给组装在一起。但是可以分块的返回给用户。比如说我们这个用这个你的服务端渲染，同时需要拉用户的信息，拉广告信息，拉内容列表，再拉一些推荐内容。然后我们可以。分块的去把这些啊。已经渲染好的内容反馈给用户。就是我们我们前面讲过了啊，动态渲染的核心。就是拼接组装数据，拼接HTM，那我们只要把分块的去把这些数据全返回给用户就可以完成确认，那这个时候我们之前说的拉好友列表耗费三秒钟这个事，这个事情就不会成为我整个页面渲染的一个瓶颈。

然后大家可以理解这样的一个技术。嗯。所以如果你使用目前使用的是SSR的话，可以去了解一个了解这个的一个技术。下面是SS级，S级是static site generation，就是静态网站生成，这个大家在啊一些。呃，一些新闻网站一些，还有或者NBA的一些，呃，报NBA的一些那个，呃，比赛网站或者是啊静态博客，这里是最常见到的静态网站生成技术。现在网站生成技术是什么呢？我们从先看一下这张图。就是首先我们需要有一个一个一个服务器，这个服务器去拉我们的数据，把这些需要。需要。最后最需要最后在用户端执行的这个H啊。提前给渲染出来，就博客里面我很常见的，假如你的页面，你的博客有40篇，那我们这40天我每一个都帮你是提前渲染好，然后用户加载的时候，就把这个体量跟对应的JS跟CS拉到就渲染出来了。

这时候基本上静态网站是可以啊，做到没有HTP，没有H请求的，就除了我啊，除了我请求HT以外，其他的接口是不需要的，因为这些接口的信息我们已经提前获取，并且拼装在HTML里面了，这是静态网站渲染，所以这个这个技术是，嗯，怎么我感觉呢，就是前端技术发展。兜兜转转，好像又回到了从前的技术。然后他当，呃，那个SG的好处就是也有很多，就是你第一个就是S比较友好，因为做SG的大部分都是。大部分都是一些博客嘛，那当然Su友好的话，对你的整个页面也是有极大帮助的，第二就是能减少服务端的一些一些负担，因为你所有的页面都是渲染好的。

不，不像你那个SSR的话，你是有一个server不停的去响应用户的请求的，而SSG的话就是你只用一个一套服务去把这些页面渲染好，然后放在那里就行了。啊，还还有就是极大的帮助，就是有可以你可以把页面放在CDN上，虽然我们其实不推荐大家把页面放在CDN上，因为呃，页面放CDN上，总体还是有一个被劫持的风险。因为CDNCDN，虽然你的域名是HTTPS的，就是是是安全的，但是CDN节点之间，那个OC节点之间，如果它是通过HTP协议。传输的话，其实是会有被运营商劫持的风险。包括大家经常在一些。网站上有的，有可能你在网吧里面，或者是我们，我实际用电信，我每年快要缴费的时候，发现电信就会在我的啊浏览器里去弹一个框，让我去缴费啊什么的，这些都是通过域名劫持实现了，就是本质上就是CDN节点之间的一个。

呃，不安全性，就是OC节点没有通过HTPS去通信去实现。然后还有一些优势就是啊。优势，最还有一个优势就是你的啊数据或者是你的页面是可以版本化的，可以版本化管理的，你的页面的内容变更啊，可以跟get去关联在一起，这个也是在我们实际开发过程中非常友好。嗯，那SSD。这样的话存在一个问题，就是所有东西都是静态的。所以又有一个新的名词叫增量式网站渲染，嗯，反正后面名词会越来越多，其实核心大家能理解就是，本质上就是。一个我觉得前端的发展本质上就是就是一个缓存技术的发展。啊，包括。啊，我们接口请求的一个耗时能越来越快，也是大家充分利用了一些后端的缓存，然后前端的缓存啊，包括你对啊。

包括你把HT提前预好，这本质上也是一种缓存技术，然后包括呃现在这里讲了一个SD，本质上也是呃一个一个缓存加异步的一个一个一个模式，就是以把一部分内容。提前渲染好，放在CDN上，然后把另外一部分内容通过这请求再获取到在最后。返回给用户再渲染出来，那这样想其实好像互联网发展兜兜转转一圈。又回到了最初的起点，是不是最初我们讲CSR的时候，其实也是这样的方案，无非就是CSR的时候大家是写铁棉袄，写啊GS，现在大家就只用写啊，只用写GS，只用去写组件。啊，后面还有一个分布式持续渲染，这这个技术我也只看到名词，也并不了解太多，我再讲了。

对我前面三个点做的总结，就是如果大家可以看到大纲的话，这前面几个点做总结。啊，第一个雅虎军规，规定30多条，这里面有很详细的规定，然后然后H2跟H3的演化，对我们整个页面性能提升非常明显，然后。啊，如果你页面有比较大的图片的话，也可以考虑新的图片格式，然后还有整个就是互联网架构演从CSR到SSR到SSD，然后到SR到呃第DPR这几种模式，嗯，其实如果你的业务比较复杂，SR也是目前发展最。呃，均衡和啊，厂商使用最多的一个技术，技术点，如果你仅仅是一个静态博客，仅仅是一个新闻页，一个广告的一个一个页面，你也可以考虑那个静态网站的一些技术。啊，最后我们结合一个实际的优化案例，来给大家讲一下我们的一个一个优化的一个情况。嗯。

这个实际优化案例，其实是前面一些同事，一个团队邀请我去给他们产品做一个一个系统的分析啊，我们当时啊，因为用户也是接入我们IM，然后我就结合他的。结合I的一些数据和用户实际页面的一个情况。用户实际页面的情况，对他做页面做了一个。做了一个一个优详细的优化分析，我们来看一下具体的过程，第一个就是我们首先打开它的页面，发现它的啊页面的一个加载时间是四点多秒。这个数据肯定不说说不上好就是啊，而且首屏时间是四点多秒，这个是我们自己的算法，然后谷歌web给的算法也是4.1秒，这个也算不上好，然还有一个问题就是它的CS的时间，就是因为偏移的那个时间也是也是比较差的，就是这里面显示的是泡。

嗯，那用户他的诉求就是页面的一个响应快，一个性能好，那我们去整个去分析它的页面，来看一下它页面都存在哪些问题。嗯，首先我们拿就仅仅用IM的数据来分析的话，就是发现啊，我们先把所有页面那个性能做了一个排序。排完以后我们发现有很他的页面，它的一个项目里面接了非常多的页面。嗯。而且这些页面不是在同一个仓库里面，就是说本质上很多页面之间没有什么关系的，但是它都用了一个上报的一个ID去上报，那对我们来说，我们就把它识别成一个项目。那它里面有一些低使用频率非常低，但是性能非常差的页面。那我们就建议他把这些页面进行，就是我们把建议他进行针对针对化，针对性的一个呃优化，把一些呃本身不在仓库一起，然后又没有高频使用，因为一些优化性能的一些诉求的页面去单独拆出来。

就是你不要影响大家了，你的成绩差，你不要跟大家一起来算平均分了，就是这个意思，然后。这个。嗯。这个是也是给大家一个一个参考建议，就是说啊，你对性能优化其实也是基于你自己的业务诉求的，我的页面，我页面就是。假如说我页面是发工资的网站，那我页面做的再差，只要他不崩，那你都要来看对不对。嗯，然后排除了页面干扰以后，然后我们又看一下网络跟跟那个区域的干扰，然后整体看网，排除网络跟区域的干扰是防止什么呢？就是。嗯，假如说这些用户有一些网使用的网络非常差的情况，这一些用户因为我们算的是平均值或者分位数嘛，那总体来说有一些比较差的数据，其实是会对你的大盘数据有影响。所以我们就做做维度分析，做维度下来看一下啊和地区啊有没有影响。我们看起来以后啊，好像这些影响都不是很大，那接下来我们就。

我我们当时看他的瀑布图，回到这这里看到的瀑布图，发现它最长的应该是资源加载这个这个。看这个瀑布图，发现它最长的应该是资源加载这个，这个呃耗时，那资源加载这个耗时为什么大呢？我们就拿它的页面实际分析。啊，也是最常用的吧，打开network去看一个他的一个耗时，我一下子就惊呆了，发现他的。主GS是H1H1的协议，并且它的大小是1.7兆，这个大小是很大的。虽然这里还有一个问题，就是前面那个雅虎军规里面，大家是说有合并JS请求嘛，合并请求就是减少APP请求的个数。

那为什么到了现在，如果我把所有的GS合在一起？反而又不行了呢。就所以这里也涉及到一个，呃，我我刚才前面也讲过，就是一个我们从写JS点零二到写组件的一个时代的一个区别，这个时候因为啊，你想你这个GS是你的主GS，你所有的渲染逻辑，所有的GS执行逻辑都是在这个JS里面的。那意味着你的这个GS要加载完成以后才能执行，那这段时间加载这个GS的时间就200多毫秒，就是你是要。啊是你页面是要是要阻塞的，你必须等这个加载完以后，你才可以渲染的页面对吧。啊，所以所以我们最早就建议这个用户把这个GS进行拆包。而且做资源加载优化，除此之外其他的协议，其他的接口，其他的资源都是HR的身边，这个最大的用了1.1也是很奇怪的。对，也是第一时间很简单就发现这个问题。

然后就把这个让就让用户做这个事情，第一个是啊拆包，就是前面一点几一点几兆，这个包太大了，你让他去去打包，比如说把一些外部依赖拆分拆拆分成，呃，然后组件可以做一些异步加载。然后还有去掉一些非必要的包，然后比如说用户全量引用了low全量引用了还有query，其实全量引了moment，这显一看就就。嗯，我们问也问他的开发者，他开发者说之前大家有用都是用那个ES或者是斜杠叉叉。这样的话，你可以只用只引用其中一个啊，一个方法，但是后面有些同学没注意就。Import-from low，那这样的话又把全量包引进来了，可以，嗯，所以整个这这些CBL包给它的整个体积占用都都非常大了。那我们可以去建议他去把这些包去掉。嗯，然后然后还有一个，呃，外派bdozer，这个可以分析你的代码包。

分析完以后，你可以看到哪些包是不需要引用的，哪些包是需要可以单独打包的。这个也可以对你的整个代码做优化。啊，第四个就是全量引用A2。之前也看到有一些HT1的加上H2的混用的方式，这个其实也不是很好。然后把一些小的资源合并成。64。然后只是只是这么简单的去做一些分包，做一些资源优化以后，用户的手时间就已经有有一点多秒提升了。然后我们重点关注的这之前看到它性能比较差的这个加载耗时从呃两秒多这里一下变动一秒，就这里直接减慢了。那这里虽简，我们发现一个问题，就是。时间并没有像那个资源加载耗时这样优化这么明显，之前是四秒，就是3.2秒，就是优化了0.8秒左右，但是这里是直接降了一点多秒，那为什么这里首充时间没有优化呢？然后我们又打开啊用户的页面去做详细分析，发现它的页面是它页面是这样，它的页面加载完以后呢，还会执行很多逻辑。

包括啊，把一些用户的数据做上报啊，还有他的页面的侧边栏啊，还有弹出广告啊等等很多逻辑，他这个页面是很复杂的。那但是，嗯。我们就想就是你这些逻辑虽然复杂，但是其实可以做到对手耗时没有影响。比如说。我们看分析的话是发现它有两个问题，第一个就是页面在渲染过程中进程阻塞，因为它执行了非常多的JS逻辑。所以他的。所以它的实际上的观感的首屏时间是比我们计算的首屏时间要晚的，为什么呢？就是我们你自己，我们自己用SDK去计算，用用户首屏的时候，其实这个时候也是需要有些资源消耗的，但是用户在页面加载完成以后，他又做了非常多的计算去把这个组进程的资源给占用了，所以我们实际计算的时候，假如他他三秒钟完成了首屏，只有我们第四秒我们在他我们。

啊，做的时候是四秒才去行这个这个回调逻辑的，以导致我们计算的时间是比的实际实际那个时间晚的。这是第一，这是用户存在的第一个问题，第二个问题就是它的，呃，首屏完成以后就做了很多do，很多很多do，就像我们前面说的弹出广告啊，现在特边栏啊，还有一些对用户数据的收集啊，然后这个也会导致我们计算的一个呃数据的失真，所以我们就跟用户建议，就是把一些CP操作去放在定时器里面。啊，一个是可以提升页面性能，第二个是也不用去占用太多主进程的一个资源。然后所以总体用户通过这个定时器改造和一个异步改造来提升那个锁屏性能。

然后我们看再看一下这里的数据啊，就是你可以看到下载是没有太多变化了，但是首屏耗时就是从之前的四秒多变成三秒多，现在变成两秒多，这在这个时候其实用户的页面性能已经提升了一半了。而且，而且我们做这个。嗯。做这些前面这两个操作其实都没有耗费用太多的时间，就是一个分包可能一天就搞定了，然后这个改造可能也就也就半天的时间就可以改造，但是用户，但是用户体验是大大提升的，就是打开的那个时间是极大的提升的。然后对于大多数来说，其实大多数用户来说，其实50%的性能提升已经可以交差了。呃，然后，但是我们前面说到了，还有一些指标并不完美，包括CS，包括那个外B里面的一个CSCS是指一个页面偏移量。简单说就是如果呃，然后我们分析的话，发现用户是其实有一个列表。

表这个列表就四到五条数据啊，四到十条数据，然后呃，开发者没有做分页。没有分的问题就是没有办法控制列表的长度。就是在用户先渲染这个列表的时候，没有办法做占位，没有办法做呃，提前预预知它的长度，然后在数据加载完以后，这个列表再渲染，就会导致整个页面发生一个变化。同时也带来的一个变化。然后。