这个请求块的浅色块部分占比比较大，根据前面的介绍，浅色部分代表的是服务器的响应速度，浏览器已经早早地发出了请求，服务器却迟迟才给回应（第一个字节到达浏览器）。
中间可能是网络慢，也可能是服务器处理速度慢，需要具体排查，毕竟这个HTML文件不算大，才111KBb，却花了179ms。
对比另外一个文件layouts.default.js，体积比它大124KB，请求耗时却比它小一半多，才74ms。（后来发现这个数据不稳定，这个HTML文件应该不至于构成性能瓶颈）
另外所有后续的请求都依赖于这个HTML，没有它其他请求都不会发生，它是一个阻塞请求，性能必须要有保障。
发现可能的性能瓶颈我们继续看右边的请求块，顶部那个超长的灰色块依然是Chrome插件的请求，我们不管，看下面那一堆黄色的请求块，这些都是JavaScript文件。
HTML文件下载完了之后，就会开始一行一行解析其中的HTML标签，遇到设置了谁、src属性的<script>标签，就会去下载src指定的JavaScript脚本文件。
从瀑布图可以看出，一共并行下载了8个JavaScript文件，它们的域名都是一样的：sf1-scmcdn2-tos.pstatp.com
不是说Chrome浏览器对同一个域名，并行的请求数最大是6个吗？
不仅仅是JavaScript文件，下面还有3个同域名的图片资源，也是在并行请求的，也就是说几乎同时发起了11个请求。
这说明
掘金的静态资源服务器升级到了HTTP/2HTTP/2的多路复用可以实现一个TCP连接同时传输多个资源。
我们到Network面板里去看下这些JavaScript的请求详情，果然和我们猜测的一致，这一点必须给掘金点个赞
发一个某86网站和掘金的对比图，大家感受一下
某86网站：
掘金：
虽然前者更像一个瀑布，但是我喜欢后者丝滑般的体验。
我们再来仔细看这8个请求，相信细致的你一定发现了一个现象：
它们的共同点除了刚才提到的域名一样外，这些请求块的左右线都很短
有三个特别长的请求块，分别是1/5/8，需要格外关注
请求块的左右线都非常短是一个好现象，说明没有什么等待时间，所有时间都用在了传输数据上。
我们分别点击1/5/8请求块看它们的详情
这非常奇怪，1/5的资源大小和8的不在一个量级上，耗时却比8还多。
为了确定这是偶然的，还是必然的，我又录制了两次这个掘金个人主页的性能报告
这次和预期的基本一致，8耗时比其他都长，这个JavaScript文件3.9MB，太大了，很可能是性能瓶颈。
其他让我们继续往下分析，黄色JavaScript色块下面一共有三种颜色的色块：
紫色：CSS样式文件
绿色：图片文件
灰色：字体文件（大小为189KB）
这几个文件体积都不大，并且通过多次生成性能报告，发现这几个请求耗时都不如第8个JavaScript文件长，所以初步判断这些请求不构成性能瓶颈。