研究报告 · 约 30,898 字 · 预计推送 4 部分

前端性能工程：Core Web Vitals、图片优化、代码分割、缓存与静态部署 —— 横纵综合报告 未开始

目录

题记与说明

修订说明（最终稿）：本报告由同课题两份章节卷综合修订而成——纵轴卷《前端性能工程纵向发展史》与横轴卷《前端性能工程横向对比报告》，两卷的检索与核实动作均于 2026-10-31 完成。凡沿用纵轴卷标注"†"者，指该卷检索中未单独验证、来自模型既有知识的背景事实；凡标注"第三方口径"或"厂商口径"者，数字来自转述而非官方一手来源，建议复核原始链接。两卷之间的事实出入（JPEG XL 支持状态、Vite 8 时间线、Web Almanac 引用口径）已在第 3.2 节逐条调和。本最终稿按独立审读意见（共 8 条）于 2026-10-31 对同日初稿逐条修订：悬空交叉引用改指 3.2 节、"Rust 化"表述改为"Go/Rust 化"、Page Experience 时间统一为 2021 年年中口径、清单归属按两卷原文逐项对齐、头条数字补可查来源或删值留方向、参考来源断链逐条补链、含糊表述与漂移数字统一口径，并新增平台二选一默认推荐、"最小可行 10 项硬门槛"（清单版本 v2026.10）与两段最小代码示例（3.4 节），完整版检查表降为附录 A。初稿中未被质疑的内容未删改。

TL;DR

三十年主线：指标从实验室规则走到真实用户 P75（CrUX/CWV；2024 年 INP 换掉 FID）；图片十年一换代，JPEG XL 2026 年回归三引擎；代码分割从打好 JS 到打得更快（Go/Rust），再到干脆不送（Astro 岛屿）；缓存与部署持续普惠。

2026-10 共识：度量 PSI 起步、CrUX P75 考核、web-vitals 补盲区；图片构建期产出 AVIF/WebP；打包交给 Vite 8 或 Turbopack；部署默认 Cloudflare Pages（判据见 3.3；纯静态零运维的例外是 GitHub Pages），指纹长缓存加 HTML 短缓存。个人博客：内容站不背运行时框架，正文页零框架 JS；INP 最难过关（第三方口径约 43% 未达标，来源见 2.2）；JPEG XL 只作渐进增强。

一、纵轴：发展脉络

1.0 阶段总览

阶段时间主线关键词
一1995–2007奠基：HTTP 缓存语义、CDN 诞生、第一条性能军规RFC 2616、Akamai、YSlow
二2008–2013规则工具化与静态复兴的种子Jekyll、WebP、Speed Index、Hugo
三2014–2016标准大战与平台化webpack、picture/srcset、HTTP/2、PWA、JAMstack、Next.js
四2017–2019真实用户度量CrUX、FID、动态 import、原生懒加载
五2020–2022 上Core Web Vitals 成为行业宪法Web Vitals、Page Experience、Vite、AVIF、Astro
六2022 下–2025INP 换血与 Rust 工具链Turbopack、INP 正式、JPEG XL 退场、Rolldown
七2025 末–2026.10当下：边缘整合与格式轮回Vite 8、Cloudflare×Astro、JPEG XL 回归

1.1 阶段一（1995–2007）：奠基——缓存语义、CDN 与第一条军规

HTTP/1.1 在 1997 年的 RFC 2068、1999 年的 RFC 2616 中确立了现代缓存的全部核心语义：Cache-Control、Expires、ETag/If-None-Match、Last-Modified（来源：RFC 2616）。此后二十多年，"缓存与静态部署"这条支线的本质，都是在教开发者正确使用这套 1999 年就定下的语义；2022 年 6 月它才由 RFC 9111《HTTP Caching》单独成册。1998 年 8 月，MIT 研究者 Tom Leighton、Danny Lewin 创立 Akamai，开创"内容分发网络（CDN）"品类，把静态资源复制到离用户更近的边缘节点（检索确认其 1998 年成立并被视为 CDN 模式开创者）。

2007 年，Yahoo! 性能团队负责人 Steve Souders 出版《High Performance Web Sites》，提出 14 条军规（减少 HTTP 请求、用 CDN、加 Expires 头、Gzip、CSS 置顶、JS 置底等）并配套 YSlow 工具；"性能黄金法则"——页面加载时间约 80% 花在前端——由此成为行业共识（来源：O'Reilly 图书页、Souders 本人阐释）。主要参与者为 IETF、MIT/Akamai 创始团队与 Yahoo! 异常表现团队；驱动因素是拨号/早期宽带时代的慢网络、门户网站与广告业务对首屏时长的直接收入敏感，以及"缓存语义已就位但缺乏使用手册"的空档。

1.2 阶段二（2008–2013）：规则工具化，静态复兴的种子

2008 年 11 月，GitHub 联合创始人 Tom Preston-Werner 发布 Ruby 静态博客引擎 Jekyll（"Blogging Like a Hacker"），同年 GitHub Pages 上线，"把博客编译成纯静态文件再托管"从此成为极客传统（来源：Wikipedia: Jekyll)、Cloudflare 纪念文）。前端模块化同步萌芽：RequireJS/AMD（2009，James Burke）†、Browserify（2011）†让"前端代码分割"第一次成为可实践的话题——虽然当时的目标只是把模块搬进浏览器，而非性能。

2010 年 9 月 27 日，Cloudflare 在 TechCrunch Disrupt 亮相，把巨头级的 CDN 与缓存能力以免费层开放给所有人，为十年后个人博客的"零成本边缘部署"埋下伏笔（检索确认 2010 年 9 月发布）。同月 30 日，Google 发布 WebP：基于 VP8 的图像格式，官方宣称比同质量 JPEG 小 25–34%，图片优化进入"格式换代"纪元（发布文见参考来源：Google Open Source Blog；后续 Google Play 2014 年用无损 WebP 替换 PNG 缩小约 35%）。2009–2010 年 Google 推出 Page Speed 扩展与 mod_pagespeed†，Yahoo 军规从此有竞品；约 2012 年，WebPagetest 的 Pat Meenan 提出 Speed Index，用"视觉完成度曲线"度量首屏快慢。2013 年，Steve Francia 用 Go 写下 Hugo，静态站点生成器进入"毫秒级构建"时代（检索确认）。

驱动因素：智能手机爆发让"页面太重"从体验问题变成流量资费问题；Git 托管平台让静态部署几乎零成本；Google 出于广告与搜索体验利益，开始系统性地"经营"网页性能。

1.3 阶段三（2014–2016）：标准大战与平台化

代码分割主引擎出现。 Tobias Koppers（sokra）2012 年启动 webpack†，2014–2015 年借 React 生态成为事实标准†；2015 年 Rich Harris 发布 Rollup——首个实现 tree shaking 的主流打包器，只打包真正被引用的代码（来源：Harris 的 tree shaking 论战文）。

响应式图片标准落地。 2012 年 Responsive Images Community Group（RICG）成立，抗议"给手机发桌面大图"；经过多年浏览器博弈，srcset 随 Chrome 34 上线（2014 年 2 月），<picture> 配合处理艺术指导/格式切换，Firefox 38、Safari 9 相继跟进（2015）（来源：Chromium 官方博客、W3C RICG、Smashing Magazine 指南）。

传输层换代。 HTTP/2 于 2015 年 5 月定稿为 RFC 7540（源自 Google SPDY†），多路复用让"域名分片、雪碧图"等 HTTP/1.1 时代技巧一夜过时；Brotli 压缩 2016 年随 RFC 7932 标准化，当年即获 Chrome 50、Firefox 44 支持（初期仅限 HTTPS），比 gzip 通常再省 14–20%；2022 年 6 月 HTTP/3（RFC 9114）接棒，基于 QUIC/UDP 消除 TCP 队头阻塞。

离线能力与静态部署平台化。 Service Worker 2015 年落地 Chrome 稳定版（约 v45）；2015 年 6 月 15 日 Alex Russell 与 Frances Berriman 提出"Progressive Web App"一词（来源：Russell 原文）。Mathias Biilmann（Netlify CEO）同年发明"JAMstack"一词（JavaScript + APIs + Markup），Netlify（2014 年创立†）开创 Git 推送即部署；ZEIT（Guillermo Rauch 创立†，2020 年改名 Vercel）随后跟进，2016 年 10 月 25 日发布 Next.js 1.0（来源：Next.js 1.0 发布文、Wikipedia: Next.js）。Let's Encrypt 2015 年 12 月公测、2016 年 4 月 12 日正式 GA，免费证书让"HTTPS-only"从大厂专利变成个人博客默认（来源：ZDNet 报道）。

Google 的两条急行军。 2015 年 10 月 7 日宣布 AMP，2016 年 2 月 AMP 页面进入移动搜索与 Top Stories 轮播（来源：Wikipedia: AMP）；2016 年 Chrome 团队开源 Lighthouse，把性能审计变成一条命令（来源：Lighthouse 官方文档、GitHub 仓库）。驱动因素：移动 SEO 与流量分配权在 Google 手里，催生 AMP 这种"走捷径"方案；React 引发的单页应用浪潮让打包器从工具变成基础设施。

1.4 阶段四（2017–2019）：从实验室指标到真实用户度量

2017 年 10 月，Google 发布 Chrome User Experience Report（CrUX）：第一次把数百万 Chrome 真实用户的加载/交互数据（经 BigQuery）公开，性能讨论从"我机器上的 Lighthouse 分数"转向"我的用户实际经历了什么"（来源：CrUX 官方文档）。实验室侧同步进化：Lighthouse 3.0 于 2018 年 7 月引入模拟节流；PageSpeed Insights 在 2018–2019 年间改为"Lighthouse 实验室数据 + CrUX 真实数据"双轨（来源同上）。指标侧，2018 年 First Input Delay（FID）被提出†（web.dev: FID），首次把"交互响应"纳入主指标，为后来 INP 埋下伏笔。

代码分割基建完工。 动态 import() 在 Chrome 63（2017 年 12 月）、Safari 11.1（2018 年）、Firefox 67（2019 年 5 月）全部落地，"按需加载"有了跨引擎的标准语法（来源：MDN: import()）。图片优化进入浏览器本体。 2019 年 7 月 30 日 Chrome 76 原生支持 loading="lazy"，延迟加载从各路 JS 库变成一行 HTML 属性（来源：web.dev: 浏览器级懒加载）。背景数据：2019 年首期 Web Almanac 显示，中位桌面页面发起 74 个请求，图片是最大的字节贡献者，JavaScript 紧随其后（来源：Web Almanac 2019: Page Weight）。框架侧，React 静态生成器 Gatsby 1.0 于 2017 年发布（项目 2015 年起源），"GraphQL + 静态 + 图片管线"一度是博客标配。

驱动因素：Chrome 既是浏览器又是广告与搜索平台，有动机把"性能"变成可公开、可排名、可归责的公共数据；前端应用体积失控引发"The Cost of JavaScript"讨论潮†。

1.5 阶段五（2020–2022 上）：Core Web Vitals 成为行业宪法

2020 年 5 月 5 日，Chromium 官方博客发布《Introducing Web Vitals》，提出 Core Web Vitals 三件套：LCP（加载）、FID（交互）、CLS（视觉稳定），并给出"好/差"阈值（LCP ≤ 2.5s、CLS ≤ 0.1†，见 web.dev: Vitals）；同一篇公告宣布这些指标将成为搜索排名信号（来源：Chromium 博客）。2021 年 4 月 Google 确认时间表，2021 年 6 月中起"Page Experience 更新"分批上线、8 月底完成——性能第一次直接写进 SEO 排名公式（来源：Google Search Central）。

构建工具革命。 Evan You 2020 年 4 月发布 Vite（浏览器 ESM + esbuild 预构建）；Evan Wallace（Figma CTO）2020 年发布 Go 语言打包器 esbuild，速度比 JS 工具链快一个量级（来源：esbuild 官网、devtools.fm 访谈）。2020 年 10 月 10 日 webpack 5 发布：Module Federation、持久缓存、更好的 tree shaking（来源：webpack 官方发布文）。

图片格式换代。 2020 年 2 月 Netflix 技术博客宣布 AVIF 是 JPEG 的最佳继任（约省 50%†）；2020 年 8 月 Chrome 85 支持，2021 年 10 月 Firefox 93 跟进，2022 年 Safari 16 补齐——AVIF 成为首个三引擎通吃的新一代格式（来源：Netflix Tech Blog）。2021 年 4 月 12 日 Cloudflare Pages GA，免费层 + 全球边缘网络对标 Netlify/Vercel，个人博客托管成本归零（来源：Cloudflare 博客）。2021 年 6 月 8 日 Astro 发布（"Ship Less JavaScript"），以 Islands 架构默认输出零 JS 静态页，把"性能即默认值"做成框架卖点（来源：Astro 发布文）。

AMP 退潮与指标预演。 2021 年年中 Page Experience 上线后，AMP 不再是 Top Stories 轮播的豁免条件——"为搜索引擎做一套平行页面"的模式失去制度红利。2022 年：Chrome 101（5 月）支持 fetchpriority 属性；5 月 10 日 INP 作为实验性响应性指标亮相；6 月 HTTP/3 定稿 RFC 9114（来源：web.dev: INP）。驱动因素：SEO 指挥棒让"性能改造"第一次有预算、有 KPI；疫情期间线上流量激增放大体验差异；webpack 十年之痒由 Go/Rust 新工具收割。

1.6 阶段六（2022 下–2025）：INP 换血与 Rust 工具链

2022 年 10 月 25 日 Next.js Conf，Vercel 发布 Rust 增量打包器 Turbopack（webpack 作者 Tobias Koppers 加盟 Vercel 主导）。2022 年 12 月：INP 由实验指标转为"待转正"，宣布将于 2024 年 3 月替换 FID；Chrome 108 同期推出 Speculation Rules API，恢复"预渲染下一页"能力（来源：web.dev: INP、Chrome 预渲染文档）。2023 年：2 月 1 日 Netlify 收购 Gatsby Inc.，JAMstack 先驱合并（来源：Gatsby v5.6 发布说明）；2022 年 10 月 31 日 Chrome 宣布移除 JPEG XL 实验支持（Chrome 110 起），规范共同作者 Jon Sneyers 感慨"JPEG XL 之死是因为浏览器拒绝发布它"，2023 年 6 月 WWDC 宣布 Safari 17 支持 JPEG XL（2023 年 9 月 18 日随 Safari 17 正式发布，官方发布说明），格式之争僵持（来源：Phoronix 报道，见参考来源）。

INP 正式生效。 2023 年 5 月 Google Search Central 发布《Introducing INP to Core Web Vitals》（官方公告）；2024 年 1 月 31 日 web.dev 确认日期；2024 年 3 月 12 日 INP 正式取代 FID 成为第三项 Core Web Vital，FID 约半年后从各工具中移除（来源：web.dev: INP CWV March 12）。2025 年：5 月 30 日 VoidZero 发布 Rolldown-Vite 技术预览（Rust 版打包内核；早期采用者生产构建提速 3–16 倍，如 Excalidraw 22.9s→1.4s，厂商口径——这是 Rolldown-Vite 技术预览阶段的数据，与 Vite 8 官方宣称的 10–30× 不是同一语境）；6 月 24 日 Vite 7.0 发布，明确 Rolldown 将成为默认内核（来源：Vite 7 发布文、VoidZero 公告）。

这一阶段的主题词是"降 JS"与"换引擎"：指标从首交互（FID）换成全交互（INP，阈值 ≤200ms†），工具链从 JS 换成 Go/Rust，部署重心从构建服务器换到边缘。驱动因素：长任务与主线程阻塞在移动端愈发致命，FID"只测第一次点击"的缺陷暴露；JS 打包工具的性能天花板逼出 Go/Rust 重写潮；"单浏览器引擎说了算"引发社区反弹（JPEG XL 事件是标志性案例）。

1.7 阶段七（2025 末–2026.10）：当下——边缘整合与格式轮回

2025 年 12 月 3 日 Vite 8 Beta 发布（VoidZero 页面标注日期），Rolldown 成为默认打包器，Vite 的"esbuild + Rollup 双内核"时代结束；2026 年一季度前后进入稳定（横轴卷核实口径），Lightning CSS 成为默认 CSS 处理器、esbuild 降级为可选 peer 依赖；2026 年 Rolldown 1.0 亮相（来源：VoidZero: Vite 8 Beta、VoidZero: Rolldown-Vite）。2026 年 1 月 16 日，Cloudflare 宣布收购 The Astro Technology Company（与 Astro 6 公测同步宣布），内容站性能框架并入边缘网络巨头（来源：Cloudflare 新闻稿、Cloudflare 博客）。

JPEG XL 三年轮回后复活。 Chrome 155 于 2026 年 10 月 6 日默认启用 JPEG XL 解码；Firefox 原计划 157 版启用，实际于 2026 年 10 月 13 日随 Firefox 158 上线（并加入默认 Accept 头）。加上 2023 年的 Safari 17，三大引擎在 2026 年秋首次全部原生支持 JPEG XL——个人博客的图片格式选项表刚刚重写（来源：Phoronix、WindowsForum）。

现状基线：2025 年 Web Almanac 显示中位桌面首页 2.86 MB、移动 2.56 MB，JavaScript 约 697 KB——图片仍是最大字节头，性能仍是未竟之业（来源：Web Almanac；2019 年基线见 Page Weight 2019，图片约占页面字节四成的口径见 Page Weight 2025）。当前三项 Core Web Vitals 为 LCP / INP / CLS（FID 已于 2024 年退位），衡量口径以 CrUX 真实用户数据为准。驱动因素：AI 爬虫与内容站流量结构变化推动边缘平台整合；浏览器引擎竞争重启（Chrome 的单边决策在 JPEG XL 等事件上遭遇反弹；Mozilla 曾坚持以内存安全的 Rust 解码器为支持 JPEG XL 的先决条件，最终产出的 Rust 解码器项目 jxl-rs 成为 Chrome 与 Firefox 共用的 JPEG XL 解码核心）；"少 JS、快默认"的共识已成主流。

1.8 纵轴五条主线洞察

  1. 指标史 = 从"实验室启发式"到"真实用户体验"：YSlow 规则（2007）→ Lighthouse 分数（2016）→ CrUX 字段数据（2017）→ Core Web Vitals（2020）→ INP 全交互响应（2024）。每一次换代，都是 Google 把"什么是快"的定义权再收紧一次。
  2. 图片永远是最大字节头（约四成，Web Almanac 2025 Page Weight 口径），格式约十年一换代：WebP（2010）→ AVIF（2020）→ JPEG XL（2026 年回归，三引擎首次齐备）。教训：格式选型要看生态而非单一浏览器，Chrome 2023 年的删除曾让 JPEG XL 押注者血本无归。
  3. 代码分割经历了"从无到有、从有到省"：RequireJS → webpack/Rollup（把 JS 打好、切好）→ esbuild/Vite/Turbopack/Rolldown（打得更快）→ Astro islands（干脆不送）。终点是"Ship Less JavaScript"。
  4. 缓存与静态部署的每一步都是"基础设施普惠"：HTTP 缓存语义（1999）→ CDN（1998）→ Let's Encrypt（2016）→ HTTP/2/Brotli（2015/2016）→ JAMstack 平台与 Cloudflare Pages GA（2021）。个人博客今天免费拿到的默认性能，二十年前是雅虎首页的专属工程。
  5. 最强驱动因素始终是移动端与 SEO：技术内因（工具链老化）决定节奏，浏览器格局（单引擎化与反弹）决定争议，而"性能直接换排名/收入"决定大众采用速度。

二、横轴：横向对比

2.1 课题界定：四个赛道

"前端性能工程"不是单一产品，而是一条由四个相互咬合的赛道组成的工程域，横轴对比需在每个赛道内部找竞品：

赛道覆盖能力同类/竞品/替代方案集合
① 度量Core Web Vitals（LCP/INP/CLS）的采集与归因Lighthouse、PageSpeed Insights、CrUX、Search Console、WebPageTest、web-vitals 自托管 RUM、商业 RUM（Sentry/Datadog 等）
② 图片优化格式选择、压缩、响应式尺寸、防 CLS格式层（JPEG/WebP/AVIF/JPEG XL）；工具层（框架内建 Image 组件 vs 图片 CDN vs 本地构建工具）
③ 代码分割打包、按路由/交互拆 JS、减少主线程阻塞Webpack、Rollup、esbuild、Vite 8（Rolldown）、Turbopack、Rspack；架构层（SPA 全量水合 vs 岛屿架构 vs RSC）
④ 缓存与静态部署HTTP 缓存策略、CDN、静态托管Cloudflare Pages、GitHub Pages、Vercel、Netlify；SSG 选型（Hugo/Astro/Hexo/WordPress）

统一对比维度五项：能力、成本（钱 + 迁移/维护）、生态、成熟度、适用场景（尤其针对个人博客）。

2.2 赛道一：度量工具对比

官方基线（2026 年现行）：横轴卷通过网页读取核对了 web.dev/articles/vitals（页面标注最后更新 2024-10-31，仍为现行版本），确认三项 Core Web Vitals 全部处于 Stable 阶段：LCP good ≤ 2.5 秒；INP good ≤ 200 毫秒；CLS good ≤ 0.1。判定口径为真实用户数据（field data）的第 75 百分位（P75），且移动端/桌面端分段分别达标。INP 于 2024 年 3 月 12 日正式替换 FID（Google Search Central 公告）；FID 只测"第一次输入到事件处理器开始执行"的延迟，INP 测的是整次访问中所有交互的输入到下一次绘制的近最差值——任何基于 FID 的旧优化清单已过时。

工具数据类型成本覆盖与局限可诊断性适用场景
Lighthouse（现为 13.x，2025-10 口径，版本号以 GitHub Releases 为准；PSI 已升级至 13.0.1）实验室（lab）免费、开源单次模拟加载（慢 3G + 中端设备），不代表真实用户★★★★★（逐项 opportunity + 诊断链）开发期回归排查、CI 门禁
PageSpeed Insights（PSI）lab + field 合体免费有 CrUX 数据时同时展示两侧★★★★（lab 侧可诊断，field 侧只有结果）单页 URL 快速体检、发版后核对
CrUX纯 field（真实 Chrome 用户）免费只有 Chrome 用户；低流量页面没有数据★★（只有 P75 结果，无归因）判断"Google 认为你的站好不好"的最终口径
Search Console CWV 报告field（CrUX 驱动）免费站点级汇总，按问题分组★★SEO 视角的站点级健康度
WebPageTest实验室（深度）免费 + 付费档可选地点/设备/连接、瀑布图、filmstrip★★★★★追踪某个资源为什么慢
web-vitals JS 库自托管 RUMfield（自己的用户）免费（官方库，见 web.dev: Vitals）真实反映自己访客（含非 Chrome），需自建上报聚合★★★（可带归因调试属性）低流量博客补 CrUX 数据缺口
商业 RUM（Sentry/Datadog 等）field付费（按事件量）全浏览器、带会话上下文★★★★（性能 + 错误关联）商业站点；个人博客通常过重

第三方 2026 年统计可作背景（第三方口径）：约 43% 的站点仍未通过 INP 的 200ms 阈值，是三项中最难通过的一项——2026 年多篇性能盘点转述 HTTP Archive 2025 Web Almanac 的数据（Design Key，2026-06-10、Sam Cheek，2026-07-31；同批转述还有"仅约 48% 移动端站点通过全部三项"，不同转述口径略有出入，精确值请以 CrUX 官方仪表盘复核）。"换指标即出局"的方向性结论可信：FID 时代移动端通过率普遍在 90% 以上，换成 INP 后降至约 65%——初稿所引"约 27% 原先通过 FID 的站点换成 INP 后不再达标"未能溯源到原始报告，删去精确值，量级按"通过率落差约 25–30 个百分点"理解（初稿另挂的 digitalapplied.com.au 与 corewebvitals.io 仅为域名首页、未给出具体文章，已不再作为数字出处）。

本赛道四条结论：

  1. "lab ≠ field"是第一分水岭。Lighthouse 测一次模拟加载，Google 排名看的是真实访问的 P75，两者可相差几十分；同为实验室口径，PSI（模拟节流 + 受控测试环境）与本地 Lighthouse（真实节流 + 本机环境）也会显著分叉（成因分析见 DebugBear 对比文；初稿所引"PSI 显示 81 而 Lighthouse 只有 41"的案例数字未能溯源，删去，保留方向性结论）。结论：以 CrUX/field 为考核口径，以 lab 为诊断手段。
  2. PSI 是性价比最高的默认入口：免费、同时给 lab + field，个人博客用它即可覆盖约 80% 的度量需求。
  3. CrUX 对个人博客有致命盲区：流量不够就没有数据。官方文档明确建议"即便有了 CrUX 也应自建 RUM"，替代方案是接入 web-vitals 官方库（约 1KB 级）把三指标发到自己的分析端点（最小实现见 3.4 示例二）。
  4. 辅助诊断指标官方口径：TTFB / FCP 定位 LCP 问题（服务器慢/渲染阻塞），TBT（仅 lab） 近似定位 INP 问题（来源：web.dev: Vitals）。

2.3 赛道二：图片优化对比

图片通常占页面字节大头（约四成，见 1.8 洞察二的 Web Almanac 口径），是 LCP 的第一变量。对比分两层：格式层与交付层。

格式层：

格式浏览器支持相对 JPEG 的收益生态/工具定位
JPEG100%基线全部兜底格式，Web Almanac 2025 中仍是最常用格式
WebP100%（全现代浏览器）体积约小 25–35%，编码快所有构建工具/CDN通用默认
AVIF约 93%（caniuse 2026 年中口径）同质量下比 WebP 更小编码慢是主要短板；主要 CDN 已支持自动协商生产站点的首选渐进格式（<picture> + WebP/JPEG 回退）
JPEG XL三引擎 2026 年 10 月起齐备（见 3.2 节调和）压缩率与渐进解码最佳工具/CDN 支持最少渐进增强实验项，暂非默认

格式层来源：第三方 2026 年格式盘点综合 caniuse 与 HTTP Archive Web Almanac 2025（JPEG 仍最常用、WebP 为最常用现代格式；AVIF 浏览器支持约 93% 但实际页面采用率仅约 0.7–2%，主因是工具与 CDN 链路缺口）。解读：AVIF 的"支持率高、采用率低"恰是个人博客可白捡的红利——只要构建链路支持，几乎没人跟你竞争这个速度档位。

交付层：

方案类型成本能力要点适合
astro:assets（<Image>/<Picture>，Astro 3.0 起稳定，默认 sharp 引擎）框架内建、构建时免费（自托管时）构建期生成多尺寸 WebP/AVIF、自动写 width/height 防 CLS、<picture> 回退（Astro 3.0 公告）静态博客的"零运维"最优解
next/image框架内建、运行时/边缘免费（Vercel 有额度）按需 resize、懒加载、priority 提示；与 React 渲染模型耦合已选 Next.js 的站点；纯静态博客略重
@nuxt/image框架内建、provider 模式免费多 provider（本地/IPX/外部 CDN）Vue/Nuxt 站点
Cloudflare Images图片 CDN存储 $5/10 万张/月、交付 $1/10 万张/月、每月前 5,000 次 unique transformations 免费、超出 $0.50/千次（横轴卷读取官方定价页核实）URL 变换、自动格式协商、零出口流量费图片量大、想甩掉构建期转换的站
Cloudinary图片 CDN + DAM$89/月起（官方定价页：Plus 档年付 $89/月、月付 $99，cloudinary.com/pricing。对比基准：按 10 万张图/月交付量折算，Cloudflare Images 约 $6/月——$5 存储 + $1 交付，依两家官方定价页折算；差额主要买的是 AI 变换、视频与 DAM 能力，而非 CDN 本身。初稿"同体量约为 Cloudflare 的 3–5 倍"的第三方说法无明确比较基准，删去）AI 变换、视频、数字资产管理有媒体资产运营需求的团队
imgix图片 CDN合约定价，约 $0.02/图·变换（第三方口径）强大的 URL 变换 API已有合约定制需求
Bunny OptimizerCDN + 优化器每月 $9.50 固定 + 低单价流量（第三方 2026 汇总，modpagespeed.com）简单、便宜预算敏感、图片中等量
本地 sharp / Squoosh CLI构建脚本免费完全可控、离线可复现；sharp 已是 Astro 等框架默认引擎极客型博客、CI 里自己动手

交付层结论：对个人博客，正解几乎是"框架内建组件 + 本地 sharp 构建期产出 AVIF/WebP"；图片 CDN 只在图片量上千且不想拉长构建时间时才值得付费（该"上千"门槛与 2.6、附录 A 统一口径）。Cloudinary/imgix 的能力优势（AI、DAM、视频）与博客场景无关，为它们付费属于错配。

2.4 赛道三：代码分割与打包器对比

打包器（2025–2026 是格局剧烈变化期）：

打包器语言/出身现状（2026-10）生态与迁移成本最适合
WebpackJS仍是存量最大的生产打包器，但已非新项目默认插件生态最厚、配置负担重老项目维持
RollupJS库打包标准；Vite 8 之前是 Vite 的生产引擎生态好发布 npm 库
esbuildGo仍是大量工具链的底层变换引擎；Vite 8 中降级为可选 peer 依赖—单项任务（转译/minify）
Vite 8Rust 核心（Rolldown 默认打包器、Lightning CSS 默认 CSS 处理器）2025-12-03 Beta（VoidZero 页面标注日期）、2026 年一季度前后转正（VoidZero: Rolldown-Vite、Vite 8 Beta 公告）；官方称构建提速 10–30×（Vite 8 Beta 公告口径：Rolldown 相比 Rollup 的提速，构建性能与 esbuild 同级——与 Rolldown-Vite 技术预览期实测的 3–16× 是两个语境，第三方复测显示收益幅度依项目而异）Vite 生态最大；插件兼容 Rollup API绝大多数新项目，包括博客
TurbopackRust（Vercel）Next.js 16（2025-10-21 发布）起成为 dev + production 双默认，可 next build --webpack 退出；Next.js 15.4 时期已通过全部 8,298 个生产构建集成测试（Next.js 15.4 公告，Next.js 官方博客口径）与 Next.js 深度绑定，脱离 Next.js 不可用全押 Next.js 的团队
RspackRust（字节系）高兼容 webpack API 的迁移路径webpack 生态近乎平移从 webpack 迁移的存量项目

第三方横向评测（pkgpulse 2026-04、kunalganglani 2026-03、基准仓库 rstackjs/build-tools-performance）的共识：Rust 化之后，三者"纯速度"差距已不大，真正的分野在生态、迁移路径与框架绑定——Turbopack 在超大应用（>2000 模块）的 HMR 上仍有约 15% 的第三方实测领先，但那不是个人博客的作战尺度。

架构层：代码分割的"降维方案"。对博客这种内容站，最大的代码分割收益不是把 JS 拆得更细，而是根本不 Ship JS：

路线代表JS 交付模型对 CWV 的影响
SPA 全量水合Next.js/Nuxt/普通 Vite SPA首屏即全量框架 JS，React.lazy/动态 import 做按路由拆分INP 与 LCP 承压，需手动优化
岛屿架构（Islands）Astro页面默认 0 JS，仅交互组件水合结构性优势：HTTP Archive CWV 技术报告口径下 Astro 站点移动端通过率约 67%，WordPress 约 49%（第三方转引，整体基线约 48%）
Server ComponentsNext.js App Router服务端渲染 + 细粒度流式有潜力，但客户端 bundle 与心智复杂度仍高于岛屿

第三方 2026 年对约 49 万站点的分析给出 Next.js 移动端 CWV 通过率约 29.3%、Nuxt 约 24.9%、Astro 约 48.0% 的量级（pagespeedmatters 数据研究，2026-07-15 发布，2026 年 5 月 CrUX/HTTP Archive 数据——与上表 CWV Tech Report 仪表盘的"Astro 67%"方法论不同，两处口径并存，均见参考来源；第三方转引，建议以原始仪表盘复核）。解读：这些数字有自选择偏差（用 Astro 的多是内容站、用 Next 的多是应用站），但方向性结论稳健——内容站的默认架构不该背一个运行时框架。

2.5 赛道四：缓存与静态部署对比

静态托管平台（免费档）：

平台带宽（免费档）构建/文件限制缓存与边缘能力备注
Cloudflare Pages官方限额页未设带宽上限（横轴卷读取官方 limits 页核实：免费档 500 次构建/月、单项目 20,000 文件、单文件 25 MiB、构建超时 20 分钟、100 个自定义域名），第三方普遍描述为"不限带宽"如上全球 300+ 边缘节点；HTML 默认边缘缓存行为可调流量型博客的成本最优解
GitHub Pages100 GB/月（软限制）；发布站点 ≤ 1 GB；Jekyll 构建 10 次/小时（软限制），用自定义 GitHub Actions 构建则不受限（官方 limits 文档）如上Fastly 驱动的 CDN，缓存策略不可细调纯静态零 fuss，但禁止当文件/视频分发服务器用（ToS）
Vercel Hobby100 GB Fast Data Transfer/月 + 100 万 CDN 请求/月无构建分钟数上限（第三方口径；免费档限额以 Vercel 官方 limits 文档与 Hobby 计划页为准——"非商业用途"限制即出自后者）边缘网络 + ISR/中间件等动态能力Next.js 原生家园；非商业用途限制要注意
Netlify Free100 GB 带宽/月（官方定价页口径，netlify.com/pricing）构建资源改为 300 credits 制（第三方口径，官方定价页为复核点；额度规则近年多次调整，以该页为准）边缘 + FunctionsDX 好，量产后转付费最快

第三方横向佐证（danubedata 2026、vibecoder 评测）结论一致："高/不设限流量 + 低成本"选 Cloudflare Pages；纯静态零运维选 GitHub Pages；深度绑定 Next.js 选 Vercel。

SSG 构建速度与博客框架：

生成器语言构建速度图片/现代工具链定位
HugoGo（单二进制）全场最快，数千页秒级（第三方共识，如 libhunt 对比、Hugo vs WordPress）需外部管线内容极多、追求构建即时性
AstroNode中等（比 Hugo 慢，多站实测可接受）astro:assets 一等公民兼顾现代前端能力与性能的博客首选
HexoNode中等一般老牌中文圈方案，生态动能已被 Astro 反超（第三方口径）
WordPressPHP（无构建）运行时渲染插件生态巨大非开发者 + 动态需求；安全/维护面大，CWV 通过率低于 Astro（约 49% vs 67%，CWV Tech Report 仪表盘口径）

缓存策略：

策略作用对象要点风险
指纹文件名 + Cache-Control: public, max-age=31536000, immutable带 hash 的 JS/CSS/图片一年缓存 + immutable 告诉浏览器不要发协商请求；内容变 = 文件名变需构建链可靠产出 hash 文件名
HTML 短缓存或不缓存文档本身max-age=0, must-revalidate（或 CDN 短 TTL + 清缓存钩子），保证发版后读者立刻看到新文章完全 no-store 会牺牲回访速度
stale-while-revalidateHTML/JSON先回旧内容、后台刷新（HTTP 标准 RFC 5861；CDN 支持度普遍好于浏览器端）读者可能短暂看到旧版
Service Worker 离线缓存全站可做离线阅读、秒开生命周期管理出错会"缓存钉死"旧页面，博客场景收益/风险比一般

2.6 四赛道"共识最优"对照

赛道2026-10 的共识最优（无脑选不出错）分歧点
度量PSI（免费双报告）+ web-vitals 自托管补盲区低流量站 CrUX 无数据；商业站加 RUM
图片框架内建组件 + 构建期 sharp 产出 AVIF/WebP图片量上千或不想构建期转换时才上付费 CDN
打包/分割Vite 8（Rolldown）；Next.js 用户直接用 Turbopack 默认webpack 存量选 Rspack；库作者用 Rolldown/Rollup
部署缓存Cloudflare Pages（默认推荐，判据见 3.3） + 指纹长缓存 + HTML 短缓存纯静态零运维可换 GitHub Pages；深度绑定 Next.js 选 Vercel；超大规模内容选 Hugo 构建 + Cloudflare Pages

三、交叉洞察

3.1 两轴相加，说明了什么

洞察一：性能的"定义权"完成了从工具到用户的迁移，纵轴的指标换代与横轴的 lab/field 分野互为表里。 纵轴显示指标五次换代（YSlow → Lighthouse → CrUX → CWV → INP），横轴则揭示了换代的操作含义：Google 的考核口径钉死在"真实用户 P75"上，任何实验室分数只是诊断线索。两轴合并的推论是——优化目标必须绑定 CrUX 口径，Lighthouse/TBT 只用来定位问题；而 INP 换掉 FID 不只是指标更替，它把"优化范围"从首次交互扩大到整次访问的所有交互，这正是第三方口径下约 43% 站点未达标（来源见 2.2）的结构性原因：靠"首屏快"的旧打法救不了全旅程的响应性。

洞察二：纵轴的"格式十年一换代"遇上横轴的"支持率/采用率落差"，给出一个可复用的红利窗口判断法。 WebP 用了十年才三引擎全覆盖；AVIF 支持（约 93%）与实际采用（约 0.7–2%）之间存在数量级落差——这个落差就是内容站的免费速度档位。JPEG XL 是同一条规律的进行时：2026 年 10 月三引擎刚齐备，构建链路与 CMS 支持尚浅，它正处在 AVIF 2020 年的位置。判断格式该不该上，看的不是"哪个浏览器支持"，而是"支持率与采用率的差值还有多大、我的构建链补齐成本多低"。

洞察三：纵轴的 Go/Rust 工具链革命，在横轴上表现为"速度之争让位于生态之争"。 esbuild（2020，Go）→ Turbopack（2022，Rust）→ Rolldown（2025–2026，Rust）三步 Go/Rust 化把打包速度拉平后，第三方评测共识是"纯速度差距已不大，分野在生态、迁移路径与框架绑定"。更重要的变化是：速度从需要用户优化的参数，变成了框架内化的默认值——Vite 8 默认 Rolldown、Next.js 16 默认 Turbopack、Astro 默认 sharp。"选哪个更快"正在变成"选哪个生态"，这对选型意味着决策成本的下降，也意味着再自建 JS 打包链已无收益。

洞察四：纵轴的"基础设施普惠史"在横轴上收束为——2026 年个人博客的成本约束已经不是钱，而是注意力与维护。 纵轴从 RFC 2616 一路数到 Cloudflare Pages GA，说明个人博客今天免费拿到的默认性能（HTTP/2/3、Brotli、全球边缘、免费 HTTPS）是二十年前雅虎首页的专属工程；横轴的平台对比进一步显示，Cloudflare Pages 免费档连带宽上限都没设，GitHub Pages 给 100 GB/月——"要不要买服务器"这个问题已经退场，"选哪家平台 + 配对缓存头"成为仅剩的决策。因此真正稀缺的资源变成了维护带宽：清单要短、工具要托管、构建要无人值守（本报告据此把实战清单拆成"最小 10 项硬门槛 + 附录 A 完整版"，见 3.3）。

洞察五：两轴都指向同一个终局判断——内容站的性能问题，答案在架构而不在调优。 纵轴的"从有到省"（islands 干脆不送 JS）与横轴的通过率数据（Astro 约 67% vs WordPress 约 49% vs Next.js 约 29%，第三方口径、有自选择偏差；前两者出自 CWV Tech Report 仪表盘口径、后者出自 pagespeedmatters 数据研究，两者方法论不同，链接均见参考来源）相互印证：单点优化（压缩、懒加载、拆包）的天花板是架构决定的上限。对一个以文字和图片为主体的博客，最有效的"性能优化"发生在选框架那一刻，而不是发布前的最后一周。

3.2 两卷矛盾与重复的调和记录

  1. JPEG XL 支持状态：横轴卷格式表写"支持约 12–15%，几乎全是 Safari"（caniuse 2026 年中口径）；纵轴卷记录 Chrome 155 于 2026-10-06 默认启用、Firefox 158 于 2026-10-13 上线。调和：两者是同一进程的两个时间截面——横轴数字反映 2026 年年中的真实状态，纵轴记录的是 2026 年 10 月的最新变化。综合口径：截至 2026-10-31，三大引擎已原生支持 JPEG XL，但工具链/CDN 支持与实际采用仍接近零，故定位不变：渐进增强实验项、必须保留 WebP/JPEG 回退，不作为默认格式。
  2. Vite 8 时间线：纵轴卷写"2025-12-02 Beta 发布、2026 年 Rolldown 1.0 亮相"；横轴卷写"2026-03 前后进入稳定"。调和：Beta（2025-12；VoidZero 页面标注日期为 2025-12-03，正文按页面日期统一）→ 稳定（2026 年一季度前后）→ Rolldown 1.0（2026 年内），三段为连续时间线，不矛盾；本报告按此顺序合并叙述。
  3. Web Almanac 引用口径：纵轴卷把 2025 年数据（桌面 2.86 MB/移动 2.56 MB/JS 约 697 KB）挂在 2019 年 page-weight 链接下；横轴卷引用 almanac.httparchive.org 的 2025 年版并补充"JPEG 仍最常用、AVIF 采用率 0.7–2%"。调和：2019 年基线（74 个请求/中位桌面页）单独标注 2019 链接，2025 年数据统一指向 Web Almanac 总站与 2025 Page Weight 章节链接（全文"约四成"图片字节占比即出自该口径）。
  4. 重复内容合并与归属对齐：纵轴第 10 节与横轴第 7 节各有一份"个人博客实战清单"，重叠约六成（AVIF/WebP 双格式、srcset、width/height、LCP 图 eager+fetchpriority、font-display: swap、零框架 JS、指纹 immutable 长缓存、PSI/CrUX 度量、第三方脚本延后）。两份清单已合并为 3.3 的"最小 10 项硬门槛"与附录 A 的完整版。归属对齐（本次修订按两卷原文逐项核对，2026-10-31）：纵轴独有项为 Speculation Rules 预渲染、季度复查（含"清单要有版本号"的自我要求）、HTTPS 必开、"别再优化 FID"；横轴独有项为 web-vitals 自托管上报、_headers 配置写法、JS < 50KB 量化目标、平台二选一结论（纵轴有"部署到边缘平台"的通用项，但无平台取舍判据）、发版后无痕复测、PSI 月度存档、Search Console 盯问题分组。初稿中三处括注与上述归属不符（_headers 误标"两卷共有"、JS < 50KB 误标"纵轴+横轴"、"别再优化 FID"误标"两卷共有"，另 3.2 原文误把"平台选择"整项列为横轴独有），已按两卷原文在附录 A 逐项改正。

3.3 对用户的判断与建议：个人博客实战清单（合并版，2026-10 · 清单版本 v2026.10）

主推栈：Astro（静态输出）+ astro:assets + PSI/web-vitals 度量 + 默认 Cloudflare Pages 托管。理由：零框架运行时 JS（直接利好 LCP/INP）、图片链路原生防 CLS、部署免费档够用、Vite 8 工具链即拿即用。若已有 Hugo/Hexo 存量博客，不必为性能迁移——Hugo 本身就是性能优等生，按清单补齐图片与缓存项即可。若在 WordPress 上且无迁移意愿，优先处理图片与 CLS 两项，性价比最高。

平台二选一（初稿全文只给"或"，本稿给出唯一默认与判据）：默认 Cloudflare Pages。判据：免费档官方限额页未设带宽上限（500 次构建/月、单项目 20,000 文件对博客绰绰有余，官方口径见 2.5）、全球 300+ 边缘节点、_headers 可细调缓存行为——这三条正中博客"流量不可预估 + 必须配缓存头"的要害。唯一改选 GitHub Pages 的场景：站点 ≤ 1 GB、纯静态零交互、发布流程已完全长在 GitHub Actions 上、且不打算细调缓存头（其 CDN 缓存策略不可细调、100 GB/月软限制）。深度绑定 Next.js 的场景选 Vercel，不在本次二选一范围内。

最小可行 10 项硬门槛（清单版本 v2026.10，核对日 2026-10-31；达标口径 CrUX P75：LCP ≤ 2.5s / INP ≤ 200ms / CLS ≤ 0.1。初稿完整清单约 40 项，与洞察四"清单要短"的主张自相矛盾，故拆分：以下 10 项是发布前的硬门槛，全量条目降为附录 A）：

  1. [ ] 正文页 0 框架 JS，全站 JS 总量 < 50KB（gzip）（零框架 JS：两卷共有；50KB 量化目标：横轴卷）
  2. [ ] 首屏主图 AVIF/WebP（<picture> 回退 JPEG）、写 width/height、fetchpriority="high" + loading="eager"，首屏图片不 lazy（两卷共有）
  3. [ ] 非首屏图片 loading="lazy" + decoding="async"；构建期 sharp 批量转格式，单图 ≤ 200KB（两卷共有 + 横轴量化）
  4. [ ] 所有 <img> 带 width/height 或 aspect-ratio；广告/嵌入位预留固定尺寸（博客建议干脆不放）（两卷共有）
  5. [ ] 字体 font-display: swap† + 尺寸接近的本地回退字体 + 子集化，最多 1–2 个字重，中文字体尤其要子集（两卷共有）
  6. [ ] <head> 无阻塞型第三方脚本；统计/评论等一律 defer/async 化或免 JS 化（两卷共有）
  7. [ ] 指纹资源 Cache-Control: public, max-age=31536000, immutable；HTML max-age=0, must-revalidate（两卷共有；_headers 具体写法见附录 A，横轴卷）
  8. [ ] 部署默认 Cloudflare Pages（判据见上），不自购服务器（部署到边缘平台：两卷共有；平台二选一结论：横轴卷）
  9. [ ] 交互功能一律 islands/动态 import() 按需加载，不整页引入 React（两卷共有）
  10. [ ] 发布前 + 每月用 PSI 记录 P75；低流量站接入 web-vitals 库补 CrUX 盲区（最小实现见 3.4 示例二）；别再优化 FID（度量口径：两卷共有；web-vitals 自托管：横轴卷；"别优化 FID"：纵轴卷）

两段最小代码示例见 3.4；完整版检查表（约 40 项，含逐项归属标注）见附录 A。

3.4 两段最小实现示例（新增，回应读者追问）

示例一：JPEG XL 渐进增强的 <picture> 写法（原则见附录 A 图片组；JXL 命中则用之，否则按序降级，永远不会比现状更差）：

<picture>
  <source type="image/jxl"  srcset="hero-800.jxl 800w, hero-1200.jxl 1200w"
          sizes="(min-width: 800px) 800px, 100vw">
  <source type="image/avif" srcset="hero-800.avif 800w, hero-1200.avif 1200w"
          sizes="(min-width: 800px) 800px, 100vw">
  <source type="image/webp" srcset="hero-800.webp 800w, hero-1200.webp 1200w"
          sizes="(min-width: 800px) 800px, 100vw">
  <img src="hero-800.jpg" srcset="hero-800.jpg 800w, hero-1200.jpg 1200w"
       sizes="(min-width: 800px) 800px, 100vw"
       width="1200" height="675" decoding="async" alt="文章首图">
</picture>
<!-- 说明：
  1. 若此图是首屏 LCP 元素，再给 <img> 加 fetchpriority="high" loading="eager"；
     非首屏图片改加 loading="lazy"。
  2. width/height 必须写（防 CLS），按源图最大尺寸填。
  3. JPEG XL 于 2026-10 起三引擎可用，但构建链/CMS 支持尚浅：
     保留 AVIF/WebP/JPEG 三级回退是硬要求（Chrome 2023 年删除导致三年空窗的教训）。 -->

示例二：web-vitals 库最小上报实现（把 LCP/INP/CLS 发到你自己的分析端点，弥补 CrUX 低流量盲区；官方库，约 1KB 级，npm README 为构建文件与版本的最终依据）：

<script>
(function () {
  var s = document.createElement('script');
  s.src = 'https://unpkg.com/web-vitals@6/dist/web-vitals.iife.js';
  s.onload = function () {
    function send(metric) {
      var body = JSON.stringify({
        name: metric.name,      // 'LCP' | 'INP' | 'CLS'
        value: metric.value,
        rating: metric.rating,  // 'good' | 'needs-improvement' | 'poor'
        id: metric.id,          // 指标会话去重用
        path: location.pathname
      });
      // sendBeacon 被浏览器拒收（返回 false）时回退 fetch + keepalive，
      // 保证读者关页前数据仍能发出
      if (!navigator.sendBeacon('/api/vitals', body)) {
        fetch('/api/vitals', { method: 'POST', body: body, keepalive: true,
          headers: { 'Content-Type': 'application/json' } });
      }
    }
    webVitals.onLCP(send);
    webVitals.onINP(send);
    webVitals.onCLS(send);
  };
  document.head.appendChild(s);
})();
</script>
<!-- 端点侧按 id/path 聚合出各指标的 P75，就是你自己用户的 CrUX 替身。
     调试期可改用归因构建 web-vitals.attribution.iife.js，
     metric 对象会多出 element/事件目标等归因字段。 -->

四、参考来源

指标与度量

图片

代码分割与工具链

缓存、部署与框架

附录 A：个人博客完整版检查表（合并版全量条目，2026-10 · 清单版本 v2026.10）

归属标注以 3.2 第 4 条的逐项核对结论为准（纵轴独有：Speculation Rules、季度复查、HTTPS 必开、"别再优化 FID"；横轴独有：web-vitals 自托管、_headers 写法、JS < 50KB 量化、平台二选一结论、发版后复测、PSI 月度存档、Search Console 盯分组）；初稿三处误标已在本次修订改正。最小硬门槛版见 3.3。

按 CWV 三指标组织的发布前检查表：

*最终稿完成于 2026-10-31，基于同日初稿按 8 条独立审读意见逐条修订；初稿中未被质疑的内容未删改。本稿新增的链接中，VoidZero 两篇公告、pagespeedmatters 数据研究、npm web-vitals 为本会话直接打开核验；Safari 17 发布说明、jxl-rs、WebP 发布文、DebugBear、designkey/samcheek 等经检索核验存在且内容匹配，未逐页全文复核。未能溯源的数字已删值留方向并注明（"PSI 81 vs Lighthouse 41"案例、"27% 原先通过 FID 的站点不再达标"精确值）；厂商自述口径（如构建提速倍数，均已注明语境）与第三方转引统计均已标注，"†"沿用纵轴卷标注口径（该卷未单独验证的背景事实）。*

思考题（读完后想一想，参考答案可展开）

  1. 报告为什么断言“内容站的性能问题，答案在架构而不在调优”？
    参考答案

    因为通过率数据印证架构决定上限：CWV Tech Report 口径下 Astro 站点移动端通过率约 67%、WordPress 约 49%；另一项约 49 万站点研究给出 Next.js 约 29.3%、Astro 约 48.0%（数字有自选择偏差但方向稳健）。岛屿架构默认输出零 JS，对 LCP/INP 有结构性优势；压缩、懒加载、拆包等单点优化的天花板由架构决定。对以文字和图片为主的博客，最有效的性能优化发生在选框架那一刻，而非发布前最后一周。

  2. Lighthouse 分数与 CrUX 真实用户数据为何可能相差很大？个人博客应以哪个为准？
    参考答案

    lab ≠ field 是第一分水岭：Lighthouse 测一次模拟加载（慢 3G + 中端设备），不代表真实用户；Google 排名看的是真实访问的 P75（CrUX field 数据），两者可相差几十分。结论：以 CrUX/field 为考核口径，lab 只作诊断手段。但 CrUX 对低流量博客有致命盲区——流量不够就没有数据，官方建议接入 web-vitals 库（约 1KB）自建 RUM 上报；PSI 免费双报告可覆盖约 80% 的度量需求。

  3. JPEG XL 已于 2026 年 10 月获得三大引擎支持，报告为何仍只把它定位为“渐进增强实验项”？
    参考答案

    因为其工具链/CDN 支持与实际采用仍接近零，构建链路与 CMS 支持尚浅——它正处在 AVIF 2020 年的位置。历史教训：Chrome 2022 年宣布移除 JPEG XL 实验支持（Chrome 110 起），造成三年空窗，格式押注者血本无归。因此要求 picture 元素保留 AVIF/WebP/JPEG 三级回退，命中则用、否则降级，永远不会比现状更差；判断格式该不该上，看支持率与采用率的差值，而非单一浏览器的支持。

  4. 按 2026 年 10 月的共识，个人博客的主推技术栈是什么？最小 10 项硬门槛里有哪些关键项？
    参考答案

    主推栈：Astro（静态输出）+ astro:assets + PSI/web-vitals 度量 + 默认 Cloudflare Pages 托管。理由：零框架运行时 JS 直接利好 LCP/INP、图片链路原生防 CLS、免费档官方未设带宽上限。关键门槛：正文页 0 框架 JS、全站 JS < 50KB（gzip）；首屏主图 AVIF/WebP、写 width/height、fetchpriority=high 且不 lazy；字体 font-display: swap + 子集化；指纹资源 immutable 长缓存 + HTML 短缓存。已有 Hugo/Hexo 博客不必为性能迁移。

← 资料库今日播报 →