← Back to Web app developers
See how it helps
Faster websites with measured results
Finds the real causes of slow page loading and delayed interactions, then checks improvements using comparable before-and-after measurements.
web-performance
Team members using this skill
When is it useful?
Use when pages feel slow, images shift content or a heavy feature delays the first useful screen.
What does it help you do?
- Measures a baseline and identifies whether images, scripts, fonts or server response dominate the delay.
- Prioritizes important content while deferring secondary assets and reducing unnecessary downloads.
- Checks interaction responsiveness, layout stability and delivery settings after the change.
Try asking this
Investigate our slow mobile landing page. Measure it before and after resizing images and deferring secondary scripts, and confirm that the main content no longer shifts. Use the same device profile and network conditions for both measurements. Report the main-content load and layout-shift changes, including any trade-off in later interaction.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Web Performance
Measure first
- Record a baseline before changing anything: Lighthouse (mobile, throttled) on a production build, plus field data if the repo collects it (RUM, CrUX, web-vitals).
- Same pages, same settings, several runs; compare medians. Report before and after numbers.
- Find the real bottleneck (Performance panel, network waterfall, bundle analyzer) before optimizing.
Targets (75th percentile)
- LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1. Also watch TTFB and total JavaScript shipped.
LCP
- Identify the LCP element. If it is an image: never lazy-load it, add fetchpriority="high", preload it if discovered late, serve the right size.
- Cut render-blocking resources: inline small critical CSS, defer non-critical CSS and scripts (defer, async, type=module).
- Reduce server time with caching and a CDN; do not render primary content client-side only.
Images
- AVIF/WebP with fallback, through the repo's image pipeline or framework component (next/image, nuxt/image, astro:assets) when present.
- Responsive srcset and sizes; never ship a 3000px image into a 400px slot.
- Always set width and height (or aspect-ratio) to reserve space.
- loading="lazy" and decoding="async" for below-the-fold images only.
Fonts
- Self-host or preconnect; preload only the one or two fonts used above the fold. WOFF2, subset where possible.
- font-display: swap or optional; use fallback metric overrides (size-adjust) to limit shift.
JavaScript
- Split code by route; lazy-load heavy, rarely used components and libraries with dynamic import.
- Remove unused dependencies, prefer smaller alternatives, keep imports tree-shakeable (no whole-library imports).
- INP: break long tasks (> 50 ms), keep input handlers light, debounce, move heavy work off the main thread, avoid layout thrashing.
- Load third-party scripts late (on interaction or idle) and only on pages that need them.
CLS
- Reserve space for images, embeds, ads and late content. Never insert content above existing content except in response to user input.
- Animate transform and opacity, not layout properties.
Caching and delivery
- Hashed static assets: Cache-Control: public, max-age=31536000, immutable. HTML: no-cache or a short max-age with revalidation.
- Brotli/gzip compression and HTTP/2+ where the repo controls server config.
- Preconnect to critical third-party origins; remove unused preloads.
Before you finish
- Baseline and after measurements recorded with the same method.
- LCP element loads early and is not lazy-loaded.
- Images sized, dimensioned and in modern formats.
- No new layout shift.
- Bundle size not increased without reason; heavy code split out.
- Cache headers correct for hashed assets versus HTML.
Included files 1
SKILL.md