Web performance optimization
Personal skills collection for Claude
npx -y skills add Lu1sDV/skillsmd --skill web-performance-optimizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when improving Lighthouse scores, reducing page load times, debugging performance bottlenecks, optimizing Core Web Vitals for SEO, or implementing modern browser performance APIs like View Transitions and Speculation Rules
SKILL.md
6.9 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it
Web Performance Optimization
Systematic approach to diagnosing and fixing web performance issues across loading, rendering, and runtime.
Business Impact: 1 second delay = 7% conversion loss. 0.1s improvement = 8% increase in conversions.
When to Use
- Lighthouse score below 90 or page speed regression
- Slow LCP (>2.5s), high CLS (>0.1), poor INP (>200ms), high TBT
- Large JavaScript bundles, render-blocking resources
- Layout shifts, jank, slow Time to Interactive (TTI)
- Setting up performance monitoring or budgets
- Implementing View Transitions, Speculation Rules, Server Components, Islands Architecture
Quick Reference
| Metric | Target | Tool |
|---|---|---|
| LCP | < 2.5s | Lighthouse, CrUX |
| CLS | < 0.1 | Lighthouse, Layout Shift Debugger |
| INP | < 200ms | Chrome DevTools Performance |
| TBT | < 200ms | Lighthouse |
| TTFB | < 800ms | WebPageTest, curl -w |
| FCP | < 1.8s | Lighthouse |
Which Reference Do I Need?
digraph perf_decision {
rankdir=TB;
node [shape=box];
problem [label="What's the problem?" shape=diamond];
qw [label="quick-wins.md\n1hr/1day/1week optimizations"];
cwv [label="core-web-vitals.md\nMetric-specific debugging"];
opt [label="optimization-techniques.md\nJS/CSS/image/caching/backend"];
mod [label="modern-patterns-2025.md\nView Transitions, Speculation Rules, RSC"];
fw [label="framework-specific.md\nNext.js, React, Vue, Astro, Svelte"];
mon [label="monitoring.md\nLighthouse CI, RUM, APM"];
problem -> qw [label="need fast ROI"];
problem -> cwv [label="Core Web Vitals failing"];
problem -> opt [label="bundle/backend/caching"];
problem -> mod [label="cutting-edge patterns"];
problem -> fw [label="framework-specific"];
problem -> mon [label="no visibility"];
}
Performance Budget
| Resource | Budget | Rationale |
|---|---|---|
| Total page weight | < 1.5 MB | 3G loads in ~4s |
| JavaScript (compressed) | < 300 KB | Parsing + execution time |
| CSS (compressed) | < 100 KB | Render blocking |
| Images (above-fold) | < 500 KB | LCP impact |
| Fonts | < 100 KB | FOIT/FOUT prevention |
| Third-party | < 200 KB | Uncontrolled latency |
Core Web Vitals at a Glance
| Metric | Target | Lighthouse Weight | Key Optimization |
|---|---|---|---|
| LCP (Largest Contentful Paint) | <2.5s | 25% | Optimize images, preload critical resources |
| INP (Interaction to Next Paint) | <200ms | 30% | Reduce JavaScript, break up long tasks |
| CLS (Cumulative Layout Shift) | <0.1 | 25% | Reserve space, optimize fonts |
| TBT (Total Blocking Time) | <200ms | 30% | Code splitting, defer non-critical JS |
| FCP (First Contentful Paint) | <1.8s | 10% | Eliminate render-blocking resources |
-> See core-web-vitals.md for debugging workflows per metric
Quick Wins (by time investment)
| Time | Optimization | Impact |
|---|---|---|
| 1hr | loading="lazy" on below-fold images | 40-60% weight reduction |
| gzip/brotli compression | 70-80% transfer reduction | |
rel="preconnect" for critical origins | 100-500ms savings | |
width/height on images | Prevents CLS | |
| 1day | Route-based code splitting | 30-50% bundle reduction |
LCP image: fetchpriority="high" + WebP/AVIF | 200-400ms LCP improvement | |
| Basic service worker | Instant repeat visits | |
| 1wk | Full HTTP + service worker caching | Reduced server load |
| Tree shaking + dead code elimination | 40-60% bundle reduction | |
| Lighthouse CI + RUM monitoring | Catch regressions |
-> See quick-wins.md for implementation details
Runtime Performance Checklist
- Batch DOM reads/writes to avoid layout thrashing
- Debounce scroll/resize handlers (100ms+)
- Use
requestAnimationFramefor animations (notsetInterval) - Virtualize long lists (1000+ items):
content-visibility: autoorreact-window/@tanstack/virtual - Avoid synchronous third-party scripts
-> See optimization-techniques.md for backend, image, JS, CSS, and caching techniques
Modern Patterns (2025)
| Pattern | Key Benefit | Complexity |
|---|---|---|
| View Transitions | Smooth page transitions, zero JS cost | Low |
| Speculation Rules | 0ms navigation via prerendering | Low |
| Server Components | Zero-bundle server-only components | Medium |
| Priority Hints | fetchpriority="high" for LCP | Low |
| content-visibility | 7x faster rendering for long pages | Low |
| Islands Architecture | 90-99% less JS shipped | High |
-> See modern-patterns-2025.md for implementation details
Red Flags
Stop and reconsider if:
- Optimizing without baseline measurement
- Focusing only on Lighthouse score (ignoring field/RUM data)
- Ignoring mobile performance (53% abandon after 3s)
- Loading all resources eagerly (no lazy loading)
- No caching strategy implemented
- Third-party scripts loaded synchronously
- Missing performance monitoring/budgets
- Layout thrashing in scroll/resize handlers
- Long tasks (>50ms) blocking main thread
Real-World Impact
- Pinterest: 40% faster perceived wait = 15% more sign-ups + 15% more SEO traffic
- Zalando: 0.1s improvement = 0.7% revenue increase
- AutoAnything: 50% faster load = 12-13% sales increase
- Core Web Vitals are Google ranking factors (June 2021+)
Common Mistakes
| Mistake | Fix |
|---|---|
| Optimizing before measuring | Always profile first with Lighthouse/DevTools |
| Lazy-loading above-the-fold images | Only lazy-load below-fold; eager-load LCP image |
| Bundling unused CSS/JS | Use coverage tab in DevTools, then code-split |
Missing width/height on images | Causes CLS — always set dimensions or use aspect-ratio |
| Blocking render with synchronous JS | Use defer or async on non-critical scripts |
| Ignoring server response time (TTFB) | Frontend optimization can't fix a slow backend |
References
- Quick Wins - Time-boxed optimizations with ROI ratings
- Core Web Vitals - LCP, INP, CLS debugging workflows
- Optimization Techniques - Backend, image, JS, CSS, caching
- Modern Patterns 2025 - View Transitions, Speculation Rules, RSC, Islands
- Framework Patterns - Next.js, React, Vue, Vite, Astro, SvelteKit
- Monitoring - Lighthouse CI, RUM, APM, performance budgets
Gives 0 of the 12 instructions most performance cost skills give in ~1.8k tokens
Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07
- keep skill files under 500 linesin 82 of 803, across 16 files
- use imperative form in instructionsin 80 of 803, across 9 files
- draft assertions while test runs are in progressin 75 of 803, across 9 files
- create two to three realistic test promptsin 74 of 803, across 9 files
- write skill descriptions to be pushyin 72 of 803, across 7 files
- save test cases to evals jsonin 72 of 803, across 6 files
- ask questions about edge cases and input formatsin 72 of 803, across 7 files
- save timing data immediately when runs completein 70 of 803, across 5 files
- include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
- launch all test runs in a single turnin 69 of 803, across 3 files
- capture intent before writing a skillin 67 of 803, across 1 file
- import directly instead of barrel filesin 52 of 803, across 15 files
Said here and by no other author read
- defer or async non-critical scripts
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.