React 页面慢，第一刀不该砍 useMemo

一个 React 页面刚交到你手里，AI 已经帮你补上了 useMemo、useCallback，甚至还贴心地包了两层 memo。

打开 Network 一看，接口还在排队。首屏还是慢。包还是大。

好家伙，经典的把桌面擦得锃亮，门口那辆堵住的卡车没人动。

这也是 Vercel 那份 React Best Practices 最值得看的地方。它没有从「怎么让组件少渲染一次」讲起，而是把异步瀑布和包体放在最高优先级。当前公开版本有 70 条规则，分成八组，skills.sh 页面显示它已有约 70.8 万次安装。很多人装它，大概也不是为了背完 70 个名词，而是因为 AI 写页面越来越快，性能债也跟着一起出厂了。

官方仓库的公开封面。具体安装量以 skills.sh 的实时页面为准。

这篇只聊一个场景。AI 帮你写完 React 或 Next.js 页面后，代码审查该先抓哪三件事。

先看用户在等谁

最常见的慢，不是 React 渲染不够聪明，是几个原本能一起出发的请求，排成了一列。

const user = await getUser()
const notices = await getNotices()
const projects = await getProjects()

如果 notices 和 projects 不依赖 user，这段代码每多一个请求，页面就多一次等待。模型很爱这么写，因为它读起来顺，类型也能过，代码审查时甚至显得挺整齐。可用户不会因为代码整齐就少等一秒。

const userPromise = getUser()
const noticesPromise = getNotices()
const projectsPromise = getProjects()

const [user, notices, projects] = await Promise.all([
  userPromise,
  noticesPromise,
  projectsPromise,
])

这不是让所有 await 都变成 Promise.all()。如果项目列表必须先拿到用户权限，硬并行反而会把逻辑搞坏。要审的是依赖关系，不是字符数量。Vercel 的规则把这类问题放在最前面，里面还有「先检查不用等待的条件」「真正走进分支再 await」「API 路由尽早启动请求」这些变体。官方规则 的共同指向很简单，别让不相干的工作在路上排队。

很多朋友会把这一步漏掉，因为瀑布没有报错，也没有红字。它只是安静地把一秒拆成三段，留给每一个打开页面的人。

再看有没有把一整车模块塞进首屏

第二个坑更隐蔽。AI 为了省事，特别容易从一个总入口导入东西，再把图表、编辑器、地图、埋点一起带进首屏。

import { Search, Settings, Sparkles } from "huge-icon-kit"
import AnalyticsPanel from "./AnalyticsPanel"

不一定每次都出事，但这种写法会让你失去判断的机会。这个入口到底会带来多少没用到的代码。那个只在点击「查看分析」后才出现的面板，为什么要跟着第一页一起下车。

import dynamic from "next/dynamic"
import Search from "huge-icon-kit/search"

const AnalyticsPanel = dynamic(() => import("./AnalyticsPanel"), {
  loading: () => <PanelSkeleton />,
})

不是哥们，动态导入也不是把所有组件都藏起来。登录框、首屏主任务、用户点进来就要操作的编辑器，拆晚了只会换一种等待。更稳的判断是，用户此刻是否真的需要它，代码路径能否被构建工具看懂。Vercel 的规则把「避免桶文件导入」「重组件按需加载」「第三方脚本延后」放进同一组，讲的就是这个顺序。它的技能页 还给了直接安装命令。

npx skills add https://github.com/vercel-labs/agent-skills --skill vercel-react-best-practices

装完别把完整文档一股脑塞给 Agent。70 条规则全铺开，模型也容易像刚领到一大叠 SOP 的新人，认真是认真，重点没了。遇到首屏慢就先调异步和包体两组，页面操作发涩再看重渲染和渲染性能。规则的价值在排序，不在体积。

先查等待和下载，再查渲染。图中是本文整理的审查顺序，不是项目实测数据。

useMemo 放到第三把刀

重渲染当然是真的问题。搜索框一输入，几百行列表跟着重算，页面会有那种拖泥带水的感觉。这里可以看 useDeferredValue、startTransition、拆分昂贵计算、把默认对象移出组件这些做法。

但别见到一个函数就套 useMemo。一个简单字符串、一段很轻的计算，记忆它的成本可能比重新算还热闹。更容易被 AI 写出来的冗余，是为了算一个派生值又开 state、再开 effect，最后把原本一行能得到的东西绕成三段流程。

厉害了，性能问题还没解决，状态机已经先长出来了。

把派生值留在 render 里，把昂贵工作和真正昂贵的组件拆开，才值得谈 memo。Vercel 把这些规则放在中等优先级，不是在说它们不重要，而是在提醒你别拿精修当抢救。接口排队和大包还在的时候，组件少渲染一次，往往救不了用户的体感。

给 Coding Agent 的审查指令，别再只说帮我优化一下

真正可拿走的不是 70 条规则，而是一段让 AI 知道先后顺序的任务描述。把下面这段放到改 React 页面或 Code Review 的任务里就够了。

请按 React 性能的影响顺序审查这次改动。

先标出互不依赖却串行等待的请求、首屏不必加载的大模块，
并给出最小改动方案和它会影响的用户路径。

再检查是否存在不必要的派生 state、昂贵重渲染或错误的 memo。
不要为了消灭所有 warning 增加缓存或拆包。

每一项建议写清证据、代价，以及如何在真实页面上验证。

这段指令有个小心思。它要求先给证据和用户路径，再给优化方案。这样模型就没法只把 useMemo 当创可贴乱贴，也不会把「性能优化」变成一场文件数量竞赛。

规则也不会替你测出真实数据。上线前还是要看自己的网络瀑布、包分析和交互过程。用户所在地区、接口缓存、图片大小、旧设备，都会让同一段代码表现出不同脾气。公开规则能帮你少走弯路，不能替你签性能保证书。

React 页面慢时，先别急着问组件有没有多渲染一次。先看它有没有在等不该等的人，有没有背着不该背的包。门口那辆卡车挪开之后，再回头擦桌子，才不算白忙。

你们团队最近一次让页面变慢的元凶，是接口排队、包体，还是重渲染？