Your app is correct, secure, and reliable. It can still fail two ways nobody warned you about: it loads so slowly that people leave before they see it, and it locks out anyone who cannot use a mouse or read a small gray label. This chapter gets you fast enough that users stay, and reachable by everyone, both measured rather than guessed.
13.2.1Fast enough that users stay
Speed is retention, not vanity. Every extra second before your app responds, more people give up and leave, and the ones who stay trust it less. The industry yardstick is Core Web Vitals: three numbers for how fast the page loads, how quickly it reacts to a tap, and whether it jumps around while loading.
These are the same measures search engines rank on, so they pay off twice. You set speed targets back when you wrote your quality bars. This chapter is where you actually hit them.
13.2.2Measure before you optimize
The one rule that saves you the most wasted effort: never guess at what is slow. Slowness rarely lives where it feels like it does, and a day spent optimizing the wrong thing moves nothing. Run an audit first, fix the single biggest offender it names, then measure again.
The tool for this is Lighthouse, built into your browser. It scores the page and points at the real problem, almost always one from a short list you can hand your agent as an audit:
Performance audit, usual suspects:
[ ] Images too large or not sized: compress, resize, lazy-load
[ ] Too much JavaScript: ship less, load heavy parts on demand
[ ] A query run once per row (the N+1 trap): fetch in one go
[ ] No caching: serve repeat reads from cache, not recompute
[ ] Fonts or third-party scripts blocking the first paint
Fix the top hit, measure again, and repeat until you land inside your targets.
13.2.3Reachable by everyone
Accessibility means the app works for people who cannot use it the way you do: moving by keyboard instead of a mouse, hearing the page through a screen reader, or needing high contrast to read it at all. This is not a favor. It is a published standard, WCAG, and in many places a legal requirement.
The lift is smaller than it sounds, because your agent already knows the rules. Ask it for semantic markup, a label on every control, a sensible focus order, and text that meets contrast, and most of the work is already done.
13.2.4Test it like a real user
Both of these are testable, so test them the way a real user would hit them. Run the audit for a score, then put your mouse down and try to reach every button, form, and menu by keyboard alone. If you get stuck, so does someone who has no other way in.
Then let your agent do the heavy lifting. This prompt runs the full audit and fixes what hurts most:
Act as a senior engineer auditing my app for speed and
accessibility. Run a performance and accessibility audit,
then list the biggest issues in order of user impact.
For each, name the cause and the smallest fix, and fix
the top few. Confirm the whole app works by keyboard and
meets AA contrast. Measure again and show before/after.
Do not chase a perfect score, chase real problems.
My app's slow or hard-to-use spots:
Do this now: paste the prompt, let your agent measure and fix the top issues, then walk the app once by keyboard yourself. Fast and reachable for everyone is what keeps the users your growth depends on.
