InfoQ我们怎样将官网的加载时间缩短 1.7 秒？( 二 )
不过 ， 我们还没有做好永久改变的准备 。 Optimizely 的工作方式是 ， 如果对实验做了更改 ， JavaScript 代码段会在 Optimizely 服务器上更新 。 更改可能是开始 / 暂停一个实验 ， 修改一个实验等等 。 你所做的任何更改都会生成新版本的 JavaScript 文件 。
因为只是在生产环境中加载了手动复制的 JavaScript 文件的静态副本 ， 所以我们不能一直保存它 ， 因为那样我们就永远无法开始 / 暂停实验 。 对软件工程师来说 ， 每次更改时都要手动复制新文件 ， 这相当麻烦 。
所以 ， 既然我们看到这种方法的好处 ， 就必须弄清楚如何从我们自己的服务器动态加载最新版本的 Optimizely 代码段 。
本文插图
为此 ， 我们创建了一个每 60 秒运行一次的 AWS Lambda 。 当运行时 ， 它会向 optimizely.com 发送一个 JavaScript 文件请求 。 它创建文件的散列 ， 并检查 S3 以确定散列是否变化（我们将上次执行时的散列存储在 S3 上的一个文件里） 。 如果散列发生变化 ， 则将新的 JavaScript 文件保存到 S3 ， 文件名中包含散列的一部分（例如：snippet-c36d504bc3c26479f1181e6119617a64.js） 。 接下来 ， Lambda 将散列发送给我们 Fastly 边缘服务器上的一个字典 。 这就是奇妙之处 。 我们将边缘服务器配置为 ESI（ Edge Side Include ）和边缘字典的组合 ， 动态地将最新的 Optimizely JavaScript 文件名插入到边缘服务器提供的每个页面的 HTML 中 。 这让我们可以在边缘处更新对 Optimizely 文件的引用 ， 而不必每次文件更改时都重新部署网站 。
以下是 WebPageTest 的截图 ， 它测量的是由 Casper 托管的新 Optimizely 文件的性能：
本文插图
下面是通过 WebPageTest 收集到的自托管前后的数据对比：
本文插图
理想情况下 ， 对于这些值 ， 我们会提供实际用户监控（RUM）的 95 百分位数据 ， 但对于 casper.com ， 我们还没有完全实现这一点 。 据推测 ， Optimizely 托管的时间（我们不确定是好是坏）和 Casper 托管内容的下载时间会有一些波动 ， 因为这是合成测试 。
这是一个 Chrome 瀑布流 ， 显示了在 casper.com 和 Optimizely 文件上运用 HTTP2 多路复用的效果 。 请注意 ， 前 5 个资产的内容下载几乎是在同一时间开始的 。
最后 ， 如前所述 ， 自托管让我们能更好地控制缓存 。 我们将边缘服务器配置为将文件在边缘和浏览器缓存中保存整整一年 。 之所以能这样做 ， 是因为文件名对于内容是惟一的（我们将文件散列的一部分添加到文件名中） ， 并在内容更改时替换对文件名的引用 。 这样 ， 如果我们不对 Optimizely 代码片段做任何修改 ， 重复访客的浏览器甚至不会向 casper.com 请求文件 。 相反 ， 它将直接从用户文件系统的缓存中提取文件 。 超级快！
本文插图
如下图所示 ， 你可以看到从浏览器缓存提供文件的好处：
这种方法的缺点是 ， 当我们频繁地修改 Optimizely 的代码段时 ， 网站访问者将无法体验到最优缓存 。 随着业务增长 ， 我们的数据分析师可能会运行更多的 a/b 测试 ， 这就需要频繁地修改文件 。 这可能导致网站访问者在访问 casper.com 期间需要下载多个版本的文件 。 我们在一个自定义的 DataDog 仪表盘跟踪 JavaScript 文件的每次修改：
推荐阅读
- InfoQ|从编译原理出发，看看你和资深 coder 差在哪儿？| 极客时间
- 圳优信息|“副业刚需”的时代，怎样发展副业才靠谱？
- 三易生活|即使在新款手机中，我们可能也避不开这些烦恼
- |联发科：我们一直很守规矩，华为事件纯属不符
- |我们试了试秒抢罗永浩直播的外挂神器
- 大肥皂|一个让我们连喊「YES」的手机，iQOO Z1体验评测
- 央视网|倒计时！火星，我们来了！
- 环球火力|2020 年北斗将覆盖全球，性能如此优秀，我们的手机何时才能用上？
- 雪山趣闻|联想红米荣耀都在发力，当轻薄本大势所趋，我们该做何准备？
- |实际评测告诉你，拥有一款华为智能眼镜是一种怎样的体验？