现象#

Lighthouse 列出的最大单体资源：

1
/_astro/fonts/db738086d23374c1.woff2
2
resourceSize: 3,293,520 B（3.1MB）
3
transferSize: 约 2,088,846 B（压缩后仍有 2MB）
4
且带 rel="preload" 高优先级，与首屏图片抢带宽

根因#

项目里本来就有一整套字体子集化流水线（scripts/subset-fonts.ts，pnpm build 会执行），它扫描 dist/ 全部 HTML 收集实际用到的字符，生成 woff2 子集并替换引用、删除原文件。但配置里只登记了一个装饰字体：

1
subsetFonts: {
2
  "--font-greatvibes": { extraChars: "" },  // 只有它
3
}
4
// 而全站正文用的是（fontConfig.selected）：
5
selected: ["--font-hanyi-wenhei"],          // ← 没登记，直接漏网

子集脚本会跳过「未在 selected/区域字体中引用」的项，于是每次构建都打印 skip，原始 TTF 原样进了部署包。

修复#

src/config/fontConfig.ts 增加一行：

1
subsetFonts: {
2
  "--font-greatvibes": { extraChars: "" },
3
  // 全站正文主字体（selected 引用），不配子集化会原样输出 3.1MB TTF
4
  "--font-hanyi-wenhei": { extraChars: "" },
5
},

无需改脚本——pnpm build 链路里已有 astro build && npx tsx scripts/subset-fonts.ts。

验证与注意点#

• 构建日志出现 Generating subset ... 211.7 KB, original: 3216.3 KB, saved 93.4%
• dist/_astro/fonts/ 下生成 e3c41cafdc6bb33b.woff2（211.7KB），原始 TTF 被脚本删除
• 全站 53 个页面的 @font-face 与 rel=preload 均已替换为 type="font/woff2"，HTML 中 .ttf 引用为 0
• 浏览器实测：document.fonts 加载成功、中文渲染无豆腐块

已知取舍：子集只包含构建时 HTML 里可见的字符。密码/加密文章解密后的字符不在其中，这些页面正文会回退到 fallbacks（PingFang/雅黑）。介意可在 extraChars 手动补字。

现象#

报告写明「未预连接任何源」：图床 tu.mstzuomu.space、统计 cloud.umami.is、static.cloudflareinsights.com 都是 HTML 解析到一半才发现的，连接建立偏晚。

修复#

src/layouts/Layout.astro 的 <head> 最顶部（<meta charset> 之后）：

1
<!-- 提前建立第三方连接：图床图片、umami 统计、Cloudflare beacon 都在 HTML 解析中途才被发现 -->
2
<link rel="preconnect" href="https://tu.mstzuomu.space" />
3
<link rel="preconnect" href="https://static.cloudflareinsights.com" />
4
{analyticsConfig?.umamiAnalytics?.websiteId && (
5
  <link rel="preconnect" href="https://cloud.umami.is" />
6
)}

注意：这三行会改变 HTML 的行号——后文 E 项定位 Lighthouse 坐标时会看到所有行号整体偏移，此为预期内现象。

现象与根因#

封面走远程 <img> 直出：src/components/common/CoverImage.astro 对所有 http(s) 图片输出裸 <img>，不经过 Astro 的优化管道。单张封面 2169×569 JPEG 约 330KB，实际显示只有 1350×300——格式（该转 WebP）和尺寸（超 3 倍）双重浪费，Lighthouse 估算 5 张可省 1.16MB。

排查：图床支持什么转换？#

图床是自建的 CloudFlare-ImgBed（CF Workers + Telegram 存储）。探测过程：

1
# 1. 直接试尺寸参数 → 403
2
curl "https://tu.mstzuomu.space/file/文章/xxx.jpg?width=1656&fallback=original"
3
# → 403 "Image resizing is disabled"   # 功能存在但默认关闭！
4

5
# 2. 查官方文档（cfbed.sanyue.de/api/file.html）
6
#    支持 width/height/fit/fallback 参数；JPEG/PNG/WebP 源 Worker 部署可处理；
7
#    开启路径：dashboard → 系统设置 → 安全设置 → 访问管理 → 图片尺寸处理
8
#    允许尺寸：留空 = 任意合法值
9

10
# 3. 后台开启后复测
11
width=1656 → 141KB   （原 330KB，-57%）
12
width=828  → 48.5KB  （-85%）
13
format=webp → 被忽略（该版本只改尺寸不转格式）

博客端实现（4 个文件）#

1. 配置开关（src/config/siteConfig.ts）：

1
imageOptimization: {
2
  // ...原有配置
3
  // 支持尺寸处理的远程图床域名（后台需开启"图片尺寸处理"）
4
  resizeHosts: ["tu.mstzuomu.space"],
5
},

2. 工具函数（src/utils/image-utils.ts）：

1
export const RESIZE_WIDTHS = [828, 1656] as const;
2

3
export function canResizeRemote(src: string): boolean {
4
  if (!/^https?:\/\//.test(src)) return false;
5
  const hosts = siteConfig.imageOptimization?.resizeHosts || [];
6
  if (hosts.length === 0) return false;
7
  try { return hosts.includes(new URL(src).hostname); }
8
  catch { return false; }
9
}
10

11
export function buildResizeUrl(src: string, width: number): string {
12
  try {
13
    const u = new URL(src);
14
    u.searchParams.set("width", String(width));
15
    u.searchParams.set("fallback", "original");
16
    return u.toString();
17
  } catch { return src; }
18
}

3. 渲染（CoverImage.astro 远程分支）：白名单域名输出 srcset 双档 + 真实显示宽度的 sizes + 回退数据属性：

1
const resizeSizes = preview
2
  ? "(max-width: 768px) 100vw, 770px"    // 列表卡桌面约 680-770px
3
  : "(max-width: 768px) 100vw, 100vw";   // 详情页封面全宽
4

5
<img
6
  src={remoteImgSrc}                          /* 1656 档 */
7
  srcset={resizeSrcset}                       /* "…828 828w, …1656 1656w" */
8
  sizes={useResize ? resizeSizes : undefined}
9
  data-resize-fallback={useResize ? remoteSrc : undefined}
10
  ...
11
/>

sizes 有个坑：本地图沿用的旧值写死了桌面 320px，单档产物无影响，但双档 srcset 下 Retina 屏会错选 828w 导致发糊——所以尺寸变体必须用真实显示宽度（770px）单独给一套。

4. 保险丝（CoverImage.astro 脚本的 onError）：尺寸版加载失败（如图床后台开关被关）时一次性回退无参数原图：

1
const resizeFallback = img.dataset.resizeFallback;
2
if (resizeFallback && !img.dataset.resizeRetried) {
3
  img.dataset.resizeRetried = 'true';
4
  img.addEventListener('load', hideLoading, { once: true });
5
  img.addEventListener('error', onError, { once: true });
6
  img.removeAttribute('srcset');
7
  img.src = resizeFallback;
8
  return;
9
}

验证#

• 浏览器 Network：封面请求全部带 ?width=828（DPR1 选小档），加载成功
• 保险丝实测：手动把 src 改成 404 → 自动回退原图 → 加载成功、无错误态、不循环
• mi-fds 域名的 2 张封面不在白名单，保持原样输出（预期行为）

现象#

首页 head 里 3 个阻塞请求：Layout.css（原始 196KB / 传输 28.7KB）、MainGridLayout.css、全局 CSS，Lighthouse 估算拖慢首屏 220–250ms——浏览器必须等它们下载解析完才画第一笔。

修复#

astro.config.mjs 顶层（Astro 配置，不是 vite.build！）：

1
// Astro 构建行为：全部 CSS 内联进 HTML（非 vite.build）
2
build: {
3
  inlineStylesheets: "always",
4
},

踩坑记录：我第一次把这个键写进了 vite: { build: { ... } } 块里——那是 Vite 的配置，不认识 inlineStylesheets，静默无效，白构建一轮。判断依据是检查产物里 <link rel="stylesheet"> 是否归零。

前置安全检查#

内联前必须确认三个 CSS 没有 url() 引用（否则内联到嵌套路径页面会相对路径断裂）：

1
# 扫描 dist/_astro/*.css 的 url( 引用
2
# 结果：三个阻塞 CSS 均为 0 处 → 内联无风险
3
# （带 url() 的 KaTeX/fancybox 是按需加载的非阻塞样式，不在范围）

验证与取舍#

• 首页 <link rel="stylesheet"> 数量：3 → 0
• HTML 原始体积 370KB → 608KB（+237KB ≈ 三者之和；gzip 后约 +38KB）
• 文章页直连、swup 切页、视觉截图均正常
• 取舍：CSS 不再单独缓存，每多看一页 HTML 多带约 38KB——换来首屏少 3 个请求，对博客访问形态是划算的
• 残余：文章页 body 尾部还有个 8.9KB 的 twikoo-custom.css（评论区样式，解析位置在正文后，不挡首屏）和 fancybox 两个运行时注入的 link，都不在阻塞路径上

方法论：怎么抓到强制重排的真凶#

强制重排 = JS 在脚本执行中读取几何/样式，浏览器被迫当场同步全量结算。坐标解读是最大的坑，先立规矩：

1. 本地跑 Lighthouse 单审计（线上报告的行号会随每次构建漂移，必须在当前产物上重测）：

1
# 用 Edge 当 Lighthouse 的浏览器（本机没装独立 Chrome 时）
2
$env:CHROME_PATH = "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
3
npx --yes lighthouse "http://127.0.0.1:8931/" `
4
  --only-audits=forced-reflow-insight --output=json --output-path=lh.json `
5
  --chrome-flags="--headless=new"

2. 以 CDP Tracing 全栈为准（Lighthouse 只给聚合后的 line/column，且行号 0-based、列号时而脚本内相对——单独解坐标会绕死）：

1
// Playwright run_code：抓带堆栈的 Layout/UpdateLayoutTree 事件
2
const cats = 'disabled-by-default-devtools.timeline,'
3
  + 'disabled-by-default-devtools.timeline.stack,'
4
  + 'disabled-by-default-devtools.timeline.frame';
5
// Tracing.start(ReportEvents) → goto + 等待 → Tracing.end
6
// 过滤 name 为 Layout/UpdateLayoutTree 且有 stackTrace 的事件，
7
// 按 dur 排序；stack[0] 是最内层帧 = 真正读取者

3. 模拟 Lighthouse 的测量条件（否则数字对不上）：Lighthouse 默认移动视口 + 4 倍 CPU 降速——

1
await client.send('Emulation.setDeviceMetricsOverride',
2
  { width: 412, height: 823, deviceScaleFactor: 2.625, mobile: true });
3
await client.send('Emulation.setCPUThrottlingRate', { rate: 4 });

六个根因与对应修复#

1
if (document.fonts) {                    // 只判断对象存在（不触发）
2
  afterFirstPaint(() => {
3
    document.fonts.ready.then(...)        // getter 访问推迟到 FCP 后
4
  });
5
}

1
// 设计要点（缺一不可，都有实测依据）：
2
// 1. 轮询 performance.getEntriesByType('paint') 中的 first-contentful-paint，
3
//    而不是双 rAF——弱性能设备首帧可能被丢弃，rAF 链会在真实绘制前跑完；
4
// 2. 每帧只放行一个回调（串行队列）——所有回调挤同一帧会互相弄脏：
5
//    前一个的写入让后一个的读取再次强制结算（实测 Waves 读前序回调的脏样式 29-31ms）；
6
// 3. 超时兜底 120 帧，防 paint 条目异常时回调永不执行。
7
export function afterFirstPaint(cb: () => void): void { /* 见仓库源码 */ }

排查过程中的三个大坑（后人必读）#

1. MCP 浏览器窗口被遮挡 = 测量全部失真：遮挡窗口的 Chromium 会暂停绘制 + rAF 压到 2fps，表现为 paint 条目永远为空、所有门闩「不触发」、滚动功能「全坏」。page.bringToFront() 一秒复活（101fps + paint 条目齐全）。做帧率/绘制相关测量前必须先置前窗口。
2. 先做基线 A/B 再怀疑自己：修到中途滚动类效果全灭，用 git stash 丢弃改动构建基线版同环境实测——基线一模一样，证明非本次回归（是环境问题），避免了整段回滚。
3. PowerShell 引号吞噬：复杂内联脚本（python -c、正则带引号）会被啃得面目全非，一律落盘成临时脚本文件执行。

结果#

改动：14 文件修改 + 1 新文件，+280/−121，commit d6ceae0a。

症状与排查设计#

同机、同站、同引擎（Chromium 154），只有真 Chrome 掉帧，Edge 正常。这个「同引擎不同表现」本身就是最强线索：嫌疑必然在两者各自的运行环境，而非站点代码。

第一轮：站点侧压力矩阵（本机 Chromium，前台窗口）

站点在默认设置的 Chrome 系浏览器下压不出掉帧。

第二轮：真 Chrome vs 真 Edge 同机对打（决定性实验）

用 Playwright 分别以临时 profile 启动两个真实浏览器 exe，跑完全相同的滚动帧率 harness（4 秒三角波滚动，统计帧间隔）：

1
// 核心：launchPersistentContext + executablePath，各自临时 user-data-dir
2
const ctx = await chromium.launchPersistentContext(tempDir, {
3
  executablePath: "C:/Program Files/Google/Chrome/Application/chrome.exe", // 或 msedge.exe
4
  headless: false,
5
  viewport: { width: 1728, height: 1080 }, deviceScaleFactor: 1.5,
6
});
7
// 页面内 harness：rAF 记录帧间隔，每帧 scrollTo 三角波滚动 4s，
8
// 统计 fps / jank(>25ms) / jank(>50ms) / worst / p95

结果：Chrome 99.9 FPS / Edge 99.9 FPS，双双零掉帧。
这一步同时排除了「Windows 每应用 GPU 指派」（系统级设置对 exe 生效，测试用的就是你的真 Chrome）。

第三轮：读真 Chrome 的配置文件（只读排查，不用开浏览器）

1
# Chrome:  %LOCALAPPDATA%\Google\Chrome\User Data\Local State
2
# Edge:    %LOCALAPPDATA%\Microsoft\Edge\User Data\Local State
3
json.load(...)["hardware_acceleration_mode"]

扩展数 0、退出状态正常——唯一差异就是这个开关。

根因与修复#

Chrome 关闭了硬件加速 → 6 层 backdrop-filter 毛玻璃、全屏壁纸滚动模糊渐变（blurRamp）、波浪 canvas 的全部合成工作由 CPU 软渲染 → 滚动掉帧；Edge 默认开 → GPU 合成 → 流畅。

修复（用户操作，一分钟）：

1. chrome://settings/system → 开启「使用硬件加速模式」→ 重启 Chrome
2. chrome://gpu 确认 Canvas / Compositing / Rasterization / Video Decode 全部 Hardware accelerated
3. 实测确认恢复正常 ✅

为什么我的自动化测试一直测不出问题：新开的 profile 用默认值（硬件加速开），测的是健康态的 Chrome。真凶藏在你日常 profile 的 Local State 里。