While measuring render counts in a React application in development, you notice every component's function body runs twice for a single update. Should you treat that as a performance problem?

## What you are actually seeing Wrapping your tree in `<StrictMode>` opts that subtree into a set of development-only checks. One of them is double-invoking functions React expects to be pure. The clearest symptom is a component body running twice per render: a `console.log` at the top of the component prints twice, a render counter increments by two, an array you accidentally push into during render gets two entries. This is not a bug, not a concurrency artefact, and not something production does. It is a deliberate amplifier: React runs the function twice so that impurity becomes visible immediately rather than as a mysterious inconsistency later. ## Why React does it React's model requires rendering to be a pure calculation: given the same props, state and context, a component must return the same result and must not observe or change anything outside itself while doing so. React relies on that to skip renders, to restart interrupted renders, and to render the same component more than once before committing. Code that mutates a module-level array during render, or logs, or writes to a ref while rendering, silently violates the contract and breaks in ways that only appear under load or during a concurrent update. By running the body twice in development, React makes the violation loud. If your render is pure, both runs produce identical elements and the doubling is invisible except in the impure things you added (like logs). If it is not pure, the second run differs and you see it during ordinary development instead of in production. The same idea covers more than the component body — updater functions passed to a state setter, for example, are also expected to be pure and get the same treatment. ## Why it is not a performance signal The doubling exists only in development, and only inside a `<StrictMode>` subtree. A production build calls each component once per render. So a doubled render count says nothing about the cost of the shipped application. Two consequences follow for measurement: - **Do not read development render counts as production counts.** They are inflated by construction inside StrictMode. - **Do not read development timings as production timings either.** Development builds carry extra validation, warnings and profiling bookkeeping that make everything slower, quite apart from StrictMode. If you need trustworthy numbers, profile a production build of the app. If you only want to compare two implementations against each other, relative numbers in development can still be informative, but treat absolute figures as meaningless. ## The wrong reaction The reaction that costs a team real money is deleting `<StrictMode>` because "it makes everything render twice". That does not speed up production by one microsecond — production was never doing it — and it removes the check that would have caught an impure render before it shipped. If the doubling is genuinely getting in the way of a specific measurement, take the measurement in a production build rather than removing the check from the codebase. ## What to say in an interview The short version: "That is `<StrictMode>`, it is development-only, it double-invokes functions React expects to be pure so impure renders surface immediately, and production renders once. I would profile a production build before making any performance claim." That answer demonstrates the thing the question is really testing — that you can tell a deliberate development-time behaviour apart from a real defect in your own code.