记一次虚晃一枪的网站优化

    简单的对博客数据装载进行了调优分析，以尽量加快数据装载与页面渲染的速度。虽然结果让人忍俊不禁，不过探索的过程还是值得记录的。

    首先是要明确的是找到导致数据加载缓慢的原因。通过 F12 的 Performance 可以解析获得。打开浏览器空白页（浏览器首页而非搜索引擎首页，以免其他数据干扰导致不易排查起点），在空白页按下F12打开开发工具页面，在network禁用cache，选择到performance，在地址栏输入需要排查的网址（先不要回车），点击如下左图所示的录制键，立即在地址栏回车访问，等到页面加载完毕后（刷新按钮不转圈），立即点击录制键以停止录制，可以得到完整的浏览器渲染过程。

    我们先找到主加载项（即访问的地址），找到调用树call tree分析项。可以发现其实整体的调用速度还算可以。主要还是网络请求获取资源上比较慢。

    展开network项，我们来详细分析每个资源加载的情况。从图中容易看出来，首先装载了的css和js的文件；等到主要的js和css装载完成开始装载页面的整体框架资源，比如我这里的avarar.jpg头像文件就在这里开始获取，还有音乐组件所要加载的数据api.i-meto.com；然后按照装载顺序开始获取网页正文资源，比如我这里访问的是某篇博客的内容，需要先调用接口 /api/blog/id 来获取博客原文，等原文获取并且基本渲染后如果有图片则开始请求博客图片，期间还装载了博客页面评论区的gif动图look.gif。

    由图标记可以看到，主要加载较慢的地方有几个。

    ① 网站js和css文件较为缓慢。

     ② avatar.jpg 网站头像文件非常大，请求服务器资源时间较长（浅绿色块）

     ③ 音乐接口调用缓慢

     ④ 请求正文的/id接口访问较为缓慢

     ⑤ 博客页面的look.gif装载太慢

    ⑥ avatar.jpg 网站头像文件非常大，从服务器下载资源时间较长（绿色块）

    ⑦ 获取博客正文图片较为正常

    下面是一些优化方案。

    首先是①，一方面尽量减少不必要的依赖引入，以减少包体积，一方面也有考虑过使用cdn来解决，不过这样会有很多隐性问题，暂且不优化。

    对于②和⑥而言，只需要把图片压缩即可，通过压缩，将原本 158KB 的图片 压成了 3.27KB ， 这里就没做cdn装载了，毕竟压缩后的图片已然很小了，不大吃资源了。

    接着来看③。先简单介绍下网站播放器组件组成，首先是Aplayer只是一个单纯的音乐播放器，本身只是个播放器样式组件，然后是MetingJS，是一个汇总三方音乐平台的项目，并且组合成了一个接口，其本身绑定使用Aplayer播放器组件。对于引入MetingJS所需要的APlayer.min.js、Meting.min.js以及APlayer.min.css这些静态资源，我全部放在了博客园挂载（很早期的方案了，那时候我还没有自己的cdn站点，然后jsdelivr在国内又不稳定，所以找了很多挂载的方案，最后发现博客园可以挂载静态资源，目前来看访问速度还不错，就一直没有换了），目前看起来访问速度还不错，无需优化。而metingJS所访问的自己的接口api.i-meto.com（依据参数获取指定三方音乐平台的播放列表），如果要实现快速的加载的话，只能我后端获取该接口数据保存至数据库/redis/内存中，转放出自己的接口，然后 修改 MetingJS 默认的调用接口即可，嘛，虽然不麻烦，但是暂且也还不想这么折腾，后续再来优化这一步了，这次这个就先保留原因逻辑不做优化。

    来到⑤，这个gif图片原本也是放在网站根目录下的，服务器带宽较小，装载这个gif图片比较慢，所以就直接放在了cdn站点加载了。

    至于⑦，装载的一系列博客正文图片，目前来看速度似乎还行（毕竟是访问的cdn站点，走的cdn流量），暂且先不优化，不过也有优化方案，图床站支持对图片自由压缩处理，只需要加上自定义的后缀就可以获得压缩后的资源了，让正文默认展示压缩后的图片，点击图片后显示原画质图片，让博客本身访问速度进一步提高，提高访问舒适度。

    最后④，在performance看的不明显，到network来看请求过程，发现浏览器处理请求发送和下载速度都很快（毕竟简单的接口请求，纯文本内容，没多大资源量），主要是卡在了服务器处理过程，大概率是服务器的锅，具体原因后文分析，先且给出的方案是服务器将博客数据进行redis缓存，以此来加快访问速度（直接全部缓存，毕竟个人博客这点数据量而言，redis还是吃得消的，全部缓存，让所有文章都可以快速的装载）。


    方案实施。

    从上面的一些总结来看，最终需要优化的点是这几个：②④⑤⑥。其中②⑥压缩图片无需多描述，随便找个在线压缩网站或者本地画图调整大小保存都可以压缩，⑤挂载在cdn站点也无需多追加描述。所以接下来只需要调优④优化接口返回。

    我们对后端程序打上监听，因为是springboot项目，可以使用Arthas进行监听。启动arthas后，使用tt进行接口监听。调用多轮发现~以外的、还不错（），服务器处理貌似也能稳在80ms左右，这样来看导致waiting for server response过长的原因并非是服务器处理速度的原因，而是、客户端的网速过慢，导致请求打到服务器太慢了，这样一来，貌似这也不需要优化了，前面的推测不成立。

    怀揣着怀疑的心情，将②⑤⑥优化好后的前端代码重新打包部署，分析。

    emmm。绿色的图片资源加载占比确实几乎可以忽略了，但是可见的，几个接口调用以及js文件加载依然耗时很长。于是在想会不会是网络波动？重新再试一个。

    这次，站点的接口访问速度倒是很快了，比较慢的就只有js和三方接口地址了。好嘛，貌似~优化了个寂寞、、、就当作是以此优化思路作为记录吧。

    算是虚晃一枪的优化。