Блог

Я разрабатываю веб-сайт, поддерживаемый генератором статического сайта, который будет создавать около 100 тыс. статических HTML-страниц. В настоящее время мой рабочий процесс заключается в создании проекта на моем локальном компьютере и использовании инструмента FTP для загрузки выходной папки (около 40 ГБ) с моего локального компьютера на удаленный рабочий сервер, что является длительным и болезненным процессом загрузки, который может занять около 24 часов.

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

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

Например, вы можете статически генерировать только 10 000 наиболее запрашиваемых во время сборки, чтобы сократить время сборки. Затем во время запроса вы можете использовать Next.js и инкрементная статическая регенерация для создания статических страниц.

Допустим, поступает запрос на одну из 90 000 страниц, которые вы не сгенерировали статически. Вместо получения статического сайта первый запрос попадет на сервер для извлечения данных и создания статической страницы. Затем эта страница кэшируется. Когда другой пользователь посещает эту страницу, он увидит статическую страницу (что намного быстрее, чем прямое общение с сервером).

Вы также можете аннулировать кеш, используя revalidate флаг. Например, вы могли бы заставить свою страницу получать новую информацию каждую минуту, используя revalidate: 60 .

Развертывание Next.js приложение для Vercel, использующее эту настройку, должно сократить время сборки и развертывания до менее чем 10 минут, при этом все еще создавая высокопроизводительный статический сайт. Просто git push в ваш репозиторий, и интеграция с GitHub создаст и развернет ваше приложение для вас. Больше никакого FTP!

Gatsby недавно добавил функцию для исправления этого (или для попытки), которая называется инкрементными сборками. По сути, он кэширует все ваши данные и повторно развертывает измененные файлы и изменения кода.

На самом деле, кажется, что эта функция ограничена Gatsby Cloud или другой CMS и недоступна для пользовательского сервера развертывания. Вот пример для достижения этого в Netlify.

До этих недавних изменений в политике Gatsby вам нужно только добавить переменную среды в команду deploy:

 GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true gatsby build
  

Имейте в виду, что этот параметр подходит не для всех серверов развертывания. Если вы заново создаете свою /public папку в каждой сборке с нуля, это не сработает.

Другой вариант — использовать огромную машину S3 от Amazon и отключить ее после завершения развертывания.