一个网站好不好用，打开和切换页面的那几秒，往往就能让人形成第一印象。
这次记录一下 Baekonbeauty 官网 和配套管理工作台采用的技术，以及让访问更顺畅的几个具体设计。既看页面，也看实际请求和项目源码，不把“感觉很快”直接写成跑分。
官网首页实拍。后台截图仅保留功能区域，已裁去账号、业务统计和其他敏感区域；管理入口不公开。
先看一组实测：HTML 首字节约 84 毫秒
2026 年 10 月 25 日，在本次执行环境中，对官网首页进行 5 次顺序请求。每次使用独立 curl 进程，启用压缩，不添加绕过缓存的随机参数，也没有进行并发压测。
| 观察项目 | 本次结果 |
|---|---|
| 首页状态与协议 | 5 次均为 HTTP/2 200，无跳转 |
| HTML 首字节时间（TTFB） | 中位数约 84.4 ms，范围 74.5–103.7 ms |
| HTML 传输体积 | gzip 后 1,948 字节，解压后 6,530 字节 |
| 官网入口 JavaScript | gzip 后约 82.7 KiB |
| 官网入口 CSS | gzip 后约 96.4 KiB |
这组数据表示 HTML 文档响应很快，不表示整页在 0.084 秒内全部加载完成。 图片、视频、接口、脚本执行和浏览器绘制还需要各自的时间；这里也没有把三项入口资源的体积当成整页体积。
测试来自单一网络出口，未确认其地区和运营商，因此不能推广成所有地区、所有手机网络的访问结果。
用了什么技术栈？
官网和管理工作台承担不同任务，前端也分开构建。结合线上产物和项目源码，可以确认到以下范围：
| 部分 | 技术与用途 |
|---|---|
| 官网前端 | Vue 3、Vue Router、Vite 构建；负责产品展示、内容页面和交互 |
| 官网内容输出 | Nginx 分流静态资源，Python 内容渲染服务输出带导航、标题、产品链接的 HTML 与 SEO 信息 |
| 管理工作台 | Vue 3、TypeScript、Vite、Element Plus、Pinia、Vue Router |
| 业务服务端源码 | Go、Gin、GORM，使用 MySQL 驱动；负责业务接口与数据访问 |
| 公开资源传输 | 本次观测到 HTTP/2、gzip、EdgeOne 响应头；部分静态资源带 COS 与缓存命中标识 |
表中的服务端实现来自当前项目源码；线上前端产物也能看到 Vue、Element Plus 和动态导入等相应特征。本次没有逐个比对所有线上文件与本地构建的哈希，也没有读取生产数据库配置。
技术选型提供工具，真正影响体验的，还包括下面这些具体做法。
官网的快：入口轻、资源分流、需要时再加载
1. 先把入口交到浏览器
官网首页 HTML 压缩后不到 2 KB，而且已经包含导航、主标题、分类和产品链接等可读内容。它同时引用前端资源，后续交互由 Vue 接管。
项目中有专门的服务端内容输出逻辑。这里能确认的是“服务端输出了可读 HTML”，并没有将它笼统称为完整的 Vue SSR 或 hydration 实现。
2. 压缩和边缘缓存各自减少一部分等待
gzip 减少文本资源的传输字节，静态资源分发与缓存则为重复访问提供复用机会。本次官网入口 JS 由约 258 KB 压至约 85 KB，CSS 由约 495 KB 压至约 99 KB。
缓存需要看具体响应：本轮首页 HTML 是 MISS，并带有 no-store；入口 JS 是 RefreshHit；样式资源出现缓存命中标识。
RefreshHit 表示缓存过期后回源校验，确认资源未变，再继续使用缓存，仍然包含校验过程。因此，“首页很快”不能简单解释为“所有内容都直接命中了 CDN 缓存”。这一区别也可以在 EdgeOne 官方响应头说明 中核对。
3. 不一次装下全部语言和图片
官网语言包使用动态导入，部分图片设置了懒加载。这样，当前暂时用不到的语言内容、屏幕下方的部分图片，可以延后获取。
这是把加载顺序安排得更合理。这里没有声称官网所有路由都懒加载，也没有将未验证的图片格式转换写成优化成果。
官网内容渲染服务的源码还对只读公开 API 数据设置了 30 秒进程内缓存，减少短时间内重复获取相同数据。它缓存的是服务端读取的内容数据，与浏览器缓存 HTML、CDN 缓存文件是不同层次。
后台的快：切换页面时，少做重复工作
后台功能区局部实拍，裁去了顶部账号与业务统计，未替换为虚构数据。
后台是日常反复使用的工具。与首次打开相比，从列表进入详情、返回原页面、切换功能时的等待，同样值得关注。
1. 站内切换复用应用，业务页面按需加载
管理工作台使用 Vue Router。应用加载后，站内切换通常由前端路由完成，公共布局和已加载的代码可以继续使用，不必每次重新下载完整 HTML。
源码中的页面加载器使用 import.meta.glob 等方式按需加载视图。用户进入相应功能时，再获取对应页面代码。这与 Vue 官方性能指南中的代码分割思路 一致。
部分标记了 keepAlive 的页面还会保留组件实例，当前代码设置最多保留 10 个。返回这些页面时，可以减少重建界面的工作。组件保留不意味着业务数据永远有效，也不意味着所有页面都被缓存。
2. 业务概况并行请求，只取当前需要的数据
工作台概况的源码使用 Promise.allSettled 并行获取多类数据，避免在前端逐项串行等待。
为了展示统计数量，请求每类列表时只取一条记录，并读取接口返回的 total，而不是先下载完整列表再数条数。这可以减少初次传输的数据量；至于数据库如何计算总数，仍取决于后端查询与索引，不能据此宣称统计没有开销。
“最近操作”则在展开时再请求，当前只取 8 条。第一次打开工作台时，就不必为暂时没看的明细列表支付全部加载成本。
常用功能入口实拍，仅展示功能名称与说明，不包含设备编号、顾客资料或业务记录。
3. 后台也启用了压缩，但完整首屏仍要单独测
本次抓取中，后台入口 JS 解压后约 1.87 MB，gzip 传输约 617 KB；入口 CSS 由约 147 KB 压至约 25 KB。压缩显著减少了传输量，浏览器仍需解压和执行代码。
这也提醒我：入口 HTML 小、页面切换流畅，与第一次访问的完整加载速度，是需要分别观察的指标。
做性能，最后还是要回到用户的等待
这套网站中，能够核实的做法包括：较轻的 HTML 入口、压缩与静态资源分发、语言和图片按需加载，以及后台的页面复用、并行请求和明细延后加载。它们分别减少传输、重复初始化与不必要的数据获取，共同为顺畅体验创造条件。
本次没有进行优化前后对照、多地区弱网测试或压力测试，也没有测得 Lighthouse 分数、LCP、INP 等完整浏览器指标，因此不为每一项设计标注虚构的提速百分比。
我更在意的是把这些细节落实到实际流程：官网先让访客看到内容，后台先让操作者找到要处理的功能，再按需要获取明细。后续继续优化，也会从这些可测量的等待开始。