Frontend performance
Skill MartinOlivero/saas-builder/skills/frontend-performance
This skill should be used when a frontend feels slow, fails Core Web Vitals, has a large bundle, or needs performance optimization. Trigger phrases include "make it faster", "improve performance", "Core Web Vitals", "LCP", "INP", "CLS", "reduce bundle size", "code splitting", "lazy load", "it's slow to load", "optimize images", "bundle too big", "Lighthouse score". It targets the real Core Web Vitals thresholds with stack-specific fixes for React + Vite + Vercel.From its SKILL.md
npx -y skills add MartinOlivero/saas-builder --skill frontend-performanceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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.
SKILL.md
3.6 KB, 831 tokens by cl100k_base, as published. Nobody here has run it
Frontend Performance
This skill makes a React + Vite app hit the Core Web Vitals bar — the same metrics Google uses for ranking and that users feel as "fast." It optimizes against real thresholds, not vibes.
Analogy: shipping a fast app is like packing for a flight. You don't drag every possession to the gate — you pack the carry-on with what's needed now (above-the-fold) and check the rest (lazy-load below-the-fold). Overpacking the initial bundle is what makes the page heavy.
The targets (field data, 75th percentile)
- LCP < 2.5s — largest content paint.
- INP < 200ms — interaction to next paint (replaced FID in March 2024).
- CLS < 0.1 — cumulative layout shift.
Discovery (max 3 questions, only if unknown)
- What's slow — first load (LCP/bundle) or interactions (INP)?
- Do you have field data (real users) or only a Lighthouse lab score?
- What's the biggest payload — JS bundle, images, or fonts?
Step 1 — Measure real users first
Install web-vitals (attribution build) and report onLCP/onINP/onCLS to your analytics. Lab tools (Lighthouse) miss field INP — optimize against real-user data, not just a local score. The Vercel Speed Insights package gives this with no backend.
Step 2 — Cut the bundle
- Route-level code splitting with
React.lazy+<Suspense>. Lazy-load below-the-fold and modal/dialog components so the initial bundle ships only above-the-fold code. - Split vendors in
vite.config.tsviabuild.rollupOptions.output.manualChunks(separatereact/react-dom, charts, icons) for long-term cache hits. - Keep the largest initial chunk under ~200KB gzipped. Treat Vite's "chunks larger than 500KB" warning as a budget failure, not a suggestion.
- Enforce the budget in CI with
size-limit; fail the build on regression. Inspect withvite-bundle-visualizer. - Tree-shake via named imports; prefer
lucide-reactover monolithic icon packs.
Step 3 — Fix LCP
- Preload the LCP image:
<link rel="preload" fetchpriority="high">. Never lazy-load the hero. - Serve images as AVIF/WebP through Vercel image optimization; always set explicit
width/height(oraspect-ratio) to prevent CLS. - Self-host or
preconnectfonts; usefont-display: swap.
Step 4 — Fix INP
- Break up long tasks; defer non-critical JS.
- Use
useTransition/startTransitionfor non-urgent React updates so input handlers stay responsive. - Avoid synchronous work inside input/click handlers.
Step 5 — Fix CLS
- Reserve space for images, ads, and embeds (explicit dimensions /
aspect-ratio). - Don't inject content above existing content after load.
- Animate only
transform/opacity(GPU-composited) — neverwidth/height/top/left, which trigger layout and hurt both CLS and INP.
Output
Deliver: a before/after of the three vitals (or the targets if no baseline), the concrete vite.config.ts chunk config, the React.lazy split points, the image/font fixes, and the CI bundle-budget step.
Reference
GoogleChrome/web-vitals (~8.5k⭐), web.dev Core Web Vitals, Vite build docs (manualChunks), Vercel image optimization, size-limit.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 1 of the 12 instructions most design frontend skills give in 831 tokens
Counted across 1,179 of the 2,086 authors here whose files we hold, read 2026-09-06
- Commit to a bold aesthetic directionin 31 of 1179, across 24 files
- Prefer component composition over inheritancein 28 of 1179, across 14 files
- Animate only transform and opacity propertieshere, and in 27 of 1179, across 22 files
- Memoize expensive computations with useMemoin 26 of 1179, across 13 files
- Use semantic HTML elementsin 24 of 1179, across 23 files
- Virtualize long lists for performancein 21 of 1179, across 10 files
- Use CSS variables for design tokensin 20 of 1179, across 14 files
- Implement loading, empty, and error statesin 20 of 1179
- Lazy load heavy components with Suspensein 19 of 1179, across 8 files
- Respect prefers-reduced-motion media queriesin 18 of 1179, across 10 files
- Prioritize CSS-only animations for HTMLin 18 of 1179, across 16 files
- Use compound components for related UI elementsin 18 of 1179, across 7 files
Said here and by no other author read
- measure real user data using web-vitals
- lazy load below-the-fold components with React.lazy
- split vendor chunks in vite.config.ts
- keep initial bundle under 200KB gzipped
- enforce bundle budget in CI with size-limit
- serve images as AVIF or WebP
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.