博客快不快，要从读者完成一次操作需要多久来判断。这个专栏持续记录无常笔记的访问速度优化：先留下测量条件与基线，再定位瓶颈、实施改动，最后用同样的方法复测。
第一篇：先测量，再优化：博客访问速度的指标与取证方法。从 HTTP 分阶段计时、Chrome Performance 和浏览器 Timing API 入手，拆开首屏、资源传输与搜索响应。
后续围绕搜索就绪状态与索引拆分、缓存策略、长文渲染和不同网络路径逐步展开。每篇保留环境、版本、样本与未解决的问题，便于对照历次结果；具体实施结果随文章更新，不把计划当作已经获得的收益。
给博客补上 favicon 后，一个自然的问题是：页面访问还有哪里慢？2026 年 10 月 30 日的检查中，首页 HTML 很小，服务器本机响应也快；但浏览器搜索仍可能等上两分钟，索引就绪后的查询也会卡顿。仅凭“首页能打开”或一个下载总耗时，很难发现这些差异。 这是“博客访问速度优化”专栏的第一篇。先把性能数据怎么取得、每个指标回答什么问题讲清楚，后续再逐项记录优化。本文数值来自当天会话及仓库 docs/PERFORMANCE-2026-10-30.md 的测量记录；代码是整理后的复现示例。当天实际完成了图标修复和性能诊断，搜索拆分、Worker 与缓存调整仍是后续方案。 先定义“快”：三个时钟不能混在一起 访问博客至少有三个值得测的阶段：收到文档和资源；看到可阅读的内容；操作后得到可用结果。下载完成不等于绘制完成，搜索框出现也不等于搜索已经可用。 层次 指标 回答的问题 获取方式 连接与响应 DNS、TCP、TLS、TTFB 时间花在建立连接，还是等待响应？ curl、Network Timing 传输 总耗时、响应体大小、压缩编码 是资源大，还是这条线路传输慢？ curl、响应头、Resource Timing 首屏 FCP、LCP 首次出现内容、最大内容何时绘制？ Chrome Performance 稳定性 CLS 内容是否在阅读时意外移动？ Performance、真实用户采样 交互 INP、长任务 用户操作后页面能否及时绘制反馈？ Performance、真实用户采样 业务可用性 索引就绪时间、输入到结果耗时 搜索何时能用，输入后多久有结果？ 自定义计时、DOM 观察 Core Web Vitals 当前关注 LCP、INP、CLS。“良好”参考线分别为 2.5 秒、200 毫秒、0.1，网站评价看真实访问的第 75 百分位，并区分移动端和桌面。一次本机 LCP 达标，不代表全站用户都达标；FCP 与 TTFB 则帮助解释加载过程。指标口径见 Web Vitals 官方说明。 实验数据适合定位和比较改动；真实用户数据适合观察不同设备、地区与访问路径的分布。这次没有 CrUX 或全站 p75，也没有 Lighthouse Performance 分数。后续若接入真实用户采样，应同时记录页面类别、设备类别与版本，避免平均值掩盖最慢的一组用户。 ...