Stop Migrating Your Broken CRA App

Three fucking weeks. That's how long I wasted migrating to Vite expecting to be the office hero. Same slow loading, same sluggish clicks, same disappointed stakeholders staring at me during the demo.

Here's what I learned the hard way: build tools make your builds fast, not your app. Your dependencies are still bloated garbage. Your images are still unoptimized 8MB PNGs from designers. Your components still re-render the entire fucking DOM tree when someone types in a search box.

Your App Is Full of Garbage

CRA apps accumulate garbage over time:

• Dependencies you tried once and never removed (depcheck finds these)
• Imports that break tree-shaking in modern bundlers
• IE11 polyfills nobody needs anymore
• UI libraries where you use 3 components out of 50 (Material-UI has optimization docs)

Bundle analyzer showed the same massive chunks. All that dead weight just moved from webpack to Vite. My "optimized" build went from like 3.2MB to maybe 3.1MB. Embarrassing doesn't even cover it.

Do This Before You Touch Any Code

Figure Out What's Actually Slow

Build your CRA app and actually look at the garbage you're shipping:

npm run build
ls -lah build/static/js/ | sort -k5 -hr

npm install --save-dev webpack-bundle-analyzer  
npx webpack-bundle-analyzer build/static/js/*.js

Bundle analyzer reveals the shit that's killing you:

• moment.js - like 300KB for date formatting JavaScript already does
• Complete UI libraries - imported all of Material-UI for 2 fucking buttons
• Icon libraries - thousands of React Icons for the handful you actually use
• Old polyfills - still supporting browsers you dropped years ago

First time I ran bundle analyzer, I wanted to throw my laptop out the window. Fifteen forgotten dependencies including some massive PDF library we tried once in 2023 and never bothered removing. Think it was like 60MB or something insane. We used react-pdf to display one document. One.

Measure Before You Migrate

npm install --save-dev lighthouse
npx lighthouse [your-dev-server-url] --view

Forget perfect Lighthouse scores. Focus on user experience:

• LCP under 2.5s - when main content actually loads
• FID under 100ms - how responsive clicks feel
• CLS under 0.1 - how much the page jumps around

Test on slow connections or prepare to get roasted by users. Our app felt snappy in dev on fiber but took forever to load on actual 3G. Like 20+ seconds. Chrome DevTools → Network → "Slow 3G" - prepare to hate yourself. The Network Information API can help you adapt to connection speed.

Performance Auditing: Lighthouse shows you exactly what's killing your load times - JavaScript blocking the main thread, massive images loading before text, and CSS that's never used.

The Web Vitals documentation has more details if you want to go deeper, but honestly just focus on LCP and CLS - those are the ones that actually affect user experience.

Core Web Vitals: Focus on the metrics users actually feel - how long until they see content (LCP), how quickly clicks respond (FID), and how much the page jumps around (CLS).

Delete Your Unused Crap

Migration breaks imports anyway. Perfect time to delete dependencies you don't need:

npm install --save-dev depcheck
npx depcheck

First time I ran depcheck on our production app, I just stared at my screen. Twenty-seven unused packages. Including jsPDF (massive), react-virtualized (we switched to react-window ages ago), and three different fucking date libraries because apparently we couldn't make up our minds.

Delete this shit immediately:

• moment.js - huge for date formatting that browsers already do
• Full lodash imports - most of lodash is just worse Array methods now
• Complete UI libraries - importing half a megabyte of Material-UI for two buttons
• IE11 polyfills - Microsoft killed IE11, let it fucking die
• Test utilities - leftover Enzyme imports from like 2019

Replace the big stuff:

// Old way: massive date library
import moment from 'moment';
const formatted = moment(date).format('YYYY-MM-DD');

// New way: browser handles it
const formatted = new Intl.DateTimeFormat('en-CA').format(date);

Look, if your team actually knows Material-UI inside and out and ships fast, maybe the bloat is worth it. I've watched teams spend months replacing MUI with some "lightweight" alternative, break half their shit, and end up with the same bundle size anyway. Pick your battles.

Use bundlephobia.com to check dependency sizes before installing. For dates, date-fns tree-shakes properly and Day.js is tiny. The webpack documentation explains tree-shaking in detail if you want to understand why imports matter so much.

Fix Your Imports

Modern bundlers hate bad imports. Fix them during migration:

// Old CRA way - loads everything
import Dashboard from './Dashboard';

// Modern way - lazy loading  
const Dashboard = lazy(() => import('./Dashboard'));

<Suspense fallback={<div>Loading...</div>}>
  <Dashboard />
</Suspense>

// Bad imports
import { Button } from '@mui/material';

// Better imports
import Button from '@mui/material/Button';

Migration Won't Magically Optimize Your Build

Copy this Vite config if you want bundle analysis:

// vite.config.js
import { visualizer } from 'rollup-plugin-visualizer';

export default {
  plugins: [
    process.env.ANALYZE && visualizer({ 
      filename: 'dist/stats.html',
      open: true 
    })
  ],
  build: {
    target: 'es2020',
    chunkSizeWarningLimit: 1000,
  }
};

Test before and after migration:

## Before
npm run build
ls -lah build/static/js/

## After  
npm run build
ls -lah dist/assets/

Don't trust your gut - "feels faster" is how I shipped a migration that actually made things slower. Lighthouse CI caught it weeks later when a client complained. Set up performance monitoring to catch regressions automatically.

Every fucking migration tutorial stops at "congrats, you switched build tools!" like that solves anything. That's like changing your car's oil and expecting it to beat a Ferrari. Here's the shit that actually matters once your dev server stops being slow as hell.

Real User Monitoring: Modern tools expose performance issues that CRA's slow build cycle was hiding. Users clicking faster than your React can re-render shows you exactly which components are performance disasters.

Resource Loading Optimization

CRA loads everything at once with no prioritization. After migration, you can actually control what loads when using resource hints and modern loading strategies.

Preload Critical Stuff

Add this to your index.html using resource hints and preload directives:

<head>
  <!-- Load fonts first - stops text jumping around -->
  <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
  
  <!-- Load hero image early -->
  <link rel="preload" href="/hero.webp" as="image">
  
  <!-- Connect to API faster -->
  <link rel="dns-prefetch" href="//api.yoursite.com">
</head>

Next.js handles this automatically:

import Image from 'next/image';

// Automatically optimized and preloaded
<Image 
  src="/hero.jpg"
  width={800}
  height={400}
  priority
  alt="Hero"
/>

Service Workers

CRA's service worker was fucking useless - it cached everything forever and gave you zero control. Spent 2 days debugging why users couldn't see updates because of aggressive caching. Modern tools like Workbox and Vite PWA actually let you cache intelligently:

// vite.config.js
import { VitePWA } from 'vite-plugin-pwa';

export default {
  plugins: [
    VitePWA({
      workbox: {
        runtimeCaching: [{
          urlPattern: /^https:\/\/api\./,
          handler: 'NetworkFirst'
        }]
      }
    })
  ]
};

Memory Leaks Become Obvious

Faster dev servers expose memory leaks like crazy. Suddenly users can click fast enough to trigger cleanup failures that CRA's sluggish reloads were hiding. Had one client's app crash after like 10 minutes - turns out we had setInterval calls running forever.

Fix Your useEffect Cleanup

Common memory leak:

useEffect(() => {
  const interval = setInterval(fetchData, 1000);
  // Missing cleanup - runs forever
}, []);

// Fixed version
useEffect(() => {
  const interval = setInterval(fetchData, 1000);
  return () => clearInterval(interval); // Actually clean up
}, []);

State Management Gets Messier Too

Most CRA apps have Redux setups that would make Dan Abramov cry. I've seen massive reducers that could be replaced with useState. Migration is perfect for cleaning up this architectural nightmare using Zustand or Jotai:

// Old way: giant context that re-renders everything
const AppContext = createContext();

// Better way: split contexts
const UserContext = createContext();
const ThemeContext = createContext();

Or just use Zustand:

import { create } from 'zustand';

const useStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user })
}));

Images Still Suck After Migration

CRA doesn't optimize images. Modern tools like Vite can if you configure them, or use Next.js Image optimization for automatic optimization:

// vite.config.js
export default {
  assetsInclude: ['**/*.webp', '**/*.avif']
};

Or just use Next.js Image component and let it handle everything automatically. The Sharp library powers most image optimization tools.

Migration changes your build tool, not your performance disasters. That 8-second LCP? Still there. Those memory leaks? Still leaking. Images that are 4MB because designers don't understand web formats? Still fucking massive.

Use tools like ImageOptim, Squoosh, or Sharp to actually optimize images. The Performance API helps you measure real impact. And React DevTools Profiler shows you which components are killing performance.

Performance Reality Check: Your bundle analyzer might show a 10% smaller build, but your users still wait 4 seconds for content to appear. Time to fix what actually matters.

Bundle size means fuck-all if your app still takes forever to load. I've watched developers throw a party for shaving a few KB from their bundle while their app takes way too long to show content. Here's what actually matters when measuring if your migration was worth the time you'll never get back.

What Matters vs What Doesn't

Core Web Vitals (Users Actually Notice These)

Core Web Vitals docs have the details, but here's the summary. The PageSpeed Insights API can automate this testing:

LCP (Largest Contentful Paint) - Under 2.5s

• When your main content actually fucking appears
• Can improve a lot with proper image preloading
• I broke image preloading during migration and LCP went from like 2s to over 4s. Clients definitely noticed. LCP optimization guide has detailed fixes.

FID (First Input Delay) - Under 100ms

• How long users wait after clicking before anything happens
• Modern tools usually fix this automatically
• One client's FID went from decent to total shit because I fucked up code splitting and blocked the main thread for way too long. FID optimization covers common fixes.

CLS (Cumulative Layout Shift) - Under 0.1

• How much your page bounces around like a trampoline
• Migration almost always makes this worse initially
• Spent an entire weekend debugging text that jumped around when fonts loaded because I removed font-display: swap. CLS optimization explains layout shift fixes.

Developer Experience (Team Productivity)

Time these before and after migration:

• Dev server startup (should be under 5 seconds)
• Hot reload (should be under 500ms)
• Production builds (should be under 5 minutes)

time npm run dev
time npm run build

Bundle Optimization

Focus on gzipped sizes, not raw bundle size. Time to Interactive matters more than total JavaScript size.

Automate Performance Testing

Manual testing is garbage and will bite you in the ass. I pushed a migration that killed LCP badly and nobody caught it for weeks until a client complained that the site "feels broken now." Automation saves your reputation.

Set up Lighthouse CI:

npm install --save-dev @lhci/cli

Basic config:

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['http://localhost:4173']
    },
    assert: {
      assertions: {
        'categories:performance': ['error', {minScore: 0.8}]
      }
    }
  }
};

Track Real Users

Lighthouse tests from fast servers. Real users have slow phones and bad connections.

import { getCLS, getFID, getLCP } from 'web-vitals';

function sendToAnalytics(metric) {
  // Send to your analytics
  console.log(metric.name, metric.value);
}

getCLS(sendToAnalytics);
getFID(sendToAnalytics);  
getLCP(sendToAnalytics);

Performance Budgets

Set limits so you notice when things get worse:

// vite.config.js
export default {
  build: {
    chunkSizeWarningLimit: 1000, // 1MB warning
  }
};

// package.json
{
  \"bundlesize\": [
    {
      \"path\": \"./dist/assets/*.js\",
      \"maxSize\": \"250 kB\",
      \"compression\": \"gzip\"
    }
  ]
}

Performance gains decay like radioactive waste. Teams add dependencies, designers upload massive PNGs, junior devs write components that re-render everything. Without monitoring, you'll be back to slow load times within months guaranteed.

Set up continuous performance monitoring with tools like SpeedCurve, Calibre, or WebPageTest. The User Timing API lets you track custom metrics. And Performance Observer can monitor real user performance automatically.