SSR Hydration vs PWA

Жирным - критический путь, чтобы хотя бы увидеть данные.

SSR & Hydration

HTML грузится каждый раз заново - его не имеет смысл кешировать.
Первый запуск: формирование HTML на лету (медленно) -> загрузка HTML (медленно) -> загрузка JS (быстро) -> загрузка данных (быстро) -> рендеринг приложения в гидратацией (медленно).
Второй запуск: формирование HTML на лету (медленно) -> загрузка HTML (медленно) -> загрузка данных (быстро) -> рендеринг приложения в гидратацией (медленно).
Высокая нагрузка на сервер - формирование HTML на каждый запуск приложения.
Приложения с большим JS показываются быстрее, но ко взаимодействию готовы позже.
Работа в оффлайне в общем случае не возможна.
Поисковики сразу получают HTML с данными.

Первый запуск: загрузка HTML (быстро) -> загрузка JS (быстро) -> рендеринг приложения (быстро) -> загрузка данных (быстро) -> показ видимых данных (медленно).
Второй запуск: рендеринг приложения (быстро) -> загрузка данных (быстро) -> показ видимых данных (быстро) | статика обновляется в фоне.
HTML может быть закеширован через ServiceWorker и выдаваться мгновенно.
HTML статичный и первый раз быстро отдаётся кеширующим прокси.
Низкая нагрузка на сервер - только отдача статики и данных через API.
Приложения с малым JS полностью стартуют быстрее.
Возможна работа в оффлайне.
Поисковики через meta-fragment направляются на серверное API для рендеринга HTML специально для них.