И снова всем привет! Судя по реакциям и количеству закладок к переводу первой части книги Patterns.dev, этот материал оказался для вас полезен. Поэтому я решил поделиться переводом второй части.
В ней речь идет про паттерны рендеринга. В случае правильного подбора можно получить более быструю сборку и отличную производительность загрузки при низких затратах на обработку.
Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed Insights, Chrome User Experience Report и другими.
Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей второй части учебника можно найти здесь.
P. S.: На данный момент выложено в виде pdf, в дальнейшем планируется полноценная публикация на github для удобства изучения
P. P. S.: Вторая часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0
Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
Введение
Когда вы начинаете разрабатывать новое веб-приложение, одно из основных решений, которое вы принимаете, — «Как и где я хочу отображать контент?». Должен ли он отображаться на веб-сервере, сервере сборки, на Edge или непосредственно на клиенте? Должен ли он отображаться сразу, частично или постепенно?
Ответы на эти важные решения во многом зависят от варианта использования. Выбор наиболее подходящего паттерна рендеринга может иметь огромное значение для взаимодействия с разработчиком (DX), которое вы создаете для команды инженеров, и взаимодействия с пользователем (UX), которое вы разрабатываете для конечных пользователей.
Выбор правильного паттерна может привести к более быстрой сборке и отличной производительности загрузки при низких затратах на обработку. С другой стороны, неправильный выбор паттерна может убить приложение, которое могло бы воплотить в жизнь отличную бизнес-идею. Таким образом, вы должны убедиться, что каждая революционная идея, которую вы имеете, переходит в разработку с соответствующим паттерном рендеринга.
Важность паттернов рендеринга
Чтобы создать отличный UX, мы обычно пытаемся оптимизировать наши приложения для показателей, ориентированных на пользователя, таких как Core Web Vitals (CWV). Метрики CWV измеряют параметры, наиболее важные для взаимодействия с пользователем. Оптимизация CWV может помочь обеспечить удобство работы пользователей и оптимальное SEO для наших приложений.
Чтобы создать отличный DX для наших продуктовых/инженерных команд, мы должны оптимизировать наши среды разработки, обеспечив более быстрое время сборки, простой откат, масштабируемую инфраструктуру и многие другие функции, которые помогают разработчикам добиться успеха.
Настройка среды разработки на основе этих принципов позволяет нашим командам разработчиков эффективно создавать отличные продукты. Суммируя наши ожидания, мы составили довольно длинный список. Но, если вы выберете правильный паттерн рендеринга, вы сможете получить большинство этих преимуществ из коробки.
Выбор паттерна
Паттерны рендеринга прошли долгий путь от рендеринга на стороне сервера (SSR) и рендеринга на стороне клиента (CSR) до паттернов со множеством нюансов, обсуждаемых и оцениваемых сегодня на разных форумах. Хотя это может показаться ошеломляющим, важно помнить, что каждый паттерн был разработан для конкретных случаев использования. Характеристика паттерна, полезная для одного варианта использования, может быть вредной для другого. Также вполне вероятно, что разные типы страниц требуют разных паттернов рендеринга на одном и том же веб-сайте.
Команда Chrome призвала разработчиков рассмотреть возможность статического рендеринга или рендеринга на стороне сервера вместо подхода полной регидратации. Со временем методы прогрессивной загрузки и рендеринга по умолчанию могут помочь найти хороший баланс производительности и предоставления функций при использовании современной платформы. В следующих главах подробно рассматриваются различные паттерны — старые и новые. Но сначала мы кратко представим некоторые из них, чтобы помочь вам понять, где они работают лучше всего.
Статический рендеринг
Статический рендеринг — это простой, но мощный паттерн, который вы можете использовать для создания быстрых веб-сайтов с почти мгновенной загрузкой страниц. При статическом рендеринге HTML для всей страницы генерируется во время сборки и не изменяется до следующей сборки. HTML-контент является статическим и легко кэшируется в CDN или пограничной сети. Сети CDN могут быстро предоставлять предварительно обработанный кэшированный HTML-код клиентам, когда они запрашивают определенную страницу. Это значительно сокращает время, которое в противном случае потребовалось бы для обработки запроса, рендеринга содержимого HTML и ответа на запрос при типичной настройке рендеринга на стороне сервера. Описанный выше процесс больше всего подходит для страниц, которые нечасто меняются и отображают одни и те же данные независимо от того, кто их запрашивает. Поскольку сегодня мы потребляем много динамических, настраиваемых данных в Интернете, у нас есть разновидности статического рендеринга для различных вариантов использования.
Базовый/простой статический рендеринг
Поскольку существует множество вариантов статического рендеринга, давайте назовем основной метод, который мы обсуждали ранее, простым статическим рендерингом. Вы можете использовать его для страниц с небольшим или отсутствующим динамическим контентом.
Обычный статический рендеринг отлично подходит для повышения производительности, поскольку он приводит к чрезвычайно быстрому TTFB, поскольку HTML уже доступен на сервере. Браузер получает более быстрый ответ и может быстро его отобразить, что приводит к быстрым FCP и LCP. Поскольку содержимое статично, при его рендеринге не происходит сдвига макета.
Таким образом, простой статический рендеринг, особенно с использованием CDN для кэширования, помогает достичь больших показателей Core Web Vitals. Однако на большинстве веб-сайтов есть хотя бы некоторый динамический контент или взаимодействие с пользователем.
Статический рендеринг на стороне клиента fetch
Допустим, мы хотим улучшить нашу демонстрацию недвижимости, чтобы отображать самые последние списки недвижимости. Нам пришлось бы использовать поставщика данных, чтобы получить эти списки.
В этом случае мы можем использовать статический рендеринг с fetch на стороне клиента. Этот паттерн отлично работает, когда вы хотите обновлять данные при каждом запросе.
Вы по-прежнему можете использовать статический рендеринг для веб-сайта, чтобы отобразить пользовательский интерфейс со скелетным компонентом, где вы хотите разместить данные динамического списка. Затем, после загрузки страницы, мы можем получить данные (например, используя SWR) на клиенте.
Пользовательский маршрут API применяется для извлечения данных из CMS и возврата этих данных.
Предварительно созданный файл HTML отправляется клиенту, когда пользователь запрашивает страницу. Сначала пользователь видит каркас пользовательского интерфейса без каких-либо данных. Клиент извлекает данные из маршрута API, получает ответ и показывает списки. (вызов гидратации не включен в пример) дает ответ и показывает списки (вызов гидратации не включен в пример).
В то время как статическая визуализация с fetch на стороне клиента дает нам хорошие TTFB и FCP, LCP не оптимальна, поскольку «самый большой контент» может отображаться только после того, как мы получим данные списков из маршрута API.
Существует также большая вероятность изменения макета, особенно если размер каркаса пользовательского интерфейса не соответствует отображаемому в конечном итоге контенту. Другим недостатком является то, что этот подход может привести к более высоким затратам на сервер, поскольку мы вызываем маршрут API один раз для каждого запроса страницы. Next.js предлагает некоторые решения, описанные в следующих разделах, для повышения производительности вашего приложения при работе с динамическими данными.