AI 做的网站很卡怎么办？性能优化实战指南（2026）

用 Claude Code、Cursor 或者 Lovable 把网站做出来、部署上线，兴冲冲把链接发给朋友——对方回一句「怎么这么卡」。这是 AI 编程时代非常典型的一幕：功能全对，体验稀烂。AI 生成的网站上线时普遍存在性能问题，海外有实测统计称大量 AI 建站项目初始 Lighthouse 分数不到 70 分。好消息是：性能优化恰恰是最适合让 AI 帮你干的活——问题能用工具量化测出来，修法有固定套路，改完立刻能重测验证。这篇 AI 网站性能优化指南带你走完「测出问题 → 看懂指标 → 喂给 AI 修 → 防止复发」的完整闭环，全程不需要你精通前端。

为什么 AI 做的网站容易卡

AI 写代码时的默认目标是「功能能跑」，不是「跑得快」。你不主动提性能要求，它就会挑最省事的写法，于是同样的坑反复出现：

• 图片原图直出：AI 生成或你随手放进去的配图动辄 2-4 MB，没压缩、没转 WebP、没懒加载，首屏最大元素（LCP）直接被拖垮。
• JS 整包引入：为了一个按钮引入整个组件库，为了一个图表拉进整个 ECharts，页面塞了几百 KB 根本用不到的 JavaScript。
• 没有任何缓存：每个访客的每次点击都打到数据库，静态内容也每次现算，小流量没事、一分享就崩。
• 接口 N+1 查询：列表页先查 20 条记录、再循环查 20 次关联数据，本地测试飞快，数据一多就卡成幻灯片。
• 第三方脚本阻塞渲染：统计、客服挂件、字体全在头部同步加载，页面白屏等它们下载完才开始渲染。

第一步：用免费工具测出问题在哪

不要凭感觉优化。先用两个免费官方工具拿到量化报告，后面所有动作都围绕报告展开：

1. 1PageSpeed Insights（pagespeed.web.dev）：输入你的网址直接测，同时给出「实验室数据」（模拟环境跑分）和「真实用户数据」（Chrome 用户 28 天实测，站点流量够大才有）。移动端和桌面端分开看，优先看移动端——它几乎总是更差的那个。
2. 2Chrome DevTools 里的 Lighthouse：打开你的网站，按 F12 → 切到 Lighthouse 面板 → 选「性能」→ 点「分析网页加载情况」。适合本地开发时反复跑，改一版测一版。
3. 3看报告时重点看两块：顶部的性能分数（0-100）判断整体水平，下面的「建议」列表就是逐条待办——每一条都写着预计能省多少加载时间。

看懂三大核心指标 Core Web Vitals

报告里最重要的是 Google 定义的三个核心网页指标（Core Web Vitals），2026 年现行的「良好」标准如下（注意 INP 已在 2024 年取代了旧指标 FID）：

三个指标对应三种用户抱怨：LCP 差 = 「半天打不开」，INP 差 = 「点了没反应」，CLS 差 = 「刚要点按钮它跳走了」。拿着这个对照表看报告，你就知道该先修哪一类。

最常见的五类问题与修法

按投入产出比排序，AI 做的网站九成的卡顿出在这五类。每一类都可以直接丢给 AI 修，括号里是对应的技术手段，你不需要亲自实现，但知道名字才能验收：

1. 1图片太大 → 转 WebP/AVIF 格式（比 JPEG 小 25-35%）、按显示尺寸缩放、首屏外的图加懒加载。用 Next.js 的话直接换 next/image 组件，一步到位。
2. 2JS 太多 → 跑一次打包分析（如 @next/bundle-analyzer）找出超过 100 KB 的依赖，按需引入替代整包引入，弹窗/图表等非首屏组件改成动态导入（dynamic import）。
3. 3没缓存没 CDN → 静态资源（图片/JS/CSS）挂 CDN；不常变的页面加缓存头或用静态生成；接口层对热点查询加内存缓存。国内站可用又拍云、七牛、腾讯云 CDN 等。
4. 4接口慢 → 让 AI 检查 N+1 查询（循环里发查询是标志）、给高频查询字段加数据库索引、列表接口加分页。
5. 5第三方脚本阻塞 → 统计、客服等非关键脚本全部加 defer 或 async，只在用到的页面加载，字体用 font-display: swap 避免白屏等字体。

把 Lighthouse 报告直接喂给 AI 修

这是整个流程里最省力的一步：Lighthouse 的「建议」列表本身就是一份写好的需求文档，直接交给 AI 执行即可。在 PageSpeed Insights 页面把报告截图，或在 DevTools 的 Lighthouse 面板用右上角菜单导出 JSON，然后在 Claude Code / Cursor 里这样说：

这是我网站首页的 Lighthouse 报告（见截图/附件 report.json）。
请按预计收益从大到小逐项处理：
1. 每修一项，先告诉我你打算改哪些文件、为什么这样改；
2. 图片优化优先用框架自带方案（如 next/image），不要引入新依赖；
3. 不要改动任何业务逻辑和页面文案，只做性能相关改动；
4. 全部改完后告诉我如何本地重新跑 Lighthouse 验证。
先给我整体计划，确认后再动手。

关键点有三个：一是「先给计划再动手」，避免 AI 一口气改乱十几个文件；二是明确「不改业务逻辑」，性能优化最怕顺手把功能改坏；三是修完立刻重测，用分数变化验收。一般跑两三轮，移动端分数从 50 拉到 85 以上是很常见的。

修完怎么防止再变卡

性能是会退化的：下次让 AI 加个新功能，它可能又引入一个 300 KB 的库。两个低成本的防退化手段：

• 把性能要求写进项目约定：在 CLAUDE.md 或 AGENTS.md 里加一条「新增依赖前先说明体积，首屏图片必须走 next/image，禁止在头部同步加载第三方脚本」，AI 每次干活都会遵守。
• 上线流程里加自动跑分：用 Lighthouse CI（@lhci/cli）在 GitHub Actions 里给每次部署自动跑 Lighthouse，分数低于阈值就挡住合并——具体 CI 配置可以参考我们的《Claude Code GitHub Actions 教程》。
• 定期看真实用户数据：流量起来之后，每月看一次 PageSpeed Insights 的真实用户部分，或在 Google Search Console 的「核心网页指标」报告里盯趋势。

把网站从「能跑」调到「跑得快」，是 AI 编程从玩具走向产品的分水岭——也是最能体现「会用 AI 的人」和「只会让 AI 生成代码的人」差距的环节。想系统掌握从开发、部署到测试、监控、性能调优的完整交付能力，欢迎来 IMAI 的体系化实战课程，我们把每个环节都拆成了可上手的实操。