← Back to React Course | Chapter 14: Performance & Production Deployment | Lesson 1 of 13

Performance क्यों जरूरी है

React performance एक dinner rush के दौरान kitchen को smoothly चलाने जैसा है — आप चाहते हैं dishes तेज़ आएं बिना effort waste किए उस food को फिर से cook किए जो किसी ने order ही नहीं किया।

Optimize करने से पहले Measure करें

Habit से React.memo और useMemo हर जगह sprinkle करना tempting है, लेकिन यह real complexity जोड़ता है और कुछ cases में unnecessarily उपयोग होने पर performance को भी hurt कर सकता है।

React DevTools Profiler आपको एक interaction record करने और exactly देखने देता है कि कौन से components re-render हुए और हर एक ने कितना समय लिया, आपको ACTUAL bottleneck की ओर point करते हुए।

Note: हमेशा पहले profile करें, फिर वही specific component optimize करें जिस पर data actually point करता है — guess न करें।
Warning: उन components को optimize करना जो actually slow नहीं हैं code complexity जोड़ता है zero real user-facing benefit के लिए।

उदाहरण: Measure Before Optimizing

markup
<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</head>
<body>
  <div id="root"></div>
  <script type="text/babel">
function App() {
  const [count, setCount] = React.useState(0);
  return <button onClick={() => setCount(count + 1)}>Count: {count} (Profile this with React DevTools)</button>;
}
ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

Re-rendering vs. Actual DOM Changes

जब एक component re-render होता है, React ज़रूरी नहीं कि actual browser DOM में कुछ भी बदले — यह नए virtual output को previous वाले के against compare (diff) करता है, और सिर्फ specific differences apply करता है।

एक component का frequently re-rendering होना automatically एक performance problem नहीं है अगर involved actual work cheap हो।

Note: छोटे, simple components के frequent re-renders अक्सर बिल्कुल fine होते हैं — performance attention उन components पर focus करें जो genuinely expensive work कर रहे हैं।
Warning: यह मान लेना कि 'यह component अक्सर re-render होता है' automatically मतलब है 'यह एक performance problem है' उन चीज़ों को optimize करने की ओर ले जा सकता है जो कभी actually slow नहीं थीं।

उदाहरण: Re-rendering vs. Actual DOM Changes

markup
<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</head>
<body>
  <div id="root"></div>
  <script type="text/babel">
function Cheap({ value }) {
  return <span>{value}</span>; // re-rendering this is essentially free
}
function App() {
  const [tick, setTick] = React.useState(0);
  React.useEffect(() => { const id = setInterval(() => setTick(t => t + 1), 1000); return () => clearInterval(id); }, []);
  return <Cheap value={tick} />;
}
ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>

Slowness के Common, Real Sources

सबसे frequent genuine performance issues हैं: हर render पर repeated expensive calculations (useMemo से fixed), हर render पर recreated functions/objects जो एक child की memoization तोड़ देते हैं (useCallback/useMemo से fixed), और virtualization के बिना बहुत large lists render करना।

Note: इनमें से हर एक का अपना dedicated tutorial इस chapter में बाद में है — यह section सिर्फ यह map है कि क्या देखना है।
Warning: वह specific fix apply करें (useMemo, useCallback, React.memo, list virtualization) जो ACTUAL measured problem से match करे, defensively हर जगह सब कुछ नहीं।

उदाहरण: Common, Real Sources of Slowness

markup
<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>
  <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
</head>
<body>
  <div id="root"></div>
  <script type="text/babel">
function App() {
  const items = Array.from({ length: 5 }, (_, i) => "Item " + i);
  // For huge lists (thousands of items), consider list virtualization
  // (a separate technique/library, not covered by useMemo/useCallback alone)
  return <ul>{items.map(i => <li key={i}>{i}</li>)}</ul>;
}
ReactDOM.createRoot(document.getElementById('root')).render(<App />);
  </script>
</body>
</html>
Related Topics
{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
आम गलतियां
  1. Prematurely optimize करना, complexity जोड़ना (memoization हर जगह) actually measure किए बिना कि क्या कोई real performance problem है।
  2. यह identify करने के लिए React DevTools Profiler उपयोग न करना कि कौन से components actually slow हैं, इसके बजाय guess करना।
  3. Re-rendering को 'DOM actually change होना' से confuse करना — React किसी component को re-render करना ज़रूरी नहीं कि browser कुछ भी repaint करे, virtual DOM diff की वजह से।
चैप्टर सारांश
  • Performance work को measuring (Profiler के through) से शुरू होना चाहिए, guess करने से नहीं कि कौन से components slow हैं।
  • Slowness के common causes: unnecessary re-renders, हर render पर repeated expensive computations, और large unoptimized lists/images।
  • React.memo, useMemo, और useCallback specific re-render problems के लिए targeted tools हैं, हर जगह apply करने के लिए एक default नहीं।
  • ज़्यादातर apps को aggressive optimization की ज़रूरत नहीं — effort वहां focus करें जहां profiling एक actual, measurable problem दिखाए।
ब्राउज़र सपोर्ट

कोई React-version restriction नहीं — React DevTools Profiler किसी भी React 16.5+ app के लिए available है।

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.