GitHub

Accessibility & Developer Experience

Accessibility IS Performance

Accessibility and performance are not competing concerns — they’re deeply complementary. Accessible sites tend to be faster because they use semantic HTML (less JavaScript for behavior), avoid layout shifts (predictable for assistive tech and for CLS), respect user preferences (prefers-reduced-motion, prefers-color-scheme), and load content progressively (good for screen readers and for perceived performance). Google increasingly ties these together: Core Web Vitals and accessibility both affect search ranking and user experience.

prefers-reduced-motion: Respecting User Needs and Saving Resources

Users who enable reduced motion in their OS settings are telling you: don’t animate aggressively. Respecting this preference isn’t just kind — it saves rendering resources. Wrap all animations (especially scroll-driven animations, transitions, and parallax effects) in the media query:

@media (prefers-reduced-motion: no-preference) {
  .element {
    animation: slide-in 0.3s ease;
    animation-timeline: view();
  }
}

For CSS transitions, a clean approach is to set a global CSS variable:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

prefers-reduced-transparency and prefers-contrast

prefers-reduced-transparency allows you to replace expensive backdrop-filter: blur() or opacity effects with solid backgrounds when the user has requested reduced transparency. As Adam Argyle notes, “it’s not a challenge to design for reduced transparency — it’s an opportunity.” Removing blur effects also reduces compositor workload.

prefers-contrast enables you to serve higher-contrast variants for users who need them, which often means simpler backgrounds and clearer borders — computationally lighter designs.

Semantic HTML: Performance by Default

Semantic HTML elements (<button>, <a>, <dialog>, <details>, <nav>, <main>, <header>, <footer>) come with built-in keyboard navigation, focus management, screen reader announcements, and browser optimizations. Replacing a <div onclick="..."> with a <button> eliminates JavaScript event handlers, ARIA attributes, keyboard handler code, and focus management logic. The Popover API and <dialog> element (Section 14) replace hundreds of lines of modal JavaScript with zero-JS, accessible-by-default implementations.

Resources:

Developer Experience & Build Performance

A fast development feedback loop is itself a performance optimization — it enables more iterations, more testing, and faster identification of regressions. The Rust-powered build tool revolution (covered in Section 4) has transformed DX:

Fast Refresh and HMR

React Fast Refresh (and equivalents in Vue, Svelte, Solid) updates components in the browser without losing state. Combined with Vite 8’s Rolldown-powered HMR (module updates in single-digit milliseconds), the edit-save-see cycle is near-instantaneous. This matters for performance work because it enables rapid iteration on optimization experiments — testing different image formats, lazy-loading thresholds, or code-splitting strategies with immediate visual feedback.

TypeScript Build Performance

TypeScript Go (tsgo) (Section 4) delivers 10× faster type checking. For large codebases, this reduces CI type-check time from minutes to seconds. The Oxc toolchain (Section 4) provides 50–100× faster linting (Oxlint) and 30× faster formatting (Oxfmt) compared to ESLint and Prettier, keeping the development loop tight.

Monorepo Tooling

Turborepo and Nx provide intelligent task scheduling, caching, and affected-project detection for monorepos. Only rebuilding and retesting packages that actually changed (not the entire monorepo) can reduce CI time from 30 minutes to 3 minutes. Remote caching (Vercel Remote Cache, Nx Cloud) shares build artifacts across team members and CI runs, eliminating redundant work.

Resources:

Performance Culture: Making It Stick

The most comprehensive technical guide is worthless if performance isn’t part of your team’s culture. The lasting impact comes from processes, not one-time optimizations.

Automate everything: Lighthouse CI in your pipeline with failing thresholds. Bundle size budgets enforced in CI. Automated image optimization in your asset pipeline. Third-party script approval process with measured performance impact.

Make performance visible: Display Core Web Vitals dashboards on team monitors. Include performance metrics in sprint reviews. Celebrate wins — “we reduced LCP by 400ms” deserves the same recognition as shipping a new feature.

Assign ownership: Designate a performance champion (or rotate the role). Include performance review in code review checklists. Make performance regression a blocking issue, not a “we’ll fix it later” ticket.

Test on real devices: Keep a budget Android phone (Samsung Galaxy A15 or equivalent, as recommended by CSS Wizardry) at your desk. If your site feels fast on that device, it’ll feel fast for nearly everyone. If it doesn’t, your Lighthouse 100 score on your M4 MacBook means nothing.

Budget for performance from the start: It’s 10× easier to maintain a fast site than to fix a slow one. Set performance budgets before writing code. Choose libraries based on size and runtime cost, not just API ergonomics. Every npm install is a performance decision.

Resources: