说到博客性能，很多人第一反应是换主题、加缓存、装一堆优化插件。但个人 Hexo 站点最常见的瓶颈，往往没有这么复杂：重复做了不必要的构建，文章图片太大，生成后没有检查资源是否真的被引用，或者把本地构建耗时和线上页面加载混成了一个问题。

我更喜欢从不会破坏内容的地方开始优化：减少无效工作，控制资源体积，确认生成结果，再考虑额外工具。

先分清两种性能

本地构建性能回答的是“从源文件到 public/ 要多久”。它受文章数量、主题渲染、Node 依赖和运行环境影响。页面加载性能回答的是“读者打开一个 URL 要等多久”。它更多受图片、脚本、样式、字体和网络影响。

两者有关，但不是一回事。把本地构建从 20 秒降到 10 秒，并不自动意味着页面会加载得更快；给页面加一个压缩插件，也不一定能解决 Docker 镜像下载慢的问题。

排查时先记录现象：是 hexo generate 慢，还是浏览器打开页面慢，还是只有某一篇文章慢。问题边界清楚，优化才不会变成凭感觉改配置。

不要每次都从清理开始

排查缓存时，hexo clean 很有用；日常每次写一段文字都 clean，却会让生成器丢掉可以复用的中间结果，也让“到底是源文件还是旧产物”的判断变得模糊。

当前仓库的标准构建入口是：

pwsh ./ops/build.ps1

它会用 Docker 执行清理和生成，适合发布前得到干净的 public/。日常本地写作可以使用 npm run server，让 Hexo 持续监听文件变化；只有页面明显残留旧结果时，再单独运行 clean。

优化不是把 clean 永远删掉，而是把它放在正确的场景：发布构建需要可复现，迭代预览需要快速反馈。

图片通常比文字更值得先处理

一篇文章的正文可能只有几十 KB，一张未经压缩的截图却可能几 MB。图片尺寸、格式和数量会直接影响页面传输，也会增加仓库体积和构建处理时间。

我会先做三个判断：

  1. 这张图是否真的帮助读者理解；
  2. 是否可以裁剪掉无关区域；
  3. 是否需要以原始分辨率发布。

公共小图片放在 source/images，文章专属资源按文章归属管理，大型媒体再考虑已经确认可用的外部图床。不要为了“以后可能用到”把一整批原图放进每篇文章。

图片路径也要在构建后确认。Markdown 能成功渲染，不代表文件一定被复制到了 public/；生成后的 HTML 和资源目录才是最后依据。

只做可解释的配置调整

性能优化最怕一次改很多项，最后不知道哪一项产生了效果。每次只改一个边界清晰的内容，例如减少一张大图、删除一个不再使用的脚本引用，或调整文章中的代码块。

修改配置前先查看当前工作树：

git status --short --branch

完成后运行内容检查和 Docker 构建：

pwsh ./ops/check.ps1
pwsh ./ops/build.ps1

这样即使优化没有带来明显收益，也能确认没有损坏文章结构或发布入口。没有基准数据时，不要把主观感觉写成精确百分比。

两个常见误区

第一个误区是“插件越多越快”。插件会增加依赖、构建步骤和升级成本。只有当问题已经被测量、插件的收益明确且维护成本可接受时，才值得引入。

第二个误区是“代码压缩等于体验优化”。压缩脚本只是一个环节；如果页面最大的资源是一张不必要的大图，先处理图片比再加一个压缩插件更直接。

第三个误区是“本地构建越快，线上一定越快”。Docker 构建环境、网络传输和浏览器缓存分别属于不同层次，应该分开验证。

用生成物做最后检查

构建完成后，我会检查文章页面是否存在，并从 HTML 中确认标题、图片引用和站内链接。对于本批次，可以用 PowerShell 做简单的存在性检查：

Test-Path public/2026/08/08/hexo-performance-optimization/index.html

这不是完整的性能测试，却能避免把“命令成功但页面没生成”误判为优化成功。真正需要比较时，再记录构建耗时和页面资源大小，确保比较条件一致。

小结

Hexo 性能优化可以从小处开始：不要无意义地 clean，控制图片和外部资源，保持配置边界清楚，使用 Docker 得到可复现构建，并把 public/ 当作验收证据。

如果你想继续优化文章被发现的方式，可以看Hexo SEO 与站点地图；如果更关心优化之后如何稳定上线和恢复，再看发布后的维护与回滚。