为什么 Wiki.js 首屏要等两秒一份完整的性能优化实战复盘【免费下载链接】wiki-Wiki.js | A modern and powerful wiki app built on Node.js项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-Wiki.js 是构建在 Node.js 上的知识库应用我们五十多人共用一个实例。一次升级后打开页面要等 2.8 秒编辑保存后还得盯着转圈。这份 Wiki.js 性能优化实录覆盖反向代理、服务端、构建、进程四处改动最终把平均首屏压进 0.9 秒以内编辑后的等待基本消失。先查体怎么证明不是机器的锅问题刚出现时第一反应是加内存、扩带宽上线后体感毫无变化。别再猜了直接上证据。三个检查各给一个可操作的动作浏览器 Network 面板勾掉停用缓存后刷新页面按总耗时排序。结果很直白——最贵的条目不是图片而是两个 JS/CSS 大文件且每次访问都完整重下。这就是典型的 Wiki.js 首屏慢症状资源太大浏览器没有复用。服务端请求日志给渲染入口加计时。日志显示每个匿名浏览都完整跑了一遍管线——Markdown 渲染、目录树解析、HTML 后处理读者不登录这活儿基本白干。SQL 日志开关在 server/core/config.js 里已经预留config.yml的flags下加一行sqllog: true服务端就会打印每条 SQL。跑一天N1 查询自己会跳出来定位完记得关掉它很吵。三查下来结论明确机器没问题慢在浏览器没记住、服务端在返工、数据库在排队。处方一反向代理层——给静态资源一年缓存只压文本看到什么Network 面板里同一批 JS/CSS 每次访问都重下。根因是前置 Nginx 没告诉浏览器这些文件不用再问了。改哪一处Nginx 配置做两件事——只给文本类资源开 Gzip给/_assets/设置一年缓存gzip on; gzip_types text/css application/javascript application/json image/svgxml; location /_assets/ { expires 1y; add_header Cache-Control public, immutable; }为什么敢给一年看 dev/webpack/webpack.prod.js产物文件名自带时间戳内容变了 URL 就变新版本一定拿得到老版本不会发错。改完看到什么这段 Nginx 静态资源缓存改动约十分钟回访用户资源请求基本归零文本类传输体积降约七成。处方二服务端层——给内存缓存贴保质期页面缓存只收匿名请求看到什么打开 server/core/cache.jsnew NodeCache()没带任何参数——缓存键永不过期内存只进不出跑得越久堆积得越多。改哪一处Node.js 内存缓存配置的核心是补两个参数stdTTL定缓存默认寿命checkperiod定周期检查间隔init() { return new NodeCache({ stdTTL: 600, checkperiod: 120 }) }等于给每条缓存贴了张保质期标签十分钟到期自动失效扫描线程定期清场。讲究一点再分层——字典类配置长 TTL热点页面短 TTL避免改完内容用户还看到旧版。静态资源和内存缓存到位后页面 HTML 每次仍要跑一遍渲染管线。对匿名读者占多数的知识库我们把缓存再往前推一层到 Nginx只缓存匿名 GET命中直接吐 HTMLproxy_cache_path /var/cache/wiki keys_zonewiki:10m max_size1g; location / { proxy_cache wiki; # 仅对匿名 GET 生效 proxy_cache_valid 200 5m; }红线提醒登录态页面严禁缓存。不同账号同一地址可见内容不同缓存串了就是安全事故。要么只对匿名请求启用要么把鉴权信息带进缓存键并用Vary头区分响应。改完看到什么2.8 秒到 0.9 秒的跃升主要来自这一步Nginx 日志里的缓存命中率可以直接核对。处方三构建层——splitChunks 与路由懒加载主包瘦四成看到什么初始主包好几 MB编辑器这种大多数人一辈子点不开的组件也在里面。改哪一处生产配置里 splitChunks 默认参数偏保守改成让全部第三方依赖显式进独立 vendor chunksplitChunks: { chunks: all, cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name: vendor } } }再加一步Webpack 路由懒加载编辑器只在用户点编辑时才下载// 点击编辑才拉取编辑器 chunk const Editor () import(/* webpackChunkName: editor */ ./components/editor.vue)改完看到什么vendor chunk 几乎不变长缓存命中率维持高位应用更新只有小块 diff 需要重下。实测首屏 JS 体积降约四成。处方四进程层——连接池、独立 worker 与堆上限看到什么高峰期接口 p95 拉长、CPU 顶格。原因有二数据库连接太少请求排队渲染是 CPU 密集任务在和 Web 请求抢同一个事件循环。改哪一处三处。先说连接池——config.sample.yml里这块默认是注释状态框架走保守默认值pool: min: 2 max: 8把数据库连接想象成电梯轿厢太少所有人都在大厅干等。其次把 server/jobs/render-page.js 里的渲染任务挪进独立 worker 进程Web 请求不再和重渲染抢事件循环。最后多实例时给 V8 堆设上限约取机器内存的四分之一防止 GC 抖动拖慢响应。改完看到什么高峰等待肉眼可见下降。注意多实例务必打开配置里的ha标志——各实例内存缓存互相独立需要发布流程统一失效才能保持一致。避坑手册这些优化我们后来全回滚了⚠️ 做过的、放弃的都写出来Gzip 连图片一起压最初把图片也塞进gzip_typesCPU 飙升、体积几乎没降后来只留文本类型。页面缓存 TTL 拉到一小时用户反馈明明改了同事看到的还是旧的。改回 5 分钟 发布时主动失效。chunk 拆得太碎一个功能拆出三四个 chunkHTTP/1.1 下请求数爆炸反而更慢后来合并并升级 HTTP/2。无脑横向扩容把实例复制成四份结果共享同一套数据库、各自维护缓存症状不变。先把慢查询修掉再谈扩容。数据与清单指标优化前优化后平均首屏耗时2.8 秒0.9 秒回访时的资源请求完整 JS/CSS 重下基本为零初始主包体积传输约 1.2 MB约 0.7 MB高峰期接口 p95约 1.5 秒约 0.5 秒内存增长趋势持续上涨不回落随 TTL 波动不漂移 今天就能动手的三件事反向代理层给/_assets/加 Gzip 和一年缓存纯 Nginx 配置十分钟见效打开 server/core/cache.js 补上stdTTL与checkperiod重启服务开启flags: sqllog跑一天揪出慢查询与 N1结束后记得关闭。照着从外到内的顺序继续小步改每一步都用数字说话能用迟早会变成好用。【免费下载链接】wiki-Wiki.js | A modern and powerful wiki app built on Node.js项目地址: https://gitcode.com/GitHub_Trending/wiki78/wiki-创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考