一次 Typecho 首页无缓存加载缓慢的排查：Vditor 插件引用的JS可能是主要原因

首页在浏览器禁用缓存后加载很慢，最初直觉往往会落在模板渲染、数据库查询或服务器性能上。但这次排查的网络瀑布图给出了更直接的线索：HTML 文档很快返回，真正拖长页面完成时间的是一批在首页无条件加载的第三方前端资源。

用户附件.png

先区分：慢在服务端，还是慢在浏览器资源

排查性能问题时，先看首页 HTML 文档本身的耗时。截图中首页文档请求约为 176 ms，而后续资源里出现了数十秒甚至一分钟级的请求。这意味着当时的主要问题不在 PHP 生成首屏 HTML，而在浏览器拿到 HTML 之后继续请求的脚本和样式。

这个区分很重要。若文档请求已经很慢，应优先检查 PHP、数据库、缓存和上游网络；若文档很快、静态资源很慢，则要从模板输出和插件注入的资源开始查。

资源名称直接指向 Vditor_for_Typecho

网络面板中最慢的资源包括：

  • mermaid.min.js，约 992 KB
  • echarts.min.js，约 335 KB
  • highlight.min.js
  • katex.min.js
  • auto-render.min.js

这些并不是 zheyu 主题自身需要的资源，而是 Vditor_for_Typecho 插件提供 Mermaid、ECharts、代码高亮和数学公式渲染时加载的依赖。

进一步检查插件代码可以看到，它注册了 Archive::header 钩子；这意味着首页、分类页、标签页和文章页都会经过这段逻辑。资源注入代码没有判断当前页面是否真的包含流程图、图表、公式或代码块，而是直接输出 Vditor 样式，以及 Mermaid、ECharts、highlight.js 和 KaTeX 的远程地址。

换句话说，即使首页只是文章列表，也会下载一整套面向文章正文渲染的库。浏览器缓存存在时，这些资源大多不会重复下载，因此问题不明显；禁用缓存或首次访问时，则完全暴露出来。特别是在网络到 unpkg.com 不稳定的环境中，大体积脚本会把页面加载时间拉到非常高。

为什么可以排除 zheyu 主题本身

zheyu 主题本身只加载本地的主题 CSS 和延迟执行的主题 JS。它会调用 Typecho 的页面头部钩子，而 Vditor 正是通过这个公共钩子把资源附加到页面中。

主题中还支持在后台配置广告脚本，因此 Google AdSense 会带来额外的广告请求和 iframe。这些请求会增加网络面板中的条目，也可能受到广告网络状态影响，但不会产生 Mermaid、ECharts、KaTeX 和 highlight.js 这一组特征明确的资源。它们是 Vditor 插件的直接证据。

验证结果

关闭 Vditor_for_Typecho 后，首页不再输出上述依赖，前后两次加载时间的巨大差异随之消失。由此可以确认：

本次“首页无缓存加载特别久”的主因是 Vditor_for_Typecho 在首页无条件加载大型第三方渲染资源，不是 zheyu 主题的基础渲染逻辑。

统计插件是另一个需要单独观察的点

排查过程中，VisitAnalytics 也值得留意。它当前采用服务端统计模式，会在页面渲染前记录访问、写入去重和聚合数据。这个行为可能增加未缓存请求的服务端工作量，但它解释不了网络面板中 Mermaid、ECharts 等资源的分钟级下载。

因此，不能把一次服务端响应波动直接归因于统计插件。应当在 Vditor 保持关闭、访问条件一致的情况下，再单独连续测量首页 TTFB，才能判断是否还存在数据库或统计写入问题。

后续优化原则

如果之后仍需要 Vditor 的正文渲染能力，更合理的做法是按页面内容按需加载：只有文章中确实使用 Mermaid、ECharts、KaTeX 或代码高亮时，才引入对应资源。也可以将依赖部署到更稳定的静态资源位置，并给版本化资源设置合适的缓存策略。

性能排查的关键不是先猜“模板慢”还是“服务器慢”，而是先从网络瀑布图定位最长请求，再沿着资源的发起位置回到对应的插件或模板代码。这次案例中，资源名称本身已经给出了答案。