core-web-vitals
addyosmani/web-quality-skills · Agent Skill
最佳化基本網頁指標(LCP、INP、CLS)以改善頁面使用者體驗,利用實地和實驗室研究的資料。當要求「改善基本網頁指標」、「修復 LCP」、「降低 CLS」、「最佳化 INP」、「最佳化頁面使用者體驗」或「修復版面配置偏移」時使用。
前往安裝 ↓總覽
| 發布者 | |
|---|---|
| 儲存庫 | addyosmani/web-quality-skills ↗ |
| 技能資料夾 | core-web-vitals |
| 星 | 2,992 |
| 分支 | 261 |
| 附帶檔案 | 4 |
| 授權 | MIT |
| 最近更新 | 2026年8月24日 |
| 連結 | 技能原始碼 ↗ · 儲存庫 ↗ |
Mozgi 檢查
我們在技能檔案中發現的內容。詳細資訊需訂閱。
安裝
技能就是一個含 SKILL.md 的資料夾。選擇你的代理,在專案根目錄的終端機(macOS、Linux 或 Windows 的 Git Bash)執行指令。
把提示貼到 Claude、Codex 或其他助理:它會自行檢查並安裝技能。
Install the “core-web-vitals” skill from mozgi.io (https://mozgi.io/skills/addyosmani-core-web-vitals/) for me. 1. Download the archive: https://mozgi.io/skills/addyosmani-core-web-vitals/download If it fails, take the skill folder from the source: https://github.com/addyosmani/web-quality-skills/tree/main/skills/core-web-vitals 2. Read SKILL.md and the other files. Check the skill is safe: no hidden commands, no sending data elsewhere, no scripts doing something other than described. If anything looks suspicious, stop and tell me. 3. Put the “core-web-vitals” folder into your agent's skills folder: .claude/skills/ for Claude Code, .agents/skills/ for Codex, .cursor/skills/ for Cursor, .gemini/skills/ for Gemini CLI. Inside the project if we are in one, otherwise in the home folder (~/.claude/skills/ etc.). 4. Make sure <skills folder>/core-web-vitals/SKILL.md exists. 5. Briefly tell me what this skill does and offer to try it on my task. If you cannot do a step yourself, tell me what to click or type.
git clone --depth 1 --branch main https://github.com/addyosmani/web-quality-skills.git /tmp/web-quality-skills mkdir -p .claude/skills cp -r /tmp/web-quality-skills/skills/core-web-vitals .claude/skills/core-web-vitals
重新啟動 Claude Code — 技能就會出現在清單中,手動呼叫:/core-web-vitals。要套用到所有專案,請放在 ~/.claude/skills。
git clone --depth 1 --branch main https://github.com/addyosmani/web-quality-skills.git /tmp/web-quality-skills mkdir -p .agents/skills cp -r /tmp/web-quality-skills/skills/core-web-vitals .agents/skills/core-web-vitals
Codex 會從目前資料夾往上到儲存庫根目錄,在 .agents/skills 中尋找技能;用 /skills 或 $core-web-vitals 呼叫。所有專案:~/.agents/skills。
git clone --depth 1 --branch main https://github.com/addyosmani/web-quality-skills.git /tmp/web-quality-skills mkdir -p .cursor/skills cp -r /tmp/web-quality-skills/skills/core-web-vitals .cursor/skills/core-web-vitals
Cursor 啟動時會載入技能;在 Agent 聊天輸入「/」呼叫。Cursor 也會讀取 .claude/skills 與 .agents/skills。所有專案:~/.cursor/skills。
git clone --depth 1 --branch main https://github.com/addyosmani/web-quality-skills.git /tmp/web-quality-skills mkdir -p .gemini/skills cp -r /tmp/web-quality-skills/skills/core-web-vitals .gemini/skills/core-web-vitals
任務符合時,Gemini CLI 會提議啟用技能,由你確認。所有專案:~/.gemini/skills。
安裝前請先檢視 SKILL.md 與相關檔案。點擊檔案即可預覽。
SKILL.md 內容
作者原文 · 唯讀Core Web Vitals optimization
Targeted optimization for the three Core Web Vitals using field data to identify user impact and browser traces to diagnose causes.
Measure before optimizing
When a runnable URL is available, read the performance measurement workflow. Prefer this sequence:
1. Check page-level CrUX p75 data, with a clearly labeled origin fallback when page data is unavailable.
2. Record a browser performance trace under stated conditions. With Chrome DevTools MCP, trace summaries can include CrUX alongside the observed lab metrics.
3. Analyze only the insights associated with the failing metric, then inspect the implicated code and resources.
4. Re-run equivalent lab measurements after the fix. Do not claim an immediate field improvement; CrUX and first-party RUM need new user visits.
If only source code is available, identify likely causes but do not claim that LCP, INP, or CLS is failing without runtime evidence.
The three metrics
| Metric | Measures | Good | Needs work | Poor |
|--------|----------|------|------------|------|
| LCP | Loading | ≤ 2.5s | 2.5s – 4s | > 4s |
| INP | Interactivity | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | Visual Stability | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
Google measures at the 75th percentile — 75% of page visits must meet "Good" thresholds.
---
LCP: Largest Contentful Paint
LCP measures when the largest visible content element renders. Usually this is:
- Hero image or video
- Large text block
- Background image
<svg>element
Common LCP issues
1. Slow server response (TTFB > 800ms)
Fix: CDN, caching, optimized backend, edge rendering
2. Render-blocking resources
<!-- ❌ Blocks rendering -->
<link rel="stylesheet" href="/all-styles.css">
<!-- ✅ Critical CSS inlined, rest deferred -->
<style>/* Critical above-fold CSS */</style>
<link rel="preload" href="/styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
3. Slow resource load times
<!-- ❌ LCP image is discovered only after a stylesheet loads -->
<div class="hero"></div>
<!-- ✅ Discoverable in initial HTML and prioritized -->
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<img src="/hero.webp" alt="Hero" fetchpriority="high">
Prefer a discoverable <img> with fetchpriority="high". Add the preload only when the trace shows that the resource would otherwise be discovered late; duplicate or speculative preloads can compete for bandwidth.
4. Client-side rendering delays
// ❌ Content loads after JavaScript
useEffect(() => {
fetch('/api/hero-text').then(r => r.json()).then(setHeroText);
}, []);
// ✅ Server-side or static rendering
// Use SSR, SSG, or streaming to send HTML with content
export async function getServerSideProps() {
const heroText = await fetchHeroText();
return { props: { heroText } };
}
5. Make navigations instant with the Speculation Rules API
For sites with predictable same-origin journeys, prerendering a likely next page can make a successful subsequent navigation much faster. Treat this as a measured navigation optimization, not a substitute for fixing the current page's LCP.
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
Current Chrome behavior is specific enough to guide the choice:
| eagerness | Trigger |
|-------------|---------|
| conservative | Pointer or touch down |
| moderate | Desktop: 200ms hover, or earlier pointer down; mobile: viewport heuristics |
| eager | Chrome 143+: desktop 10ms hover; mobile 50ms after the anchor enters the viewport |
| immediate | As soon as the rules are observed |
Start conservatively and measure prediction hit rate, transferred bytes, server load, and navigation improvement before expanding the rules. Recheck Chrome's maintained eagerness documentation ↗ before hardcoding timing-sensitive behavior.
Caveats:
- Bandwidth/CPU cost. Each prerender is roughly a full page load. Scope
wherecarefully (href_matchespatterns, exclude logout/checkout) and avoidimmediateoutside small sites. - Side effects fire early. Analytics, ads, and any code that runs on load will fire when the prerender starts, not when the user navigates. Gate side effects on the
prerenderingchangeevent ↗ ordocument.prerendering. - Chromium-only. Safari and Firefox ignore the script — it's a progressive enhancement, never a regression.
LCP optimization checklist
- [ ] TTFB < 800ms (use CDN, edge caching)
- [ ] LCP resource is discoverable in initial HTML and prioritized; preload only if the trace shows late discovery
- [ ] LCP image optimized (WebP/AVIF, correct size)
- [ ] Critical CSS inlined (< 14KB)
- [ ] No render-blocking JavaScript in <head>
- [ ] Fonts don't block text rendering (font-display: swap)
- [ ] LCP element in initial HTML (not JS-rendered)
- [ ] Speculation Rules added for likely-next navigations (moderate eagerness)
LCP element identification
This snippet diagnoses the current page session. It is not field data.
// Find your LCP element
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
console.log('LCP time:', lastEntry.startTime);
}).observe({ type: 'largest-contentful-paint', buffered: true });
---
INP: Interaction to Next Paint
INP measures responsiveness across clicks, taps, and key presses during a visit. Diagnose its input delay, processing time, and presentation delay separately; a slow interaction may involve main-thread contention before the handler, expensive application work, or delayed rendering after it.
When field INP is poor or a trace identifies a slow interaction, read the INP reference ↗ for trace interpretation, yielding patterns, third-party and rendering causes, a single-session observer, and first-party attribution.
---
CLS: Cumulative Layout Shift
CLS measures unexpected layout shifts across a page visit. Use field attribution or a trace to identify the shifted node and the trigger; do not assume the visible victim caused the shift.
When field CLS is poor or a trace reports shifts, read the CLS reference ↗ for reserved-space patterns, dynamic content, font and animation fixes, a debugging observer, and a verification checklist.
---
Measurement sources
| Source | Use |
|--------|-----|
| Browser performance trace (Chrome DevTools MCP: performance_start_trace) | Observe one load or interaction and diagnose focused insights; use included CrUX context when available |
| CrUX or Search Console | Prioritize aggregated real-user outcomes at p75 |
| Lighthouse CLI or PageSpeed Insights | Controlled lab fallback when DevTools tools are unavailable |
| First-party RUM | Segment current production experience by route, device, release, and attribution |
| Raw PerformanceObserver | Inspect one page session during debugging |
Do not route performance through Chrome DevTools MCP's lighthouse_audit; that capability intentionally covers non-performance Lighthouse categories. Do not compare a single lab value directly with a field p75 as if they were equivalent samples.
When adding or reviewing production collection, read the first-party RUM reference. Prefer the web-vitals library because raw browser APIs do not by themselves implement every Core Web Vital's lifecycle and reporting rules.
---
Framework quick fixes
Next.js
// LCP: Use next/image with priority
import Image from 'next/image';
<Image src="/hero.jpg" priority fill alt="Hero" />
// INP: Use dynamic imports
const HeavyComponent = dynamic(() => import('./Heavy'), { ssr: false });
// CLS: Image component handles dimensions automatically
React
// LCP: Preload in head
<link rel="preload" href="/hero.jpg" as="image" fetchpriority="high" />
// INP: Memoize and useTransition
const [isPending, startTransition] = useTransition();
startTransition(() => setExpensiveState(newValue));
// CLS: Always specify dimensions in img tags
Vue/Nuxt
<!-- LCP: Use nuxt/image with preload -->
<NuxtImg src="/hero.jpg" preload loading="eager" />
<!-- INP: Use async components -->
<component :is="() => import('./Heavy.vue')" />
<!-- CLS: Use aspect-ratio CSS -->
<img :style="{ aspectRatio: '16/9' }" />
References
- Detailed LCP optimization ↗ — read when an LCP trace points to discovery, loading, or render delay
- Detailed INP optimization ↗ — read when a trace or field attribution identifies a slow interaction
- Detailed CLS optimization ↗ — read when a trace or field attribution identifies unexpected shifts
- web.dev LCP ↗
- web.dev INP ↗
- web.dev CLS ↗
- Performance skill
常見問題
core-web-vitals 技能有什麼用途?
最佳化基本網頁指標(LCP、INP、CLS)以改善頁面使用者體驗,利用實地和實驗室研究的資料。當要求「改善基本網頁指標」、「修復 LCP」、「降低 CLS」、「最佳化 INP」、「最佳化頁面使用者體驗」或「修復版面配置偏移」時使用。
如何安裝 core-web-vitals?
打開本頁的「安裝」區塊並選擇你的代理 — Claude Code、Codex、Cursor 或 Gemini CLI:那裡有把技能資料夾複製到正確位置的現成指令。也可以複製「透過助理」分頁中的提示,讓助理自行檢查並安裝技能。
core-web-vitals 適用哪些 AI 模型?
技能是純 Markdown 指示(Agent Skills 格式),因此 core-web-vitals 適用任何讀取 SKILL.md 的代理:Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot、OpenCode 等。只有在任務符合技能描述時,模型才會載入指示。
core-web-vitals 是免費的嗎?
此技能由 addyosmani 公開發布,採用 MIT 授權。技能本身免費 — 你只需向 AI 供應商支付實際使用的 token 費用。
安裝技能安全嗎?
技能是代理會遵循的指示,安裝前請閱讀 SKILL.md 及相關檔案。技能資料夾中的腳本只有在代理執行時才會運行 — 留意它的動作,不要授予多餘權限。
技能和 MCP 伺服器或外掛有何不同?
MCP 伺服器或外掛為模型提供新工具 — 會執行並回傳結果的程式碼。技能提供的是知識與流程:如何處理任務、要遵循哪些步驟、好的成果長什麼樣子。它不需要伺服器或 API 金鑰。