优化动机

移动端首屏原始表现附图

CDN未生效附图

优化实践

移动端FCS改善

PageSpeed问题定位

• 由于HF Space的部署是限定Dockerfile的方式，所以在github的commit后需要重新factory rebuild，不适宜快速测试，过程中先以netlify的做效果展示

• 抓大头，定位到一个对渲染影响极大的的内容，与获取字体的请求有关

无效依赖修改

• 跳转代码中定位，是对东亚三国语言安装对应的Noto CJK衬线与非衬线字体

• 按照配置用的FONTS_SANS去搜，找到对应的字体选择，发现Noto CJK的几个字体排在特别后面，甚至在system-ui后面，这怎么fallback也到不了Noto CJK这块，算是dead fonts了，字体也得tree-shaking一下 ）

• 重新检查网站上相关的字体设置，发现除了部分地方用到了IBM的字体，基本都是系统自带，且这个字体除了英文排列更紧密，没显得太多变化，于是同样删除

• 对其他依赖此对象的部分同样更新

检查修改是否可行

• 提交后检查网站中是否存在显示异常，基本都走本地系统字体，一般为微软雅黑，代码走Consolas，甚至网站唯一的平假名也能用微软雅黑正常显示

• 在不具备相同字体的移动端环境同样测试，正常工作

效果检验

• 修改结束，commit重测PageSpeed

• FCS从2.0s优化到1.3s

修改CF CDN/Worker配置

CF CDN调整过程

• F12检查请求中的CF缓存状态，发现是过期状态

• 查询发现，s-maxage是CF的CDN缓存时长，在没有进行额外操作的情况下查询为1，刷个新就过期了

• 打开CF对应域名的面板，找到Cache Rules，设置Edge TTL强制修改CDN缓存时长，顺带也把浏览器的缓存时长也改了

• 在另一浏览器里重新访问，尽管s-maxage仍为1，但已经被忽略，状态为HIT命中状态，其中CF-Ray指明Edge的区域，此处为SJC，美国，距离代理IP地理上较近

对比Netlify的海内外访问

• 先对比海外，以Dallas的US节点为参考

• 先Disable cache，检查发现Netlify Edge没有命中，最终是走到Origin命中Nextjs缓存，在Netlify Dashboard上没有看到直接缓存规则相关的设置，可以当做无CDN的原始速度来对比

• Netlify的Cache-Status取值介绍

• 以首页为benchmark，大概稳定在500-600ms的区间内

• 查看CF CDN状态，命中，地点在SJC，与测试的US节点对上

• 耗时在170~180范围内，偶尔跳到230左右

对比Netlify的国内访问

• Cache-Status相关状态仍然不变，结果仍为500ms-600ms左右

• CF命中，CDN位置在HKG，香港

• 耗时约80~100ms

对比Vercel海外访问

• 由于Vercel的域名校验需要上一级的控制权，比如对camelliav.cloudns.ch需要在cloudns.ch这一级加记录校验，而又不支持绑到xxx.camelliav.cloudns.ch（这样有其上一级控制权）这一级，所以只有海外对比，没有国内的

• 先检查Vercel，X-Vercel-Cache命中，CDN生效

• 几次测试结果大约在230-330间，偶有180，比CF的海外访问慢些

对比自身CDN前后

• 在CF的dashboard里purge everything清除所有CDN缓存

• 测试CF Cache MISS

• 出现几个600ms的耗时

• 再次请求后基本都控制在200出头

浏览器缓存

• 对于一部分文章的文档文件，由于

优化效果

• 移动端测试

其他结果

• PC端测试

其他结果

nobelium@1.3.0 analyse E:\Core\blog-merge\nobelium ANALYZE=true next build

可进一步的扩展