SSR ломается не на рендере, а на мелочах вокруг данных и окружения

SSR ломается не на рендере, а на мелочах вокруг данных и окружения

SSR удобен, пока сервер и клиент видят один и тот же мир. Как только в шаблоне появляются random, Date.now(), доступ к window или локаль из браузера — разметка начинает расходиться, а гидрация получает лишнюю работу.

Типовые ошибки:
— Запросы внутри компонента без единого слоя кеша: сервер отдал одно, клиент тут же догнал другое.
— Условный рендер по размеру экрана или времени: на сервере нет viewport, и первый HTML уже «не тот».
— Тяжёлые эффекты в mounted/onMount: SSR отдал страницу быстро, но интерактивность приехала позже, чем ожидалось.

Проверяйте не только HTML, но и порядок данных: одинаковые параметры, одинаковый формат дат, одинаковые флаги feature toggle. Если часть интерфейса зависит от браузера, лучше явно отделить её в client-only блок, чем пытаться угадать состояние на сервере.

Хороший SSR — это не магия скорости, а дисциплина одинакового состояния на двух сторонах. Если есть сомнение, сначала сделайте рендер предсказуемым, и только потом ускоряйте его кешем, стримингом или пререндером.