Google Lighthouse 初学者指南：真实的投资组合优化案例研究
I’m happy to translate the article for you, but I’ll need the full text of the post (the content you’d like translated). Could you please paste the article’s body here? Once I have the text, I’ll provide a Simplified Chinese translation while preserving the original formatting, markdown, and any code blocks or URLs.
介绍
您已经了解了 Google Lighthouse 是什么、它是如何工作的以及各项指标的含义。大多数教程就此止步，但本文将向您展示 如何真正提升 这些分数。
本文面向初级开发者——尤其是首次使用 Lighthouse 的人——提供关于如何根据 Lighthouse 报告采取实际行动的实用指南。
前置条件
- 对核心网页指标（Core Web Vitals）和加载指标有基本了解：FCP、LCP、INP、CLS。
准备您的环境
在正确的环境中测试
- 为了衡量真实世界的性能，请在站点托管的 实时域名 上运行 Lighthouse。
- 您也可以在开发期间或本地生产构建上运行它以捕获问题，但 不要使用这些结果来判断站点的真实性能。
在运行 Lighthouse 之前使用隐身窗口。这可以避免浏览器扩展干扰测试结果。
💡 小贴士
PageSpeed Insights 显示真实用户通过 Chrome UX Report（CrUX）数据体验您站点的情况。它非常适合发现真实世界的性能问题，并基于实际用户数据做出决策。
注意： PageSpeed Insights 也使用 Google Lighthouse，因此实验室数据、审计以及改进建议的呈现方式非常相似。
在分析 Lighthouse 结果时需要注意的事项
分数会波动，不同扫描之间可能相差 20–30 分。
- 运行 Lighthouse 4–5 次 以获得可靠的整体情况。
- 也可以在 1–2 小时后再运行一次，以获得更广阔的视角。
修复问题后，不要只看最终的 Performance 分数。
- 返回 Insights（洞察）标签页。
- 确认该洞察不再被高亮显示或其严重程度已降低。
- 查看相关数值（节省的时间、文件大小、延迟）以确认实际改进。
某些修复 不会导致 Performance 分数出现明显跳升，但仍能提升整体性能。
不必修复 Lighthouse 标记的所有项。
- 有些项目是站点构建方式固有的，除非导致重大问题，否则不值得投入大量精力。
优先级排序：
- 红色（高警告）洞察 通常影响最大，应该首先处理。
- 黄色（中等警告）洞察 也值得考虑，尤其是修复成本低且易于实现时。
实践演练：我的作品集
基准 Lighthouse 运行
在进行任何更改之前，我多次运行 Lighthouse 以建立可靠的基准。
| 版本 | 截图 |
|---|---|
| Mobile | (插入移动端截图) |
| Desktop | (插入桌面端截图) |
为什么关注移动端？ Google 采用移动优先策略，而在我的案例中，移动端和桌面端加载的是相同的资源（仅布局不同）。提升移动端的结果也会同步提升桌面端的结果。
初始得分
- 移动端性能得分： 55
指标贡献
| 指标 | 贡献 | 显示内容 |
|---|---|---|
| TBT | 30 / 30 | 已经处于良好状态 |
| CLS | 25 / 25 | 布局偏移不是问题 |
| Speed Index (SI) | 0 / 10 | 页面视觉加载时间过长 |
| FCP | 0 / 10 | 首次可见内容出现得太晚 |
| LCP | 0 / 25 | 主要内容加载得太晚 |
要点： 页面稳定性（CLS、TBT）良好，但 内容显示缓慢（FCP、LCP、Speed Index）。接下来的步骤将聚焦这三个指标，首先从 FCP 入手，因为更早在屏幕上呈现内容通常也能帮助提升 LCP。
Source: …
针对 FCP 的优化
为 FCP 过滤 Lighthouse 建议
通常我会从 Insights 选项卡开始，但有一个诊断信息吸引了我的注意：
潜在节省： 2445 KiB 来自 未使用的 JavaScript。
我发现的情况
- 构建后的 JavaScript 包总大小：2517 KB —— 对于一个简单的作品集页面来说简直荒唐。
- 大部分体积来自 home.js（2005 KB）和 index.js（472 KB）。
调查过程
我检查了组件中导入的库，发现 一个库 占据了大部分体积。我只需要其中的一小部分，于是我：
- 更改导入方式，只引入所需的子集。
- 重新 构建 项目。
结果
- 包体积大幅下降（从约 2.5 MB 降至几百 KB）。
- 浏览器现在下载的代码更少，页面能够更快开始渲染。
对评分的影响：
- 性能得分从 55 提升到 87。
- FCP 和 LCP 均得到改善，因为页面能够更早显示内容。
注意： 即使 Lighthouse 将 “Reduce unused JavaScript” 标记为 未评分，但削减如此大量的 JavaScript 对整体性能产生了巨大的影响。
修复摘要
| 修复 | 更改内容 | 为什么有效 |
|---|---|---|
| 修剪未使用的 JavaScript | 用最小子集替换了大型库导入 | 减少了 bundle 大小 → 更快的下载 → 更早的内容绘制 (FCP) → 更好的 LCP |
| (文章继续时会列出其他修复) |
最后思考
- 运行多次 Lighthouse 审计 以获得稳定的基准。
- 优先处理高严重性洞察（红色警告），但如果中等严重性的问题容易修复，也不要忽视。
- 专注于对当前得分最重要的指标（例如 FCP、LCP、Speed Index）。
- 即使是“未评分”的建议也可能产生巨大影响——始终调查大幅节省的警告。
通过遵循这种系统化的方法，你可以将 Lighthouse 从静态报告转变为 可操作的路线图，实现真正的性能提升。祝优化愉快！
Source: …
提升页面性能：我的做法与原因
1. 减少 JavaScript 包体积
- 原始包体积 很大，导致页面首次加载变慢。
- 通过剔除未使用的代码并在可能的地方使用懒加载，JavaScript 大小显著下降（见诊断截图）。
2. 自行托管 Google Fonts
为什么？
| 好处 | 说明 |
|---|---|
| 无第三方依赖 | 摆脱对 Google 字体分发服务的依赖。 |
| 更快的连接 | 消除一次额外的 DNS/TCP/TLS 握手。 |
| 隐私友好 | 不会把访客 IP 或请求数据发送给 Google（有助于 GDPR 合规）。 |
怎么做？
- 从 Google Fonts 下载所需字体。
- 将
.ttf文件转换为 WOFF2（更小、针对网页优化）。- 使用转换工具或 Google‑WebFont‑Helper 网站获取已生成的 WOFF2 文件。
自行托管后，性能得分跃升至 ≈95‑96，因为外部请求及其阻塞渲染的延迟消失了。
3. 优先加载 Largest Contentful Paint (LCP) 图像
LCP 图像原本以普通优先级加载，导致延迟。
<!-- Placeholder for hero image -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image">添加 fetchpriority="high" 可让浏览器优先加载该图像。
结果： 数值得分变化不大，但这是一项对实际加载速度非常有帮助的最佳实践。
4. 优化图像交付
| 原始格式 | 新格式 | 原因 |
|---|---|---|
| PNG / JPEG | WebP | WebP 在保持相似视觉质量的前提下，可将文件体积缩小约 75‑80 %。 |
- 除了已经只有 30 KB 的 LCP 图像外，所有图像均已转换为 WebP。
- 合计图像体积从 ≈8 000 KB → 200 KB。
5. 最终结果
| 指标 | 之前 | 之后 |
|---|---|---|
| 移动端性能得分 | 55 | 96 |
| 桌面端性能得分 | 68 | 100 |
| JavaScript 包体积 | 大 | 大幅缩小 |
| 字体请求 | 外部（Google Fonts） | 自行托管 |
| LCP 图像优先级 | 普通 | fetchpriority="high" |
| 总图像体积 | ~8 MB | ~200 KB |
注： 还处理了一些可访问性和 SEO 的细节，但此处省略，以便聚焦于性能。
6. 网络依赖树问题（已忽略）
Lighthouse 报告了一个 高危 的 “Network Dependency Tree” 问题：部分资源等待前置请求完成，阻碍了完全并行加载。
- 解决该问题需要对页面架构进行大幅重写。
- 关键路径延迟 仅约 300 ms，相比其他收益可忽略不计。
因此，我保持了原样。
7. 保持性能健康
- 每次重大改动后运行 Lighthouse（新增章节、库、图像等）。
- 将 Lighthouse 集成到 CI/CD，并设定最低性能阈值——构建失败时会立即提醒。
- 持续跟踪关键指标（FCP、LCP、CLS），并导出报告（HTML/JSON）以保存历史记录。
- 使用 PageSpeed Insights 获取真实用户数据（CrUX），待流量增长后使用。
- 可选的高级监控：
- 引入 web‑vitals 库收集真实用户指标。
- 将这些指标送入分析平台，实现持续可视化。
底线： 目标并非追求完美分数，而是了解并持续解决拖慢站点的因素。一旦能熟练阅读 Lighthouse 报告，判断该修哪些、该忽略哪些以及如何保持站点快速，就变得轻而易举。