77t rendering что это такое
Rendering: Теория
Типичный graphics pipeline практически не отличается в realtime и в не-realtime рендеринге и включает в себя следующие «стадии»:
— преобразования в «мировой» системе координат, учитывающие такие «трансформации» объектов, как перемещение, вращение, масштабирование, сдвиг;
— преобразования в координатном простанстве «виртуальной» камеры (в пространстве «наблюдателя трехмерной сцены»), которые переводят «мировые» координаты объектов в координаты «поля зрения» наблюдателя;
— полученные после предыдущего этапа координаты годятся для изометрической проекции (используемой, как правило, в системах автоматизированного проектирования), для «реалистичного» рендеринга требуется еще учитывать перспективные искажения, что и делается путем перспективных преобразований.
Матрица, «ответсттвенная» за перемещение объекта на расстояние x, y, z вдоль соответствующих координатных осей:
А эти матрицы выполняют вращение объекта на соответствующий угол вокруг осей x, y, z:
Для полноты картины надо добавить еще матрицу масштабирования вдоль осей x, y, z. Вот она:
Чтобы не возиться с каждым преобразованием по отдельности, матрицы перемножают согласно правилам матричной алгебры и в результате получают матрицу «мировых» преобразований:
Подобные матрицы существуют и для преобразований в координатном пространстве камеры (наблюдателя) и для перспективных преобразований. Не будем себе забивать голову, а сразу приведем «результирующее» преобразование точки с координатами x, y, z в трехмерном виртуальном пространстве сцены в пиксел с координатами x’, y’, z’, w’ (координата w’ используется для придания координатной системе «однородности» с размерностью матриц, а координата z’ используется для построения «карты глубины» (или Z-буфера), которая понадобится на следующих стадиях рендеринга):
На практике, конечно, все эти формулы с синусами-косинусами преобразуют к более удобному для вычислений виду, например, такому:
[ Матричные преобразования и методы HSR, работающие в координатном пространстве «наблюдателя», с вычислительной точки зрения довольно тривиальны и с успехом выполняются GPU современных видеокарт, освобождая CPU для решения более сложных задач рендеринга. ]
Ray casting (метод «бросания» луча) используется в realtime-рендеринге (например, в компьютерных играх), где скорость «создания картинок» важнее их «качества». Суть метода в следующем: из «точки наблюдения» в направлении пиксела, цвет которого определяется, «выстреливается» воображаемый луч. Если луч пересекает какой-нибудь примитив, то этот примитив «окрашивает» соответствующий пиксел в свой цвет. Существуют вариации метода, когда «бросаются» дополнительные лучи от примитива в «точку наблюдения» или от источника света в сторону примитива (для вычисления освещенности и теней). Для вычисления освещенности примитива могут использоваться и данные, полученные методом radiosity.
Radiosity (или метод излучения) часто называют Global Illumination, хотя, сторого говоря, radiosity всего лишь один из алгоритмов вычисления этой самой «глобальной освещенности», который используется, как правило, в сочетании с другими алгоритмами. Методом radiosity пытаются моделировать путь отраженного от поверхности света, который в реальности отражается не в одном направлении («угол отражения равен углу падения»), а рассеивается (diffusion) в простанственную полусферу, «освещая» целую область вокруг точки падения, при этом цвет рассеянного света изменяется в соответствии с цветом поверхности в точке падения луча. Сложность и точность метода radiosity варьируется в очень широких пределах. В realtime-рендеринге и при рендеринге outdoor-сцен глобальную освещенность имитируют с помощью нехитрого трюка, слегка «освещая» всю сцену воображаемым источником света, называемым ambiance (окружающая среда). А вот в сочетании с методом трассировки лучей (ray tracing) radiosity позволяет получить очень реалистичные изображения, особенно при рендеринге indoor-сцен, правда, ценой увеличения во много раз времени рендеринга :(. Впрочем, многие 3D-программы позволяют «вручную» дать «указания» рендеру, какие объекты будут участвовать в рассчете глобальной освещенности, а какие нет, при этом можно получить очень хороший (в смысле реалистичности) результат гораздо быстрей.
Как же «функционирует» алгоритм radiosity? Если выражаться корректно, то алгоритм «оперирует» не лучами, а световой энергией, «циркулирующей» в трехмерной сцене. В общем случае трехмерная сцена состоит их бесконечного множества точек, «обменивающихся» световой энергией. Проследить все эти «взаимодействия» не представляется возможным, поэтому бесконечное множество точек заменяют на конечное число «участков» (patches) поверхностей, образующих трехмерную сцену. Способов «разбиения» на участки довольно много, но универсального, пригодного «на все случаи жизни», пока не изобрели. Алгоритм radiosity многопроходный, на каждом проходе для каждого «участка» вычисляется световая энергия, пришедшая к нему от других участков. Часть этой энергии поглощается участком, остальное «отражается» обратно в сцену и учитывается при следующем проходе. В математическом виде это выглядит так:
После первого прохода «засвеченными» оказываются участки, на которые падает прямой свет от источника. С каждым следующим проходом количество «засвеченных» участков оказывается все больше (за счет отраженной световой энергии), сцена светлеет, пока не приходит в «равновесное» состояние, когда последующие проходы практически ничего уже не меняют.
Как уже упоминалось, метод radiosity дает «частное» решение уравнения рендеринга, поэтому при «реалистичном» рендеринге radiosity используется в компании с другими методами, в первую очередь с ray tracing.
Для того, чтобы метод трассировки лучей мог работать, все поверхности в сцене должны быть математически описаны (в виде формул). «Забота» по математическому описанию возложена на программы моделирования, хотя можно делать и «вручную» на «встроенных» языках 3D-программ. Рассмотрим на примере сферы, как работает типичный «трассер». На языке аналитической геометрии это «звучит» так: найти точки пересечения сферы радиусом Sr и центром (Sx, Sy, Sz), описываемой уравнением
[ Как видим, найти точки пресечения луча с самой замысловатой поверхностью с «вычислительной» точки зрения не представляет никаких трудностей. По крайней мере, для центрального процессора (CPU). Попытки возложить «тяготы» трассировки на специализированные устройства («усовершенствованную» видеокарту, например) предпринимаются постоянно, достигнуты определенные успехи, но до «широкого внедрения» подобных устройств пока далеко. И опять же, для чего нужен будет CPU, если всю работу за него будут выполнять «подмастерья» :)? ]
Ежели пустить процесс «размножения» лучей «на самотек», то результата (вычисленного цвета пиксела) мы никогда не дождемся. Поэтому на «процесс» накладывают определенные ограничения, типа максимального количества отражений/преломлений, после которого трассировка луча прекращается. Трассировка также прекращается, если луч попадает в источник света или в тень. Таким образом все «соударения» исходного луча с поверхностями в сцене учитываются при формировании цвета пиксела «отрендеренного» изображения.
Дополнительные лучи «генерятся» также для «обсчета» таких эффектов, как «трехмерный» motion blur, Depth of Field, «объемных» эффектов и других.
Методом фотонных карт (photon mapping) моделируются такие оптические явления, как каустические пятна (caustics), диффузные «межотражения» (как в методе radiosity) и некоторые другие. Как и в методе radiosity, «засветка» трехмерной сцены фотонами не зависит от положения «наблюдателя» и этот факт можно использовать для «реалистичной» анимации сцен, единственным движущимся объектом в которых является камера. А вот «картинка», получаемая методом ray tracing, целиком зависит от положения «наблюдателя», поэтому при рендеринге анимации трассировку в каждом кадре приходится начинать «по новой».
Что такое рендеринг на стороне сервера и нужен ли он мне?
В новом году начнем общение с вами с затравочной статьи о серверном рендеринге (server-side rendering). В случае вашей заинтересованности возможна более свежая публикация о Nuxt.js и дальнейшая издательская работа в этом направлении
С появлением современных фреймворков и библиотек для JavaScript, которые предназначены, прежде всего, для создания интерактивных веб-страниц и одностраничных приложений, сильно изменился весь процесс показа страниц пользователю.
До пришествия приложений, полностью генерируемых на JS в браузере, HTML-разметка выдавалась клиенту в ответ на HTTP-вызов. Это могло происходить путем возврата статического HTML-файла с контентом, либо путем обработки отклика при помощи какого-либо серверного языка (PHP, Python или Java), причем, более динамическим образом.
Подобное решение позволяет создавать отзывчивые сайты, работающие гораздо быстрее стандартных сайтов, действующих по модели «запрос-отклик», поскольку при работе устраняется время, проводимое запросом «в пути».
Типичный отклик, отправляемый сервером на запрос к сайту, написанному на React, будет выглядеть примерно так:
В этот момент уже можно воспользоваться встроенным в браузер инспектором HTML, чтобы просмотреть весь отображенный HTML. Однако, заглянув в исходный код, мы не увидим ничего кроме HTML, приведенного выше.
Почему это проблема?
Хотя такое поведение и не доставит проблем большинству наших пользователей либо при разработке приложения, оно может стать нежелательным, если:
“Ладно, но в демографическом отношении моя целевая аудитория точно не относится ни к одной из этих групп, так стоит ли мне волноваться?”
Есть еще две вещи, которые следует учитывать при работе с приложением, рендеринг в котором выполняется на стороне клиента: поисковики и присутствие в социальных сетях.
Сегодня из всех поисковиков лишь Google обладает некоторыми возможностями отобразить и сайт и учесть его JS прежде, чем отобразить страницу. Кроме того, хотя Google и сможет отобразить индексную страницу вашего сайта, известно, что могут возникать проблемы с навигацией по сайтам, на которых реализован роутер.
Это означает, что вашему сайту будет очень непросто забраться в топ выдачи любого поисковика кроме Google.
Та же проблема просматривается и в социальных сетях, например, в Facebook — если ссылкой на ваш сайт поделятся, то ни его название, ни картинка-превью не отобразятся как следует.
Как решить эту проблему
Есть несколько способов ее решения.
A — Попробуйте оставить все ключевые страницы вашего сайта статическими
Когда создается сайт-платформа, куда пользователю придется входить под своим логином, а без входа в систему контент посетителю не предоставляется, можно попробовать оставить статическими (написанными на HTML) общедоступные страницы вашего сайта, в частности, индекс, «о нас», «контакты» и не использовать JS при их отображении.
Поскольку ваш контент ограничен требованиями по входу в систему, он не будет индексироваться поисковиками, и им нельзя будет поделиться в социальных сетях.
B — Генерируйте части вашего приложения в виде HTML-страниц в процессе сборки
В проект можно добавить такие библиотеки как react-snapshot; они используются для генерации HTML-копий страниц вашего приложения и для сохранения их в специально предназначенном каталоге. Затем этот каталог развертывается наряду с пакетом JS. Таким образом, HTML будет подаваться с сервера вместе с откликом, и ваш сайт увидят в том числе те пользователи, у которых отключен JavaScript, а также заметят поисковики и т.д.
Как правило, сконфигурировать react-snapshot не составляет труда: достаточно добавить библиотеку в ваш проект и изменить сборочный скрипт следующим образом:
C — Создать на JS приложение, использующее серверный рендеринг
Один из важнейших выигрышных моментов у современного поколения приложений на JS заключается в том, что их можно запускать как на клиенте (в браузере), так и на сервере. Так удается генерировать HTML для страниц, являющихся более динамичными, таких, чей контент в период сборки еще не известен. Подобные приложения часто называют «изоморфными» или «универсальными».
Два наиболее популярных решения, обеспечивающих серверный рендеринг для React:
Создайте собственную реализацию SSR
Важно: если вы собираетесь попробовать самостоятельно создать собственную реализацию SSR для приложений на React, то должны будете обеспечить работу node-бэкенда для вашего сервера. Вы не сможете развернуть это решение на статическом хосте, как в случае со страницами github.
Первым делом нам понадобится создать приложение, точно как в случае с любым другим приложением React.
Давайте создадим входную точку:
И компонент-приложение (App):
А также “оболочку”, чтобы загрузить наше приложение:
Express – это мощный веб-сервер для node, pug – движок-шаблонизатор, который можно использовать с express, а babel-node – это обертка для node, обеспечивает транспиляцию на лету.
Сначала скопируем наш файл index.html и сохраним его как index.pug :
Создадим наш сервер:
Разберем этот файл по порядку.
При помощи renderToString мы отображаем наше приложение. Код выглядит точно как у входной точки, но такое совпадение не является обязательным.
Теперь, когда у нас есть отображенный HTML, мы приказываем express отобразить в ответ файл index.pug и заменить переменную app тем HTML, что мы получили.
Наконец, мы обеспечиваем запуск сервера и настраиваем его так, чтобы он слушал порт 3000.
Теперь нам осталось всего лишь добавить нужный скрипт в package.json :
Если все выглядит именно так, это означает, что серверный рендеринг работает как положено, и можно приступать к расширению вашего приложения!
Зачем же нам по-прежнему нужен bundle.js?
В случае такого крайне простого приложения, которое рассмотрено здесь, включать bundle.js не обязательно – без этого файла наше приложение все равно останется работоспособным. Но в случае с реальным приложением включить этот файл все-таки потребуется.
Это позволит браузерам, умеющим обрабатывать JavaScript, взять работу на себя и далее взаимодействовать с вашей страницей уже на стороне клиента, а тем, что не умеют разбирать JS – перейти на страницу с нужным HTML, который возвратил сервер.
О чем необходимо помнить
Притом, что серверный рендеринг выглядит достаточно незамысловато, при разработке приложений нужно обращать внимание на некоторые темы, на первый взгляд не вполне очевидные:
Разные GPU-тесты (Redshift,Fstorm,Octane,V-Ray,Arnold и т.д.) (обновлено 3 апреля 2021)
Всем привет. Делал я как-то давно такие тесты и решил запостить их здесь. Думаю многим будет интересно. Не смотря на то, что 3я серия уже давно вышла, 2080Ti пока не потеряли своей актуальности и вполне себя прекрасно показывают, хотя думаю скоро и до 3й серии доберусь =) А пока вот такой длинопост с кучей разных тестов.Приятного чтения и просмотра!
Графические процессоры NVIDIA в сочетании с драйверами Studio обеспечивают высокий уровень производительности и возможностей для самых требовательных графических приложений. Узнайте, какие преимущества для ваших любимых приложений обеспечивает ускорение на GPU NVIDIA.
Сделал вывод, что с новыми Nvidia Studio быстрее.
Да и Походу они добавили ускорялку в Out of Core. =) Как говорил Lino. Несколько секунд прибавляет. Так что включайте эту опцию, когда рендерите свои сцены, насыщенные миллионами поликов.
Update: В самом новом Redshift уже внедрили Optix 7.2, который еще быстрее.
Далее, Макс Ачковский кинул свои тесты в нашу Octane группу, расхваливал V-Ray с новыми дровами.
На этой сценке хороший прирост с RTX и новыми дровами. И это учитывая тот факт, что вирей у него пиратский, не последний =) на 5й бетке я думаю вообще будет песня. Жду сцену
И видяха 2070, на которой еще RTX не в полной мере работает =) Но человек доволен приростом.
Render Time = 4m RTX
Render Time = 2m
Render Time = 43s
6 мая 2020
Так, сегодня затестил выход за 11 Гб одной видеокарты =) Keyshot тянет. Значит Nvlink работает.
15 млр поликов. 15 гб памяти скушало из 22 Гб. Все работает.
Забавно, что GTA 5 тоже видит 22 гб.
23 июня 2020
Очередной тест производительности. Но уже с FStorm.
7.09.2020
22.09.2020
11.10.2020
18.10.2020
На этом пока все друзья. Однозначно буду еще делать тесты и постить их в новых постах.
Всем хорошего дня и настроения.
С Уважением,
Кривуля Андрей Charly
Рендеринг в веб
о переводе
Наше понимание в этой области основано на нашей работе с Chrome, и контактировании с большими сайтами в течение последних нескольких лет. В общем, мы хотим вдохновить разработчиков рассмотреть использование серверного рендеринга или статического рендеринга с полноценной регидратацией.
Чтобы лучше понимать архитектуры, из которых мы выбираем, когда принимаем решение, нам необходимо иметь четкое понимание каждого подхода и последовательную терминологию, которую мы будем использовать, когда говорим о них. Различия между этими подходами помогают проиллюстрировать компромиссы при рендеринге в вебе через призму производительности.
Терминология
Рендеринг
Rehydration (регидратация): «загрузка» JavaScript отображениий на клиенте таким образом, чтобы они повторно использовали отрендеренное на сервере DOM-дерево и данные HTML-а
Prerendering (пре-рендеринг): выполнение клиентского приложения во время сборки для захвата его начального состояния в виде статического HTML.
Performance
Server Rendering (Серверный рендеринг)
Серверный рендеринг генерирует полный HTML страницы на сервере в ответ на навигацию. Это позволяет избежать дополнительных проходов для получения данных и шаблонов на клиенте, так как это выполняется до того, как браузер получает ответ..
Серверный рендеринг обычно даёт быстрый First Paint (FP) и First Contentful Paint (FCP). Выполнение логики страницы и её рендеринг на сервере позволяют избежать отправки большого количества JavaScript клиенту, что помогает достичь быстрого Time to Interactive (TTI). Это имеет смысл потому, что при серверном рендеринге вы на самом деле просто посылаете текст и ссылки в браузер пользователя. Такой подход может хорошо работать для широкого спектра устройств и сетевых условий и открывает интересные возможности для оптимизации браузера, например можно выполнять разбор потоковых (streaming) документов.
При серверном рендеринге пользователи вряд ли будут вынуждены ждать, пока CPU-зависимый JavaScript будет выполнен, прежде чем они смогут использовать ваш сайт. Даже когда стороннего JS не избежать, использование серверного рендеринга для уменьшения собственных JS costs (JS затрат) может дать вам больше «budget» (бюжета) для остального. Однако, есть один основной недостаток такого подхода: генерация страниц на сервере занимает время, что часто может привести к замедлению Time to First Byte (TTFB).
Достаточно ли серверного рендеринга для вашего приложения, во многом зависит от того, какое приложение вы строите. Существует давняя дискуссия о правильности применения серверного рендеринга вместо клиентского рендеринга, но важно помнить, что вы можете использовать серверный рендеринг для одних страниц, а для других нет. Некоторые сайты с успехом переняли гибридный рендеринг. Netflix делает серверный рендеринг своих относительно статических страниц, в то время как делает prefetching JS для страниц с тяжелым взаимодействием, давая этим более тяжелым отрендеренным на клиенте страницам больше шансов на быструю загрузку.
Многие современные фреймворки, библиотеки и архитектуры позволяют отрисовывать одно и то же приложение как на клиенте, так и на сервере. Эти инструменты могут быть использованы для Server Rendering, однако важно отметить, что архитектуры, где рендеринг происходит как на сервере, так и на клиенте, являются собственным классом решений с очень различными характеристиками производительности и компромисами. React пользователи могут использовать для серверного рендеринга renderToString() или решения, построенные на нем, такие как Next.js. Пользователи Vue могут ознакомиться с руководством по серверному рендерингу Vue или познакомиться с Nuxt. В Angular есть Universal. Однако большинство популярных решений используют ту или иную форму гидратации (hydration), поэтому перед выбором инструмента следует ознакомиться с используемыми подходами.
Static Rendering (Статический рендеринг)
Решения для статического рендеринга бывают разных форм и размеров. Такие инструменты как Gatsby разработаны для того, чтобы разработчики чувствовали, что их приложение отрисовывается динамически, а не генерируется на этапе сборки. Другие, такие как Jekyll и Metalsmith, принимают их статическую природу, предоставляя подход более заточенный на шаблоны.
Одним из недостатков статического рендеринга является то, что отдельные HTML-файлы должны быть сгенерированы для каждого возможного URL. Это может быть сложно или даже невозможно, когда вы не можете предсказать, какими будут эти URL заранее, или если на сайте большое количество уникальных страниц.
Если вы не уверены, является ли решение статическим рендерингом или пре-рендерингом, попробуйте такой тест: отключите JavaScript и загрузите созданные веб-страницы. У статически отрендеренных страниц бОльшая часть функционала все равно будет существовать и без включённого JavaScript. У пре-рендеренных страниц все еще может быть некоторая базовая функциональность, такая как ссылки, но бОльшая часть страницы будет неживой.
Серверный рендеринг против статического
Серверный рендеринг генерирует HTML по требованию для каждого URL, но это может быть медленнее, чем просто обслуживание статически отрендереного контента. Если вы готовы сделать дополнительные усилия, то серверный рендеринг + [HTML кеширование] (https://freecontent.manning.com/caching-in-react/) может значительно сократить время серверного рендеринга. Положительной стороной серверного рендеринга является возможность получать более «живые» данные и отвечать на более полный набор запросов, чем это возможно при статическом рендеринге. Страницы, требующие персонализации, являются хорошим примером типа запроса, который плохо работает со статическим рендерингом.
Серверный рендеринг также может представлять интересные решения при построении PWA. Лучше ли использовать full-page service worker кеширование, или просто рендерить на сервере отдельные фрагменты контента?
Client-Side Rendering (CSR)
Рендеринг на стороне клиента (CSR) означает рендеринг страниц непосредственно в браузере с использованием JavaScript. Вся логика, сбор данных, шаблонирование и маршрутизация обрабатываются на клиенте, а не на сервере.
Для тех, кто создает одностраничное приложение, определение основных частей пользовательского интерфейса, разделяемого большинством страниц, означает возможность применить технику Application Shell caching. В сочетании с service workers это может драматически повысить воспринимаемую производительность при повторных визитах.
Комбинация серверного рендеринга и клиентского через регидратацию
Часто называемый Universal Rendering или просто «SSR», этот подход пытается сгладить компромиссы клиентского и серверного редеринга, делая и то, и другое. Навигационные запросы, такие как полная загрузка страницы или перезагрузка, обрабатываются сервером, который рендерит приложение в HTML, затем JavaScript и данные, используемые для рендеринга, встраиваются в результирующий документ. При тщательной реализации, это даёт быстрый FCP (First Contentful Paint) такой же, как Server Rendering, а далее «усиливает это» путем рендеринга опять же на клиенте с помощью техники, называемой (re)hydration ((ре)гидратация). Это новое решение, но оно может иметь некоторые существенные недостатки в производительности.
Основной недостаток SSR с регидратацией (rehydration) заключается в том, что она может оказать значительное негативное влияние на TTI (Time To Interactive), даже если она улучшает FP (First Paint). SSR-страницы часто выглядят обманчиво полностью загруженными и интерактивными, но на самом деле не могут реагировать на ввод, пока не будет выполнен JS на стороне клиента и не будут прикреплены обработчики событий. Это может занять секунды или даже минуты на мобильном устройстве.
= Проблема регидратации: Одно приложение по цене двух
Проблемы с регидратацией часто могут быть хуже, чем задержка интерактивности из-за JS. Для того, чтобы JavaScript на стороне клиента мог точно «определить» («pick up») то место, где остановился сервер, без необходимости повторно запрашивать все данные, использованные сервером для рендеринга этого HTML, текущие SSR решения обычно сериализуют ответ из зависимых данных UI в документ в виде тегов script. Полученный HTML-документ содержит высокий уровень дублирования:
Как вы видите, сервер возвращает описание пользовательского интерфейса приложения в ответ на навигационный запрос, но также возвращает исходные данные, использованные для составления этого интерфейса, и полную копию реализации интерфейса, которая затем загружается на клиенте. Только после того, как bundle.js завершит загрузку и выполнение, этот пользовательский интерфейс станет интерактивным.
Показатели производительности, собранные с реальных веб-сайтов, использующих SSR регидратацию, указывают на то, что их использование должно приводить в уныние. В конце концов, причина сводится к Пользовательскому Опыту: очень легко оставить пользователей в «жуткой долине».
Но всё же надежда на SSR с регидратацией есть. В краткосрочной перспективе, только использование SSR для высоко кешируемого содержимого может уменьшить задержку TTFB (Time to First Byte), давая результаты, схожие с пре-рендерингом. Регидратация инкрементальная, прогрессивная или частичная, может быть ключом к тому, чтобы сделать эту технику более жизнеспособной в будущем.
Потоковый серверный рендеринг и прогрессивная регидратация
Серверный рендеринг за последние несколько лет претерпел ряд изменений.
= Частичная регидратация
Частичная регидратация оказалась трудной для осуществления. Этот подход является продолжением идеи прогрессивной регидратации, когда отдельные части (компоненты / виджеты / деревья), подлежащие прогрессивной регидратации, анализируются, а те, которые обладают низкой интерактивностью или не обладают реактивностью помечаются. Для каждой из этих наиболее статических частей соответствующий код JavaScript затем трансформируется в инертные ссылки и декоративную функциональность, уменьшая их влияние на стороне клиента до почти нулевого уровня. Подход, основанный на частичной гидратации, имеет свои собственные проблемы и компромиссы. Он создает некоторые интересные вызовы для кеширования, а навигация на стороне клиента означает, что мы не можем иметь HTML рендерящийся на сервере для инертных частей приложения и доступный без полной загрузки страницы.
= Трисоморфный рендеринг (Trisomorphic Rendering)
Если service workers, являются подходящим вариантом для вас, то «трисоморфный» рендеринг также может быть вам интересен. Это метод, при котором вы можете использовать потоковый серверный рендеринг для начальных/не-JS навигаций, а затем попросить ваш service worker взять на себя рендеринг HTML для навигации после того как он будет смонтирован. Это может поддерживать кешированные компоненты и шаблоны в актуальном состоянии и позволяет использовать навигацию в стиле SPA для рендеринга новых UI-частей в той же сессии. Такой подход лучше всего работает, когда вы можете поделиться одним и тем же шаблоном и кодом маршрутизации между сервером, клиентской страницей и service worker.
SEO соображения
Команды часто учитывают влияние SEO при выборе стратегии для рендеринга в вебе. Серверный рендеринг часто выбирается для обеспечения поисковым роботам возможности лёгкого «полного поиска». Поисковые роботы могут понимать JavaScript, но часто существуют ограничения, о которых стоит знать в части того как они рендерят. Рендеринг на стороне клиента может работать, но часто не без дополнительного тестирования и трудной работы. В последнее время динамический рендеринг также стал вариантом, заслуживающим внимания, если ваша архитектура в значительной степени ориентирована на клиентский JavaScript.
В случае сомнений, инструмент Mobile Friendly Test бесценен для проверки, что выбранный вами подход делает то, что бы вы хотели. Он показывает визуальный предварительный просмотр того, как какую-либо страницу видет поисковый робот Google, сериализованный HTML контент, найденный (после выполнения JavaScript), и любые ошибки, обнаруженные во время рендеринга.
Заключение.
При принятии решения о подходе к рендерингу, измеряйте и понимайте, каковы ваши «узкие места». Подумайте, может ли статический рендеринг или серверный рендеринг дать вам хотя бы 90% возможностей. Совершенно нормально обычно отправлять HTML с минимальным количеством JS, чтобы получить интерактивный опыт. Вот удобная инфографика, показывающая спектр возможностей в разрезе сервер-клиент:
Благодарности
Спасибо всем этим людям за отзывы и вдохновение:
Jeffrey Posnick, Houssein Djirdeh, Shubhie Panicker, Chris Harrelson, and Sebastian Markbåge