image


React.js — это сейчас одна из самых популярных библиотек для создания современных веб-приложений. React славится гибкостью и богатством экосистемы. Одним из значительных достоинств этой экосистемы является Next.js — и то, как он успешно развивается. С этим фреймворком стало значительно удобнее разрабатывать приложения на основе React, их возможности расширились. В этой статье мы рассмотрим, как Next.js улучшил React, затронем его особенности, преимущества, и что из них вытекает.

Что такое Next.js?


Next.js — это открытый фреймворк React для фронтенд-разработки, который позволяет реализовать, в частности, рендеринг на стороне сервера и генерацию статических веб-сайтов для веб-приложений на основе React. Это фреймворк более высокоуровневый, чем React, построенный на основе React и помогающий стандартизировать разработку быстрых, хорошо масштабируемых и удобных веб-приложений.

Рендеринг на стороне сервера (SSR) и статическая генерация сайтов (SSG)


Когда в Next.js появились функции рендеринга на стороне сервера (SSR) и статической генерации сайтов (SSG), возможности приложений React значительно расширились, особенно в том, что касается поисковой оптимизации (SEO) и производительности. Давайте подробнее рассмотрим, как эти функции помогают решать конкретные задачи и находить надежные решения.

Сложность работы с React:


  • Приложения React обычно отображаются в браузере клиента. Хотя такой рендеринг на стороне клиента отлично подходит для интерактивных веб-приложений, у него есть недостатки, особенно касающиеся SEO и медленной первичной загрузки страниц.
  • Поисковики системы иногда с трудом индексируют страницы с JavaScript и клиентскими рендерами, что может негативно сказаться на SEO.
  • Рендеринг на стороне клиента также означает, что содержимое страницы становится доступно не сразу, поскольку перед рендерингом необходимо загрузить и запустить JavaScript, из-за чего загрузка, опять же, замедляется.

Чтобы проиллюстрировать, как Next.js развился на основе традиционного React и эффективно решает проблемы, связанные с рендерингом на стороне клиента, давайте рассмотрим пример с кодом. Мы создадим простую страницу блога, на которой продемонстрируем как SSR, так и SSG в Next.js.

Пример: Страница блога с React (традиционный подход)


В типичной конфигурации React можно получать посты из блога на стороне клиента, например, так:

// Blog.js (используется React)
import React, { useState, useEffect } from 'react';

const Blog = () => {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    fetch('/api/posts')
      .then(response => response.json())
      .then(data => setPosts(data));
  }, []);

  return (
    <div>
      {posts.map(post => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.content}</p>
        </article>
      ))}
    </div>
  );
};

export default Blog;

При таком подходе данные собираются на стороне клиента, из-за этого замедляется загрузка и ухудшаются показатели SEO, поскольку контент не сразу поступает на индексирование в поисковых системах.

Переход на Next.js с применением SSR


Решение Next.js, в котором применяется SSR:
  • SSR в Next.js отображает компоненты React на стороне сервера, заранее генерируя полный HTML для каждой страницы.
  • Когда пользователь или поисковый бот запрашивает страницу, сервер отправляет полностью структурированный HTML, обеспечивая немедленный доступ к контенту. Это способствует SEO, так как поисковые системы могут легко просматривать и индексировать содержимое страницы.
  • SSR также ощутимо улучшает производительность, особенно при первичной загрузке страницы, так как пользователи получают полностью сформированную страницу быстрее.
  • Такой подход особенно полезен на сайтах с большим объемом контента, в частности, в блогах или интернет-магазинах, где качественная SEO и быстрая доставка контента имеют решающее значение.

В Next.js мы можем использовать рендеринг на стороне сервера для получения данных ещё до того, как страница будет отображена:

// pages/blog.js (using Next.js with SSR)
import React from 'react';

const Blog = ({ posts }) => (
  <div>
    {posts.map(post => (
      <article key={post.id}>
        <h2>{post.title}</h2>
        <p>{post.content}</p>
      </article>
    ))}
  </div>
);

export async function getServerSideProps() {
  const response = await fetch('https://example.com/api/posts');
  const posts = await response.json();
  return {
    props: { posts },
  };
}

export default Blog;

Здесь getServerSideProps получает данные с сервера до того, как страница будет отображена. Тем самым гарантируется, что HTML-разметка, отправленная в браузер, уже содержит посты из блога.

Как это работает:

1. Получение данных на сервере: Каждый раз, когда пользователь запрашивает страницу из блога, на сервере запускается getServerSideProps.

2. Fetch API: Получает записи блога из внешнего API. (https://example.com/api/posts).

3. Возврат элементов: Полученные записи возвращаются в качестве элементов компонента Blog.Render

4. Страница: Next.js затем отображает компонент Blog на стороне сервера, используя эти пропсы, и отправляет полностью отображённый HTML на клиент.
Пример использования: этот подход идеален, когда содержимое блога часто меняется, и вы хотите, чтобы на странице всегда отображались самые актуальные записи.

Лучшие примеры использования статической генерации сайта (SSG)


1. Блоги и сайты с документацией:
  • Контент, который редко меняется, идеально подходит для SSG.
  • Быстрая загрузка и превосходные показатели SEO, поскольку страницы предварительно преобразуются в статический HTML..

2. Маркетинговые веб-сайты:
  • Корпоративные, целевые или портфолио страницы, где контент в основном статичен.
  • SSG обеспечивает высокую производительность, что очень важно для удобства пользователей и для целей SEO.

3. Списки товаров в интернет-магазинах:
  • Для страниц, содержание которых меняется нечасто, например, для списков товаров.
  • Ускоряет загрузку страниц, благодаря чему покупки делать приятнее.

4. Порталы с общедоступным контентом:
  • Новостные сайты или образовательные ресурсы со статичными статьями.
  • SSG легко справляется с большим трафиком благодаря CDN-кэшированию.

Реализация статической генерации сайта (SSG)


Проблемы с динамическим рендерингом:
  • Динамический рендеринг страниц, несмотря на большие возможности, может быть ресурсоемким и более медленным, чем традиционные подходы поскольку при каждом запросе серверу приходится рендерить страницу заново.
  • Из-за этого могут возникать «узкие места» в производительности, особенно в условиях высокого трафика..

Решение Next.js с использованием SSG:
  • С помощью SSG Next.js предварительно обновляет страницы во время сборки. Это означает, что статические HTML-файлы для каждой страницы генерируются заранее.
  • Эти статические файлы можно подать непосредственно из CDN, что значительно снижает нагрузку на сервер и ускоряет доставку контента.
  • SSG идеально подходит для сайтов с нечасто меняющимся содержимым, таких как сайты документации, блоги или маркетинговые страницы.
  • Такой подход также обеспечивает практически мгновенную загрузку и снижает нагрузку на сервер, поскольку ему не нужно рендерить страницы для каждого запроса.
  • Next.js также позволяет осуществлять инкрементную статическую регенерацию (ISR), при которой страницы обновляются через заданные промежутки времени или по требованию, обеспечивая актуальность содержимого без ущерба для производительности.

Если записи в блоге меняются нечасто, мы можем использовать статическую генерацию сайта для повышения производительности:

// pages/blog.js (использование Next.js с SSG)
import React from 'react';

const Blog = ({ posts }) => (
  // ... как и ранее
);

export async function getStaticProps() {
  const response = await fetch('https://example.com/api/posts');
  const posts = await response.json();
  return {
    props: { posts },
    revalidate: 10, // Инкрементная статическая регенерация (ISR),  на которую требуются считанные секунды
  };
}

export default Blog;

В этом случае страница генерируется во время сборки и подается как статический файл. С помощью функции инкрементной статической регенерации (опция revalidate) страница может периодически обновляться, обеспечивая свежесть содержимого.

Как это работает:

1. Получение данных во время сборки: getStaticProps запускается во время сборки, получая записи блога из API.

2. Статическая генерация: Страница Blog предварительно отображается в виде статического HTML с полученными данными.

3. Переаттестация: Ключ revalidate, установленный на 10, включает ISR. Он указывает Next.js обновлять страницу не чаще чем раз в 10 секунд, если поступают новые запросы.

4. Подача статической страницы: Статично сгенерированная страница обслуживается пользователями. Если через 10 секунд страница запрашивается снова, а данные изменились, Next.js регенерирует страницу с обновленным содержимым.

Пример использования: Этот метод подходит для содержания блогов, не требующих обновления в реальном времени. ISR гарантирует, что содержимое не устарело, периодически обновляя страницу.

Лучшие примеры использования рендеринга на стороне сервера (SSR)


1. Динамические пользовательские панели:
  • Приложения, в которых содержимое зависит от конкретного пользователя и часто меняется, например, пользовательские панели в SaaS-приложениях.
  • SSR гарантирует, что контент будет актуальным и персонализированным для каждого пользователя.

2. Сайты электронной коммерции с динамическим контентом:
  • Страницы с часто меняющимся содержимым, например, прайс-листы, сведения о наличии товаров на складе или отзывы пользователей.
  • SSR может динамически генерировать страницы на основе поступающих данных в режиме реального времени.

3. Социальные сети:
  • Сайты с быстро меняющимся содержанием, например, ленты социальных сетей или форумы.
  • SSR позволяет динамически отображать контент, что очень важно для таких интерактивных платформ.

4. Сайты, характеризующиеся интенсивным взаимодействием с пользователями и данными в реальном времени:
  • Такие приложения, как платформы для онлайн-трейдинга, прямые трансляции спортивных событий или интерактивные игровые сайты.
  • SSR помогает предоставлять актуальный контент при каждом запросе, что очень важно для точности данных в реальном времени.

Выбор между SSG и SSR


Компромисс между производительностью и свежестью данных:
  • SSG обеспечивает более высокую производительность и масштабируемость, поскольку обслуживает статические файлы.
  • SSR обеспечивает более свежий контент, но сам подход может быть более ресурсоемким.

Аспекты SEO:
  • И SSG, и SSR подходят для SEO. SSG может выигрывать за счёт ускорения загрузки, но SSR больше подходит для динамического контента, который должен быть проиндексирован.

Разработка и обслуживание:
  • SSG, как правило, проще разрабатывать и поддерживать для сайтов со статичным содержимым.
  • SSR может быть более сложным, но необходим для динамичных, ориентированных на пользователя приложений.

Заключение


Сочетая SSR и SSG, Next.js предоставляет разработчикам мощные инструменты для преодоления ограничений клиентского рендеринга в React. Эти приёмы позволяют улучшить поисковую оптимизацию, обеспечивают более быструю загрузку и более эффективное использование ресурсов сервера. Выбор между SSR и SSG (или гибридным подходом) может быть сделан в зависимости от конкретных потребностей приложения, от того, что для вас более актуально: динамическая интерактивность или оптимизированную производительность. Такая гибкость — значительный прогресс в создании современных, масштабируемых и высокопроизводительных веб-приложений на React.

Комментарии (4)


  1. Propan671
    28.06.2024 12:37
    +11

    Мне очень нравятся буллетпоинты, где одно и то же переформулировано несколько раз и выдается под видами "вот вам 5 преимуществ Next JS" + возвращаемся к SEO через каждые 3 слова. Можно, пожалуйста, меньше использовать GPT для генерации материала для блога? Это как минимум неуважительно - люди должны тратить время на прочтение, а вы даже не потратили его на написание/редактуру.

    В статье заявлен разбор "всех преимуществ Next", но поговорили только о SSR и SSG (хотя и неплохо для джунов). В общем, пожалуйста, работайте над материалом перед его выкладыванием.


  1. oldd
    28.06.2024 12:37
    +3

    Лучшие примеры использования рендеринга на стороне сервера (SSR)

    4. Сайты, характеризующиеся интенсивным взаимодействием с пользователями и данными в реальном времени:

    Вы ничего не путаете? Предлагаете сделать чат на ssr, чтобы страничку постоянно перезагружать?


  1. gun_dose
    28.06.2024 12:37
    +3

    SSG хорошо подходит для простых сайтов, где контент редко меняется. Но прикол в том, что для таких сайтов в принципе не нужен реакт.

    Я работал с некстом ещё когда там не было SSG. Это была 6-я версия. До этого много работал с Drupal. В целом некст очень нравился, единственное, что время ответа сервера всегда оставляло желать лучшего. Даже после всех оптимизаций время ответа составляло 500-700мс. Для сравнения, для Drupal этот показатель считается очень плохим, там норма без кэширования страниц 200-300мс. И вот, время шло, а некст всё не становился быстрее. И вдруг с очередной новой версией вышел SSG. Для моих кейсов он не годился, поэтому я остался на SSR, который с новыми версиями так и не стал быстрее.

    В итоге я пришёл к выводу, что сами разрабы next.js уже опустили руки в попытках сделать его быстрее и выпустили костыль в виде SSG. Да именно костыль. Идее сгенерировать весь сайт в статику сто лет в обед, и это всегда было "оружием судного дня", которое применяли лишь в том случае, когда другие способы не дают должного эффекта. К слову, для сайтов написанных на php это нужно крайне редко.

    Почему же next такой медленный? Всё просто: реакт на бэкенде - это просто дикий оверхэд. Что такое реакт? Это virtual DOM + миллион слушателей событий. Зачем слушатели событий на бэкенде? Какое событие может произойти в время рендеринга страницы, когда там нет ни window, ни document, ни юзера с мышкой или клавой? Странно, что мало кто это понимает.


  1. rtatarinov
    28.06.2024 12:37

    О чем эта статья вообще? Где реальный сравнительный анализ. NextJs быстрее, чем SPA. Дайте нам метрики с LCP например.

    Seo, seo, seo. Почему nextjs, а не prerender например, который решает вопросы seo? Слишком поверхностная статья