Небольшое практическое исследование было вдохновлено статьей https://itnext.io/using-css-to-speed-up-your-react-apps-a26470829472, а конкретно следующим отрывком (перевод мой): Представьте, что у вас есть 2 вкладки. При переключении между ними стандартными методами “React” происходит размонтирование “таба из” и монтирование “таба в”. ... пример из Твиттера ... Ответ кроется в React runtime. Каждый раз при монтировании нового компонента, React должен создать virtual DOM (связанный список всех подкомпонентов внутри смонтированного дерева),выполнить всю логику внутри каждого из компонентов (или deprecated componentWillMount ) и затем добавить компоненты в DOM. В то же время, React должен размонтировать предыдущий компонент,что означает - свернуть virtual DOM, прогнать componentWillUnmount и затем удалить соответствующие элементы из DOM. Возможно, это окажется сюрпризом, но размонтирование - не дешевая операция. Вы можете подумать, что это просто удаление, но  React должен удалить рефы из многих участков virtual DOM и прогнать жизненные циклы всех компонентов, которые будут отмонтированы (unmounted). Это может происходить не быстро. До времен React Fiber (перед React 15.x.x.) размонтирование предыдущего и монтирование следующего компонента было последовательным. Нынче, React производит это параллельно для экономии времени, с учетом того, что эти процессы не зависят друг от друга. Фокус в том,чтобы не заставлять React монтировать\размонтировать,а использовать CSS для показа\скрытия содержимого табов. Дальше было про тот же пример из Твиттера и то, что при таком подходе к разработке - DOM дерево может слишком разрастись. Как разработчик приложения, которое потенциально может генерировать очень много компонентов и огромное количество табов (и человек, получивший задачу разобраться - а не будет ли это хорошей оптимизацией))) - я решил написать простой код для проверки этой теории и соотвественно последствий: Единственная бибилиотека, которая была установлена после CRA и дальнейшей чистки от лишнего - это uniqueId (для дополнительной нагрузки и дополнительный демонстрации - как работают ключи). Код имитирует переключение между двумя табами по нажатию кнопок - закомментированный участок кода из 2х строк заменяет собой раскомментированный и наоборот. Мы генерируем 2 списка по 50000 строк (в зависимости от мощности вашего компьютера - для наглядности, попробуйте поиграть с этой цифрой, если отрабатывает слишком быстро или слишком медленно) с немного разными стилями. Как это работает, уверен, каждый в состоянии проверить сам, так что перейду сразу к выводам: в случае с работой через React-way у меня на ноутбуке переключение между табами составляет от 7 до 10 секунд в случае с работой через скрытие display:none\display:block - переключение от 1.5 до 2.5 секунд Казалось бы вопросы сняты - можно пользоваться, но давайте посмотрим на выделение памяти для chrome.exe(для win10 - это найти через поиск "монитор ресурсов"): потребление памяти находится в рамках 600-1200мб в случае с рендером методами React от 1800 до 3200мб в случае со скрытием табов через стили Итог: для твиттера и таба настроек\юзера- очень даже неплохой вариант, а вот если что-то потенциально более нагруженное или с бОльшим (или непредсказуемым) количеством тяжелых табов- то лучше не надо(в перевод статьи этот вывод не вошел для сохранения интриги). Update: в ближайшее время ожидаем в  react@18+ Offscreen api, что должно снять вообще этот вопрос.