Skills / Make it fast
Make it fast
Make a slow site measurably faster. Lighthouse first, then the real fixes (usually images, fonts, and render-blocking code), then re-measure. Use when they say "my site is slow", "improve my Lighthouse score", or after a site gains real images.
Use this skill. Nothing to install.
Don't have an agent? · Raw file: skills/make-it-fast.md
Watch the first two minutes
This is how a session goes, measurement first. Click through it.
Scripted example of a real session.
Think a slow site means a rewrite?
It almost never does. Guessing at performance work wastes an afternoon, so this skill refuses to touch anything before the report runs. On a static site the culprits come from a short list: images that are far larger than the size they display at, webfonts loaded carelessly, and scripts that block rendering. The report says which of those you actually have and roughly what fixing each would save, and you fix in that order, re-measuring as you go.
What you end up with
Before and after screenshots of the same report, saved in the repo, and the ability to say which fix bought what:
PageSpeed Insights · mobile · example.com
BEFORE AFTER
performance 43 96 1
LCP 6.8 s 1.9 s 2
CLS 0.31 0.02
page weight 4.6 MB 310 KB
what each fix bought: 3
photos resized + WebP most of the weight
width/height on images the jumping stopped
script tags deferred faster first paint
- Numbers, twice. One report before touching anything, one after. The pair is the receipt, and it belongs in the repo next to the code that earned it.
- The two that matter get one-line meanings. LCP is how long the biggest thing on screen takes to show. CLS is how much the page jumps around while loading. The skill explains each as it comes up, so the report stops being alphabet soup.
- Cause mapped to effect. Because you re-measured after every fix, you can say which change bought which improvement. That sentence is resume-grade: build-resume turns it into a line like "cut page load from 7 seconds to 2".
Questions people actually ask
Do I need to score 100?
No. The skill's own stopping rule is that a static site scoring 90 or so on mobile is done. The last few points cost the most effort and buy visitors the least, so it tells you to stop rather than chase them.
What is usually the problem?
Images, almost always. Full-size phone photos on a page that displays them small account for most of a bad score on a first site. Fonts and render-blocking scripts are the usual runners-up, and the report ranks your specific list.
Do the tools cost anything?
No. PageSpeed Insights runs in the browser, Lighthouse ships inside Chrome DevTools, and squoosh.app re-encodes images for free. There is nothing to buy in this skill.
Will the fixes change how my site looks?
Mostly no. An image resized to the size it displays at looks identical where it sits. The one visible decision is fonts, and it stays yours: keeping a webfont with two weights and font-display swap is fine, and system fonts are a real option the skill offers rather than imposes.
How often should I re-run the report?
Whenever the site meaningfully changes, especially when it gains images, since that is how most sites get slow again. You'll know how by then: re-running it yourself is part of this skill's definition of done.
Where to go from here
Report habit formed? It carries directly into these:
Curious? Read the full skill — the exact instructions your agent gets
---
name: make-it-fast
category: web
description: Make a slow site measurably faster. Lighthouse first, then the real fixes (usually images, fonts, and render-blocking code), then re-measure. Use when they say "my site is slow", "improve my Lighthouse score", or after a site gains real images.
---
# make-it-fast
Speed up a live site with someone, and the rule is:
measure before touching anything. Guessing at performance work wastes
an afternoon; the report says exactly what is slow, and a static site
usually has one or two real problems. Fixing those is an hour, and
the before/after numbers become a resume-grade receipt.
## Measure first
1. Run PageSpeed Insights on the live URL (or Lighthouse in Chrome
DevTools — same engine; PageSpeed adds real-user data if the site
has traffic). Use the mobile result; it is the harsh one and the
one that reflects most visitors.
2. Save the "before": screenshot the score and the numbers for LCP,
CLS, and total page weight. Explain each in one line as it comes
up — LCP is how long the biggest thing takes to show, CLS is how
much the page jumps around while loading.
3. Read the Opportunities list together and pick the top two or
three by estimated savings. Agree on a target tied to the real problem,
such as reducing image weight or LCP, rather than treating one synthetic
score as proof. Ignore low-impact findings for now.
## Fix what it flagged
Work down their list, deploy, re-measure after each fix so they see
cause and effect. The usual suspects:
- Images, almost always the whole problem. Resize to the largest
size actually displayed, re-encode (WebP via `squoosh.app` or a
CLI, whichever they prefer), set `width` and `height` attributes
so the page stops jumping, add `loading="lazy"` to images below
the fold. A 4 MB phone photo becoming 80 KB is the day's win.
- Fonts. System fonts cost zero and look fine — that is a real
option, their call. If they keep a webfont: two weights maximum,
`font-display: swap` so text never waits invisible.
- Render-blocking code. Small CSS can be inlined; script tags get
`defer`; anything unused gets deleted. Check for libraries loaded
out of habit — a static site rarely needs any.
## Done
- Before and after screenshots of the same report, saved in the repo
- The agreed metric improved on repeated runs, and they can say which fix
changed what; record normal run-to-run variation instead of claiming false
precision
- No fix broke anything: click through the live site on a phone
- They know how to re-run the report themselves next time the site
changes
The receipts feed build-resume ("cut page load from Xs to Ys"), and
the audit habit carries straight into accessibility-pass, which
lives in the same Lighthouse report.