页面速度 Page Speed
一句话定义
从服务端与前端实现角度看页面速度的三个可测环节：服务器响应（TTFB）、资源加载与渲染阻塞、以及最终反映到 Core Web Vitals 上的表现（LCP、INP、CLS）。
打个比方 Analogy
点一份现炒的菜：后厨开始动锅的时间是 TTFB，传菜通道有没有被杂物堵住是渲染阻塞，菜真正端上桌的时间是 LCP。三个环节坏在任何一环，顾客感知到的都是「这家上菜慢」。
岗位实战怎么做 In Practice
按环节拆开治，不要笼统地「优化速度」：1) 服务端——TTFB 目标 600ms 以内，靠缓存、CDN、数据库查询与后端渲染优化；2) 资源与渲染路径——关键 CSS 内联、非关键 JS 用 defer/async、图片用 WebP/AVIF 并显式声明尺寸；3) 现场数据——用 CrUX 与 GSC 的 Core Web Vitals 报告看真实用户分布，而不是只看实验室跑分。
案例与避坑 Pitfalls
两个常见误判：一是把实验室分数当结论，PSI 跑 100 分但真实用户 LCP 依然不达标（因为跑分用的是理想网络）；二是只盯加载速度不看交互响应——INP 在 2024 年取代 FID 之后，「页面能打开但点不动」成了新的低分主因。至于「53% 的移动用户会放弃加载超过 3 秒的页面」，出处是 Google 2016 年的那项研究，数字可以引用，但别把它当今天的手机网络现状。