6月30日老板召集部门开会，当时发生了一件很尴尬的事情，老板打开了台macBookAir，系统上的图标很老，估摸着还是雪豹那个时代的系统，然后打开了公司主站gulugulu.cn，奇迹发生了，网站居然卡在那需要10来秒才能打开，我很尴尬，但是还是很镇定的说应该是电脑系统太老了，老板打开了bilibili 和taptap的网站基本上都能在几秒内打开，脸上有些挂不住啊（我自信5月份将主站升级到Vue2.0之后性能已经有了质的飞越，多次测试都在3秒以内可以打开，没想到...），之后换了台较新的macbookpro后网站打开快多了，这让我很好奇为什么差别这么远，而bilibili和taptap在两台电脑上打开速度相差不大，之后我把bilibili和taptap首页所有资源全部做了一个统计，对比：
| 站点 | 图片 | js | css | 总资源 | 总加载时间 |
|---|---|---|---|---|---|
| gulugulu.cn(优化前) | ~3000kb | ~1800kb | ~400kb | ~5800kb | <=3.2秒 |
| bilibili.com | <900kb | <300kb | <20kb | <=1300kb | <=2.2秒 |
| taptap.com | <2000kb | <100kb | <109kb | <=2200kb | <=1.8秒 |
| gulugulu.cn(优化后) | <=1400kb | <=610kb | <=170kb | <=2400kb | <=2.5秒 |
当时分析出如下信息：
图片：
blibili页面内容长度大，没有大幅banner类图片，所有图片内容均做了懒加载，所以首屏加载时仅仅加载了显示屏区域内的图片，并且图片均做了两类适配，支持webp格式的显示webp，不支持webp格式的显示jpg，同事做了类似阿里云裁剪设置，图片最大的都不超过75kb，真心佩服。
taptap稍差一点，就内容而言并没有bilibili丰富，但是因为他们最大的图片有200kb左右，没有webp格式，同样他也做了懒加载，但是因为有大幅图片存在，所以首屏中图片已经达到了2000Kb。
最后说说我们gulugulu，惊喜的发现有一个小图片就有1300kb，我欲哭无泪，定是运营上传图片时没有压缩图片，向来自己动手。
1、首先我对从阿里云获取的图片做了统一的裁剪处理，设置宽度为容器的1.5倍高度自动，格式jpg，清晰度80%，添加类似这样的命令后缀即可@1e_120w_120h_1c_0i_0o_90Q_1x.jpg。
2、然后对本地图片全部通过tinypng.com压缩，后再次导入项目。
3、最后对大于10kb的icon尽量全部采用svg字体文件替代
最后测得首页所有图片即使没有做懒加载也不到1400kb（首页内容太少，几乎只有一屏，做懒加载没必要）除了最大的一个banner有200kb之外，其余所有图片均小于80kb
js && css：
因为框架是spa类型的框架，前端逻辑和依赖较多，js就会比taptap这类以后端架构为主的页面大很多，组件的按需加载早已经做过了,当时有段时间总觉得是因为自己代码写的不好导致的。
反复观察bilibili和taptap的载入情况后发现，他们都开启了gzip压缩，千方百计让运维重新过了一次nginx的设置，开启gizp后js大小下降非常明显最大的一个357kb文件在gzip5级压缩下，大小下降到了150kb。之后我将npm安装的第三方插件大部分转成了script标签引入方式，静态文件分配到若干cdn中，并做了dns-prefetch，dns预解析。终于将js降到了原来的1/3大小。之后又打开了cdn中的gzip和缓存策略，设置完成后测试网站首屏已经相当喜人，最快首屏可以到1.8秒左右。性能魔方测试结果排名16，平均载入时间<2.3秒。
之后优化方向
1、可能会加入懒加载和webp格式图片。
2、可能会尝试在vue中多书写公共样式，减少scoped样式，以减少css大小
- 相关项目
地址：gulugulu.cn
