从23秒到2秒，一次真实的网站性能优化历险记

前言：神秘的“加载中”

在上一篇文章中，我们成功搭建了私有密码库Vaultwarden。功能完美，安全可靠，但一个恼人的问题出现了：每次打开登录页面，都要盯着加载动画转圈长达20多秒！这对于一个追求极致体验的用户来说，是无法接受的。

是服务器太弱？还是程序本身有问题？为了揭开真相，我开始了一场有趣的性能优化之旅。我的破案工具，就是每个浏览器都内置的“开发者工具”（按下F12即可召唤）。

第一幕：审问第一嫌疑人——服务器后端

一个网页加载缓慢，最常见的怀疑对象就是服务器“反应慢”。我打开开发者工具的“网络(Network)”面板，刷新页面，开始分析。

调查方法: 关注瀑布图中的第一个请求，也就是对域名 https://vault.yourdomain.com 本身的请求。我们需要查看它的“等待(TTFB – Time to First Byte)”时间。这个时间代表了从我们发出请求，到服务器处理完毕并返回第一个字节数据所用的时间。
惊人的发现: 调查结果显示，TTFB只有104毫秒！这个速度快得惊人。
初步结论: 这证明我的服务器后端（包括Nginx、Docker和Vaultwarden程序本身）性能极佳，它在0.1秒内就已经响应了请求。服务器后端是无辜的！ 问题必然出在后续的数据传输阶段。

第二幕：揪出真正的罪魁祸首——前端资源

既然服务器响应很快，那为什么总时间还那么长？我将目光投向了瀑布图中那些长长的、蓝色的加载条。

调查方法: 分析那些.js (JavaScript) 和 .css (样式表) 文件的加载情况。
罪证确凿: 我看到了触目惊心的数字：
- 一个名为 main.js 的文件，体积近2MB，下载耗时22.7秒！
- 一个名为 polyfills.js 的文件，体积1.1MB，下载耗时19.4秒！
最终结论: 谜底揭晓！问题在于浏览器下载这些前端资源文件实在是太慢了。原因是“文件体积过大”和“服务器网络带宽有限”这两个因素叠加造成的。

第三幕：祭出两大“银弹”——压缩与缓存

既然问题是“大文件、慢网络”，解决方案就非常清晰了：“把文件变小”和“让浏览器少下载”。

第一发银弹：Gzip压缩 (把文件变小)
- 原理: .js 和 .css 本质上都是文本文件，使用Gzip压缩可以极大地减小它们的体积，通常能减少60%以上。
- 操作: 我登录宝塔面板，在网站设置的“性能调整”里，开启了Gzip压缩，压缩级别选择了公认的黄金值“6”。
第二发银弹：浏览器缓存 (让浏览器少下载)
- 原理: 告诉浏览器，这些静态文件（如图标、字体、JS、CSS）在未来7天内都不会改变，你把它们存到电脑本地吧，下次就不用再问我要了。
- 操作: 我在网站的“配置文件”中，添加了如下的Nginx缓存规则：
  Nginx
  location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 7d; }

第四幕：最后的谜团——神秘的WASM文件

两套组合拳打出去后，速度确实快了不少，但仍然没有达到预期。我再次打开网络面板，发现总下载量依然偏大。经过仔细排查，我发现了一个被遗漏的“大块头”：一个3.4MB，Content-Type为application/wasm的文件。

终章：见证奇迹

在完成所有优化后，我清空缓存，再次刷新了页面。

首次访问: 总加载时间从23.5秒缩短到了10.5秒。总下载量从近6MB压缩到了3.4MB。考虑到我服务器3Mbps的物理带宽上限（理论下载3.4MB就需要9秒），这个结果已经达到了物理极限。
再次访问: 当我第二次刷新页面时，奇迹发生了。由于浏览器缓存生效，所有静态资源都从本地读取，整个页面的加载时间不到2秒！

结语

这次优化历险记告诉我们，面对网站缓慢的问题，不要凭空猜测。学会使用开发者工具，通过数据分析定位瓶颈，然后针对性地使用“压缩”和“缓存”这两大通用法宝，往往能取得事半功倍的效果。在下一篇，也是本系列的终章，我们将讨论如何为我们的服务器建立一套万无一失的备份策略。

近期文章