如何让你的网站更快：实用检查清单

要让网站更快，先用 PageSpeed Insights 测量，然后修复它指出的最大原因——通常是过大的图片、过多的 JavaScript、笨重的字体或第三方脚本。目标是达到 Google Core Web Vitals 的“良好”标准：主要内容在 2.5 秒内可见，对点击的响应在 200 毫秒内完成，几乎没有布局跳动。大多数网站只需要做几项改动就能达标，无需重写。

修改之前先测量

凭猜测行事只会浪费时间。两个免费工具几乎能满足所有人的需求：

• PageSpeed Insights（pagespeed.web.dev）——粘贴一个在线网址。它会显示来自真实 Chrome 用户的字段数据（如果你的网站有足够的流量），以及来自模拟加载的实验室数据，并列出具体问题。
• Chrome 开发者工具中的 Lighthouse——同样的实验室测试，可以在任何你能打开的页面上运行，包括预览。请使用移动模式测试；问题通常会在网络较慢的手机上暴露出来。

真正重要的数字是 Google 的 Core Web Vitals。截至 2026 年 9 月，Google 在 web.dev 上的文档给出了以下“良好”阈值，以页面加载的第 75 百分位数衡量：

INP 已在 2024 年取代了较早的 First Input Delay 指标。如果某个工具仍在报告 FID，说明它已经过时。

记下你的初始数据。每次修复之后，都重新测试，这样你就知道哪些改动真正有效。

时间都花在哪里：选项与权衡

每个常见原因都有对应的修复方法，而每种修复都有其代价。从最上面的几项开始——它们最便宜，也最常见。

图片

图片是最常见的问题，也是最容易修复的。一张 4,000 像素宽的照片如果只显示 800 像素宽，那么每位访客下载的数据都是实际所见的五倍。

• 按显示尺寸提供图片，并为手机和桌面端配置响应式 srcset 尺寸。
• 使用现代格式（WebP 或 AVIF）并采用合理的压缩率。
• 为每张图片设置 width 和 height，让浏览器预留空间。仅此一项就能解决大部分布局偏移。
• 对首屏以下的图片使用 loading="lazy" 懒加载。
• 绝不要对页面顶部的主图片使用懒加载。 Google 的 LCP 指南对此说得很直接：对 LCP 图片懒加载，一定会延迟它的加载。应改为设置 fetchpriority="high"。

JavaScript

许多 AI 构建的网站都是单页应用（SPA）：浏览器先下载一个 JavaScript 包，然后再绘制页面。包越大，空白屏幕停留的时间就越长。修复方法按投入从低到高排列：

1. 移除不用的内容。 请求列出依赖项清单，删掉那些一度添加过却早已忘记的库——为了一个日期而引入的日期库，为了五个图标而引入的整套图标包。
2. 按路由拆分。 只有有人打开管理后台时，才加载其代码，而不是在首页就加载。
3. 预渲染公开页面。 以真实 HTML 形式交付的营销页面，会在任何 JavaScript 运行之前就出现。这也有助于搜索引擎；参见 AI 构建网站的 SEO。

INP 变慢通常意味着有一个长任务阻塞了页面——例如每次按键都对一个庞大的列表进行过滤，或者某个单元格变化时重新渲染整张表格。Chrome 开发者工具的性能面板可以显示具体是哪一项。

字体

每个字体家族和字重都是另一个文件。两个字体家族、三到四个字重通常就足够了。预加载首屏使用的字体，使用 font-display: swap 让文字立即显示；如果外部字体服务对你的访客来说速度较慢，可以自行托管字体。

第三方脚本

聊天小部件、分析工具、热力图、广告像素、嵌入视频和社交信息流，都会从其他服务器加载代码。每一个看起来都很小，但加在一起，往往是页面中最慢的部分。保留你真正会去查看的那些。其余的在页面可交互之后再加载；对于较重的嵌入内容（如 YouTube 播放器、地图），可以替换为轻量的预览图，点击后再加载真正的内容。

服务器响应

首字节时间（TTFB）——服务器开始响应需要多长时间——处于其他所有指标的底层。通过 CDN（一个在访客附近的服务器网络；参见什么是 CDN）提供的静态页面，几乎在任何地方都很快。而每次请求都由服务器生成的页面，则依赖于该服务器及其数据库。对重复工作进行缓存，并为慢查询添加数据库索引，是常见的修复方法。

有效的提示词

务必具体：说明页面、指标和约束条件。如果你有 PageSpeed Insights 的检测结果，请一并粘贴。

PageSpeed Insights 显示首页在移动端的 LCP 为 4.8 秒，而 LCP 元素是主视觉图片。请将主视觉图片调整尺寸并转换为 WebP，提供响应式尺寸，设置 width 和 height，给它加上 fetchpriority="high"，并确保它没有使用懒加载。对首屏以下的所有图片进行懒加载。不要改变设计。

请审核此应用的依赖项。列出每个包、哪里在使用它，以及它大致会给打包体积增加多少。移除未使用的包，并把 /admin 和 /settings 路由拆分成只在访问时才加载的独立代码块。

/products 页面上的搜索框输入时有卡顿感。请对筛选做防抖处理，避免每次按键都重新渲染整个列表；如果列表超过 200 项，请进行分页或虚拟化。

分步操作

1. 测试线上页面：在 PageSpeed Insights 中以移动端模式测试。记录 LCP、INP 和 CLS，以及列出的前三个问题。
2. 先修复图片：尺寸、格式、宽高属性、首屏以下懒加载，以及主视觉图片的优先级。
3. 删除你不用的第三方脚本，其余的延后加载。
4. 精简字体，只保留设计所需的部分。
5. 缩减 JavaScript：移除未使用的包，按路由拆分。
6. 预渲染公开页面，前提是它们仍是客户端渲染且 LCP 依然很慢。
7. 检查服务器：缓存、数据库索引，以及对很少变化的内容使用静态托管。
8. 重新发布并重新测试。 PageSpeed Insights 中的字段数据会在随后几周内随着真实访问的积累而更新，因此在早期请以实验室数据来判断结果。

常见错误

• 只在快速的笔记本电脑上测试。 你的访客使用的是中端手机和不稳定的移动数据。请用移动模式测试。
• 一味追求满分 100。 实验室分数只是参考。一旦 Core Web Vitals 进入良好区间，内容和可用性就比最后那几分更重要。
• 所有内容都懒加载，包括主视觉图片。这会让 LCP 变得更糟。
• 再加一个速度插件或库来优化。 减少体积几乎总是比额外添加代码来管理更有效。
• 优化的是预览，而不是线上网站。 开发预览使用的是未经优化的构建。请测量已发布的网址。
• 只修复一次速度。 每一个新的小部件、图片和功能都会增加体积。大的改动之后要重新测试。

速度检查清单

• 移动端的 LCP ≤ 2.5 秒，INP ≤ 200 毫秒，CLS ≤ 0.1
• 图片已缩放、压缩、采用现代格式，并设置了 width 和 height
• 主视觉图片未懒加载；首屏以下的图片已懒加载
• 没有未使用的 JavaScript 库；体积大的路由已拆分出去
• 两个或更少的字体家族，主字体已预加载
• 只保留你真正使用的第三方脚本，并延后加载
• 公开页面已尽可能预渲染或静态化
• 发布后已在线上网址上重新测试

速度与移动端布局密切相关；参见如何让网站适配移动端。如需完整的上线前检查，如何把 AI 原型推向生产涵盖了其余内容。

Mythex 上的速度优化

在 Mythex 上，你可以在聊天中提出要求，或者在 Pro 套餐的代码编辑器中进行这些改动。请检查已发布的线上网址，而不是预览，因为预览运行的是开发服务器。发布时，静态前端会被部署为静态网站（静态网站），这很适合内容页面。带有服务器的应用会缩容至零：空闲时休眠，下次访问时唤醒，因此长时间无人访问后的第一次请求会更慢，而且挂载的数据库在 5 分钟空闲后会进入休眠（托管限制）。如果某个公开页面只有首次访问很慢，那很可能就是这个原因。将营销页面保持为静态有助于改善这一点。修改之后，请重新发布并强制刷新。

常见问题