React Performance and Security Checklist Before Launch

Concept lesson · explains an idea. Code is shown for reading, not run.

Use this lesson as a checklist before you launch, and again for periodic reviews. Each item links back to where the course explains it. Tick what applies; no app needs every item.

Performance

Bundle

[ ] Measured a production build (npm run build), never the dev server (Production Builds).
[ ] The JavaScript on the first page is as small as you can reasonably make it; heavy features and routes are lazy-loaded (Lazy Loading).
[ ] No large library imported for one small function; imports are specific.
[ ] You looked at what is inside the bundle with an analyzer.

Delivery

[ ] Gzip or Brotli compression is on.
[ ] Hashed assets have long cache lifetimes; index.html is not cached for long (Deployment Fundamentals).
[ ] The site is served over HTTP/2 or HTTP/3 and HTTPS (most hosts do this by default).
[ ] Fonts: few families and weights, font-display: swap, preload only what is critical.

Images and media

[ ] Images are resized to the size they are shown, in modern formats (WebP or AVIF where suitable).
[ ] width and height (or an aspect ratio) are set to prevent layout shifts.
[ ] Images below the fold use loading="lazy"; the main image on the page does not.

Rendering

[ ] No unnecessary re-renders on key interactions; measured with the Profiler (Performance Optimization).
[ ] Long lists are paginated or virtualized (Pagination).
[ ] Expensive work is out of render or in transitions (Keeping the UI Responsive).
[ ] Effects clean up; no leaks from timers and listeners (Cleanup Functions).

Data

[ ] Requests are cancelled or ignored when stale (Aborting Requests).
[ ] Repeated data is cached (library or loader), and requests do not wait in long chains.
[ ] Loading, error and empty states exist for every request.

Measure with real tools

[ ] Lighthouse and PageSpeed Insights run on the production URL.
[ ] The Core Web Vitals are checked: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), Cumulative Layout Shift (stability). Check Google’s documentation for the current thresholds.
[ ] A test on a slow device and network (throttling in developer tools), not only a fast laptop.

Security

Secrets and configuration

[ ] No secrets in the bundle, in VITE_ variables, in source maps or in Git (Why Secret Keys Must Not Be Exposed).
[ ] Public keys are restricted to your domain and have usage limits.
[ ] .env.local is ignored by Git; .env.example has fake values.

Data and API

[ ] The server validates and authorises every request; the client is not trusted (API Security Fundamentals).
[ ] HTTPS everywhere, with no mixed content.
[ ] Sessions use HttpOnly, Secure, SameSite cookies, with CSRF protection, or tokens are handled with care.
[ ] CORS allows only the origins you need.
[ ] Error messages shown to users do not reveal internals.

Cross-site scripting

[ ] No dangerouslySetInnerHTML with unsanitised data.
[ ] URLs from data are validated (https:, http:, mailto: only) before they go into href or src.
[ ] A Content Security Policy header is set where possible.
[ ] Third-party scripts are few, trusted and loaded from known places.

Dependencies

[ ] npm audit is clean or the remaining issues are understood.
[ ] The lock file is committed and CI installs with npm ci.
[ ] Packages are updated regularly; abandoned ones are replaced.

Privacy

[ ] You collect only the data you need, and the privacy and cookie notices match what the app really does.
[ ] Personal data is not logged to the console or error trackers.

Quality

[ ] Accessibility checked with the keyboard and a screen reader (Accessibility in React).
[ ] Tests run in CI for key flows (Testing); the build passes on a clean Linux machine.
[ ] Error boundaries protect the app and report errors; source maps are available to your error tracker privately (Error Boundaries).
[ ] Monitoring after launch: errors, performance and uptime.
[ ] SEO basics for pages that must be found: titles, descriptions, canonical URLs and a sitemap; consider server rendering if content pages matter (Client-Side React vs React Frameworks).
[ ] The 404 page, the offline or failed-load behaviour and the empty states have been designed.

How to use this list

Run through it before the first launch and mark what you will fix and what you accept.
Turn the important items into automated checks in CI: lint, tests, build, npm audit, a bundle-size budget and an accessibility test.
Repeat the review every few months. Dependencies, browsers and threats change.

Key points

Performance: small bundles, caching, compressed and sized images, measured on production builds with real tools.
Security: no secrets in the browser, server-side checks, HTTPS, XSS-safe rendering, healthy dependencies.
Quality: accessible, tested, monitored and ready for failure; automate what you can.