推文

@fireandstart · 2026-10-14 06:53

这份清单把“网站变慢”拆成了图像与字体、前端代码、数据库/API、服务器与网络四组，价值在于把性能讨论变成可逐项检查的工程问题。比如按实际显示尺寸提供 WebP/AVIF、延迟加载首屏以下媒体、拆分首屏不需要的组件、处理 N+1 查询，以及让函数靠近数据库，分别对应下载体积、主线程负担、查询放大和网络往返。 我尤其认同先让代理找瓶颈、再验证修复的顺序：清单不是性能处方，某项建议是否适用仍取决于页面结构、查询计划和真实流量。像 RLS 索引与 auth.uid() 的写法，需要结合策略和执行计划判断；缓存则必须明确用户隔离，不能为提速泄露个性化响应。移动端慢网模拟也应覆盖关键流程，避免只优化 Lighthouse 分数。 如果把这套流程用于真实项目，我会再补上每项改动的基线、设备与网络条件、三次测量的中位数，以及回滚方式。这样团队能区分“清单上做了什么”和“用户实际快了多少”，也能避免为追求分数删功能或引入新的可靠性问题。

曝光 13 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 4.283587399153833