комментариев на Хабре в прод! (потыкать тут: https://habr.com/ru/post/423889/ )
Что за стриминг рендер спросите вы?
На сервере стриминг рендер отдаёт разметку компонентов сразу же как она готова вместо того чтобы дожидаться рендера всего приложения. На клиенте стриминг рендер берёт этот стрим и рендерит его так как будто бы мы загружали новый документ (при этом текущая страница остаётся на месте). Думайте об этом как об iframe, только вместо iframe у вас полноценный документ в документе!
Зачем это нужно, предвосхищаю уже следующий вопрос.
Дело в том что рендерить на клиенте десятки тысяч компонентов долго, дорого, но не ахуенно. Основная проблема в том что такой рендеринг происходит синхронно и ваш основной поток будет полностью заблокирован. Например вы хотите прочитать первые 100 комментариев к статье, но вынуждены ждать пока загрузятся 2000 комментов. К тому же такой рендер нельзя переиспользовать (например вкрутить кеш на уровне сервера). Как альтернатива этому существует тайм-слайсинг рендера (пушим в рендер цикле элементы которые можно отрендерить), но это имеет свои ограничения: как я уже сказал нельзя закешировать и это всё ещё клиентский рендер (люди на мобилках не скажут вам спасибо). Более того любой стриминг рендер медленнее синхронного рендера из-за издержек на работу ивент лупа, обработку стрима и так далее.
И вот мы приходим к стриминг рендеру на сервере. Вместо выполнения работы на клиенте мы выполняем самую тяжёлую часть на сервере и просто рисуем разметку на клиенте.
Как же это работает после отрисовки?
Я рад что вы спросили. Мы обманываем вью и подсовываем в приватное свойство ._vnode наш корневой элемент. Это включает режим гидратации во вью и он начинает думать об этой разметке как о своей родной.
Но ведь это будет очень долго гидрироваться и всё-равно будет заблочен основной поток?
Да, это будет долго гидрироваться и на этот случай здесь обязательно нужно использовать плагин vue-lazy-hydration и гидрировать только что что пользователь видит на экране.
А как быть с тем что юзер обновляет страницу и хочет вернуться на ту позицию где он был до этого?
Да, это сложная проблема, и сейчас мы её решили тем что сохраняем те места где нам нужна эта позиция и выполняем полный рендер комментов на сервере. Клиент ждёт дольше, но не теряет скролл.
Ну а работает-то хотя бы быстрее?
Это самый интересный вопрос. Стриминг рендер работает медленее чем синхронный SSR. Но это только на числовых показателях. Самое важное что даёт стриминг рендер это Time to first content, время за которое мы уже можем начинать читать контент. И тут у стриминг рендера просто нет конкурентов. Поэтому получается парадокс: стриминг работает медленее, а кажется что быстрее. Поэтому очень важно оптимизировать не цифры, а пользовательский опыт.
Посмотреть как это работает можно уже прямо сейчас, вот статья где 2500 комментов: https://habr.com/ru/post/423889/
Можете её открыть и прокрутить до комментов, обратите внимание как скоро вы можете начать читать эти комменты. Потом обновите страницу и сравните это ожидание с тем сколько вам пришлось ждать комменты при первом заходе.
Кому интересно как выглядит разметка которая стримится можете заглянуть вот сюда: https://habr.com/ssr/comments/423889?fl=ru&hl=ru
Важное уточнение: сейчас стриминг комментов работает БЕЗ кеширования, но это не значит что его не будет. :)
Не раскрываю огромное множество подробностей которые нужно учитывать при реализации этой техники, возможно будет отдельная статья :)
3?) У меня 7-9 -_-
це, видимо, то самое content-visibility, о котором Станислав писал неделью ранее)
Можете скринкаст показать?
ещё бы понять как.. Я на рабочей убунте без понятия, как делать скринкасты :D
Статья в первый раз у меня открылась за 700мс, во второй за 30 секунд. Стриминг открылся за 13 секунд.
Стикер
Такое тоже может быть, сейчас у нас стриминг висит на той же ноде что и обычный SSR, когда вынесем в отдельный процесс или воркер станет заметно лучше.
Люблю такие вещи объяснять заказчику 🙂 "ой, что-то эта ваша 3d анимация не грузится мгновенно...можно это как-то исправить?" 😓
Обсуждают сегодня