ฝัง
- เผยแพร่เมื่อ 31 มี.ค. 2024
- Ближайшая конференция - HolyJS 2024 Autumn, 7 ноября (online), 14-15 ноября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/K18Cxd
- -
React Server Components - новая фича в React, которая позволяет разработчикам создавать компоненты на стороне сервера. Это значит, что компоненты могут быть рендерены на сервере до того, как они будут отправлены на клиент - что улучшает производительность и уменьшает время загрузки страницы.
Спикер расскажет о плюсах и минусах фичи, какие она открывает возможности и как работает под капотом.
Скачать презентацию с сайта HolyJS - jrg.su/zOtfzJ
#javascript #frontend - บันเทิง
эксперт на старте кринжа нагнал, а у спикера неплохой тг канал
Спасибо за доклад, почти два года сижу в чате по next.js, всегда слушаю твои советы, со своим анализом.
Удачи в следующих докладах и не волнуйся=)
Надеюсь, будешь ещё выступать с другим материалом
Супер!
Спасибо за контент
Начало ролика напомнило первую серию Кремниевой долины
Если клиент ждет рендера на сервере, то это плохо для всех. SSR эффективен только в паре с кэшированием. Клиенту лучше отдать spa, если нет кэша. И рендерить далее в фоне в кэш. В этом случаи не переносится нагрузка со всех клиентов на сервер, при этом решается задача seo и улучшаются до максимума всякие метрики. Я как понимаю серверные компоненты требуют вычислений на каждый запрос? В них нащупывается хоть какой-то плюс только, если реально нужны все эти вычисления и рендеры на каждый запрос. Тогда рендер отдается постепенно патчами в потоке. Но зачем, не понимаю?? Клиент всё также ждет..., замечает постепенное оживление кусков страницы. Причём рендер серверных компонентов не сеошный (без js не пропатчятся в DOM). Зачем нужен такой рендер, кто скажет?
Будем говорить в контексте фреймворка nextjs, где это все более менее работает, но стоит помнить что есть различия в некоторых определениях и в алгоритмах от исходного задуманного в реакте.
Все дело в TTFB и TTI и в FCP (к сожалению стриминг не всегда положительно сказывается на FCP и тем более на CLS). Все эти метрики очевидно требуют чтоб в браузер летела максимально готовая html. Лучше думать о RSC как о куске кода который исполняется только на сервере, а для фронта он является просто куском html. Поэтому эти RSC не могут иметь внутри изменяемого состояния, т.е. всякие хуки состояния, обработчики событий и тд не могут быть использованы в серверных компонентах. Но зато можно спокойно использовать серверные библиотеки, делать запросы и передавать сериализуемые данные в клиентские компоненты. Да, этот кусок все еще подвергается процессу согласования, а значит для этого куска есть сериализованное дерево. Тем не менее это все равно легковес по сравнению с client component. Это уменьшает вес передаваемых на клиент данные, а это улучшает TTFB, TTI, FCP. Также все апи ключи и прочая security sensitive информация не уходят за границу сервера. Не то чтобы раньше это было сложно делать, но теперь стало проще.
Теперь по поводу стратегий рендринга. RSC работает со стратегиями SSR, SSG и streaming. Плюс теперь есть также кэширование роутов и запросов (fetch). И все это прямо из коробки. Поэтому нагрузка на сервер на каждый запрос в худшем случае не выше чем при обычном SSR и зачастую ниже если хоть немного оптимизировать. Если у тебя статический сайт, то все будет отдаваться из кэша, а в случае чего всегда можно запустить ревалидацию. Новые страницы также будут появляться и кэшироваться. Если у тебя есть динамика, то кэширование роутев и запросов в помощь. А если прям куча динамики, то стриминг и динамаческие компоненты помогут улучшить ситуацию. И все это положительно влияет на TTFB, TTI, FCP в той или иной мере.
Отдельно про streaming - загруженная страница уже прошла гидратацию и является интерактивной и далее гидратация будет запускаться после каждого загруженного куска. Кеш для стриминга также можно использовать. Стриминг выгодно вешать на интерфейсы что не несут супер важной информации в контексте страницы (например не содержат сео инфу и микродату), на элементы что имеют тяжелый бек и на элементы с медленными запросами. Все это очевидно ускорит TTFB, TTI. Важно что я говорю о метриках, а не про ощущения пользователя. Пример лк какого нить sentry, облачного провайдера и тд. Нужно ли там сео в лк? Нет. Важно ли чтобы пользователь получил страницу максимально быстро? Да, мы не может заставлять пользователя ждать по десяток секунд пока весь интерфейс прогрузится.
Стоит отметить что в полной мере часть плюсов раскрывается на платформах что полностью поддерживают nextjs. Очевидно что одна из таких это vercel и например частично netlify. На подобных платформах сразу доступна fsd (full site delivery) cdn, edge functions, ISR и тд. Это хорошо ускоряет nextjs.
@@delave-las-kure Важны метрики про скорость загрузки сайта? Они становятся лучше чем у SPA только при кэшировании рендера, когда при любом раскладе отдаётся кэш. Классическая оптимизация - посчитать всё заранее. Желание улучшить TTFB при сложности (невозможности) применять кэширование наверное и приводит к потоковому рендеру. Но с потоковым рендером только первый байт быстро отдаётся, далее то надо ждать "десятки секунд" вычислений (асинхронного рендера) на сервере. Потоковый рендер и серверные компоненты не ускоряют рендер. Сервер "один", клиентов "много". Чтобы всё более менее работало и приходиться платить за инфраструктуру (fsd (full site delivery) cdn, edge functions, ISR и тд). Если кто не понимает, данные и так в потоке отдаются - браузер получает полноценный html со скриптами от первого рендера, но с пустым содержимым (что смогли отрендерить синхронно на сервере). Поток не закрывается и после закрытого тега прилетают куски перерендера от suspence в виде патчей-скриптов. Будут они нормально индексироваться? Так то и SPA индексируется, но ужасно хуже по сравнению со статическим html. После гидрации приложение работает как SPA, независимо от сервера рендера. Значит вся security sensitive информация все равно нужна на клиенте? SSR вынуждены были применять из-за SEO, но с новомодными потоковыми рендерами вопросы SEO не решаются. Зачем тогда SSR? SPA и так очень быстро загружается браузером и легко кэшируется на CDN и данных значительно меньше передаётся клиенту. После рендера на сервере нужно же ещё стейт передать клиенту, восстановить состояние при котором был рендер. И, например, есть компонент с svg иконками в виде вёрстки jsx - для SPA сборки оптимальный вариант. Но рендер одной страницs со сотню иконками приводит к ощутимому дублированную svg разметки - вес html документа (рендера) будет измеряться мегабайтами!
@@delave-las-kure Важны метрики про скорость загрузки сайта? Они становятся лучше чем у SPA только при кэшировании рендера, когда при любом раскладе отдаётся кэш. Классическая оптимизация - посчитать всё заранее. Желание улучшить TTFB при сложности (невозможности) применять кэширование наверное и приводит к потоковому рендеру. Но с потоковым рендером только первый байт быстро отдаётся, далее то надо ждать "десятки секунд" вычислений (асинхронного рендера) на сервере. Потоковый рендер и серверные компоненты не ускоряют рендер. Сервер "один", клиентов "много". Чтобы всё более менее работало и приходиться платить за инфраструктуру (fsd (full site delivery) cdn, edge functions, ISR и тд). Если кто не понимает, данные и так в потоке отдаются - браузер получает полноценный html со скриптами от первого рендера, но с пустым содержимым (что смогли отрендерить синхронно на сервере). Поток не закрывается и после закрытого тега прилетают куски перерендера от suspence в виде патчей-скриптов. Будут они нормально индексироваться? Так то и SPA индексируется, но ужасно хуже по сравнению со статическим html. После гидрации приложение работает как SPA, независимо от сервера рендера. Значит вся security sensitive информация все равно нужна на клиенте? SSR вынуждены были применять из-за SEO, но с новомодными потоковыми рендерами вопросы SEO не решаются. Зачем тогда SSR? SPA и так очень быстро загружается браузером и легко кэшируется на CDN и данных значительно меньше передаётся клиенту. После рендера на сервере нужно же ещё стейт передать клиенту, восстановить состояние при котором был рендер. И, например, есть компонент с svg иконками в виде вёрстки jsx - для SPA сборки оптимальный вариант. Но рендер одной страницs со сотню иконками приводит к ощутимому дублированную svg разметки - вес html документа (рендера) будет измеряться мегабайтами!
Крутой спикер, кстати у него BMW
Обычно в обществе принято о таком не распространяться)00)
Хороший доклад, но докладчик не очень - слушать невозможно, смотрел через силу потому что тема интересная
мемы просто шедевральны!