frontend-performance

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Frontend Performance

前端性能

Optimize frontend applications for maximum Lighthouse scores and real-user performance. This skill covers the technical performance layer -- for how it looks, see

sheleg-design

; for what the interface must do, see

super-ux

优化前端应用，以获得尽可能高的 Lighthouse 分数和真实用户性能。本 skill 关注技术性能层——页面外观参见

sheleg-design

；界面必须完成的功能参见

super-ux

。

Audit Workflow

审计工作流

Measure -- Run PageSpeed Insights or Lighthouse (Chromium) and load the same scenario in WebKit first (see Test browser below). Record scores, failing audits and the engine of each number.
Diagnose -- Map each failing audit to a specific code-level cause (see checklist below).
Prioritize -- Fix by impact: P0 blocks rendering, P1 hurts metrics, P2 is informational.
Implement -- Apply fixes per the reference guides.
Validate --
```
next build
```
(or framework equivalent) + re-run Lighthouse and the WebKit run. Verify no regressions in either engine.

测量——运行 PageSpeed Insights 或 Lighthouse（Chromium），并首先在 WebKit 中加载相同场景（参见下文“测试浏览器”）。记录分数、未通过的审计项以及每个数值对应的测量引擎。
诊断——将每个未通过的审计项映射到具体的代码层原因（参见下方检查清单）。
排定优先级——按影响程度修复：P0 阻塞渲染，P1 损害指标，P2 仅供参考。
实施——按照参考指南应用修复。
验证——执行
```
next build
```
（或框架中的等效命令），然后重新运行 Lighthouse 和 WebKit 测试。验证两个引擎中均未出现回归。

Test browser — WebKit (Safari) first

测试浏览器——优先使用 WebKit（Safari）

Load and profile the page in WebKit first: Safari through

safaridriver

(WebDriver;

sudo safaridriver --enable

once) for a real browser, Playwright's

webkit

(the

webkit

project,

--browser webkit

, installed with

npx playwright install webkit

) for scripted runs and traces, Safari Web Inspector's Timelines for debugging. On macOS open a page with

open -a Safari <url>

, not the system default browser, which may be another engine. An automation library (browser-use and the like) runs on its WebKit/Safari backend where it has one. WebKit has the narrowest support envelope of the big three — a regression that only iOS Safari users feel is invisible to every Chrome tool below.

Lighthouse, PageSpeed Insights, CrUX, a CDP trace and the chrome-devtools MCP are Chromium by definition — they stay in this workflow as the stated Chromium exception: use them when the task needs Chrome itself, and say which and why. Prefer the Chrome Dev build for a Chrome run you start; give it a temporary profile (never the user's), record what you started, and close every process you started before you finish. A page checked only in Chromium is reported as "checked only in Chromium", never as "tested in a browser"; a Lighthouse score is a Chrome lab number, not a cross-browser verdict.

首先在 WebKit 中加载并分析页面：使用 Safari 配合

safaridriver

（WebDriver；只需执行一次

sudo safaridriver --enable

）进行真实浏览器测试，使用 Playwright 的

webkit

（

webkit

项目，

--browser webkit

，通过

npx playwright install webkit

安装）执行脚本化测试和 trace，使用 Safari Web Inspector 的 Timelines 进行调试。在 macOS 上，使用

open -a Safari <url>

打开页面，不要使用系统默认浏览器，因为默认浏览器可能采用其他引擎。browser-use 等自动化库在具备相应后端时，会在其 WebKit/Safari 后端上运行。WebKit 是三大浏览器中支持范围最窄的——仅影响 iOS Safari 用户的回归问题，对下文所有 Chrome 工具来说都是不可见的。

Lighthouse、PageSpeed Insights、CrUX、CDP trace 和 chrome-devtools MCP 本质上均基于 Chromium——它们作为明确声明的 Chromium 例外保留在此工作流中：当任务需要测试 Chrome 本身时使用它们，并说明所用工具及原因。对于自行启动的 Chrome 测试，优先使用 Chrome Dev 构建版；为其提供临时 profile（绝不使用用户的 profile），记录启动的内容，并在结束前关闭所有已启动的进程。仅在 Chromium 中检查过的页面必须报告为“仅在 Chromium 中检查过”，绝不能称为“已在浏览器中测试”；Lighthouse 分数是 Chrome 的实验室数据，而不是跨浏览器结论。

Core Web Vitals, and the diagnostics beside them

Core Web Vitals 及其配套诊断

Two INDEPENDENT axes, and conflating them is the common error. Axis one: is it a Core Web Vital — what Google reports and ranks on (LCP, INP, CLS) — or not. Axis two: where can you measure it — in the FIELD (real users, CrUX) or only in the LAB (a synthetic run). These do not line up: a metric can be not-CWV and still field-measurable. FCP is the case that breaks the one-axis story — it is NOT a Core Web Vital, yet it IS field-measurable (CrUX reports FCP; web.dev lists both lab and field tools for it). The earlier claim that "only the three CWV are field-measurable" was wrong.

Metric	Core Web Vital?	Field-measurable?	Good	Needs Work	Poor
LCP	yes	yes (CrUX)	< 2.5s	2.5-4.0s	> 4.0s
INP	yes	yes (CrUX)	< 200ms	200-500ms	> 500ms
CLS	yes	yes (CrUX)	< 0.1	0.1-0.25	> 0.25
FCP	no	yes (CrUX)	< 1.8s	1.8-3.0s	> 3.0s
TBT	no	no (lab only)	< 200ms	200-600ms	> 600ms
SI	no	no (lab only)	< 3.4s	3.4-5.8s	> 5.8s

A field claim carries its provenance, always: p75 (the 75th-percentile value Google classifies on, never a mean), the device/cohort (phone vs desktop, and which population), the period (CrUX is a 28-day trailing window), and the sample size (a thin origin has no field data — that is

unknown

, not

good

). A number without these four is a lab number wearing a field label.

TBT is a diagnostic CORRELATE of INP, never a substitute for its evidence. A good lab TBT is a hint that INP may be fine; it does NOT PROVE INP, because INP is measured on real interactions the lab did not perform. So a page with CrUX FCP data and a Lighthouse TBT but no field INP reports FCP = field-supported, INP = unknown — never "INP passed by TBT". Telling a client their Speed Index is a failing Core Web Vital is telling them about a thing Google does not rank; telling them INP passed because TBT did is telling them about a measurement nobody took.

Thresholds and the classification verified against

web.dev/articles/vitals

, 2026-08-16.

存在两个相互独立的维度，将二者混为一谈是常见错误。 维度一：它是否属于 Core Web Vital——即 Google 纳入报告和排名的指标（LCP、INP、CLS）。维度二：可以在哪里测量——是在 FIELD（真实用户，CrUX） 中，还是仅在 LAB（合成运行） 中。二者并不对应：一个指标即使不是 CWV，也可能通过实地数据进行测量。FCP 正是打破“单轴叙事”的特殊情况——它不是 Core Web Vital，却可以通过实地数据测量（CrUX 会报告 FCP；web.dev 同时列出了其实验室和实地测量工具）。此前“只有三个 CWV 可以通过实地数据测量”的说法是错误的。

指标	Core Web Vital？	实地可测？	良好	需要改进	较差
LCP	是	是（CrUX）	< 2.5s	2.5-4.0s	> 4.0s
INP	是	是（CrUX）	< 200ms	200-500ms	> 500ms
CLS	是	是（CrUX）	< 0.1	0.1-0.25	> 0.25
FCP	否	是（CrUX）	< 1.8s	1.8-3.0s	> 3.0s
TBT	否	否（仅实验室）	< 200ms	200-600ms	> 600ms
SI	否	否（仅实验室）	< 3.4s	3.4-5.8s	> 5.8s

实地数据结论始终必须附带来源信息：p75（Google 用于分类的第 75 百分位值，绝不是均值）、设备/群体（手机还是桌面，以及具体人群）、周期（CrUX 为过去 28 天的滚动窗口）和样本量（数据量少的来源站点没有实地数据——这是 unknown，而不是 good）。缺少这四项信息的数值，只是一个披着实地数据标签的实验室数值。

**TBT 是 INP 的诊断相关指标，绝不能替代 INP 的实际证据。**良好的实验室 TBT 仅提示 INP 可能没有问题；它不能证明 INP，因为 INP 是根据实验室未执行的真实交互测量的。因此，对于一个拥有 CrUX FCP 数据和 Lighthouse TBT、但没有实地 INP 数据的页面，应报告 FCP = 有实地数据支持，INP = unknown，绝不能写成“INP 因 TBT 合格而通过”。告诉客户 Speed Index 是未通过的 Core Web Vital，等于谈论一个 Google 不参与排名的指标；告诉客户 INP 因 TBT 合格而通过，则是在引用一个根本没有人测量过的数据。

阈值和分类依据

web.dev/articles/vitals

核验，核验日期为 2026-08-16。

Performance Checklist

性能检查清单

Fonts (LCP, FCP)

字体（LCP、FCP）

Self-host fonts -- Never load from external CDNs via
```
<link>
```
tags. Use framework font optimization (
```
next/font/google
```
,
```
@fontsource
```
, etc.) to inline CSS and self-host files.
Preload critical fonts -- The font used by the LCP element must load early.
Limit font families -- Max 3 families. Each family adds ~20-50KB.
Subset fonts -- Only load needed character sets (
```
latin
```
,
```
latin-ext
```
).
Use
font-display: swap
-- Prevents invisible text during load (FOIT).
Remove unused preconnects -- If fonts are self-hosted,
```
preconnect
```
to font CDNs is dead weight.

Before any of these changes: MEASURE, don't prescribe. The items below are optimization HEURISTICS, not blanket rules — each is conditional on evidence, and applied blind it can lose function for a score. Before changing anything, check three things: the performance trace + the scenarios (what a low-end device on a slow network actually waits for), the browser-support contract (who must the page still work for), and the accessibility owner (structure is theirs, not the score's). A change ships only with acceptance covering: low-end/slow-network scenarios, keyboard + heading structure intact, the supported-browser matrix still served, NO new unapproved CSP origin, and several comparable before/after measurements showing the win with no functional loss.

自托管字体——绝不要通过
```
<link>
```
标签从外部 CDN 加载字体。使用框架字体优化功能（
```
next/font/google
```
、
```
@fontsource
```
等）来内联 CSS 并自托管字体文件。
预加载关键字体——LCP 元素使用的字体必须尽早加载。
限制字体系列——最多使用 3 个字体系列。每个系列约增加 20-50KB。
使用字体子集——仅加载所需的字符集（
```
latin
```
、
```
latin-ext
```
）。
使用
font-display: swap
——防止加载期间出现不可见文本（FOIT）。
移除未使用的 preconnect——如果字体已自托管，对字体 CDN 使用
```
preconnect
```
就只是无效负担。

在进行上述任何更改前：先测量，不要直接开处方。以下项目是优化启发式规则，而非一刀切的规则——每一项都以证据为条件；盲目应用可能为了分数而损失功能。更改前需要检查三件事：性能 trace 与场景（低端设备在慢速网络上实际等待什么）、浏览器支持约定（页面仍须在哪些浏览器上工作）以及无障碍负责人（页面结构由其负责，而不是由分数负责）。只有验收范围覆盖以下内容的更改才能发布：低端设备/慢速网络场景、键盘操作与标题结构保持完整、继续支持受支持的浏览器矩阵、不新增未经批准的 CSP origin，以及提供多项可比较的前后测量数据，证明优化收益且没有功能损失。

JavaScript (TBT, FCP, LCP)

JavaScript（TBT、FCP、LCP）

Code split by the MEASURED waterfall -- lazy-load what the trace shows the first paint does not need; "only hero + nav in the initial bundle" is a starting hypothesis, not a rule — a section the scenario needs above the fold stays, whatever the score says.
Defer third-party scripts -- GA, analytics, chat widgets load after interactive (
```
afterInteractive
```
or
```
defer
```
).
Target the browsers your USERS run --
```
browserslist
```
follows a stated user-support policy (your analytics, your contract), not a default "last 2". The
```
last 2
```
line below is an EXAMPLE; shipping it without checking who it drops is how a working browser stops being served for a polyfill saving:
```
# example only — replace with your measured support matrix
last 2 Chrome versions, last 2 Firefox versions, last 2 Safari versions, last 2 Edge versions
```
Tree-shake imports -- prefer named imports where the bundle analyzer shows
```
import * as
```
pulling dead weight; it is a tree-shaking aid, not a ban — a namespace import that costs nothing measured is not a defect.

Analyze bundles -- Use

@next/bundle-analyzer

source-map-explorer

, or

vite-plugin-visualizer

按照实测瀑布图进行代码拆分——对 trace 显示首次绘制不需要的内容执行懒加载；“初始 bundle 仅包含 hero 和 nav”只是一个起始假设，并不是规则——如果场景需要首屏之下的某个 section 参与展示，无论分数如何都应保留。
延迟第三方脚本——GA、分析工具和聊天组件应在交互后加载（
```
afterInteractive
```
或
```
defer
```
）。
以用户实际使用的浏览器为目标——
```
browserslist
```
应遵循明确的用户支持策略（依据你的分析数据或合同约定），而不是默认使用“last 2”。下面的
```
last 2
```
配置仅是示例；未检查会排除哪些用户就直接发布，会让原本可用的浏览器因为节省一个 polyfill 而停止获得服务：
```
# example only — replace with your measured support matrix
last 2 Chrome versions, last 2 Firefox versions, last 2 Safari versions, last 2 Edge versions
```
对导入进行 tree-shaking——当 bundle analyzer 显示
```
import * as
```
引入无效负担时，优先使用具名导入；这只是 tree-shaking 的辅助手段，而不是绝对禁令——如果实测命名空间导入没有产生额外成本，就不算缺陷。

分析 bundle——使用

@next/bundle-analyzer

、

source-map-explorer

或

vite-plugin-visualizer

。

CSS & Animations (CLS)

CSS 与动画（CLS）

Composite-only animations -- Only animate
```
transform
```
and
```
opacity
```
(GPU-composited). Never animate
```
background-position
```
,
```
width
```
,
```
height
```
,
```
top/left
```
,
```
margin
```
,
```
padding
```
.
Use
will-change
sparingly -- Add
```
will-change: transform
```
or
```
will-change: filter
```
only on elements that actually animate.
Inline critical CSS -- Framework should handle this (Next.js does automatically).
Avoid layout shifts -- Set explicit
```
width
```
/
```
height
```
on images and embeds. Reserve space for dynamic content.

仅使用合成层动画——只对
```
transform
```
和
```
opacity
```
设置动画（由 GPU 合成）。绝不要对
```
background-position
```
、
```
width
```
、
```
height
```
、
```
top/left
```
、
```
margin
```
、
```
padding
```
设置动画。
谨慎使用
will-change
——仅在实际发生动画的元素上添加
```
will-change: transform
```
或
```
will-change: filter
```
。
内联关键 CSS——这通常应由框架处理（Next.js 会自动完成）。
避免布局偏移——为图片和嵌入内容设置明确的
```
width
```
/
```
height
```
。为动态内容预留空间。

Images (LCP, CLS)

图片（LCP、CLS）

Use
<Image>
component -- Framework-optimized components (
```
next/image
```
, Astro
```
<Image>
```
) auto-resize, convert to WebP/AVIF, and add
```
width
```
/
```
height
```
.
Priority-load LCP image -- Add
```
priority
```
(Next.js) or
```
fetchpriority="high"
```
to the hero/LCP image.
Lazy-load below-fold -- All images below the initial viewport get
```
loading="lazy"
```
.
Size budget: Hero < 200KB, thumbnails < 50KB, icons as SVG.
Responsive
sizes
-- Always provide
```
sizes
```
attribute for responsive images.

使用
<Image>
组件——框架优化组件（
```
next/image
```
、Astro
```
<Image>
```
）会自动调整尺寸、转换为 WebP/AVIF，并添加
```
width
```
/
```
height
```
。
优先加载 LCP 图片——为 hero/LCP 图片添加
```
priority
```
（Next.js）或
```
fetchpriority="high"
```
。
懒加载首屏以下内容——初始视口以下的所有图片都应设置
```
loading="lazy"
```
。
大小预算：Hero < 200KB，缩略图 < 50KB，图标使用 SVG。
响应式
sizes
——响应式图片始终应提供
```
sizes
```
属性。

Caching (Repeat Visits)

缓存（重复访问）

Static assets:
```
Cache-Control: public, max-age=31536000, immutable
```
for hashed files (JS, CSS, fonts, images).

HTML:

Cache-Control: public, max-age=0, must-revalidate

(or framework default).

Verify patterns -- Test cache header
```
source
```
patterns against actual URLs. Common mistake: glob-style patterns (
```
{.svg,.png}
```
) don't work in all frameworks' path-matching (e.g., Next.js uses
```
path-to-regexp
```
). Use regex parameter syntax instead:
```
/:path*.:ext(svg|png|jpg|jpeg|gif|webp|ico|woff|woff2)
```

静态资源：对带哈希的文件（JS、CSS、字体、图片）使用
```
Cache-Control: public, max-age=31536000, immutable
```
。

HTML：使用

Cache-Control: public, max-age=0, must-revalidate

（或框架默认值）。

验证匹配规则——根据实际 URL 测试缓存 header 中的
```
source
```
匹配规则。常见错误是 glob 风格的规则（
```
{.svg,.png}
```
）并非适用于所有框架的路径匹配逻辑（例如 Next.js 使用
```
path-to-regexp
```
）。应改用正则参数语法：
```
/:path*.:ext(svg|png|jpg|jpeg|gif|webp|ico|woff|woff2)
```

Content Security Policy (Best Practices)

Content Security Policy（最佳实践）

Approve origins by FUNCTIONAL NECESSITY, not for the score -- an origin enters the CSP because the page genuinely needs it, and each is reviewed; whitelisting everything the page happens to load to silence console errors trades the whole point of a CSP for a Best-Practices number. No new origin ships unapproved.
Audit after every third-party change -- Adding analytics, fonts, or CDN scripts requires CSP updates.
Tighten after migration -- If you move from external fonts to self-hosted, remove the old CSP entries.

Common CSP origins:

Google Analytics:

https://www.googletagmanager.com

https://www.google-analytics.com

Cloudflare:
```
https://static.cloudflareinsights.com
```
Stripe:
```
https://js.stripe.com
```

按功能必要性批准 origin，而不是为了分数——某个 origin 进入 CSP，是因为页面确实需要它，并且每个 origin 都经过审查；为了消除控制台错误而将页面恰好加载的所有内容加入白名单，相当于牺牲 CSP 的核心目的。任何新 origin 都不得在未经批准的情况下发布。
每次变更第三方内容后进行审计——添加分析工具、字体或 CDN 脚本后，需要更新 CSP。
迁移后收紧策略——如果从外部字体迁移到自托管字体，应删除旧的 CSP 条目。

常见 CSP origin：

Google Analytics：

https://www.googletagmanager.com

、

https://www.google-analytics.com

Cloudflare：
```
https://static.cloudflareinsights.com
```
Stripe：
```
https://js.stripe.com
```

Accessibility (Lighthouse A11y Score)

无障碍（Lighthouse A11y 分数）

These directly affect the Lighthouse Accessibility score:

Contrast ratio -- WCAG AA requires 4.5:1 for normal text, 3:1 for large text. Avoid opacity modifiers on text colors (e.g.,
```
text-primary/80
```
in Tailwind reduces contrast). Use full-opacity color tokens.
Heading hierarchy follows STRUCTURE, decided with the accessibility owner -- sequential
```
h1
```
->
```
h2
```
->
```
h3
```
, no skipped levels. Demote a heading to
```
<p>
```
only when it is genuinely NOT a section title; downgrading a real footer-section heading to
```
<p>
```
to quiet a Lighthouse audit removes structure a screen-reader user navigates by. Accessibility is the owner here, not the score.
Alt text -- Decorative images next to identical text get
```
alt=""
```
. Informative images get descriptive alt. Never duplicate adjacent text.
Tap targets -- Minimum 48x48px on mobile. Applies to buttons, links, form inputs.

以下内容会直接影响 Lighthouse Accessibility 分数：

对比度——WCAG AA 要求普通文本达到 4.5:1，大文本达到 3:1。避免在文本颜色上使用透明度修饰器（例如 Tailwind 中的
```
text-primary/80
```
会降低对比度）。使用完全不透明的 color token。
标题层级遵循结构，并与无障碍负责人共同决定——按
```
h1
```
->
```
h2
```
->
```
h3
```
的顺序排列，不跳级。只有当某个标题确实不是章节标题时，才将其降级为
```
<p>
```
；为了消除 Lighthouse 审计提示而将真正的页脚章节标题降级为
```
<p>
```
，会破坏屏幕阅读器用户赖以导航的结构。这里应由无障碍负责人负责，而不是由分数负责。
Alt 文本——装饰性图片如果旁边已有相同文字，应使用
```
alt=""
```
。信息型图片应提供描述性 alt 文本。绝不要重复相邻文字。
点击目标——移动端最小尺寸为 48x48px。适用于按钮、链接和表单输入框。

Framework-Specific Guides

各框架专用指南

Next.js: See references/nextjs.md for
```
next/font
```
,
```
next/image
```
,
```
next/dynamic
```
,
```
next/script
```
, cache headers in
```
next.config
```
, CSP configuration, and bundle analysis.
CSS/Animation: See references/css-performance.md for compositing rules, gradient animation alternatives,
```
will-change
```
usage, and critical CSS strategies.
Accessibility: See references/accessibility-perf.md for contrast calculations, heading hierarchy rules, and ARIA patterns that affect Lighthouse.

Next.js：参见 references/nextjs.md，了解
```
next/font
```
、
```
next/image
```
、
```
next/dynamic
```
、
```
next/script
```
、
```
next.config
```
中的缓存 header、CSP 配置和 bundle 分析。
CSS/动画：参见 references/css-performance.md，了解合成层规则、渐变动画替代方案、
```
will-change
```
用法和关键 CSS 策略。
无障碍：参见 references/accessibility-perf.md，了解影响 Lighthouse 的对比度计算、标题层级规则和 ARIA 模式。

Common PageSpeed Failures & Fixes

常见 PageSpeed 失败项与修复方式

Audit	Cause	Fix
"Eliminate render-blocking resources"	External font CSS, large CSS files	Self-host fonts, inline critical CSS
"Reduce unused JavaScript"	Full page bundle loaded upfront	Code-split with dynamic imports
"Avoid non-composited animations"	Animating `background-position` , `width` , etc.	Replace with `transform` / `opacity` / `filter`
"Serve static assets with efficient cache policy"	Missing or short `Cache-Control` headers	Set `max-age=31536000, immutable` for hashed assets
"Background/foreground colors do not have sufficient contrast"	Opacity modifiers on text colors	Use full-opacity color tokens
"Heading elements not in sequential order"	Skipped heading levels (h1 -> h4)	Fix hierarchy or use `<p>` for non-structural headings
"Browser errors logged to console"	CSP blocking scripts/styles	Whitelist required origins in CSP
"Image elements do not have [alt] attributes"	Missing or redundant alt text	Add descriptive alt, or `alt=""` for decorative
"Avoid chaining critical requests"	Waterfall of blocking resources	Preload critical resources, self-host
"Legacy JavaScript"	Polyfills for modern APIs	Update `browserslist` targets

审计项	原因	修复方式
"Eliminate render-blocking resources"	外部字体 CSS、大型 CSS 文件	自托管字体、内联关键 CSS
"Reduce unused JavaScript"	初始即加载完整页面 bundle	使用动态导入进行代码拆分
"Avoid non-composited animations"	对 `background-position` 、 `width` 等设置动画	改用 `transform` / `opacity` / `filter`
"Serve static assets with efficient cache policy"	缺少 `Cache-Control` header 或有效期过短	对带哈希的资源设置 `max-age=31536000, immutable`
"Background/foreground colors do not have sufficient contrast"	文本颜色使用了透明度修饰器	使用完全不透明的 color token
"Heading elements not in sequential order"	跳过标题层级（h1 -> h4）	修复层级，或对非结构性标题使用 `<p>`
"Browser errors logged to console"	CSP 阻止脚本或样式	将必要 origin 加入 CSP 白名单
"Image elements do not have [alt] attributes"	缺少或重复 alt 文本	添加描述性 alt，或对装饰性图片使用 `alt=""`
"Avoid chaining critical requests"	阻塞式资源形成请求瀑布流	预加载关键资源、自托管资源
"Legacy JavaScript"	为现代 API 提供 polyfill	更新 `browserslist` 目标

Performance Budget Template

性能预算模板

Set these limits for landing pages:

Resource	Budget
Total page weight	< 1.5 MB
JavaScript (compressed)	< 200 KB
CSS (compressed)	< 50 KB
Fonts (total)	< 150 KB
Hero image	< 200 KB
LCP	< 2.5s (mobile)
FCP	< 1.8s (mobile)
CLS	< 0.1
TBT	< 200ms

为落地页设置以下限制：

资源	预算
页面总大小	< 1.5 MB
JavaScript（压缩后）	< 200 KB
CSS（压缩后）	< 50 KB
字体（总计）	< 150 KB
Hero 图片	< 200 KB
LCP	< 2.5s（移动端）
FCP	< 1.8s（移动端）
CLS	< 0.1
TBT	< 200ms

Related Skills

Degradation

降级处理

Not Claude Code (Cursor, Codex, the skills CLI, the API container): the pack's
```
PreToolUse
```
gate does not run — every rule here still applies, enforced by a person instead of a hook.
No browser channel (no
```
safaridriver
```
, no Playwright
```
webkit
```
, no Chrome DevTools MCP): a page is judged from the diff and the numbers are not measured on this machine. Record the weaker claim; a Lighthouse score nobody ran is not a score.
No network: PageSpeed Insights and field data are unavailable. Lab reasoning is still worth doing — say which half you did.

不适用于 Claude Code（Cursor、Codex、skills CLI、API container）：该技能包的
```
PreToolUse
```
gate 不会运行——这里的每条规则仍然适用，只是由人员而非 hook 执行。
无浏览器通道（没有
```
safaridriver
```
、Playwright
```
webkit
```
或 Chrome DevTools MCP）：只能根据 diff 判断页面，且未在本机完成数据测量。应记录这一较弱结论；无人运行过的 Lighthouse 分数不能算作分数。
无网络：无法使用 PageSpeed Insights 和实地数据。实验室层面的推理仍然值得进行——应明确说明完成了哪一部分。

Triggers

触发词

More phrases that route here: "performance audit", "LCP", "CLS", "INP", "render-blocking", "code splitting", "lazy loading", "cache headers", "оптимизация скорости".

更多会将请求路由至此的短语：“performance audit”、“LCP”、“CLS”、“INP”、“render-blocking”、“code splitting”、“lazy loading”、“cache headers”、“速度优化”。