[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FA067Q5DR3CFSCVSQJVCG1":3,"skill-same:01M6FA067Q5DR3CFSCVSQJVCG1":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":39,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6FA067Q5DR3CFSCVSQJVCG1","performance-optimization",null,"Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-performance-optimization\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"performance","Optimization","performance optimization","2026","github","when","vitals","improvement","load","tree","you","web vitals","critical","requirements","application","wed","main","community","agent-skills","use","profiling","core web vitals","https","license","core","web","2026-11-10 10:12:30",false,"---\nname: performance-optimization\ndescription: Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.\nrisk: critical\nsource: https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Ftree\u002Fmain\u002Fskills\u002Fperformance-optimization\nsource_repo: addyosmani\u002Fagent-skills\nsource_type: community\ndate_added: 2026-07-01\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Fblob\u002Fmain\u002FLICENSE\n---\n## Supporting material availability\n\nThis catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:\n\n- `\u003Csupport-root>\u002Freferences\u002Fperformance-checklist.md`\n\nObtain the required material from the [declared upstream source](https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills), or from a user-provided installation of that source. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.\n\n\n# Performance Optimization\n\n## Overview\n\nMeasure before optimizing. Performance work without measurement is guessing — and guessing leads to premature optimization that adds complexity without improving what matters. Profile first, identify the actual bottleneck, fix it, measure again. Optimize only what measurements prove matters.\n\n## When to Use\n\n- Performance requirements exist in the spec (load time budgets, response time SLAs)\n- Users or monitoring report slow behavior\n- Core Web Vitals scores are below thresholds\n- You suspect a change introduced a regression\n- Building features that handle large datasets or high traffic\n\n**When NOT to use:** Don't optimize before you have evidence of a problem. Premature optimization adds complexity that costs more than the performance it gains.\n\n## Core Web Vitals Targets\n\n| Metric | Good | Needs Improvement | Poor |\n|--------|------|-------------------|------|\n| **LCP** (Largest Contentful Paint) | ≤ 2.5s | ≤ 4.0s | > 4.0s |\n| **INP** (Interaction to Next Paint) | ≤ 200ms | ≤ 500ms | > 500ms |\n| **CLS** (Cumulative Layout Shift) | ≤ 0.1 | ≤ 0.25 | > 0.25 |\n\n## The Optimization Workflow\n\n```\n1. MEASURE  → Establish baseline with real data\n2. IDENTIFY → Find the actual bottleneck (not assumed)\n3. FIX      → Address the specific bottleneck\n4. VERIFY   → Measure again, confirm improvement\n5. GUARD    → Add monitoring or tests to prevent regression\n```\n\n### Step 1: Measure\n\nTwo complementary approaches — use both:\n\n- **Synthetic (Lighthouse, DevTools Performance tab):** Controlled conditions, reproducible. Best for CI regression detection and isolating specific issues.\n- **RUM (web-vitals library, CrUX):** Real user data in real conditions. Required to validate that a fix actually improved user experience.\n\n**Frontend:**\n```bash\n# Synthetic: Lighthouse in Chrome DevTools (or CI)\n# Chrome DevTools → Performance tab → Record\n# Chrome DevTools MCP → Performance trace\n\n# RUM: Web Vitals library in code\nimport { onLCP, onINP, onCLS } from 'web-vitals';\n\nonLCP(console.log);\nonINP(console.log);\nonCLS(console.log);\n```\n\n**Backend:**\n```bash\n# Response time logging\n# Application Performance Monitoring (APM)\n# Database query logging with timing\n\n# Simple timing\nconsole.time('db-query');\nconst result = await db.query(...);\nconsole.timeEnd('db-query');\n```\n\n### Where to Start Measuring\n\nUse the symptom to decide what to measure first:\n\n```\nWhat is slow?\n├── First page load\n│   ├── Large bundle? --> Measure bundle size, check code splitting\n│   ├── Slow server response? --> Measure TTFB in DevTools Network waterfall\n│   │   ├── DNS long? --> Add dns-prefetch \u002F preconnect for known origins\n│   │   ├── TCP\u002FTLS long? --> Enable HTTP\u002F2, check edge deployment, keep-alive\n│   │   └── Waiting (server) long? --> Profile backend, check queries and caching\n│   └── Render-blocking resources? --> Check network waterfall for CSS\u002FJS blocking\n├── Interaction feels sluggish\n│   ├── UI freezes on click? --> Profile main thread, look for long tasks (>50ms)\n│   ├── Form input lag? --> Check re-renders, controlled component overhead\n│   └── Animation jank? --> Check layout thrashing, forced reflows\n├── Page after navigation\n│   ├── Data loading? --> Measure API response times, check for waterfalls\n│   └── Client rendering? --> Profile component render time, check for N+1 fetches\n└── Backend \u002F API\n    ├── Single endpoint slow? --> Profile database queries, check indexes\n    ├── All endpoints slow? --> Check connection pool, memory, CPU\n    └── Intermittent slowness? --> Check for lock contention, GC pauses, external deps\n```\n\n### Step 2: Identify the Bottleneck\n\nCommon bottlenecks by category:\n\n**Frontend:**\n\n| Symptom | Likely Cause | Investigation |\n|---------|-------------|---------------|\n| Slow LCP | Large images, render-blocking resources, slow server | Check network waterfall, image sizes |\n| High CLS | Images without dimensions, late-loading content, font shifts | Check layout shift attribution |\n| Poor INP | Heavy JavaScript on main thread, large DOM updates | Check long tasks in Performance trace |\n| Slow initial load | Large bundle, many network requests | Check bundle size, code splitting |\n\n**Backend:**\n\n| Symptom | Likely Cause | Investigation |\n|---------|-------------|---------------|\n| Slow API responses | N+1 queries, missing indexes, unoptimized queries | Check database query log |\n| Memory growth | Leaked references, unbounded caches, large payloads | Heap snapshot analysis |\n| CPU spikes | Synchronous heavy computation, regex backtracking | CPU profiling |\n| High latency | Missing caching, redundant computation, network hops | Trace requests through the stack |\n\n### Step 3: Fix Common Anti-Patterns\n\n#### N+1 Queries (Backend)\n\n```typescript\n\u002F\u002F BAD: N+1 — one query per task for the owner\nconst tasks = await db.tasks.findMany();\nfor (const task of tasks) {\n  task.owner = await db.users.findUnique({ where: { id: task.ownerId } });\n}\n\n\u002F\u002F GOOD: Eager relation loading; inspect generated queries (include is not always a SQL join)\nconst tasks = await db.tasks.findMany({\n  include: { owner: true },\n});\n```\n\n#### Unbounded Data Fetching\n\n```typescript\n\u002F\u002F BAD: Fetching all records\nconst allTasks = await db.tasks.findMany();\n\n\u002F\u002F GOOD: Paginated with limits\nconst tasks = await db.tasks.findMany({\n  take: 20,\n  skip: (page - 1) * 20,\n  orderBy: { createdAt: 'desc' },\n});\n```\n\n#### Missing Image Optimization (Frontend)\n\n```html\n\u003C!-- BAD: No dimensions, no format optimization -->\n\u003Cimg src=\"\u002Fhero.jpg\" \u002F>\n\n\u003C!-- GOOD: Hero \u002F LCP image — art direction + resolution switching, high priority -->\n\u003C!--\n  Two techniques combined:\n  - Art direction (media): different crop\u002Fcomposition per breakpoint\n  - Resolution switching (srcset + sizes): right file size per screen density\n-->\n\u003Cpicture>\n  \u003C!-- Mobile: portrait crop (8:10) -->\n  \u003Csource\n    media=\"(max-width: 767px)\"\n    srcset=\"\u002Fhero-mobile-400.avif 400w, \u002Fhero-mobile-800.avif 800w\"\n    sizes=\"100vw\"\n    width=\"800\"\n    height=\"1000\"\n    type=\"image\u002Favif\"\n  \u002F>\n  \u003Csource\n    media=\"(max-width: 767px)\"\n    srcset=\"\u002Fhero-mobile-400.webp 400w, \u002Fhero-mobile-800.webp 800w\"\n    sizes=\"100vw\"\n    width=\"800\"\n    height=\"1000\"\n    type=\"image\u002Fwebp\"\n  \u002F>\n  \u003C!-- Desktop: landscape crop (2:1) -->\n  \u003Csource\n    srcset=\"\u002Fhero-800.avif 800w, \u002Fhero-1200.avif 1200w, \u002Fhero-1600.avif 1600w\"\n    sizes=\"(max-width: 1200px) 100vw, 1200px\"\n    width=\"1200\"\n    height=\"600\"\n    type=\"image\u002Favif\"\n  \u002F>\n  \u003Csource\n    srcset=\"\u002Fhero-800.webp 800w, \u002Fhero-1200.webp 1200w, \u002Fhero-1600.webp 1600w\"\n    sizes=\"(max-width: 1200px) 100vw, 1200px\"\n    width=\"1200\"\n    height=\"600\"\n    type=\"image\u002Fwebp\"\n  \u002F>\n  \u003Cimg\n    src=\"\u002Fhero-desktop.jpg\"\n    width=\"1200\"\n    height=\"600\"\n    fetchpriority=\"high\"\n    alt=\"Hero image description\"\n  \u002F>\n\u003C\u002Fpicture>\n\n\u003C!-- GOOD: Below-the-fold image — lazy loaded + async decoding -->\n\u003Cimg\n  src=\"\u002Fcontent.webp\"\n  width=\"800\"\n  height=\"400\"\n  loading=\"lazy\"\n  decoding=\"async\"\n  alt=\"Content image description\"\n\u002F>\n```\n\n#### Unnecessary Re-renders (React)\n\n```tsx\n\u002F\u002F BAD: Creates new object on every render, causing children to re-render\nfunction TaskList() {\n  return \u003CTaskFilters options={{ sortBy: 'date', order: 'desc' }} \u002F>;\n}\n\n\u002F\u002F GOOD: Stable reference\nconst DEFAULT_OPTIONS = { sortBy: 'date', order: 'desc' } as const;\nfunction TaskList() {\n  return \u003CTaskFilters options={DEFAULT_OPTIONS} \u002F>;\n}\n\n\u002F\u002F Use React.memo for expensive components\nconst TaskItem = React.memo(function TaskItem({ task }: Props) {\n  return \u003Cdiv>{\u002F* expensive render *\u002F}\u003C\u002Fdiv>;\n});\n\n\u002F\u002F Use useMemo for expensive computations\nfunction TaskStats({ tasks }: Props) {\n  const stats = useMemo(() => calculateStats(tasks), [tasks]);\n  return \u003Cdiv>{stats.completed} \u002F {stats.total}\u003C\u002Fdiv>;\n}\n```\n\n#### Large Bundle Size\n\n```typescript\n\u002F\u002F Modern bundlers (Vite, webpack 5+) handle named imports with tree-shaking automatically,\n\u002F\u002F provided the dependency ships ESM and is marked `sideEffects: false` in package.json.\n\u002F\u002F Profile before changing import styles — the real gains come from splitting and lazy loading.\n\n\u002F\u002F GOOD: Dynamic import for heavy, rarely-used features\nconst ChartLibrary = lazy(() => import('.\u002FChartLibrary'));\n\n\u002F\u002F GOOD: Route-level code splitting wrapped in Suspense\nconst SettingsPage = lazy(() => import('.\u002Fpages\u002FSettings'));\n\nfunction App() {\n  return (\n    \u003CSuspense fallback={\u003CSpinner \u002F>}>\n      \u003CSettingsPage \u002F>\n    \u003C\u002FSuspense>\n  );\n}\n```\n\n#### Missing Caching (Backend)\n\n```typescript\n\u002F\u002F Cache frequently-read, rarely-changed data\nconst CACHE_TTL = 5 * 60 * 1000; \u002F\u002F 5 minutes\nlet cachedConfig: AppConfig | null = null;\nlet cacheExpiry = 0;\n\nasync function getAppConfig(): Promise\u003CAppConfig> {\n  if (cachedConfig && Date.now() \u003C cacheExpiry) {\n    return cachedConfig;\n  }\n  const config = await db.config.findFirst();\n  if (!config) throw new Error(\"Application configuration missing\");\n  cachedConfig = config;\n  cacheExpiry = Date.now() + CACHE_TTL;\n  return cachedConfig;\n}\n\n\u002F\u002F HTTP caching headers for static assets\napp.use('\u002Fstatic', express.static('public', {\n  maxAge: '1y',           \u002F\u002F Cache for 1 year\n  immutable: true,        \u002F\u002F Never revalidate (use content hashing in filenames)\n}));\n\n\u002F\u002F Cache-Control for API responses\n\u002F\u002F Only for explicitly public, non-personalized data; private responses need a separate policy.\nres.set('Cache-Control', 'public, max-age=300'); \u002F\u002F 5 minutes\n```\n\n## Performance Budget\n\nSet representative, product-specific budgets; these are illustrative starting points:\n\n```\nJavaScript bundle: \u003C 200KB gzipped (initial load)\nCSS: \u003C 50KB gzipped\nImages: \u003C 200KB per image (above the fold)\nFonts: \u003C 100KB total\nAPI response time: \u003C 200ms (p95)\nTime to Interactive: \u003C 3.5s on 4G\nLighthouse Performance score: ≥ 90\n```\n\n**Enforce in CI:**\n```bash\n# Bundle size check\nnpx bundlesize --config bundlesize.config.json\n\n# Lighthouse CI\nnpx lhci autorun\n```\n\n## See Also\n\nFor detailed performance checklists, optimization commands, and anti-pattern reference, see `references\u002Fperformance-checklist.md`.\n\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"We'll optimize later\" | Performance debt compounds. Fix obvious anti-patterns now, defer micro-optimizations. |\n| \"It's fast on my machine\" | Your machine isn't the user's. Profile on representative hardware and networks. |\n| \"This optimization is obvious\" | If you didn't measure, you don't know. Profile first. |\n| \"Users won't notice 100ms\" | Measure whether latency affects this product's users; no universal conversion multiplier applies. |\n| \"The framework handles performance\" | Frameworks prevent some issues but can't fix N+1 queries or oversized bundles. |\n\n## Red Flags\n\n- Optimization without profiling data to justify it\n- N+1 query patterns in data fetching\n- List endpoints without pagination\n- Images without dimensions, lazy loading, or responsive sizes\n- Bundle size growing without review\n- No performance monitoring in production\n- `React.memo` and `useMemo` everywhere (overusing is as bad as underusing)\n\n## Verification\n\nAfter any performance-related change:\n\n- [ ] Before and after measurements exist (specific numbers)\n- [ ] The specific bottleneck is identified and addressed\n- [ ] Core Web Vitals are within \"Good\" thresholds\n- [ ] Bundle size hasn't increased significantly\n- [ ] No N+1 queries in new data fetching code\n- [ ] Performance budget passes in CI (if configured)\n- [ ] Existing tests still pass (optimization didn't break behavior)\n\n## Limitations\n\n- Use this skill only when the task clearly matches its upstream source and local project context.\n- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.\n- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.\n\nAssess Core Web Vitals field distributions at the 75th percentile, segmented by device where appropriate. RUM collection requires privacy\u002Fdata-retention scope. Shared caches must be keyed by tenant\u002Fauthorization context or restricted to genuinely global configuration; never cache private API data publicly. Validate page inputs and use stable unique ordering\u002Fcursor pagination for mutable datasets. TTI is a historical metric, not a current Core Web Vital.\n","## Supporting material availability\n\nThis catalog copy contains the inline guidance below, but does not include the following supporting paths. They are external prerequisites, not bundled files:\n\n- `\u003Csupport-root>\u002Freferences\u002Fperformance-checklist.md`\n\nObtain the required material from the [declared upstream source](https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills), or from a user-provided installation of that source. Resolve each path relative to that installation, inspect its contents, and verify any applicable license and execution prerequisites. Do not run a command or claim a referenced procedure was followed until its required file exists. Do not fabricate the missing scripts or treat an unrelated file with the same name as equivalent. Independent steps fully documented here can proceed within the user’s authorized scope; report any dependent step as unavailable.\n\n\n# Performance Optimization\n\n## Overview\n\nMeasure before optimizing. Performance work without measurement is guessing — and guessing leads to premature optimization that adds complexity without improving what matters. Profile first, identify the actual bottleneck, fix it, measure again. Optimize only what measurements prove matters.\n\n## When to Use\n\n- Performance requirements exist in the spec (load time budgets, response time SLAs)\n- Users or monitoring report slow behavior\n- Core Web Vitals scores are below thresholds\n- You suspect a change introduced a regression\n- Building features that handle large datasets or high traffic\n\n**When NOT to use:** Don't optimize before you have evidence of a problem. Premature optimization adds complexity that costs more than the performance it gains.\n\n## Core Web Vitals Targets\n\n| Metric | Good | Needs Improvement | Poor |\n|--------|------|-------------------|------|\n| **LCP** (Largest Contentful Paint) | ≤ 2.5s | ≤ 4.0s | > 4.0s |\n| **INP** (Interaction to Next Paint) | ≤ 200ms | ≤ 500ms | > 500ms |\n| **CLS** (Cumulative Layout Shift) | ≤ 0.1 | ≤ 0.25 | > 0.25 |\n\n## The Optimization Workflow\n\n```\n1. MEASURE  → Establish baseline with real data\n2. IDENTIFY → Find the actual bottleneck (not assumed)\n3. FIX      → Address the specific bottleneck\n4. VERIFY   → Measure again, confirm improvement\n5. GUARD    → Add monitoring or tests to prevent regression\n```\n\n### Step 1: Measure\n\nTwo complementary approaches — use both:\n\n- **Synthetic (Lighthouse, DevTools Performance tab):** Controlled conditions, reproducible. Best for CI regression detection and isolating specific issues.\n- **RUM (web-vitals library, CrUX):** Real user data in real conditions. Required to validate that a fix actually improved user experience.\n\n**Frontend:**\n```bash\n# Synthetic: Lighthouse in Chrome DevTools (or CI)\n# Chrome DevTools → Performance tab → Record\n# Chrome DevTools MCP → Performance trace\n\n# RUM: Web Vitals library in code\nimport { onLCP, onINP, onCLS } from 'web-vitals';\n\nonLCP(console.log);\nonINP(console.log);\nonCLS(console.log);\n```\n\n**Backend:**\n```bash\n# Response time logging\n# Application Performance Monitoring (APM)\n# Database query logging with timing\n\n# Simple timing\nconsole.time('db-query');\nconst result = await db.query(...);\nconsole.timeEnd('db-query');\n```\n\n### Where to Start Measuring\n\nUse the symptom to decide what to measure first:\n\n```\nWhat is slow?\n├── First page load\n│   ├── Large bundle? --> Measure bundle size, check code splitting\n│   ├── Slow server response? --> Measure TTFB in DevTools Network waterfall\n│   │   ├── DNS long? --> Add dns-prefetch \u002F preconnect for known origins\n│   │   ├── TCP\u002FTLS long? --> Enable HTTP\u002F2, check edge deployment, keep-alive\n│   │   └── Waiting (server) long? --> Profile backend, check queries and caching\n│   └── Render-blocking resources? --> Check network waterfall for CSS\u002FJS blocking\n├── Interaction feels sluggish\n│   ├── UI freezes on click? --> Profile main thread, look for long tasks (>50ms)\n│   ├── Form input lag? --> Check re-renders, controlled component overhead\n│   └── Animation jank? --> Check layout thrashing, forced reflows\n├── Page after navigation\n│   ├── Data loading? --> Measure API response times, check for waterfalls\n│   └── Client rendering? --> Profile component render time, check for N+1 fetches\n└── Backend \u002F API\n    ├── Single endpoint slow? --> Profile database queries, check indexes\n    ├── All endpoints slow? --> Check connection pool, memory, CPU\n    └── Intermittent slowness? --> Check for lock contention, GC pauses, external deps\n```\n\n### Step 2: Identify the Bottleneck\n\nCommon bottlenecks by category:\n\n**Frontend:**\n\n| Symptom | Likely Cause | Investigation |\n|---------|-------------|---------------|\n| Slow LCP | Large images, render-blocking resources, slow server | Check network waterfall, image sizes |\n| High CLS | Images without dimensions, late-loading content, font shifts | Check layout shift attribution |\n| Poor INP | Heavy JavaScript on main thread, large DOM updates | Check long tasks in Performance trace |\n| Slow initial load | Large bundle, many network requests | Check bundle size, code splitting |\n\n**Backend:**\n\n| Symptom | Likely Cause | Investigation |\n|---------|-------------|---------------|\n| Slow API responses | N+1 queries, missing indexes, unoptimized queries | Check database query log |\n| Memory growth | Leaked references, unbounded caches, large payloads | Heap snapshot analysis |\n| CPU spikes | Synchronous heavy computation, regex backtracking | CPU profiling |\n| High latency | Missing caching, redundant computation, network hops | Trace requests through the stack |\n\n### Step 3: Fix Common Anti-Patterns\n\n#### N+1 Queries (Backend)\n\n```typescript\n\u002F\u002F BAD: N+1 — one query per task for the owner\nconst tasks = await db.tasks.findMany();\nfor (const task of tasks) {\n  task.owner = await db.users.findUnique({ where: { id: task.ownerId } });\n}\n\n\u002F\u002F GOOD: Eager relation loading; inspect generated queries (include is not always a SQL join)\nconst tasks = await db.tasks.findMany({\n  include: { owner: true },\n});\n```\n\n#### Unbounded Data Fetching\n\n```typescript\n\u002F\u002F BAD: Fetching all records\nconst allTasks = await db.tasks.findMany();\n\n\u002F\u002F GOOD: Paginated with limits\nconst tasks = await db.tasks.findMany({\n  take: 20,\n  skip: (page - 1) * 20,\n  orderBy: { createdAt: 'desc' },\n});\n```\n\n#### Missing Image Optimization (Frontend)\n\n```html\n\u003C!-- BAD: No dimensions, no format optimization -->\n\u003Cimg src=\"\u002Fhero.jpg\" \u002F>\n\n\u003C!-- GOOD: Hero \u002F LCP image — art direction + resolution switching, high priority -->\n\u003C!--\n  Two techniques combined:\n  - Art direction (media): different crop\u002Fcomposition per breakpoint\n  - Resolution switching (srcset + sizes): right file size per screen density\n-->\n\u003Cpicture>\n  \u003C!-- Mobile: portrait crop (8:10) -->\n  \u003Csource\n    media=\"(max-width: 767px)\"\n    srcset=\"\u002Fhero-mobile-400.avif 400w, \u002Fhero-mobile-800.avif 800w\"\n    sizes=\"100vw\"\n    width=\"800\"\n    height=\"1000\"\n    type=\"image\u002Favif\"\n  \u002F>\n  \u003Csource\n    media=\"(max-width: 767px)\"\n    srcset=\"\u002Fhero-mobile-400.webp 400w, \u002Fhero-mobile-800.webp 800w\"\n    sizes=\"100vw\"\n    width=\"800\"\n    height=\"1000\"\n    type=\"image\u002Fwebp\"\n  \u002F>\n  \u003C!-- Desktop: landscape crop (2:1) -->\n  \u003Csource\n    srcset=\"\u002Fhero-800.avif 800w, \u002Fhero-1200.avif 1200w, \u002Fhero-1600.avif 1600w\"\n    sizes=\"(max-width: 1200px) 100vw, 1200px\"\n    width=\"1200\"\n    height=\"600\"\n    type=\"image\u002Favif\"\n  \u002F>\n  \u003Csource\n    srcset=\"\u002Fhero-800.webp 800w, \u002Fhero-1200.webp 1200w, \u002Fhero-1600.webp 1600w\"\n    sizes=\"(max-width: 1200px) 100vw, 1200px\"\n    width=\"1200\"\n    height=\"600\"\n    type=\"image\u002Fwebp\"\n  \u002F>\n  \u003Cimg\n    src=\"\u002Fhero-desktop.jpg\"\n    width=\"1200\"\n    height=\"600\"\n    fetchpriority=\"high\"\n    alt=\"Hero image description\"\n  \u002F>\n\u003C\u002Fpicture>\n\n\u003C!-- GOOD: Below-the-fold image — lazy loaded + async decoding -->\n\u003Cimg\n  src=\"\u002Fcontent.webp\"\n  width=\"800\"\n  height=\"400\"\n  loading=\"lazy\"\n  decoding=\"async\"\n  alt=\"Content image description\"\n\u002F>\n```\n\n#### Unnecessary Re-renders (React)\n\n```tsx\n\u002F\u002F BAD: Creates new object on every render, causing children to re-render\nfunction TaskList() {\n  return \u003CTaskFilters options={{ sortBy: 'date', order: 'desc' }} \u002F>;\n}\n\n\u002F\u002F GOOD: Stable reference\nconst DEFAULT_OPTIONS = { sortBy: 'date', order: 'desc' } as const;\nfunction TaskList() {\n  return \u003CTaskFilters options={DEFAULT_OPTIONS} \u002F>;\n}\n\n\u002F\u002F Use React.memo for expensive components\nconst TaskItem = React.memo(function TaskItem({ task }: Props) {\n  return \u003Cdiv>{\u002F* expensive render *\u002F}\u003C\u002Fdiv>;\n});\n\n\u002F\u002F Use useMemo for expensive computations\nfunction TaskStats({ tasks }: Props) {\n  const stats = useMemo(() => calculateStats(tasks), [tasks]);\n  return \u003Cdiv>{stats.completed} \u002F {stats.total}\u003C\u002Fdiv>;\n}\n```\n\n#### Large Bundle Size\n\n```typescript\n\u002F\u002F Modern bundlers (Vite, webpack 5+) handle named imports with tree-shaking automatically,\n\u002F\u002F provided the dependency ships ESM and is marked `sideEffects: false` in package.json.\n\u002F\u002F Profile before changing import styles — the real gains come from splitting and lazy loading.\n\n\u002F\u002F GOOD: Dynamic import for heavy, rarely-used features\nconst ChartLibrary = lazy(() => import('.\u002FChartLibrary'));\n\n\u002F\u002F GOOD: Route-level code splitting wrapped in Suspense\nconst SettingsPage = lazy(() => import('.\u002Fpages\u002FSettings'));\n\nfunction App() {\n  return (\n    \u003CSuspense fallback={\u003CSpinner \u002F>}>\n      \u003CSettingsPage \u002F>\n    \u003C\u002FSuspense>\n  );\n}\n```\n\n#### Missing Caching (Backend)\n\n```typescript\n\u002F\u002F Cache frequently-read, rarely-changed data\nconst CACHE_TTL = 5 * 60 * 1000; \u002F\u002F 5 minutes\nlet cachedConfig: AppConfig | null = null;\nlet cacheExpiry = 0;\n\nasync function getAppConfig(): Promise\u003CAppConfig> {\n  if (cachedConfig && Date.now() \u003C cacheExpiry) {\n    return cachedConfig;\n  }\n  const config = await db.config.findFirst();\n  if (!config) throw new Error(\"Application configuration missing\");\n  cachedConfig = config;\n  cacheExpiry = Date.now() + CACHE_TTL;\n  return cachedConfig;\n}\n\n\u002F\u002F HTTP caching headers for static assets\napp.use('\u002Fstatic', express.static('public', {\n  maxAge: '1y',           \u002F\u002F Cache for 1 year\n  immutable: true,        \u002F\u002F Never revalidate (use content hashing in filenames)\n}));\n\n\u002F\u002F Cache-Control for API responses\n\u002F\u002F Only for explicitly public, non-personalized data; private responses need a separate policy.\nres.set('Cache-Control', 'public, max-age=300'); \u002F\u002F 5 minutes\n```\n\n## Performance Budget\n\nSet representative, product-specific budgets; these are illustrative starting points:\n\n```\nJavaScript bundle: \u003C 200KB gzipped (initial load)\nCSS: \u003C 50KB gzipped\nImages: \u003C 200KB per image (above the fold)\nFonts: \u003C 100KB total\nAPI response time: \u003C 200ms (p95)\nTime to Interactive: \u003C 3.5s on 4G\nLighthouse Performance score: ≥ 90\n```\n\n**Enforce in CI:**\n```bash\n# Bundle size check\nnpx bundlesize --config bundlesize.config.json\n\n# Lighthouse CI\nnpx lhci autorun\n```\n\n## See Also\n\nFor detailed performance checklists, optimization commands, and anti-pattern reference, see `references\u002Fperformance-checklist.md`.\n\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"We'll optimize later\" | Performance debt compounds. Fix obvious anti-patterns now, defer micro-optimizations. |\n| \"It's fast on my machine\" | Your machine isn't the user's. Profile on representative hardware and networks. |\n| \"This optimization is obvious\" | If you didn't measure, you don't know. Profile first. |\n| \"Users won't notice 100ms\" | Measure whether latency affects this product's users; no universal conversion multiplier applies. |\n| \"The framework handles performance\" | Frameworks prevent some issues but can't fix N+1 queries or oversized bundles. |\n\n## Red Flags\n\n- Optimization without profiling data to justify it\n- N+1 query patterns in data fetching\n- List endpoints without pagination\n- Images without dimensions, lazy loading, or responsive sizes\n- Bundle size growing without review\n- No performance monitoring in production\n- `React.memo` and `useMemo` everywhere (overusing is as bad as underusing)\n\n## Verification\n\nAfter any performance-related change:\n\n- [ ] Before and after measurements exist (specific numbers)\n- [ ] The specific bottleneck is identified and addressed\n- [ ] Core Web Vitals are within \"Good\" thresholds\n- [ ] Bundle size hasn't increased significantly\n- [ ] No N+1 queries in new data fetching code\n- [ ] Performance budget passes in CI (if configured)\n- [ ] Existing tests still pass (optimization didn't break behavior)\n\n## Limitations\n\n- Use this skill only when the task clearly matches its upstream source and local project context.\n- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.\n- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.\n\nAssess Core Web Vitals field distributions at the 75th percentile, segmented by device where appropriate. RUM collection requires privacy\u002Fdata-retention scope. Shared caches must be keyed by tenant\u002Fauthorization context or restricted to genuinely global configuration; never cache private API data publicly. Validate page inputs and use stable unique ordering\u002Fcursor pagination for mutable datasets. TTI is a historical metric, not a current Core Web Vital.\n",{"name":5,"risk":35,"source":54,"license":14,"date_added":55,"description":7,"source_repo":56,"source_type":40,"license_source":57},"https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Ftree\u002Fmain\u002Fskills\u002Fperformance-optimization",1782864000000,"addyosmani\u002Fagent-skills","https:\u002F\u002Fgithub.com\u002Faddyosmani\u002Fagent-skills\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-performance-optimization",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-11 14:20:43",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add boisenoise\u002Fskills-collections --skill performance-optimization",{"tool":70,"command":71},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill performance-optimization",{"tool":73,"command":74},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill performance-optimization","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-performance-optimization\u002FSKILL.md",true,[],[79,105,128,153,172,195],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":83,"licenseFileUrl":84,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":49},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[48,88,89,90,91,92,93,94,95,96,97,98,99,100,101,35,102,103,104,28,26],"access","web access","official","development","browser","search","data","Tools","read","fetch","only","youtube","free tools","platform","free","cover","normal",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":83,"licenseFileUrl":109,"sourceHtmlUrl":110,"categories":111,"keywords":115,"publishedAt":49},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[112],{"categoryNo":113,"categoryName":114,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[107,116,117,27,90,91,46,95,118,119,120,121,42,122,123,35,124,125,126,127,26],"MCP","cli","Budget","credentials","team","catalog","call","discover","external tools","with","scoped","blob",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":83,"licenseFileUrl":132,"sourceHtmlUrl":133,"categories":134,"keywords":140,"publishedAt":49},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[130,27,90,46,45,141,142,143,144,145,35,146,147,148,125,149,150,151,152,127,107,26],"email","enrichment","business","evidence","phone","ranking","post","job description","for","person","candidate","reason",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":83,"licenseFileUrl":157,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":49},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[161,162,163,27,90,46,164,165,45,166,118,167,168,169,144,35,170,171,127,107,26],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":83,"licenseFileUrl":176,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":49},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[180,181,27,182,90,183,46,184,185,186,187,188,35,189,190,191,192,193,194,127],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":83,"licenseFileUrl":199,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":49},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[203,204,205,27,90,46,206,207,143,208,209,35,210,211,212,213,214,215,216,127],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]