Marico's space

说实话，以前 Web 性能优化这事，大家普遍觉得是"锦上添花"——功能做完再顺手搞一下。但现在不一样了：用户预期页面两秒内加载完，搜索引擎越来越偏向快体验，每多一毫秒延迟都能实实在在影响转化率。

然而，尽管这个现实大家都懂，很多开发团队还是把性能当附属品——功能上线之后再来打补丁。

今天聊聊实用的、以开发者为中心的性能优先网站构建策略，真正重要的指标，以及如何把性能文化揉进团队工作流。

为什么性能是一等公民

性能不只是关乎"用户没耐心"这件事。它直接影响：

• 搜索可见性——Core Web Vitals 是排名信号，慢网站在自然流量上吃亏。
• 可访问性——用老设备或信号差的移动网络的用户，受笨重包体积的影响更大。
• 基础设施成本——页面臃肿意味着更多带宽、更多 CDN 流量、更多计算资源。
• 开发迭代速度——开发时慢的网站，迭代起来通常也慢。

如果你试过在成熟代码库上做性能改造，你会知道从第一天就考虑性能比事后补救要简单得多。

真正重要的指标

优化任何东西之前，先量对东西。像"页面加载时间"这种虚荣指标，掩盖的问题比揭示的多。

Core Web Vitals

Google 的 Core Web Vitals 仍然是最有用的基准：

• Largest Contentful Paint（LCP）——主要内容渲染多快。目标：2.5 秒以内。
• Interaction to Next Paint（INP）——页面对用户输入响应的感受。目标：200ms 以内。
• Cumulative Layout Shift（CLS）——加载过程中布局多稳定。目标：0.1 以内。

Beyond the Basics

要看到更完整的图景，还要追踪：

• Time to First Byte（TTFB）——暴露服务器和网络瓶颈。
• Total Blocking Time（TBT）——开发时 INP 的 lab 代理指标。
• JavaScript bundle 大小——大多数团队手里最大的杠杆。

Real-user monitoring（RUM）要始终和 lab 数据配合着用。Chrome User Experience Report、SpeedCurve，或者用 PerformanceObserver API 轻量自研，能告诉你用户实际体验是什么，而不只是 Lighthouse 预测的数字。

影响最大的架构决策

少发 JavaScript

这个听起来像废话但一直被忽视。每 1KB JavaScript 都需要下载、解析、编译、执行——而且往往是在 CPU 性能一般的 Android 设备上。在引入新框架或库之前，先想想这个问题能不能用 HTML 和 CSS 解决。

实用策略：

• 在路由和组件边界做代码分割。
• Tree shaking 去掉没用到的 exports。
• 替换重的依赖——你的日期选择器真的需要 Moment.js 吗？Intl.DateTimeFormat 是内置的。
• Islands 架构，内容为主的站点只水合交互部分。

选对渲染策略

对于很少变化的内容，静态生成通常优于服务器渲染。对于个性化仪表盘，带部分水合的流式 SSR 往往是最佳平衡点。"我们 SSR 一切"或者"我们做 SPA"这种一刀切的做法，通常都是在牺牲性能。

激进缓存，智能失效

配置得当的 CDN 能把慢 origin 变成快体验。对版本化的资源用不可变缓存，HTML 用 stale-while-revalidate，API 响应尽量边缘缓存。HTTP 缓存一直是开发者工具箱里最被低估的性能工具之一。

图片和字体：沉默的带宽杀手

图片通常是页面重量最大的部分。AVIF 和 WebP 这样的现代格式比 JPEG 小 30-50%，而且几乎无感知质量损失。配合 <picture> 元素和正确设置的 sizes 属性，响应式图片其实没那么麻烦。

字体方面：

• 尽量自托管，避免第三方 DNS 和 TLS 开销。
• 用 font-display: swap 或 optional 防止文字不可见。
• 只子集化你真正需要的字形。
• 用 <link rel="preload"> 预加载关键字体文件。

建立性能文化

工具和技术只能帮你到这里。持续交付快网站的团队，把性能当成共同责任，而不是某个工程师的个人爱好。

性能预算

给 bundle 大小、图片重量和关键指标设硬限制。用 bundlesize、size-limit 或 Lighthouse CI 在 CI 里强制执行。某个 PR 把 LCP 推过预算线就应该让构建失败——跟单元测试失败一模一样。

让性能可见

墙上一个 dashboard、Slack bot 发每周 RUM 总结、sprint review 里一张简单的记分卡——可见性带来责任。当整个团队看到性能在往错的方向走，问题就会被修复。

定期审计

维护得再好的网站也会 drift。第三方脚本堆积、图片优化流水线坏掉、新功能引入回归。很多团队会请专门做 SEO 审计的外部专家来配合内部监控，特别是当技术 SEO 和性能有重叠的时候。一双外部新鲜眼睛往往能发现内部团队已经视而不见的问题。

实用的起点

如果你面对一个性能低下的代码库不知道从哪开始，按这个顺序试：

1. 用 RUM 和 Lighthouse 测量，建立基准线。
2. 审计第三方脚本——分析、标签管理、聊天组件。去掉不产生价值的。
3. 优化图片——转现代格式、懒加载折页以下内容。
4. 裁剪 JavaScript——用 webpack-bundle-analyser 或类似工具分析 bundle，消灭最大的问题。
5. 给 CI 加上性能预算，让成果被锁定，而不是慢慢被侵蚀。

每一步一两个 sprint 都能完成，加在一起能把一个卡慢的网站变成真正快的体验。

最后想法

性能不是一次性的检查清单——它是融进团队对代码、内容和基础设施思考方式的持续实践。把这些内化的开发者交付的网站体验更好、排名更高、运行成本更低。有了正确的指标、架构和团队文化，性能优先开发就不再是琐事，而会成为你做 Web 开发的标准方式。

译者按：原文 https://dev.to/manchesterdigitalhub/building-performance-first-websites-a-developers-guide-to-measurable-speed-3li3