React Production Checklist: Security, Performance, Monitoring (2026)

React apps, when deployed to production, can become surprisingly vulnerable and slow if you don’t have a solid grasp on a few key areas. Think of this as the "what you actually need to worry about after 'it works on my machine'" guide.

Security: Protecting Your Users and Your App

1. Cross-Site Scripting (XSS) Prevention

• What it is: Attackers inject malicious scripts into your web page, which then execute in your users’ browsers. This can steal session cookies, hijack accounts, or deface your site.
• Diagnosis: Look for places where you’re directly rendering HTML strings or using dangerouslySetInnerHTML.
• Fix: Always sanitize user-provided content before rendering it. For simple text, React automatically escapes it. For HTML, use libraries like dompurify.

  import DOMPurify from 'dompurify';
  
  function RenderHtmlContent({ htmlString }) {
    const sanitizedHtml = DOMPurify.sanitize(htmlString);
  
    return <div dangerouslySetInnerHTML={{ __html: sanitizedHtml }} />;
  
  }
  

  This works because dompurify strips out any potentially harmful JavaScript or malicious tags from the htmlString before it’s inserted into the DOM.
• Common Cause: Not properly sanitizing data fetched from external APIs or user input fields.
• Diagnosis: Use your browser’s developer tools to inspect network requests and look for suspicious payloads in API responses.
• Fix: Implement a server-side validation and sanitization layer for all incoming data. For example, in Node.js with Express and express-validator:

  const { body } = require('express-validator');
  const sanitizeHtml = require('sanitize-html');
  
  app.post('/api/comments', [
    body('commentText').trim().escape().customSanitizer(value => {
      return sanitizeHtml(value, {
        allowedTags: [], // Strip all HTML tags
        allowedAttributes: {}
      });
    }),
  ], (req, res) => {
    // ... process validated and sanitized comment
  });
  

  This ensures that even if malicious input slips through client-side checks, it’s cleaned up before hitting your database or being processed further.
• Common Cause: Using deprecated or insecure libraries.
• Diagnosis: Regularly run npm audit or yarn audit to identify known vulnerabilities in your dependencies.
• Fix: Update vulnerable packages to their latest versions. If a direct update isn’t possible, consider patching or finding alternative libraries.

  npm update --save-dev react react-dom
  # or
  yarn upgrade react react-dom
  

  This replaces the old, vulnerable code with newer, security-patched versions, mitigating known exploits.
• Common Cause: Insecure handling of authentication tokens (e.g., storing sensitive tokens in localStorage).
• Diagnosis: Inspect your browser’s localStorage and sessionStorage for sensitive information like JWTs.
• Fix: Use HttpOnly cookies for authentication tokens. These are inaccessible to JavaScript, preventing XSS attacks from stealing them. Configure your backend to set cookies with the HttpOnly and Secure flags.

  // Example Node.js (Express)
  res.cookie('token', yourToken, { httpOnly: true, secure: true, sameSite: 'strict' });
  

  This mechanism ensures that the browser automatically sends the cookie with requests to your domain but prevents client-side scripts from reading or manipulating it.
• Common Cause: Exposing sensitive API keys or environment variables directly in the client-side bundle.
• Diagnosis: Use your browser’s developer tools (Network tab) to inspect JavaScript files and look for hardcoded API keys.
• Fix: Never embed secrets in client-side code. Use environment variables that are processed during the build step and replaced with non-sensitive values, or fetch secrets from a secure backend API at runtime. For build-time variables with Webpack:

  // webpack.config.js
  const webpack = require('webpack');
  const Dotenv = require('dotenv-webpack');
  
  module.exports = {
    plugins: [
      new Dotenv(), // Loads .env file
      new webpack.DefinePlugin({
        'process.env.SOME_PUBLIC_KEY': JSON.stringify(process.env.SOME_PUBLIC_KEY),
      }),
    ],
  };
  

  This injects values from your .env file into your JavaScript bundle as global constants, making them available during runtime without exposing the actual secret.
• Common Cause: Lack of Content Security Policy (CSP).
• Diagnosis: Use online CSP evaluators or check your browser’s developer console for "Refused to load…" errors.
• Fix: Implement a strict CSP header on your server.

  Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none';
  

  This header tells the browser which sources are allowed to load resources (scripts, styles, images, etc.), significantly reducing the attack surface for XSS and data injection.
• Next Error: 403 Forbidden if your CSP is too restrictive and blocks legitimate resource loading.

Performance: Keeping Users Engaged

1. Code Splitting and Lazy Loading

• What it is: Instead of serving one massive JavaScript bundle, break it down into smaller chunks that are loaded only when needed. This dramatically improves initial page load times.
• Diagnosis: Use your browser’s Network tab to observe the size of your main JavaScript bundle. If it’s over 1MB, you likely need code splitting.
• Fix: Use React’s React.lazy and Suspense for component-level lazy loading, and configure your bundler (Webpack, Vite) for route-based splitting.

  // App.js
  import React, { Suspense, lazy } from 'react';
  import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
  
  const HomePage = lazy(() => import('./pages/HomePage'));
  const AboutPage = lazy(() => import('./pages/AboutPage'));
  
  function App() {
    return (
      <Router>
        <Suspense fallback={<div>Loading...</div>}>
          <Switch>
            <Route exact path="/" component={HomePage} />
            <Route path="/about" component={AboutPage} />
          </Switch>
        </Suspense>
      </Router>
    );
  }
  

  This tells React to only fetch and execute the JavaScript for HomePage or AboutPage when the user navigates to those routes, rather than loading everything upfront.
• Common Cause: Unnecessary re-renders of components.
• Diagnosis: Use the React DevTools Profiler to identify components that are re-rendering frequently without a change in their props or state.
• Fix: Use React.memo for functional components and PureComponent or shouldComponentUpdate for class components to prevent unnecessary re-renders.

  // Functional component
  const MyComponent = React.memo(function MyComponent(props) {
    /* render using props */
  });
  
  // Class component
  class MyComponent extends React.PureComponent {
    render() {
      /* render using this.props */
    }
  }
  

  These optimizations ensure that a component only re-renders if its props or state have actually changed, saving CPU cycles.
• Common Cause: Large, unoptimized images.
• Diagnosis: Use browser developer tools (Lighthouse, Network tab) to identify large image files that are taking a long time to load.
• Fix: Serve images in modern formats (WebP), use responsive images (srcset), and implement lazy loading for images below the fold. Tools like react-lazyload or Intersection Observer API can help.

  import LazyLoad from 'react-lazyload';
  
  function MyImageComponent({ src, alt }) {
    return (
      <LazyLoad height={200} offset={100} once>
        <img src={src} alt={alt} />
      </LazyLoad>
    );
  }
  

  This ensures that images are only loaded when they are about to enter the viewport, reducing initial load time and bandwidth usage.
• Common Cause: Inefficient state management or context usage.
• Diagnosis: Use React DevTools Profiler and observe how many components re-render when a small piece of global state changes. If many unrelated components re-render, your context might be too broad or your state structure inefficient.
• Fix: Split contexts into smaller, more specific ones. Use memoization (useMemo, useCallback) for derived state or functions passed down through props. Consider state management libraries like Zustand or Jotai for more granular state updates.

  // Example of splitting context
  const UserContext = React.createContext();
  const ThemeContext = React.createContext();
  
  function App() {
    return (
      <UserContext.Provider value={user}>
        <ThemeContext.Provider value={theme}>
          {/* ... components ... */}
        </ThemeContext.Provider>
      </UserContext.Provider>
    );
  }
  

  By separating concerns into distinct contexts, only components subscribed to the relevant context will re-render when that specific context’s value changes.
• Common Cause: Excessive use of inline styles or large style objects.
• Diagnosis: Profile your app in the React DevTools. Frequent style recalculations can appear as performance bottlenecks.
• Fix: Use CSS-in-JS libraries that optimize style injection and batching (e.g., Styled Components, Emotion) or use traditional CSS with global stylesheets and classNames. Avoid creating new style objects on every render if possible.

  // Using styled-components
  import styled from 'styled-components';
  
  const Button = styled.button`
    background-color: ${props => props.primary ? 'blue' : 'gray'};
    padding: 10px 20px;
    border-radius: 5px;
  `;
  

  styled-components generates unique class names for your styles and injects them efficiently, often leading to better performance than inline styles or poorly managed style objects.
• Common Cause: Not leveraging the browser’s caching mechanisms effectively.
• Diagnosis: Inspect your network requests in the browser’s developer tools. Look for resources that are repeatedly fetched with a 200 OK status instead of 304 Not Modified or from the cache.
• Fix: Configure your web server (Nginx, Apache, CDN) to set appropriate Cache-Control and Expires headers for static assets like JavaScript bundles, CSS files, and images. Use cache-busting techniques (e.g., appending hashes to filenames) for versioned assets.

  # Example Nginx configuration for caching static assets
  location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
      expires 365d;
      add_header Cache-Control "public, immutable";
  }
  

  This tells browsers and intermediate caches to store these assets for a long time, so subsequent requests for the same file are served directly from the cache, dramatically speeding up page loads for returning visitors.
• Next Challenge: Maximum call stack size exceeded errors due to infinite re-render loops after fixing performance issues.

Monitoring: Knowing What’s Happening

1. Error Tracking and Reporting

• What it is: Automatically capturing unhandled JavaScript errors in production and sending them to a centralized service for analysis.
• Diagnosis: You’ll know you need this when users report issues you can’t reproduce, or when you see a spike in generic error messages.
• Fix: Integrate an error tracking service like Sentry, Bugsnag, or Datadog APM.

  // Example with Sentry
  import * as Sentry from "@sentry/react";
  import { Integrations } from "@sentry/tracing";
  
  Sentry.init({
    dsn: "YOUR_SENTRY_DSN",
    integrations: [new Integrations.BrowserTracing()],
    tracesSampleRate: 1.0,
  });
  
  function App() {
    return (
      <Sentry.ErrorBoundary fallback={"An error occurred"}>
        {/* Your application components */}
      </Sentry.ErrorBoundary>
    );
  }
  

  This wraps your application in an error boundary that catches JavaScript errors, logs them to Sentry, and displays a fallback UI, giving you immediate insight into production failures.
• Common Cause: Not tracking client-side errors, only server-side.
• Diagnosis: You have server logs but no clear picture of what’s failing in the user’s browser.
• Fix: Ensure you have a robust client-side error tracking solution in place. Configure it to capture unhandled exceptions, promise rejections, and even specific application-level errors you define.

  // Example: Capturing a specific error
  try {
    // some operation that might fail
    throw new Error("User failed to save preferences");
  } catch (error) {
    Sentry.captureException(error);
    // ... handle error locally if needed
  }
  

  This allows you to distinguish between different types of client-side failures and prioritize fixes based on user impact.
• Common Cause: Inadequate logging of application events.
• Diagnosis: When debugging, you lack context about user actions leading up to an error.
• Fix: Implement custom logging within your application to track key user interactions, state changes, and API calls. Send these logs to your error tracking service or a dedicated logging platform.

  // Example: Logging a successful API call
  Sentry.configureScope(scope => {
    scope.setTag("api", "user_profile");
    scope.setExtra("userId", userId);
  });
  Sentry.captureMessage("User profile loaded successfully", Sentry.Severity.Info);
  

  These structured logs provide invaluable context, helping you pinpoint the exact sequence of events that led to a production issue.
• Common Cause: Not monitoring performance metrics.
• Diagnosis: Users complain about slowness, but you have no data to quantify it or identify the bottleneck.
• Fix: Use performance monitoring tools (also often part of APM solutions like Datadog, New Relic, or Sentry’s performance monitoring) to track metrics like First Contentful Paint (FCP), Time to Interactive (TTI), and resource load times.

  // Example: Using Sentry's BrowserTracing integration (already in init above)
  // Sentry automatically instruments many performance metrics.
  // You can also manually start/stop transactions:
  const transaction = Sentry.startTransaction({
    name: "UserLogin",
    op: "auth",
  });
  try {
    // ... login logic ...
  } catch (e) {
    Sentry.captureException(e);
  } finally {
    transaction.finish();
  }
  

  This provides a dashboard of your application’s performance, allowing you to identify slow routes, resource bottlenecks, and the impact of code changes.
• Common Cause: Missing uptime monitoring.
• Diagnosis: Your application goes down, and you’re one of the last to know.
• Fix: Set up external uptime monitoring services (e.g., Uptime Robot, Pingdom, Datadog Synthetics) that periodically ping your application’s critical endpoints. Configure alerts for downtime.

  # Example: Cron job to ping a health check endpoint
  # (This is a simplified example; dedicated services are better)
  */5 * * * * curl -f https://your-app.com/api/health || echo "App is down!" | mail -s "App Down Alert" admin@example.com
  

  This proactive approach ensures you’re notified immediately when your application becomes unavailable, allowing for rapid response before it impacts a large number of users.
• Common Cause: Lack of user feedback mechanisms.
• Diagnosis: You rely solely on error reports, missing out on user-reported bugs or feature requests.
• Fix: Integrate a user feedback widget or a simple "Report Issue" button that allows users to submit feedback directly from the application. This can be a simple form that sends an email or creates a ticket in your issue tracker.

  // Example: Simple feedback button
  function FeedbackButton() {
    const handleClick = () => {
      const feedback = prompt("Please tell us what you think:");
      if (feedback) {
        // Send feedback to your backend or error tracking service
        fetch('/api/feedback', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ feedback }),
        });
        alert("Thank you for your feedback!");
      }
    };
    return <button onClick={handleClick}>Feedback</button>;
  }
  

  This creates a direct channel for users to communicate problems or suggestions, enriching your understanding of user experience and potential issues.
• Next Step: Your error tracking system starts flooding you with "Degraded Performance" alerts after a recent deployment.