一篇没有代码块的关于页，为什么要先准备整套代码高亮语法？
排查博客的服务端 CPU 开销时，这个问题比删动画、压图片更值得先问。浏览器里的视觉效果和服务端页面生成不是同一笔成本；这次明显的局部开销，出现在 Markdown 编译与高亮初始化里。
我调整了高亮入口和缓存兜底。部分页面的本地冷编译明显变快，但这还不能写成“全站 CPU 同比下降”，更不能直接换成账单节省。优化的对象、测量的对象和最终计费的对象，必须分开。
先弄清楚，哪一种 CPU 在忙
这次关注的是线上函数执行代码消耗的 CPU 时间，不是部署时打包整个站点，也不是访客浏览器播放背景动画的时间。Vercel 对函数 CPU 和执行时长有各自的计量口径，排查前应该先确认用量页上的具体指标。函数用量说明
还有两个容易混淆的层次：团队用量不等于某个项目的用量；一个人打开首页，也不一定只带来一次后端工作。浏览器预取、爬虫、预览和核验请求，都可能出现在请求记录里。不能把自动化流量一概归成外部爬虫，更不能把自己没点过的文章当成从未收到请求。
因此，我先对照请求路径、冷启动与缓存状态，再看本地编译。用量总数适合提醒风险，不足以单独定位原因。
改高亮的入口，而不是去掉高亮
原来的路径会为页面编译准备完整语法。对于没有代码的正文，这项准备没有产生读者能看到的价值。
修改后的处理顺序很朴素：
- 正文没有代码块，直接跳过高亮初始化。
- 简单代码块按实际语言加载，保留亮暗主题和语言标记。
- 遇到依赖嵌入或注入语法的复杂内容，仍走较完整的加载路径。
- 同一进程里的高亮器继续复用，避免把每次高亮都变成重新初始化。
最后一条很重要：冷进程里的一次初始化成本，不代表每次访问都会重复支付。Shiki 的官方建议也强调复用高亮器，并按需要选择语法与构建方式。性能建议
按需加载也不是只拿当前代码块的语言名就完事。模板字符串、嵌入语言和注入规则可能依赖其他语法；过度裁剪的结果，可能是页面更快了，代码颜色却不完整，甚至随访问顺序变化。
这次选择保守一点：简单页面争取收益，复杂语法优先保持原显示。后续还可以继续细拆，但没有必要为了漂亮的平均数把兼容性一起裁掉。
缓存少做重复工作，但仍要能更新
另一个改动是延长时间兜底，将内容推送后的主动失效保留下来。
它不是让文章永远缓存，也不是到了固定时刻主动重建全站。ISR 的时间再验证通常由后续访问触发；缓存失效、重新生成和读者拿到新内容，是需要分别核对的环节。Next.js ISR 指南
这次的取舍是：正常内容变更依赖 Webhook 通知，时间兜底不要过于积极。代价也要一起接受——如果通知漏掉，兜底更新可能更晚。只改一个缓存数字，却不测推送链路，是把性能问题换成内容新鲜度问题。
验证不能只看一张耗时表
在这次本地对照中，没有代码的正文、简单代码文章，冷编译收益很明显；复杂语法页面则基本没有同等收益。这不是失败，而是保留完整语法路径的预期代价。
优化时还对已有文章做了渲染结果一致性检查，并核对新增文章、正文修改、搜索用的终端索引、RSS 与 sitemap 的刷新流程。这些检查支持“改动没有只顾速度、忘了内容更新”，但仍不等于长期线上表现已经测完。
目前最该保留的结论是：部分本地编译路径变快了，线上整站收益仍需要观察。 本文不是新的性能跑分，也没有重新测量优化后的完整账期。
为什么不能把局部倍数直接套到账单
可以先把服务端总 CPU 粗略拆成：
总 CPU ≈ 各类请求数量 × 各类请求的平均 CPU 成本，再求和高亮优化只减少其中一部分成本。框架启动、模块加载、内容解析和其他页面工作仍然存在；缓存调整影响的是重新生成机会，也不会让请求数按缓存间隔等比例下降。账单还可能包含其他计费项，不能只看这一项 CPU。
接下来应该比较同口径的时间窗：项目相同、版本分开、请求类型可区分，再同时看缓存命中、函数调用与 CPU 增量。自己的核验流量也要记录，否则验证优化的过程本身就可能把观察窗口搅混。
如果只带走一个做法，我会选这个：先找出“没有必要却每次准备”的工作，删掉它，再证明内容没有变坏。至于到底省了多少整站成本，让后续用量回答，不替它提前宣布。