基于 v-lazy-load 做了懒加载优化后，提交了一个版本给测试伙伴进行验证，这时候遇到了一个问题：

那就创建一个预发布环境支持上 CDN 加速，就齐了

且慢，运维伙伴反馈：

为了达到套餐内能实现预发布环境部署来验证实际的优化效果，我们内部决定要做一轮 域名收敛 专项。经过这样的处理后，将原始的 *.thethinkacademy.com 的路径统一调整为 thethinkacademy.com/* 来节省域名资源。

经过这一轮调整后，终于可以来验证一下之前的优化改动的效果了。

经过回归测试发现，没有明显的改善，新加坡的还在另一个指标上下降了 😦

我们现在使用 webpagetest 来进行性能测试，在之前的团队里我和伙伴们还做过基于 lighthouse 的性能分析和优化，这次也综合参考了部分 lighthouse 的分析结果来改进。

一起看一下 webpagetest 的衡量指标：

• Security Score

• First Byte Time

• Keep-Alive

• GZIP text

• Compress Images

• Use Progressive JPEGs

• Cache Static

• Use A CDN

其中 Security Score First Byte Time   Cache Static 分均为 F 最低，其中 First Byte Time 是很重要的一个指标，即服务端开始给浏览器返回数据的标示；相比这个指标其实 lighthouse 的 首屏渲染 其实更有价值，现在先依据 webpagetest 的标准来进行优化。

一般来说性能不好，无外乎这么几个点，其中非常容易做的就是静态资源的压缩和格式转换，通过 lighthouse 分析可以发现，有一些大尺寸图片以及一些体积巨大（600KB+）的图片资源存在，这些资源对于加载性能影响巨大，需要消灭。

如何优化图片体积，通过 webspeedtes.cloudin ary.com 来分析可以得到一个非常不错的结果：

结果来看采用 AV1 编解码的图片格式 AVIF 一骑绝尘，但别忘了这个新格式在浏览器的支持上还不够，不能直接默认启用，还需要考虑 fallback 方案，而 webp 也是 Google 在推进的图片格式同一样有不错的表现，但同样为了做到各种浏览器的普适性，webp 都是一个需要考虑 fallback 方案的格式。这么一来，从项目的时间风险来看需要考虑如下方案：

A. 采用原格式进行图片压缩；

B. 采用 JPEG2000 进行格式转换（大部分情况下表现同样亮眼）；

C. 采用激进的 AVIF、webp 格式同样考虑 fallback 格式。

为了支持多种图片格式，需要将 <img> 换成 <picture> 

<picture>  <source srcset="mdn-logo.svg" type="image/svg+xml">  <source srcset="mdn-logo.avif" type="image/avif">  <source srcset="mdn-logo.webp" type="image/webp">  <img src="mdn-logo.png" alt="MDN"></picture>

通过图片压缩工具 pngquant 可以将 1MB 的文件压缩到 400KB± 整体效果还是比较可观的，而且处理起来的成本并不高，因此这个 A 计划作为这个项目的首个版本会优先上线，后续增加对于 avif/webp 格式的尝试来进一步节省空间和流量，到时候会进一步分享这部分的经验。

安全性得分部分，根据测试结果的说明，可以较快确认解决方案:

  app.use(async (ctx, next) => {    ctx.set('Strict-Transport-Security', 'max-age=63072000')    ctx.set('X-XSS-Protection', '1; mode=block')    ctx.set('X-Frame-Options', 'DENY')    ctx.set('X-Content-Type-Options', 'nosniff')    await next()  })

<meta http-equiv="Content-Security-Policy" content="default-src https: http: 'self' 'unsafe-eval' 'unsafe-inline'; img-src data: https: http: 'unsafe-eval' 'unsafe-inline'; child-src https: http:; script-src https: http: 'unsafe-eval' 'unsafe-inline';">

应用上面的代码改动后，安全得分直接升级到 A

在后面测试过程中首屏加载时间指标在 A 和 B 之间反复出现，通过分析结果来看出现在 JavaScript 以及 CSS 文件过大，而这部分的优化则是一个相对复杂的过程，通过 webpack 打包的分析可以发现：

moment 以及 monent-timezone 是最大的那个包

前面 2 个 200KB+ 的包就是 moment 以及 momen t-timezone 真愁人，我查看了一下代码里具体是如何使用 moment 以及 moment-timezone 的，发现其实我们并不需要这么一个庞然大物来解决我们遇到的问题，本来还计划基于 Intl 来自己做一套满足要求的精简版本来替代 moment 以及 moment-timezone 不过在调研的过程中，发现了 luxon 。

通过项目地址 moment.github.io/luxon 可以发现，其实也是出自 moment 团队的项目，这么一来不需要自己重复造轮子了，经过一些代码的改动，包括查阅文档，通过了完整的编译构建后，可以看看最终的结果：

优化了将近 200KB

对于 JavaScript 以及 CSS 的体积优化是一个相对中长期的过程，中间需要较多的代码整理、重构、甚至重新的技术选型。后面会继续做这方面的尝试和分享。

在使用 luxon 替换 moment 的过程中已经遇到了多处重复代码实现同样的逻辑，这种就需要遵循 DRY 原则将他们消灭掉。