Benchmark · 基线
性能基线
拿数字说话
「感觉挺快」不算结论,跑一遍请求数再说。
页面体积基线
越小越好,这是刻意的
| 页面 | HTML | 样式 | 脚本 | 外部请求 |
|---|---|---|---|---|
| 首页 | 约 13 KiB | style.css 8 KiB + sub.css 12 KiB | main.js 7 KiB + sub.js 7 KiB | 1(Releases API) |
| 软件库 | 约 8 KiB | 同上 | sub.js | 0 |
| 单个应用 | 约 5 KiB | 同上 + app.css 5 KiB | app.js 5–9 KiB | 0 |
| 在线工具箱 | 约 4 KiB | tools.css | tools.js 约 60 KiB | 0 |
| 状态页 | 约 4 KiB | 同上 | js/status.js 7 KiB | 12(四仓各三次,15 分钟一次) |
没有字体文件、没有图标库、没有框架。图标用 emoji 与内联 SVG,字体用系统字体栈。
怎么自己测
三条命令,别信感觉
# 1. 体积与请求数
curl -s -o /dev/null -w "size=%{size_download} time=%{time_total}\n" https://xkmyth.github.io/
# 2. 打开 DevTools → Network → 勾选 Disable cache → 刷新,看 Transfer 总量
# 3. Lighthouse(移动端 + 桌面端各跑一次),重点看 TBT 与 CLS
这套站点的目标是:首屏请求数 ≤ 6、传输 ≤ 60 KiB、CLS 接近 0。达不到就说明有人往页面里塞了多余的东西。
性能上的取舍
明确知道放弃了什么
不做视觉重特效
星空是 canvas,只在可见时绘制,DPR 上限 2,切后台立刻停。
不做无限滚动列表
工具与截图都在本地,一次性渲染;数据量变大前不引入虚拟滚动。
不做 SSR
静态 HTML 已经是「构建期渲染」,没有服务端可做,也不需要。
实测体积
脚本量的,不是估的(gzip 按 9 级压缩模拟服务器压缩结果)
| 资源 | 原始 | gzip 后 |
|---|---|---|
| 主站 style.css | 30.2 KiB | 7.8 KiB |
| 主站 sub.css | 27.3 KiB | 6.9 KiB |
| 主站 sub.js | 20.1 KiB | 6.7 KiB |
| 主站 main.js | 4.1 KiB | 1.7 KiB |
| 工具站 tools.css | 23.8 KiB | 6.1 KiB |
| 工具站 tools.js | 271.3 KiB | 79.4 KiB |
| 工具站 script.js | 5.8 KiB | 2.2 KiB |
| 页面 HTML | 原始 | gzip 后 |
|---|---|---|
| 首页 | 21.5 KiB | 6.0 KiB |
| 工具目录 | 72.8 KiB | 17.0 KiB |
| 软件库 | 17.5 KiB | 5.3 KiB |
| 工具总览 | 7.5 KiB | 2.8 KiB |
| 某个工具详情 | 8.5 KiB | 3.1 KiB |
| 站务日志 | 11.0 KiB | 4.0 KiB |
首次访问首页的传输量 ≈ 首页 HTML + style.css + sub.css + sub.js 的 gzip 之和,其余页面复用缓存。工具站第一次打开会多下载一份 tools.js(160 个工具的定义都在里面,换来的是一次加载之后完全离线可用)。