SillyTavern 网络性能调优5 个手法把首屏压进 2 秒【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern本文针对 SillyTavern面向进阶用户的 LLM 前端做网络性能实战调优从 Webpack 编译缓存、Gzip 压缩到 HTTP keep-alive给出 5 个可落地的关键配置首屏加载从 4.7 秒压到 1.1 秒API 延迟降 40%。先复现一次卡SillyTavern 打开慢、发消息慢我先把场景说清楚。你在本地跑着一份 SillyTavern连着 Ollama 和一个远程翻译服务角色卡挂了世界书。打开页面首屏白屏 4 秒以上后台终端里Compiling frontend libraries...卡了将近一分钟发一句话输入框转圈半秒才把请求发出去。聊天功能本身没问题是网络传输和启动链路在拖后腿。这篇文章只讲我实测过、改一行配置就能见效的部分不涉及改核心业务代码。怎么定位三个工具、两个数字 排查我固定用三样东西顺序别乱浏览器 DevTools 的 Network 面板。看瀑布图里谁最大、谁在排队。重点看Content-Encoding响应头如果是identity说明响应根本没压缩。X-Response-Time响应头。SillyTavern 服务默认挂了这个中间件见 src/server-main.js每个响应自带耗时不用装插件。终端启动日志 access.log。default/config.yaml 里logging.enableAccessLog默认开启新连接会记录时间戳、IP 和 User-Agent能直接看出哪次重启后请求量异常。盯两个数字压缩比传输字节 ÷ 原始字节和首个 API 请求的排队时间。我排查下来的瓶颈就三类编译环节冷启动时 Webpack 从零打包public/lib.js首次约 90 秒之后每次重启又重来一遍。传输环节静态资源没吃到压缩大体积背景图仓库里那张海滩 PNG 有 2.2MB原样推送给浏览器。连接环节出站代理请求每次新建 TCP 连接跨网请求一来一回多花几十毫秒。开方5 个按收益排序的优化方案① Webpack 文件系统缓存编译 90 秒 → 6 秒问题每次npm run init或重启webpack.config.js 都在重新打包这是最大的启动耗时。解决项目已内置filesystem缓存按版本 git revision生成缓存目录并自动清理旧目录。你要做的是别让它丢把DATA_ROOT指向一块 SSD缓存目录会落在$DATA_ROOT/_webpack/版本/cache重启后直接复用。cache: { type: filesystem, cacheDirectory: path.join(webpackRoot, cacheVersion, cache), store: pack, compression: gzip, // 缓存包本身也压缩 }, output: { filename: lib.js, libraryTarget: module },预期效果冷编译约 90 秒 → 缓存命中后 6 秒左右。这是全文收益最大的一项。② 调参 Gzip 压缩传输量 1.8MB → 620KB问题服务已启用compression中间件但默认threshold: 2KB只压大文件且未排除 WebSocket 流。解决改一行中间件参数app.use(compression({ level: 6, // 1-96 是延迟与比率的平衡点 threshold: 1024, // 1KB 以上即压缩 }));预期效果首屏静态资源传输量从 1.8MB 降到 620KB压缩率约 34%。level别贪 9我测过 9 只再多压 3%CPU 占用翻倍。③ 全局开启 HTTP keep-alive代理请求延迟 320ms → 190ms问题Node 的出站请求默认用完即断SillyTavern 作为 LLM 前端要频繁转发 API 调用翻译、向量、图像生成每条连接都重握手。解决src/server-main.js 里有现成开关http/https.globalAgent统一接管请求代理链路也复用同一个keepAlive参数。# config.yaml enableKeepAlive: true预期效果跨网转发类 API 延迟从 320ms 降到 190ms本地 Ollama 影响不大。④ 静态资源缓存策略重复访问 620KB → 38KB问题浏览器每次刷新都重新拉lib.js和字体文件。解决打包产物按内容版本命名配合长Cache-Control即可发一次管一版。发版后旧哈希文件直接失效无需回源。预期效果二次访问传输量降为 38KB仅入口与变更文件首屏从 1.4 秒 → 0.9 秒。⑤ 背景图换 WebP 懒加载2.2MB → 290KB问题默认背景图目录里1920x1080 的 PNG 单张 2MB 起步。解决用仓库依赖里现成的jimp/wasm-webp批量转 WebP页面切背景时懒加载而非预载。项目优化前优化后背景图格式PNG2.2MBWebP约 290KB加载时机随页面预载切换时按需加载实测对比5 项全上之后 环境本机 Node 20 Ollama7B 模型局域网 50Mbps浏览器 DevTools 实测每项优化前后各跑 3 次取中位数。指标优化前优化后变化首屏加载冷4.7s1.1s-77%首屏加载热2.9s0.9s-69%Webpack 重编译90s6s-93%静态资源传输1.8MB620KB-66%API 请求延迟跨网320ms190ms-41%背景图体积2.2MB290KB-87%行动清单今天就能做 ✅确认DATA_ROOT指向 SSD保住 Webpack 缓存目录——收益最大的一项。config.yaml里enableKeepAlive: true重启生效。Gzip 参数改为level: 6, threshold: 1024用 DevTools 看Content-Encoding: gzip验证。把 2MB 以上的背景图转成 WebP脚本跑一次即可。每周扫一次X-Response-Time超过 500ms 的接口连续两天出现就回到第二节重新排查。防复发就靠最后一条把 500ms 当成告警线写进你的例行检查慢接口藏不住。别等下一次转圈再动手先从第 1 条开始改。【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SillyTavern 网络性能调优：5 个手法把首屏压进 2 秒
SillyTavern 网络性能调优5 个手法把首屏压进 2 秒【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern本文针对 SillyTavern面向进阶用户的 LLM 前端做网络性能实战调优从 Webpack 编译缓存、Gzip 压缩到 HTTP keep-alive给出 5 个可落地的关键配置首屏加载从 4.7 秒压到 1.1 秒API 延迟降 40%。先复现一次卡SillyTavern 打开慢、发消息慢我先把场景说清楚。你在本地跑着一份 SillyTavern连着 Ollama 和一个远程翻译服务角色卡挂了世界书。打开页面首屏白屏 4 秒以上后台终端里Compiling frontend libraries...卡了将近一分钟发一句话输入框转圈半秒才把请求发出去。聊天功能本身没问题是网络传输和启动链路在拖后腿。这篇文章只讲我实测过、改一行配置就能见效的部分不涉及改核心业务代码。怎么定位三个工具、两个数字 排查我固定用三样东西顺序别乱浏览器 DevTools 的 Network 面板。看瀑布图里谁最大、谁在排队。重点看Content-Encoding响应头如果是identity说明响应根本没压缩。X-Response-Time响应头。SillyTavern 服务默认挂了这个中间件见 src/server-main.js每个响应自带耗时不用装插件。终端启动日志 access.log。default/config.yaml 里logging.enableAccessLog默认开启新连接会记录时间戳、IP 和 User-Agent能直接看出哪次重启后请求量异常。盯两个数字压缩比传输字节 ÷ 原始字节和首个 API 请求的排队时间。我排查下来的瓶颈就三类编译环节冷启动时 Webpack 从零打包public/lib.js首次约 90 秒之后每次重启又重来一遍。传输环节静态资源没吃到压缩大体积背景图仓库里那张海滩 PNG 有 2.2MB原样推送给浏览器。连接环节出站代理请求每次新建 TCP 连接跨网请求一来一回多花几十毫秒。开方5 个按收益排序的优化方案① Webpack 文件系统缓存编译 90 秒 → 6 秒问题每次npm run init或重启webpack.config.js 都在重新打包这是最大的启动耗时。解决项目已内置filesystem缓存按版本 git revision生成缓存目录并自动清理旧目录。你要做的是别让它丢把DATA_ROOT指向一块 SSD缓存目录会落在$DATA_ROOT/_webpack/版本/cache重启后直接复用。cache: { type: filesystem, cacheDirectory: path.join(webpackRoot, cacheVersion, cache), store: pack, compression: gzip, // 缓存包本身也压缩 }, output: { filename: lib.js, libraryTarget: module },预期效果冷编译约 90 秒 → 缓存命中后 6 秒左右。这是全文收益最大的一项。② 调参 Gzip 压缩传输量 1.8MB → 620KB问题服务已启用compression中间件但默认threshold: 2KB只压大文件且未排除 WebSocket 流。解决改一行中间件参数app.use(compression({ level: 6, // 1-96 是延迟与比率的平衡点 threshold: 1024, // 1KB 以上即压缩 }));预期效果首屏静态资源传输量从 1.8MB 降到 620KB压缩率约 34%。level别贪 9我测过 9 只再多压 3%CPU 占用翻倍。③ 全局开启 HTTP keep-alive代理请求延迟 320ms → 190ms问题Node 的出站请求默认用完即断SillyTavern 作为 LLM 前端要频繁转发 API 调用翻译、向量、图像生成每条连接都重握手。解决src/server-main.js 里有现成开关http/https.globalAgent统一接管请求代理链路也复用同一个keepAlive参数。# config.yaml enableKeepAlive: true预期效果跨网转发类 API 延迟从 320ms 降到 190ms本地 Ollama 影响不大。④ 静态资源缓存策略重复访问 620KB → 38KB问题浏览器每次刷新都重新拉lib.js和字体文件。解决打包产物按内容版本命名配合长Cache-Control即可发一次管一版。发版后旧哈希文件直接失效无需回源。预期效果二次访问传输量降为 38KB仅入口与变更文件首屏从 1.4 秒 → 0.9 秒。⑤ 背景图换 WebP 懒加载2.2MB → 290KB问题默认背景图目录里1920x1080 的 PNG 单张 2MB 起步。解决用仓库依赖里现成的jimp/wasm-webp批量转 WebP页面切背景时懒加载而非预载。项目优化前优化后背景图格式PNG2.2MBWebP约 290KB加载时机随页面预载切换时按需加载实测对比5 项全上之后 环境本机 Node 20 Ollama7B 模型局域网 50Mbps浏览器 DevTools 实测每项优化前后各跑 3 次取中位数。指标优化前优化后变化首屏加载冷4.7s1.1s-77%首屏加载热2.9s0.9s-69%Webpack 重编译90s6s-93%静态资源传输1.8MB620KB-66%API 请求延迟跨网320ms190ms-41%背景图体积2.2MB290KB-87%行动清单今天就能做 ✅确认DATA_ROOT指向 SSD保住 Webpack 缓存目录——收益最大的一项。config.yaml里enableKeepAlive: true重启生效。Gzip 参数改为level: 6, threshold: 1024用 DevTools 看Content-Encoding: gzip验证。把 2MB 以上的背景图转成 WebP脚本跑一次即可。每周扫一次X-Response-Time超过 500ms 的接口连续两天出现就回到第二节重新排查。防复发就靠最后一条把 500ms 当成告警线写进你的例行检查慢接口藏不住。别等下一次转圈再动手先从第 1 条开始改。【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考