前端性能：先找到慢在哪里，再决定怎么优化
“首页慢”至少可能指三件事：迟迟没有主要内容，点击后反应迟钝，或者页面不断跳动。把它们分开测，优化才不会变成到处加缓存。
用指标描述用户感受
Core Web Vitals 中，LCP 关注主要内容出现时间，INP 关注交互响应，CLS 关注视觉稳定性。当前良好体验参考线是 LCP 不超过 2.5 秒、INP 不超过 200ms、CLS 不超过 0.1，通常看真实访问的第 75 百分位。实验室测试与真实用户数据各有价值，一次本机跑分不代表所有读者。
首屏时间还受服务器响应、网络、资源发现和客户端工作影响。只压缩图片可能对脚本长任务毫无帮助；只换 CDN 也不会修复每个按键过滤十万条正文的问题。
给知识库做一个加载预算
首页只需要目录和摘要，就不必同时下载完整编辑器和所有图表能力。路由级分包减少初始资源，重型图表按需加载，图片提供尺寸避免布局跳动，长文章代码块使用内部横向滚动。
字体也有成本。选择合理字体文件和加载策略，避免为了几个图标下载一整套字体。资源使用内容哈希可以支持长期缓存，而入口 HTML 的缓存更新策略要确保用户能拿到新资源引用。
防抖、节流与虚拟列表分别解决什么
防抖等待连续输入暂歇后执行，适合减少搜索请求；节流限制高频操作的执行频率，适合部分滚动反馈；虚拟列表减少实际渲染节点，适合很长的列表。三个方案针对不同成本，不能互相替代。
防抖期间输入本身仍应及时显示。请求取消解决过期工作，缓存减少重复工作，分页减少数据规模。先确定瓶颈再组合，不要默认每个搜索框都需要五个性能库。
用一轮实验闭环
先在移动设备或合理限速下记录基线，确定主要瓶颈，再做一项变更并重复相同场景。比如发现 Mermaid 首屏加载很重，就先验证仅包含图表的文章是否需要立即加载它，再测普通文章的改善以及图表文章是否仍能正常工作。
性能优化也有回归风险。虚拟列表可能影响浏览器查找、屏幕阅读器和滚动定位；图片延迟加载若误用在首屏主图上，反而会拖慢 LCP。收益和功能损失都应记录。
练习与参考
记录同一篇长文章首次访问与再次访问的网络资源量、主要内容出现时间和交互延迟。解释缓存改变了哪些部分，又有哪些主线程工作仍然重复。
读懂指标的含义，避免“分数很好但仍不好用”
LCP 关注视口中符合条件的最大内容元素的呈现时刻，不是页面所有资源完成下载的时间。INP 反映交互到下一次绘制的响应质量，包含排队等待、处理和呈现相关延迟；接口总耗时与它有关但不是同一指标。CLS 衡量意外布局偏移，不是图片总大小。
真实访问的第 75 百分位意味着约四分之三观测不超过相应值，具体统计还需按官方口径划分设备和数据窗口。不要把本机一次 Lighthouse 分数直接写成“所有用户 200ms 内响应”。如果样本太少或用户群不同，应说明测量范围。
以知识库图片为例：预留宽高比能减少加载后推挤正文；压缩体积能减少传输；把首屏主图错误设为懒加载可能延迟发现和下载，反而伤害主要内容出现时间。每项措施对应不同原因，不能混成一句“图片优化”。
记录优化前后的同设备、同网络、同页面数据，多跑几次观察变化范围，再看真实用户趋势。若收益小于噪声，不急着宣布成功。也要复查键盘操作、文章目录定位和浏览器查找，尤其是引入虚拟化之后。