Next.js: Потоковый рендеринг для уменьшения TTFB и загрузки процессора

Следует упомянуть одну вещь ..

Потоковый рендеринг обычно не приводит к значительным улучшениям ЦП, поскольку объем работы, которую необходимо выполнить, тот же. Но это сократит время отклика.

Хорошая идея - предоставить способ настройки системы рендеринга SSR. Но я думаю, что пока мы будем придерживаться методов RenderToString () React по умолчанию.

Это то, что мы могли бы сделать после 2.0.

Потоковый рендеринг обычно не приводит к значительным улучшениям ЦП, поскольку объем работы, которую необходимо выполнить, тот же.

_из aickin / react-dom-stream _

Один вызов ReactDOM.renderToString может доминировать над ЦП и истощать другие запросы. Это особенно проблематично на серверах, которые обслуживают как маленькие, так и большие страницы.

Разве потоковая передача не приведет к значительному сокращению выделения памяти и использования ЦП для больших страниц, будучи одновременно асинхронной и частичной?

Думал, это было в том же духе. Кто-нибудь пробовал https://github.com/FormidableLabs/rapscallion ?

Он предоставляет потоковый интерфейс, так что вы можете сразу же начать отправку контента клиенту.

Другие особенности из документации:

• Рендеринг бывает асинхронным и неблокирующим.
• Rapscallion примерно на 50% быстрее, чем renderToString.
• Он предоставляет потоковый интерфейс, так что вы можете сразу же начать отправку контента клиенту.
• Он предоставляет возможность создания шаблонов, так что вы можете обернуть HTML-код вашего компонента в шаблон, не отказываясь от преимуществ потоковой передачи.
• Он предоставляет API кэширования компонентов для дальнейшего ускорения рендеринга.

Добавлен пример Rapscallion в # 2279 ... может подтвердить, что Rapscallion + Next безумен. Потоковый рендеринг / рендеринг на основе обещаний - это круто, но кеширование на уровне компонентов меняет правила игры для нас ...: godmode:

Теперь, когда у React 16 есть собственный renderToNodeStream , для next.js было бы огромным преимуществом добавить возможность его использования вместо renderToString . Как вы думаете, @timneutkens?

Это уже в нашем списке вещей, которые нужно добавить 👍

Есть новости об этом?

https://github.com/zeit/next.js/pull/4074#issuecomment -466996162

Какие-нибудь Новости?

Next.js должен предоставить пользовательский render (с renderToString качестве средства рендеринга по умолчанию), чтобы пользователь мог использовать свой собственный асинхронный рендерер, я думаю.
Отсутствие этой функции вынудило меня использовать razzle для использования асинхронного рендерера :( (его DX далек от NextJS, но мне пришлось смириться с этим, чтобы продолжить).

Мне нравится в Next.js все, кроме двух вещей:

• Пользовательский асинхронный рендерер.
• Пользовательская конфигурация babel как для сервера, так и для клиента.

какой-либо план / план поддержки потокового рендеринга? так и ожидалось, что это будет в next.js.

Ожидается, что команда React реализует React Fizz / их план.

@timneutkens В чем проблема, PR отслеживать здесь?

Из сообщения в блоге Facebook, опубликованного 8 августа 2019 г.
https://reactjs.org/blog/2019/08/08/react-v16.9.0.html

Обновление серверного рендеринга
Мы начали работу над новым серверным рендерером с поддержкой Suspense, но мы не ожидаем, что он будет готов к первоначальному выпуску Concurrent Mode. Этот выпуск, однако, предоставит временное решение, позволяющее существующему рендереру сервера немедленно генерировать HTML для откатов Suspense, а затем отображать их реальный контент на клиенте. Это решение, которое мы в настоящее время используем в Facebook, пока не будет готов рендерер потоковой передачи.

Для тех, кто все еще ждет поддержки потоковой передачи на сервере :)

Есть ли какое-либо обновление или какой-либо другой метод для реализации renderToNodeStream в next.js?

Есть ли обновление?

<3

Есть обновления?

@StarpTech Я немного изучил это (тоже любопытно для этой функции!), И похоже, что команда реагирования работает над чем-то, называемым response-flight , что, вероятно, станет основой для потокового решения, которое мы ждем здесь :)

реагировать-полет:

Это экспериментальный пакет для использования пользовательских потоковых моделей React.

Соответствующие PR, проливающие свет на внутреннюю работу, интерпретируемые мной (не экспертом ни в чем из этого 🙈)
# 17285 : Базовый api для полета, сервер должен иметь возможность передавать все в виде строки, но оставлять заполнители для фрагментов, которые асинхронно разрешаются на сервере. Неполный, но интересный синтаксис того, как response будет узнавать из потока, какой тип данных он фактически представляет, находится здесь .

# 17398 Более свежий PR, добавляет api для Chunks, так что (если вам повезет) вы можете попробовать эту часть самостоятельно. Не знаю, как все сложится, но, тем не менее, я доволен тем, что вся эта работа выполняется :)

_Это может быть немного не по теме, но, надеюсь, будет интересно людям, подписавшимся на этот выпуск :) _

@pepf спасибо за информацию!

Хм. Спасибо всем ребята, интересная информация. Я просто думаю, почему NextJS должен ждать, пока React поддержит SSR для беспокойства и прочего, а не просто использовать streamAsString сейчас?

@arunoda Я думаю, это снизит потребление памяти, что очень важно для лямбда-функций с низким объемом памяти или Cloudflare Workers.

Есть новости об этом?

Какие-нибудь Новости?

Есть новости, ребята? :П

Учитывая, что такая тревожная тревога кажется, что она никогда не выйдет наружу, можем ли мы как-то вернуться к этому? Я вижу начальное время рендеринга 800-1000 мсек на довольно общих страницах с низким содержанием (которые рендерируются бессерверной функцией на vercel). Потоковая передача HTML в теории может увеличить эту начальную точку соприкосновения и привести к гораздо более быстрому восприятию UX при первой загрузке.

Это ограничение Vercel, а не NextJS? Падет ли Vercel жертвой того же холодного стартапа, что и Lambda? Моя команда запускает кучу сайтов с тяжелым контентом, и наше время составляет менее 50 мс для всего запроса. Я не думаю, что стриминг станет здесь серебряной пулей.

Я не ожидаю, что это будет серебряная пуля, но это, безусловно, было бы желанным улучшением.

50 мс звучат мизерно и относительно незначительно для оптимизации по сравнению с упомянутым временем холодного старта, но это не при рендеринге на краю с помощью чего-то вроде Cloudflare Workers (это столько же, сколько пинг до ближайшего краевого местоположения Cloudflare, или как минимум половина ), Cloudflare Workers реагируют очень быстро, обычно менее чем за 5 миллисекунд, при холодном запуске. Напротив, обе функции Lambda и Lambda @ Edge могут занять секунду, чтобы отреагировать на холодный запуск.
Я знаю, что это не лучший аргумент в пользу того, что Varcel (который создает свой собственный cdn) нанял разработчиков next.js для определения этого приоритета.

Есть ли какая-либо документация или репозитории, в которых люди успешно развернули next.js для работников облачной среды? Я немного погуглил и не смог найти в нем много информации. Это было бы потрясающе.

Отправлено с моего телефона

5 июля 2020 г. в 17:47 Wis [email protected] написал:

50 мс звучат очень мало и относительно несущественно для оптимизации по сравнению с упомянутым временем холодного старта, но 50 мс - это много при рендеринге на краю с помощью чего-то вроде Cloudflare Workers (это столько же, сколько пинг до ближайшего краевого местоположения Cloudflare или, по крайней мере, половина), Cloudflare Workers реагируют очень быстро, обычно менее чем за 5 миллисекунд, при холодном запуске. Напротив, обе функции Lambda и Lambda @ Edge могут занять секунду, чтобы отреагировать на холодный запуск.
Я знаю, что это не лучший аргумент в пользу того, что Varcel (который создает свой собственный cdn) нанял разработчиков next.js для определения этого приоритета.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или откажитесь от подписки.

50 мс звучат мизерно и относительно незначительно для оптимизации по сравнению с упомянутым временем холодного старта

Чтобы прояснить, я не жаловался на время отклика в 50 мс - я просто указывал, что SRR NextJS относительно эффективен даже на севере от 3 тыс. Запросов в минуту для страниц с тяжелым контентом, поэтому проблема Switz может лежать в другом месте.

Есть ли какая-либо документация или репозитории, в которых люди успешно развернули next.js для сотрудников Cloudflare?

Мне это тоже было бы интересно. В настоящее время мы работаем в Fargate, но следующим логическим шагом будет продвижение нашего приложения на периферию.

Я внес все возможные улучшения в свой HTML, и время отклика сервера просто невероятное! :(

@huggler, вы можете объединить этот пример с cacheable-response . Вы можете использовать Redis (или, например, кеш в памяти) для хранения HTML в кеше. Это улучшает время отклика сервера.

Есть ли какая-либо документация или репозитории, в которых люди успешно развернули next.js для работников облачной среды? Я немного погуглил и не смог найти в нем много информации. Это было бы потрясающе.

@switz @ tills13 вы проверяли https://fab.dev/ ? Мы играли с ним в начале 2020 года, и он был в стадии предварительного выпуска, но, похоже, они продвинулись довольно далеко. Одним из их ограничений был сам Cloudflare, но сейчас все могло измениться.

Давно не смотрел. Придется переоценить. Последний раз, когда я смотрел, было несколько довольно серьезных компромиссов.

Я также слежу за https://github.com/flareact/flareact.

Есть новости по этому поводу?