Использовать один процесс рендеринга в браузере что это
Русские Блоги
Принцип рендеринга браузера, о котором вы не знаете
Предисловие
В этой статье мы берем Webkit в качестве примера для проведения глубокого анализа процесса рендеринга в современных браузерах.
Если хотите читать больше качественных статей, ткните пожалуйстаБлог GitHub。
Процесс загрузки страницы
Перед тем как представить процесс рендеринга в браузере, мы кратко познакомим вас с процессом загрузки страницы, который поможет лучше понять последующий процесс рендеринга.
Основные моменты заключаются в следующем:
Браузер получает IP-адрес доменного имени в соответствии с DNS-сервером;
Отправить HTTP-запрос на эту IP-машину;
Сервер получает, обрабатывает и возвращает HTTP-запрос;
Браузер получает возвращенный контент.
Сервер получает HTTP-запрос, а затем после расчета (отправка разного контента разным пользователям) возвращает HTTP-запрос. Возвращаемое содержимое выглядит следующим образом:
Фактически, это набор строк формата HMTL, потому что только браузеры формата HTML могут правильно анализировать его, что является требованием стандарта W3C. Следующим шагом является процесс рендеринга в браузере.
Процесс рендеринга в браузере
Процесс рендеринга в браузере примерно разделен на следующие три части:
1) Браузер проанализирует три вещи:
2) После завершения анализа движок браузера построит дерево рендеринга через дерево DOM и дерево правил CSS.
Дерево рендеринга Дерево рендеринга не эквивалентно дереву DOM.Дерево рендеринга включает только узлы, которые необходимо отобразить, и информацию о стиле этих узлов.
Дерево правил CSS в основном предназначено для завершения сопоставления и присоединения правила CSS к каждому элементу (то есть каждому кадру) в дереве рендеринга.
Затем вычислите положение каждого кадра, что также называется процессом компоновки и перекомпоновки.
3) Наконец, нарисуйте, вызвав API собственного графического интерфейса операционной системы.
Далее мы подробно расскажем о важных шагах, которые мы прошли.
Постройте DOM
Браузер выполнит ряд шагов для преобразования файлов HTML в деревья DOM. Макроскопически его можно разделить на несколько этапов:
Браузер считывает необработанные байты HTML с диска или сети и преобразует их в строки в соответствии с указанной кодировкой файла (например, UTF-8).
Контент, передаваемый по сети, на самом деле представляет собой данные размером 0 и 1 байт. Когда браузер получает эти байтовые данные, он преобразует байтовые данные в строку, которая и является кодом, который мы написали.
Преобразуйте строку в токен, например: \u0026lt;html\u0026gt; 、 \u0026lt;body\u0026gt; Подождите.Токен будет определять, является ли текущий токен «начальным тегом», «конечным тегом» или «текстом», а также другой информацией.。
В это время у вас должны возникнуть вопросы, как сохранить связь между узлами?
Фактически, это роль Token для идентификации «начального тега» и «конечного тега». Например, узел между начальным тегом и конечным тегом токена «title» должен быть дочерним узлом «head».
На рисунке выше показана взаимосвязь между узлами. Например, токен «Hello» расположен между начальным тегом «title» и конечным тегом «title», что указывает на то, что токен «Hello» является дочерним узлом токена «title». Точно так же токен «title» является дочерним узлом токена «head».
Фактически, в процессе построения DOM, вместо ожидания преобразования всех токенов, создаются объекты узлов. Вместо этого генерируются токены при использовании токенов для создания узловых объектов. Другими словами, после того, как каждый токен сгенерирован, токен будет немедленно использован для создания объекта узла.Примечание. Токен с закрывающим тегом не создает объект узла.
Далее мы приводим пример, предполагая, что есть текст HTML:
Приведенный выше HTML проанализирует это:
Создать CSSOM
DOM захватит содержимое страницы, но браузер также должен знать, как отображать страницу, поэтому необходимо создать CSSOM.
В этом процессе браузер будет определять стиль каждого узла, и на самом деле этот процесс очень ресурсоемкий. Потому что вы можете установить стиль для узла самостоятельно или получить его через наследование. В этом процессе браузер должен повторно просмотреть дерево CSSOM, а затем определить, в каком стиле находится конкретный элемент.
Постройте дерево рендеринга
После того, как мы сгенерируем дерево DOM и дерево CSSOM, нам нужно объединить два дерева в дерево отрисовки.
У нас могут возникнуть сомнения:Что делать, если браузер обнаруживает JS-файлы во время рендеринга？
Другими словами, если вы хотите отобразить первый экран быстрее, на первом экране должно быть загружено меньше файлов JS, поэтому рекомендуется размещать тег скрипта внизу тега body. Конечно, на данный момент это не означает, что тег скрипта должен быть размещен внизу, потому что вы можете добавить атрибуты defer или async к тегу скрипта (разница между ними будет представлена ниже).
Файлы JS не только блокируют построение DOM, но и заставляют CSSOM блокировать построение DOM.。
Первоначально построение DOM и CSSOM не влияло друг на друга. Однако, как только был введен JavaScript, CSSOM начал блокировать построение DOM. Только после создания CSSOM DOM возобновляет построение DOM.
Это связано с тем, что JavaScript может не только изменять DOM, но и изменять стиль, то есть изменять CSSOM. Поскольку неполный CSSOM нельзя использовать, если JavaScript хочет получить доступ к CSSOM и изменить его, то при выполнении JavaScript он должен иметь возможность получить полный CSSOM. Таким образом, это приводит к явлению: если браузер не завершил загрузку и построение CSSOM, а мы хотим запустить скрипт в это время, браузер задержит выполнение скрипта и построение DOM до тех пор, пока не завершит загрузку и построение CSSOM. Другими словами,В этом случае браузер сначала загрузит и создаст CSSOM, затем выполнит JavaScript и, наконец, продолжит построение DOM.。
Макет и чертеж
После того, как браузер сгенерирует дерево рендеринга, оно будет расположено в соответствии с деревом рендеринга (также называемое перекомпоновкой). На этом этапе браузер должен определить точное положение и размер каждого узла на странице. Обычно такое поведение также называется «автоматическая перестановка».
Результатом процесса макета является «блочная модель», которая точно фиксирует точное положение и размер каждого элемента в области просмотра, а все относительные измерения будут преобразованы в абсолютные пиксели на экране.
После завершения макета браузер немедленно выдаст события «Paint Setup» и «Paint» для преобразования дерева рендеринга в пиксели на экране.
Выше мы подробно рассказали о важных этапах рабочего процесса браузера, а затем обсудим несколько связанных вопросов:
Несколько дополнительных примечаний
1. Какова роль async и defer? Какая разница?
Затем давайте сравним разницу между атрибутами defer и async:
Синяя линия представляет загрузку JavaScript; красная линия представляет выполнение JavaScript; зеленая линия представляет анализ HTML.
1) Ситуация 1 \u0026lt;script src=\u0026quot;script.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt;
Без defer или async браузер сразу загрузит и выполнит указанный сценарий, что означает, что он загрузит и выполнит элемент документа, не дожидаясь последующей загрузки.
2) Ситуация 2 \u0026lt;script async src=\u0026quot;script.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt; (Асинхронная загрузка)
3) Ситуация 3 \u0026lt;script defer src=\u0026quot;script.js\u0026quot;\u0026gt;\u0026lt;/script\u0026gt; (Отсроченное исполнение)
Атрибут defer представляет отложенное выполнение введенного JavaScript, то есть HTML не прекращает синтаксический анализ, когда этот JavaScript загружен, и два процесса являются параллельными. После того, как весь документ проанализирован и загружен defer-script (порядок этих двух вещей не имеет значения), весь код JavaScript, загруженный defer-script, будет выполнен, а затем будет запущено событие DOMContentLoaded.
2. Почему манипулировать DOM медленно?
Думайте о DOM и JavaScript как об отдельных островах, соединенных между собой платным мостом. —— «Высокопроизводительный JavaScript»
3. Вы действительно разбираетесь в перерисовке и перерисовке?
Процесс рендеринга в основном выглядит следующим образом (четыре шага желтого цвета на рисунке ниже):
1. Расчет стиля CSS
2. Постройте дерево рендеринга
3.Координаты и размер макета-позиционирования
4. Официально приступить к покраске
Примечание. В приведенном выше процессе есть много соединительных линий, что означает, что Javascript динамически изменяет атрибуты DOM или свойства CSS, что приведет к повторному макету, но некоторые изменения не будут повторять макет. Это стрелки, указывающие на небо на изображении выше, например изменение Следующее правило CSS не соответствует элементу.
Перерисовка: когда наша модификация DOM вызывает изменение стиля, но не влияет на его геометрические свойства (например, изменение цвета или цвета фона), браузеру не нужно пересчитывать геометрические свойства элемента и напрямую рисовать новый элемент. Стиль (пропустите ссылку переформатирования, показанную на рисунке выше).
Reflow: когда наша модификация DOM вызывает изменение геометрического размера DOM (например, изменение ширины, высоты или скрытых элементов элемента), браузеру необходимо пересчитать геометрические свойства элемента (геометрические свойства и положение других элементов также будут затронуты соответствующим образом. Затронуто), а затем нарисовать результаты вычислений.Этот процесс называется перекомпоновкой (также называемой перегруппировкой).
Мы знаем, что при создании веб-страницы она будет отображаться как минимум один раз. В процессе доступа пользователя он будет продолжать перерисовку. Повторный рендеринг будет повторять перерисовку + перерисовку или только перерисовку.
Reflow обязательно вызовет перерисовку, а перерисовка не обязательно вызовет перерисовку. При установке стилей узлов часто происходит перерисовка и перекомпоновка, что также сильно влияет на производительность. Стоимость перекомпоновки намного выше, чем стоимость перерисовки. Изменение дочерних узлов в родительском узле может вызвать серию перекомпоновок родительского узла.
1) Общие атрибуты и методы, вызывающие переформатирование
Любая операция, изменяющая геометрическую информацию элемента (положение и размер элемента), вызовет перекомпоновку,
Добавить или удалить видимые элементы DOM;
Изменения содержимого, например, ввод текста пользователем в поле ввода;
Вычислить свойства offsetWidth и offsetHeight;
Установите значение атрибута стиля.
2) Общие атрибуты и методы, вызывающие перерисовку
3) Как уменьшить переформатирование и перерисовку
Используйте преобразование вместо вершины;
Замените display: none на видимость, потому что первый вызовет только перерисовку, а второй вызовет перекомпоновку (измените макет);
Не помещайте значение атрибута узла в цикл как переменную в цикле.
Не используйте макет таблицы, небольшое изменение может привести к изменению макета всей таблицы;
Выбор скорости реализации анимации, чем выше скорость анимации, тем больше времени перекомпоновки, вы также можете использовать requestAnimationFrame;
Селектор CSS сопоставляет и выполняет поиск справа налево, чтобы избежать слишком большого количества уровней узлов;
Задайте узел, который часто перерисовывается или перекомпоновывается, как слой.Слой может предотвратить влияние режима визуализации узла на другие узлы. Например, для тега видео браузер автоматически превратит узел в слой.
Стратегия оптимизации производительности
На основе представленного выше принципа рендеринга браузера, последовательности построения DOM и структуры CSSOM, инициализация может оптимизировать рендеринг страницы и повысить производительность страницы.
Оптимизация JS: \u0026lt;script\u0026gt; Тег плюс атрибут defer и атрибут async используются для управления загрузкой и выполнением скрипта без блокировки синтаксического анализа документа страницы.
Атрибут Defer: используется для запуска нового потока для загрузки файла сценария и выполнения сценария после анализа документа.
Атрибут async: новый атрибут HTML5, используемый для асинхронной загрузки файлов сценария и немедленного объяснения и выполнения кода после загрузки.
Оптимизация CSS: \u0026lt;link\u0026gt; Установка значения атрибута в атрибуте rel тега как preload позволяет вам указать на вашей HTML-странице, какие ресурсы необходимы сразу после загрузки страницы, оптимально настроить порядок загрузки и улучшить производительность отрисовки.
подводить итоги
Подводя итог, мы приходим к такому выводу:
CSSOM заблокирует рендеринг, и только когда CSSOM будет построен, он перейдет на следующий этап построения дерева рендеринга.
Обычно DOM и CSSOM строятся параллельно, но когда браузер встречает тег скрипта без атрибутов defer или async, построение DOM приостанавливается. Если случится так, что браузер еще не завершил загрузку и построение CSSOM, потому что JavaScript может изменять CSSOM, поэтому вам нужно дождаться сборки CSSOM перед выполнением JS и, наконец, перестроить DOM.
Рендеринг WEB-страницы: что об этом должен знать front-end разработчик
Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.
Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.
Отмечу, что статья нацелена не на точную передачу механики работы браузеров, а, скорее, на понимание её общих принципов. Тем более, разные браузерные движки сильно отличаются в алгоритмах работы, поэтому охватить все нюансы в рамках одной статьи не представляется возможным.
Процесс обработки WEB-страницы браузером
Для начала, рассмотрим последовательность работы браузера при отображении документа:
Repaint
Reflow
Если же изменения затрагивают содержимое, структуру документа, положение элементов — происходит reflow (или relayout). Причинами таких изменений обычно являются:
Оптимизация со стороны браузера
Браузеры по возможности локализуют repaint и reflow в пределах элементов, подвергнувшимися изменению. Например, изменение размеров абсолютно или фиксировано спозиционированного элемента затронет только сам элемент и его потомков, в то время как изменение статично спозиционированного — повлечет reflow всех элементов, следующих за ним.
Ещё одна особенность — во время выполнения JavaScript браузеры кэшируют вносимые изменения, и применяют их в один проход по завершению работы блока кода. Например, в ходе выполнения данного кода произойдет только один reflow и repaint:
Однако, как описано выше, обращение к свойствам элементов вызовет принудительный reflow. То есть, если мы в приведённый блок кода добавим обращение к свойству элемента, это вызовет лишний reflow:
В итоге мы получим 2 reflow вместо одного. Поэтому, обращения к свойствам элементов по возможности нужно группировать в одном месте, дабы оптимизировать производительность (см. более подробный пример на JSBin).
Затем, попробуем реализовать задуманное следующим образом:
Данное решение не будет работать, как ожидается, т.к. изменения кэшируются и применяются только в конце блока кода. Нас выручит принудительный reflow, в результате код приобретёт следующий вид, и будет в точности выполнять поставленную задачу:
Практические советы по оптимизации
На основе данной статьи, а также других статей на Харбе, где освещается вопрос оптимизации клиентской части, можно вывести следующие советы, которые пригодятся при создании эффективного фронтенда:
Надеюсь, каждый читатель извлёк из статьи что-нибудь полезное. В любом случае — спасибо за внимание!
UPD: Спасибо SelenIT2 и piumosso за верные замечания по поводу эффективности обработки CSS-селекторов.
Рендеринг в веб
о переводе
Наше понимание в этой области основано на нашей работе с 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