SSG для большого каталога: сколько страниц можно генерировать

SSG для большого каталога не имеет универсального лимита по числу страниц: практический предел определяется временем сборки, доступной памятью, количеством одновременно запускаемых задач, размером данных и тем, как устроена генерация HTML. Для небольшого и среднего каталога все публичные страницы можно создать заранее. При росте числа маршрутов сборка начинает зависеть от стоимости обработки каждой страницы, запуска браузера, запросов к данным и записи файлов. Поэтому оценивать масштаб нужно не по одному числу URL, а по измеренному времени, пиковому потреблению памяти, частоте обновлений и допустимому времени публикации.

Что такое SSG

Static Site Generation создаёт HTML-файлы во время сборки, а не при каждом запросе пользователя. В результате сервер может отдавать заранее подготовленные документы и статические ресурсы. Такой подход подходит для страниц, содержимое которых известно до публикации: карточек товаров или услуг, статей, категорий и информационных страниц.

SSG не означает, что приложение полностью лишено JavaScript. В готовой странице могут оставаться клиентские компоненты, интерактивные формы и другие функции. Главное отличие в том, что основной публичный HTML создаётся заранее.

Для большого каталога SSG работает по одному принципу: система получает список записей, строит для каждой записи URL, генерирует HTML, сохраняет результат и проверяет созданный файл. Чем больше маршрутов и чем тяжелее обработка одного маршрута, тем выше общее время сборки.

От чего зависит предел

Число страниц, которое можно сгенерировать за одну сборку, определяется несколькими параметрами:

• временем генерации одной страницы;
• объёмом данных, загружаемых для маршрутов;
• размером итогового HTML;
• количеством JavaScript и CSS-ресурсов;
• использованием браузера при пререндеринге;
• числом параллельных задач;
• доступной памятью и процессорным временем;
• скоростью файловой системы;
• частотой обновления каталога;
• ограничениями CI-среды и хостинга.

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

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

Последовательная генерация

В последовательном режиме система обрабатывает один маршрут за другим. Такой способ проще всего отлаживать: для каждого URL можно сохранить время начала, время окончания, статус, размер HTML и причину ошибки.

Преимущества последовательного режима:

• низкая пиковая нагрузка;
• предсказуемое потребление памяти;
• простая диагностика;
• понятный порядок логов;
• меньше конфликтов при записи файлов.

Недостаток — длительное время сборки. Если один маршрут обрабатывается несколько секунд, большой каталог может собираться долго даже при небольшой сложности каждой страницы.

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

Параллельная генерация

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

Для пререндеринга через Puppeteer обычно ограничивают количество одновременно открытых страниц. Не нужно создавать новый процесс браузера для каждого URL. Более предсказуемая схема — один браузер, ограниченное число вкладок, тайм-аут для каждой страницы и обязательное закрытие вкладки после завершения.

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

Результат нужно сохранять в уникальный путь. До запуска задач необходимо проверить отсутствие одинаковых slug и конфликтов между маршрутами.

Память и браузер

В SSG память расходуется на данные каталога, сборщик, процесс Node.js, браузер, открытые страницы, DOM, ресурсы и внутренние структуры приложения. При пререндеринге особенно важно учитывать, что браузер может быть тяжелее простой функции преобразования данных.

Node.js позволяет получать сведения о памяти процесса через process.memoryUsage(). Среди показателей есть RSS, общий размер heap, используемая часть heap, внешняя память и память массивов. Эти данные можно записывать после каждой группы маршрутов, чтобы увидеть рост потребления во время сборки. [web:100]

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

Для диагностики фиксируют:

• память перед началом сборки;
• память после загрузки данных;
• память после каждой партии маршрутов;
• максимальное значение RSS;
• время обработки каждого маршрута;
• размер созданного HTML;
• количество ошибок и повторных попыток.

Нельзя выбирать число параллельных задач только по количеству ядер процессора. Ограничение должно подтверждаться измерением памяти и стабильностью сборки.

Данные каталога

Большой каталог может перегружать сборку ещё до генерации HTML. Если все записи, изображения, характеристики и связанные сущности загружаются в память одним объектом, память расходуется независимо от количества одновременно обрабатываемых страниц.

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

Важно разделять список маршрутов и содержимое страницы. Для построения списка может быть достаточно идентификатора и slug. Полные данные можно загружать только во время генерации соответствующего маршрута. Такой подход уменьшает объём данных, удерживаемых в памяти одновременно.

Если каталог поступает из API, запросы должны иметь тайм-аут, обработку ошибок и ограничение частоты. Неограниченный параллельный поток запросов может перегрузить источник данных, а сборка станет нестабильной.

Кеширование

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

Кеш должен иметь понятное правило актуальности. Если после изменения товара или услуги старый HTML остаётся в кеше, публикация выдаст устаревшую страницу. Поэтому ключ кеша должен зависеть от идентификатора записи, версии данных или времени обновления.

Кеширование не означает, что страницу можно не проверять. После использования кеша всё равно нужно убедиться, что файл существует, соответствует текущему маршруту и содержит актуальные метаданные.

В CI нужно отдельно проверять, когда кеш восстанавливается и когда сборка действительно выполняет генерацию заново. Иначе время сборки может выглядеть хорошим только из-за сохранённых результатов.

Инкрементальный подход

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

Для этого нужно определить связь между изменением данных и URL. Изменение записи должно приводить к повторной генерации её страницы, связанных категорий, пагинации и других документов, в которых это изменение отображается.

Инкрементальная схема требует контроля старых файлов. Если запись удалена или стала недоступной, её прежний HTML не должен оставаться опубликованным без решения о статусе URL. Для удалённых страниц применяют корректную обработку 404 или 410 в зависимости от задачи.

У инкрементальной публикации появляется дополнительная сложность: набор файлов на сервере может быть результатом нескольких сборок. Нужна процедура удаления устаревших документов и проверка соответствия sitemap фактически доступным страницам.

Пагинация и категории

Большой каталог часто включает не только страницы отдельных элементов, но и категории, фильтры, сортировки и пагинацию. Каждая дополнительная комбинация параметров может увеличить число маршрутов.

До генерации нужно решить, какие страницы являются самостоятельными публичными документами. Нельзя автоматически создавать HTML для каждой комбинации фильтров, если эти URL не имеют самостоятельной пользы, уникального содержания и понятной стратегии индексации.

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

Для каждого типа маршрута нужно определить собственные метаданные, canonical и правила включения в sitemap. Страница списка не должна случайно получать title и canonical от отдельной карточки.

Приоритеты генерации

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

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

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

Контроль времени сборки

Время сборки нужно измерять по этапам, а не только выводить общий результат. Минимальные этапы:

• подготовка данных;
• создание списка маршрутов;
• генерация каждой группы страниц;
• обработка ассетов;
• запись HTML;
• валидация;
• упаковка и публикация.

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

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

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

Надёжность публикации

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

Для каждого маршрута проверяют существование HTML, title, H1, основной текст, canonical и ожидаемые ссылки. Для каталога дополнительно проверяют уникальность slug, отсутствие дублирования файлов и соответствие количества опубликованных записей списку данных.

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

Для ошибок полезно сохранять входные данные, URL, лог браузера, скриншот и HTML. Это ускоряет повторное воспроизведение и помогает отделить ошибку данных от ошибки генератора.

Когда полный SSG не подходит

Полная статическая генерация может быть неудачным выбором, если каталог очень часто меняется, страницы зависят от пользователя, данные должны быть актуальны в момент запроса или количество маршрутов постоянно растёт без контроля.

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

Выбор зависит не только от SEO. Важны допустимое время публикации, стоимость CI, требования к свежести, сложность данных, размер команды и возможность контролировать ошибки.

Практическая схема выбора

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

Для среднего каталога подходит ограниченная параллельность, кеширование данных, измерение памяти и разделение маршрутов по типам.

Для большого каталога нужна архитектура с партиями, приоритетами, инкрементальными обновлениями, контролем устаревших файлов и отдельным мониторингом времени сборки.

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

Чек-лист большого каталога

• Определён полный набор типов маршрутов.
• Список URL строится из единого источника данных.
• Дублирующиеся slug обнаруживаются до генерации.
• Разделены список маршрутов и полные данные страницы.
• Установлен лимит параллельности.
• Закрываются вкладки и браузерные ресурсы.
• Измеряются время и память по группам маршрутов.
• API-запросы имеют тайм-аут и обработку ошибок.
• Настроено кеширование с правилом актуальности.
• Определено, когда нужна полная, а когда инкрементальная сборка.
• Удалённые записи не оставляют старый HTML.
• Фильтры и параметры не создают бесконтрольные дубли.
• Для каждой страницы проверяются title, H1, текст и canonical.
• Отчёт разделяет успешные, пропущенные и ошибочные маршруты.
• Важные страницы имеют более высокий приоритет.
• Публикация не считается успешной при пропуске обязательных URL.

Источники

• Vite: Building for Production — https://vite.dev/guide/build
• Vite: Deploying a Static Site — https://vite.dev/guide/static-deploy
• Node.js: Process and memoryUsage — https://nodejs.org/api/process.html
• Node.js: Understanding and Tuning Memory — https://nodejs.org/learn/diagnostics/memory/understanding-and-tuning-memory
• Puppeteer: Chrome for Developers — https://developer.chrome.com/docs/puppeteer
• Puppeteer: Getting Started — https://pptr.dev/guides/getting-started