Jump to

Skill · Performance optimization

Performance optimization.

Diagnose web performance and fix the worst offender first.

Diagnose web performance issues and produce a remediation plan, anchored to Core Web Vitals. Three metrics carry most of the weight for both user experience and search: LCP, INP, and CLS. Beyond them sit TTFB, bundle size, images, fonts, and third-party scripts, which often dominate the budget.

This skill is for when performance itself is the goal, deeper than the checks in QA or technical SEO. The discipline is measuring first, then fixing the worst offender rather than the easiest one.

Audience: front-end and platform engineers fixing Core Web Vitals, reducing bundle size, or running a pre-launch or annual performance pass.

View the skill on GitHubBrowse the full catalog

The framework

Three vitals carry most of the weight.

LCP, INP, and CLS drive both user experience and search. Identify which is failing and focus there first.

  1. 01LCP (Largest Contentful Paint): time until the largest visible element renders. Good under 2.5 seconds. Server-render the LCP element, optimize and preload its image, and cut render-blocking resources.
  2. 02INP (Interaction to Next Paint): responsiveness to interactions, replacing FID. Good under 200ms. Break long tasks into chunks, memoize expensive work, debounce high-frequency handlers, and keep the DOM under about 1500 elements.
  3. 03CLS (Cumulative Layout Shift): how much the page jumps as it loads. Good under 0.1. Set width and height on media, reserve space for late-loading content, and preload critical fonts.

The rest of the budget

Five areas beyond the Core Web Vitals.

The vitals are the headline metrics; these are where the work usually lands once the worst offender is identified.

  1. 01

    Time to First Byte

    Server response time, ideally under 800ms; a bad TTFB makes everything worse. Cache queries, use a CDN, pre-render, and watch serverless cold starts.

  2. 02

    Bundle size

    Initial JS under about 170KB compressed. Tree-shake imports, code-split per route, lazy-load below the fold, and replace heavy libraries.

  3. 03

    Image optimization

    Images are 60 to 80% of page weight. Modern formats, responsive srcset, lazy-load below the fold, explicit dimensions, and never lazy-load the LCP image.

  4. 04

    Font loading

    Self-host fonts, preload the critical ones, use font-display thoughtfully, subset to drop unused glyphs, and provide a matching system fallback.

  5. 05

    Third-party scripts

    Often dominate the performance budget. Audit each for whether it is required, can defer, or can run off the main thread.

How to optimize

Measure first; field data is the source of truth.

Measure before optimizing. Performance work without a baseline is theater, so capture the current Core Web Vitals from Lighthouse, WebPageTest, or real-user monitoring first, then fix the single worst offender rather than shaving milliseconds off a metric that already passes.

Field data is the source of truth. Lighthouse runs in idealized lab conditions that are useful for diagnosis, but a great lab score with poor real-user metrics means the test does not match how users actually load the page. Check the Chrome User Experience Report and real-user monitoring, not only the on-demand scan.

Not every byte is equal. A render-blocking 100KB script is worse than a deferred 500KB one, and execution time matters more than raw size, so a small bundle that takes five seconds to parse loses to a larger one that runs fast. And own the third parties: they run on your domain in your users' eyes, and roughly half of performance issues trace back to them.

Reference files

Three references that go alongside the SKILL.md.

  • references/audit-template.md

    The full performance audit report template.

  • references/optimization-checklist.md

    A quick-reference checklist of common optimizations by priority.

  • references/optimization-playbook.md

    A symptom-to-fix playbook for the common LCP, INP, and CLS problems.

Browse all reference files on GitHub

Bridges to other skills

When the goal is something other than speed.

This skill is for performance in depth. These cover the lighter checks and the adjacent concerns it is often confused with.

  • Lighter checks

    qa-testing

    Runs a basic performance pass as part of general QA. Reach for this skill when a Lighthouse score in the full QA tier turns out to need real investigation.

  • Crawl and index

    seo-technical

    Core Web Vitals are one page-experience signal there, alongside crawlability and indexing. Performance optimization owns the vitals in depth; technical SEO owns whether the page ranks at all.

  • General bugs

    code-review-web

    Reviewing code for correctness and stack anti-patterns is a different lens. A slow render is a performance problem; a wrong render is a code-review one.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What are the three Core Web Vitals?
LCP (Largest Contentful Paint), the time until the largest visible element finishes rendering, good under 2.5 seconds. INP (Interaction to Next Paint), the responsiveness to user interactions, which replaces FID, good under 200ms. And CLS (Cumulative Layout Shift), how much the page jumps as it loads, good under 0.1. The three carry most of the weight for both user experience and search, so the audit identifies which one is failing and focuses there first.
What should I fix first?
The worst offender. Identify which of LCP, INP, or CLS is failing and concentrate there, because over-optimizing TTFB by 10ms while CLS sits at 0.4 fixes the wrong thing. Measure to establish the baseline, fix one thing at a time so the impact is measurable, re-measure after each major change, and iterate, because performance is rarely solved in a single pass.
Why measure field data instead of only Lighthouse?
Because Lighthouse runs in idealized lab conditions, while field tools (the Chrome User Experience Report, real-user monitoring, and Search Console's Core Web Vitals report) reflect what users actually experience. A great Lighthouse score paired with bad real-user metrics means the test conditions do not match users. Lab tools are useful for diagnosis, but field data is the source of truth for what to prioritize.
How big should the JavaScript bundle be?
Aim for initial JS under about 170KB compressed for typical pages and lazy-loaded chunks under about 100KB each. But execution time matters more than raw size: a small bundle that takes five seconds to parse and run is worse than a larger one that executes fast. Tree-shake imports, code-split per route, lazy-load below-the-fold components, replace heavy libraries with lighter ones, and use a build-time bundle analyzer to find the bloat.
What about third-party scripts?
They often dominate the performance budget, and a common pattern is that roughly half of performance issues come from third parties: analytics, ads, and chat widgets. Audit each one for whether it is truly required, whether it can load after page interaction, whether it can run off the main thread, and whether a lighter alternative exists. Third parties run on your domain in your users' eyes, so own them rather than blaming the tag.