首页加载慢的四个坑：jsdelivr、3.5MB 字体和跑丢的 WPLANG

早上打开博客，首页转了三四秒才出来，滚动条一顿一顿的。想着顺手看看资源加载，结果一查，问题比想象中整齐——三个坑排成一队。

先量，别猜

老规矩，先看每个请求花了多久，而不是盯着页面感叹「怎么这么慢」：

首页总耗时       约 4.8s
argon_assets_path  →  jsdelivr 单个 JS  5.9s
自定义字体 echo     →  fastly.jsdelivr  4.3s（3.5MB）
前台语言           →  英文

三个问题挤在同一个页面里，彼此还互相掩护：字体慢拖住渲染，JS 慢拖住交互，语言出错则是另一个维度的毛病。

主题的 argon_assets_path 指向了 jsdelivr。理论上用公共 CDN 是好事，但现实是——国内访问 jsdelivr 的延迟和稳定性已经不是当年那个样子了。

实测单个 JS 文件就要 5.9 秒。一个页面几十个资源，串起来就是首页那几秒的空白。

修法：把资源路径改回本地，让静态文件从自己的服务器出。

这个更夸张。站点用的自定义字体 echo 通过 fastly.jsdelivr 加载，文件本体 3.5MB，下载耗时 4.3 秒。

字体是阻塞渲染的关键资源，浏览器在拿到它之前不敢把文字画出来——所以这 4.3 秒，用户看到的基本是一片空白。

改前：fastly.jsdelivr  →  4.3s
改后：本地同域         →  0.27s

提速约 16 倍

改成本地后 0.27 秒，同一个文件，差距只来自「从哪儿取」。顺带说一句，3.5MB 的字体本身也偏重，后续可以考虑做子集化，不过那是另一件事了。

检查过程中发现前台显示的是英文。这类问题通常不看代码，先看配置——WPLANG 这个选项缺失了。

WordPress 靠 WPLANG 决定前台语言，选项一旦不存在（不是空值，是不存在），它就退回默认的 en_US。

wp option get WPLANG
→ 空 / 不存在

wp option update WPLANG zh_CN
→ 前台恢复中文

问题全在配置层面——把便宜的本地路径换成了看起来很美的公共 CDN，结果换来了几秒的等待。

顺手检查时还发现音乐播放器不显示：xf-music-player 元素在 DOM 里存在，但 customElements.get('xf-music-player') 返回 undefined——自定义元素根本没注册成功，所以宽高为 0、彻底不可见。

这个和上面的资源迁移大概率有关（脚本没加载完，或者加载顺序变了），但还没修完，所以先记在这里，等解决了再单独写一篇。

教训就一句：提速先量，别先猜。如果凭直觉去改，很可能只动了那个 0.27 秒的字体，然后把 5.9 秒的 JS 继续留在那里。