Claude 页面加载从 3 秒降到半秒，这套优化提示词收好

页面打开了，输入框却还不能打字。

这一小段等待，很难靠「模型又升级了」安慰过去。你要发的消息已经想好了，网页还在忙自己的事。

9 月 23 日，Claude 团队公开了一次性能优化复盘。他们在 8 月用了两周，改善 claude.ai 和桌面应用的核心体验。其中，网页首次加载到可以输入的耗时，P75 从 3085 毫秒降到 550 毫秒，约等于从 3 秒降到半秒。官方工程复盘

P75 可以理解成，把一批耗时从短到长排列，取排在四分之三位置的那个数。它比只展示一次最快结果更有参考价值，但也没有覆盖所有慢用户。

好家伙，输入框终于比你那句「怎么还没好」来得快了。

这里测的是页面变得可操作需要多久，不能拿来宣称 Claude 回答问题快了这么多。官方说整体约快了 3 倍，也是在汇总多项用户体验指标，各项改善幅度不同。

我更想聊的是，遇到自己项目里的慢页面，怎么把问题交给 Claude。

「帮我优化性能」这句话太宽了。它可以给你列出缓存、懒加载、拆包、减少渲染，每一项都对，看完却还是不知道该改哪儿。

下面这套提示词，是我根据这个问题整理的中文工作模板，并非官方原文，也没在你的项目里验证过。里面的页面、操作、设备和验收要求，都要换成你自己的。

先把那个「慢」描述出来

假设你的项目有一个客户列表，点开详情时，会卡一下。

光把整个仓库递给 Claude，它看到的是许多可能需要优化的代码。把那一下卡顿的触发过程递给它，它才有一个具体问题可以追。

请调查客户列表点击详情后卡顿的问题。先不要修改代码。沿着这一次操作，找到事件触发、数据请求、状态更新和界面显示的位置。说明怎样复现、怎样测量开始与结束，以及当前有哪些证据。没有测量依据的原因只能列为假设，不要写成已定位。

我会特别保留「先不要修改代码」。调查阶段最怕还没确定病灶，代码已经改了一圈。

有些项目连「结束」都说不清楚。请求返回算结束，还是骨架屏消失算结束？文字出来了，但按钮还点不了，又算不算？

如果你关心的是用户能否开始下一步，就把终点设在那里。接口快了，用户仍然在等，这两件事完全可以同时发生。

录一段屏、说明点击顺序、给出一份脱敏后的性能记录，都比「偶尔很慢，你看看」更能缩小范围。给录屏时，顺手标出你觉得难受的位置，免得模型忙着优化你根本不在意的那一段。

还有一个小细节，测试账号里的数据量要像真实使用。空列表里的详情页秒开，并不能解释几千条记录时为什么卡住。

让它交一份能复查的基线

原因先别急着下结论。让 Claude 把测量条件和结果记下来。

为刚才的操作建立修改前基线。记录浏览器或运行环境、数据规模、冷启动与热启动条件，以及每次测量结果。说明采样次数和限制。若结果波动很大，先排查波动来源。保存可重复执行的测量步骤，让修改后能用相同条件重跑。

这段提示词的价值，是替下一轮比较留一把尺子。

同一份数据、同一种操作、同样的缓存条件。否则这一轮第一次打开，下一轮缓存全热了，再漂亮的数字也不好解释。

我不建议在通用模板里直接规定「跑三次就够」或者「快一成算成功」。轻量脚本和复杂网页的波动不同，网络条件也不同，让它先报告样本和限制，你才知道这组结果值不值得信。

如果你是产品经理，不需要先学会所有性能工具。你可以要求开发同事或 Claude 把测量过程说明白，做到另一个人照着步骤，也知道在测哪一下。

这已经能挡住不少「我这边感觉快了」。

再让它动手，一次处理一个瓶颈

官方这次使用了一个挺直观的方法，让静态输入框先出现，用户可以在 React 初始化时输入，随后再交给真实组件接管。他们还给接管过程补了对齐和按键测试。官方实现与验证说明

这例子让我在意的地方，是交接。

你让用户提前打字，就得保证接管时字不会丢。一个提前出现却不能可靠输入的框，能把等待变成另一种烦躁。

当然，你的项目不一定需要静态输入框。更常见的可能是重复请求、一个牵动整个列表的状态更新，或者同步执行太多工作。没有测量结果之前，这些都只是排查方向。

拿到证据后，再给修改任务。

根据已经记录的测量结果，选择证据最充分的一个瓶颈，提出最小修改并实施。保留原有功能和数据含义。先写能够复现问题或约束关键行为的检查，再修改。完成后用相同条件重跑基线，同时报告收益、未改善部分、新增复杂度和回退方法。若收益无法稳定复现，明确说明，不扩大修改范围掩盖结果。

这段稍长，但我觉得值得保存。

性能优化很容易一路顺手改下去。这个组件看着也不合理，那个状态管理也想换，半天之后，卡顿问题还在，重构已经拥有了自己的路线图。

不是哥们，我们最初只是想让点开详情那一下顺一点。

把改动收小，有两个现实好处。出了问题容易退回去，有了收益也知道是哪一刀起作用。

完成报告里，我尤其想看「新增复杂度」。为了省一点时间，加上一套只有作者看得懂的缓存失效规则，维护成本可能比这点收益更扎眼。让模型把这个代价写出来，才方便人决定值不值得留。

数字变好之后，再看一遍真实操作

一组性能结果不能替你判断所有体验。

想象一个列表为了更快显示，先把第一行放出来，后面的内容一边加载一边推着页面往下跳。数字可能漂亮，手指却找不到刚准备点的按钮了。

又或者输入框出现得很早，但中文输入法还没处理好。页面跑得快，你得重新打字，省下来的时间转头又交回去了。

所以最后一轮，我会这样交代。

复核这次修改的用户体验。按原来的操作路径检查输入、点击、滚动、加载状态和错误提示；涉及输入时检查中文输入法与连续按键。给出修改前后的截图或录屏，以及功能检查结果。区分本地测量和真实用户数据，不把其中一个当成另一个。上线前按项目已有评审和发布流程处理。

这段可以跟前面的测量记录一起转给同事。接手的人能看到任务从哪儿开始，改了什么，以及哪些问题还没被验证。

顺便说一句，不是每次都需要全套检查。只动了一个纯计算函数，输入法测试就无关；改的是输入框接管，这项反而应该留下。模板的作用是提醒你补齐关键问题，不是让所有任务都跑成一场大型仪式。

我也不会从这篇官方复盘推出「换个提示词，你的页面就能快 3 倍」。团队的基础设施、权限、评审配合和项目状况，都影响结果。

普通项目今天就能试的，是挑一个最烦人的等待，把触发过程、测量终点和修改前结果写清楚，然后交给 Claude 处理一轮。

跑完之后，即使没变快，能明确排除一个猜测，也比收到十条通用优化建议更有用。

你最近最想让 Claude 帮忙处理的，是页面打开慢、输入卡顿，还是切换页面时那一下停顿？