Дякую за запитання.

Читайте уважно контекст в якому описані ті, чи інші переваги/недоліки. У статті наводиться опис конкретного застосування та поліпшення роботи на проєкті з великою кількістю AB-тестів, асинхронних запитів та динамічного контенту, а не простий опис технологій які існують. Оскільки проєкт мав довгу історію розвитку, то і вимоги до нього постійно змінювались. SSG мав певні переваги в попередніх версіях проєкту ( зважаючи на контекст/ архітектуру / запити бізнесу), але зі збільшенням кількості функціонала та динамічного контенту — цей підхід став не відповідати технічним вимогам. Він застарів в контексті конкретного проєкту, а не як спосіб рендерингу в цілому. Відхід від SSG до SSR як раз і дав змогу вирішити всі ті проблеми, з яким проект зіткнувся до переходу.

Для типових статичних веб-сайтів він залишаеться хорошим рішенням. Підіймати SSR для корпоративного сайту на 3-5 сторінок немає сенсу.

Приблизно декілька робочих місяців, але робили паралельно з підтримкою минулої версії.
Суттєвих проблем з переходом не мали, головне було заздалегідь продумати архітектуру. Трішки довелось витрачати час на пошуки рішень по реалізації певних логік новими інструментами або аналогами.

Тести були як авто-, так і мануальні. Перевіряли базові логіки, візуал, оптимізацію. Також, проводили тестові запуски на малих об’ємах реальних юзерів.