Aie Web Performance

---
name: aie-web-performance
description: Audits and fixes web page load performance. Analyzes images, CSS, JavaScript, fonts, and third-party assets, then produces a prioritized before/after report with concrete optimization steps and copy-paste code. Targets Core Web Vitals (LCP, INP, CLS) and Lighthouse scores. Stack-agnostic — plain HTML, WordPress, React, Next.js, Vite, Astro, or a hosted builder; uses free tools only (Lighthouse, ImageMagick, cwebp/AVIF, PurgeCSS, bundle analyzers). Trigger on "my site is slow," "speed up my site," "improve page load," "optimize performance," "Core Web Vitals," "LCP/INP/CLS," "Lighthouse score," "reduce bundle size," "optimize images," "why is my site slow," or "performance audit."
---

# Web Performance Optimizer

Find what makes a page slow, then fix it. Produce a prioritized report with real byte savings and ready-to-use code — not generic advice.

## Why it matters

Speed affects conversion, bounce rate, and search ranking. Google uses Core Web Vitals as a ranking signal (https://developers.google.com/search/docs/appearance/page-experience), and field data consistently ties faster pages to higher engagement and revenue. Optimize the metrics that reflect real user experience: LCP, INP, and CLS.

## When to use this skill

The user says the site feels slow, has poor Lighthouse or Core Web Vitals scores, or wants to trim page weight. Works from a live URL or from a local project directory / source files.

## Inputs to gather

- **URL or local path** to the site.
- **Stack** if known (plain HTML, WordPress, React, Next.js, Vite, Astro, etc.) — it changes which build fixes apply.
- **Target devices/browsers** and any specific concern (slow mobile, janky scroll, layout jump).

## Audit procedure

Measure first, then attribute weight to the biggest offenders. For the full checklists and the exact commands and code snippets, read `reference/optimization-guide.md`.

1. **Baseline** — run Lighthouse (or read PageSpeed Insights field data) and record LCP, INP, CLS, FCP, TBT/TTI, and total transfer size. Note the LCP element specifically.
2. **Images** — usually 50-80% of page weight. Check dimensions vs. displayed size, compression, modern formats (AVIF/WebP), `srcset`/`sizes`, and lazy loading for below-the-fold images (never lazy-load the LCP image).
3. **CSS** — minification, critical-CSS inlining for above-the-fold, unused-selector removal, and avoiding layout-triggering animations (prefer `transform`/`opacity`).
4. **JavaScript** — the most expensive resource. Check bundle size, code splitting, `defer`/`async`, tree-shaking, and unnecessary polyfills. Reducing main-thread work is the main lever for INP.
5. **Fonts** — `font-display: swap`, preload critical fonts, subsetting, and variable fonts to replace multiple files. Prevents invisible-text delays and font-swap CLS.
6. **Preload / preconnect / prefetch** — preload the LCP resource, preconnect to critical third-party origins, prefetch likely next-page assets. Don't over-preload.
7. **Delivery** — confirm Brotli/gzip compression, HTTP/2 or HTTP/3, caching headers, and CDN use.

## Core Web Vitals targets (good thresholds)

Source: https://web.dev/articles/vitals

- **LCP** (Largest Contentful Paint) — < 2.5s
- **INP** (Interaction to Next Paint) — < 200ms  *(replaced FID as a Core Web Vital in March 2024 — https://web.dev/blog/inp-cwv-launch)*
- **CLS** (Cumulative Layout Shift) — < 0.1
- Supporting: FCP < 1.8s, TBT low, Lighthouse Performance 90+.

## Priority of fixes

**High impact (do first)**
1. Image optimization — 30-50% byte reduction typical.
2. JS minification + code splitting — 20-40% reduction, big INP win.
3. Unused CSS removal — 20-60% reduction.
4. Font-display + subsetting — faster text render, less CLS.
5. Reserve space for images/embeds/ads (width+height or aspect-ratio) — kills CLS.

**Medium impact**
- Critical CSS inlining, defer/async scripts, preload the LCP resource, Brotli/gzip.

**Lower impact (situational)**
- Service-worker caching, CDN tuning, HTTP/3.

## Output format

```
PERFORMANCE REPORT — {url}
Date: {date}

CORE WEB VITALS (before)
  LCP {x}s   INP {x}ms   CLS {x}
  Lighthouse Performance: {n}/100
  Total transfer: {x} KB   |  LCP element: {selector}

TOP BOTTLENECKS (ranked by impact)
  1. {issue} — est. saving {x} KB / {x}ms — {fix}
  ...

FIXES BY AREA
  Images    ...  (with commands/HTML)
  CSS       ...
  JavaScript...
  Fonts     ...
  Delivery  ...

PROJECTED AFTER
  LCP ~{x}s   INP ~{x}ms   CLS ~{x}   (state assumptions)

VERIFICATION
  Re-run Lighthouse; confirm field data in PageSpeed Insights / CrUX after ~28 days.
```

## Guardrails

- Optimizations must preserve functionality — flag anything that could change behavior.
- Field data (real users, CrUX) is the source of truth; lab data (Lighthouse) is a proxy. Say which one a number comes from.
- Don't invent savings numbers — label estimates as estimates and show the reasoning.
- All recommended tools are free: Lighthouse CLI, ImageMagick, `cwebp`/`avifenc`, PurgeCSS, and framework bundle analyzers.