static site generation что это

Cogear.JS – современный генератор статических сайтов

Хочу представить вниманию хабровчан генератор статических сайтов с открытым исходным кодом, написанный на Node.JS, в основе которого лежит Webpack.

Проект вдохновлён тем же Jekyll, но в основе своей использует современный технологический стек. Например, предоставляет возможность «горячей подгрузки» (без перезагрузки страницы) изменённых скриптов и стилей.

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

Особенности

Для каких целей подойдёт:

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

Можно сделать даже коллективный блог, при помощи Pull Requests на Github.

При помощи Firebase или любого другого API, написанного на любом языке (PHP, Ruby, Python, Node.JS) или даже с помощью WordPress (JSON-API), и современного фронтэнд фреймворка типа Vue.JS или React, можно сделать динамический сайт под более сложные задачи: интернет-магазин, каталог продукции и так далее.

Для чего не подойдёт:

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

Требования

Надобно иметь установленные Node.JS (9.x или выше) и NPM (обычно идут вместе).

Скачать и установить (если ещё этого не сделали).

Рекомендуется последняя (v10.12.0) верися Node.JS.

Теперь можно сгенерировать первый сайт.

Использование

Перейдите в директорию, где хранятся Ваши веб-сайты.

Вызовите комнаду на генерацию нового сайта:

После чего проследуйте в данную директорию:

Запустите Cogear.JS в режиме development (разработка) или production (подготовка к продакшену) (больше о режимах работы).

Опции

Полезные ссылки

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

Источник

Выбираем генератор статических сайтов

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

Первая публикация в этом цикле будет посвящено сравнительному анализу генераторов статических сайтов.

Критерии сравнения

Генератором статических сайтов называется программный инструмент, превращающий текстовые записи (с разметкой или без) в статичные HTML-страницы. Все инструменты такого рода работают примерно одинаково: берется контент, склеивается с шаблоном, после чего отправляется на хостинг. Количество существующих генераторов статических сайтов исчисляется сотнями, если не тысячами.

Обзор генераторов

MiddleMan, Jekyll, Octopress

Все три из перечисленных генераторов написаны на Ruby и во многом схожи по набору функций. Именно поэтому мы решили объединить их в одну группу.

Процедура установки всех этих продуктов сопряжена с некоторыми трудностями: версии Ruby, включенной в официальные репозитории Linux-систем, скорее всего будет недостаточно — придется обновить ее до самой последней. Также потребуется установить менеджер пакетов RubyGems и менеджер версий Rbenv.

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

Поддерживается деплой с помощью FTP, SFTP, rsync, git (на официальном сайте выложены скрипты для автоматизации процедуры деплоя; еще одно расширение опубликовано на GitHub). Возможен также деплой на AWS и BitBalloon (имеются соответствующие плагины).

Jekyll (см. также статью на Хабре ) известен в первую очередь тем, что используется в качесте дефолтного движка для статических сайтов на основе GitHub Pages. Очень часто он используется для ведения блогов. Несомненным преимуществом Jekyll является поддержка разметки Liquid: это дает возможность создавать шаблоны, используя конструкции исключительно языка разметки, а не языка программирования.

Расширений и плагинов для Jekyll существует довольно много (см. информацию на официальном сайте, а также здесь и здесь). Официальные плагины «заточены» в основном на работу с GitHub Pages. Плагины, опубликованные на GitHub, в большинстве своем предназначены для расширения возможностей блоггинга (добавление облака тэгов, полнотекстовый поиск по блогу и даже специализированный плагин для научных и образовательных блогов).

Поддерживается деплой по FTP, а также с помощью rsync и git.

В отличие от двух предыдущих продуктов, Octopress является специализированным генератором: он по сути представляет собой надстройку над Jekyll c дополнительными плагинами и responsive-шаблоном, обеспечивающими более удобное ведение блогов.

В качестве формата разметки постов по умолчанию используется Markdown, но можно использовать и обычный HTML. Несомненным плюсом Octopress является поддержка переезда с других площадок: например, все записи из блога на WordPress можно перенести в новый статический блог при помощи специального скрипта (правда, велика вероятность того, что после переноса оформление некоторых текстов может «поломаться», и их потребуется править вручную). «Из коробки» поддерживается и работа с сервисом Disqus, что упрощает перенос комментариев. Блог на основе Octopress можно интегрировать с социальными сетями (Facebook, Twitter, Google Plus и другими).

Существуют плагины, реализующие, например, вставку календарей (похожих на те, что иногда встречаются в блогах на WordPress), списка похожих постов, облака тэгов и так далее.

По умолчанию поддерживается деплой с помощью git (на GitHub Pages или Heroku) или rsync (на любой хостинг, где можно настроить SFTP или можно запустить rsync). Можно настроить и деплой по FTP (о том, как это сделать, можно прочитать, например, здесь).

Этот генератор статических сайтов изначально замышлялся как полный аналог Jekyll, только написанный на Python — отсюда и название, отсылающее к знаменитой повести Р.Л. Стивенсона «Странная история доктора Джекилла и мистера Хайда».

Следует различать старую и новую версию Hyde. Старая версия основана на Django templates; в настоящее время ее разработка приостановлена (последние коммиты в репозитории на GitHub датируются 2009 — 2010 годом). Новый Hyde (см. также репозиторий на GitHub) в настоящее время находится в активной разработке.

По функциональности новый Hyde не отличается от MiddleMan и Jekyll. Мы немного потестировали его, и он произвел на нас вполне приятное впечатление. Из обнаруженных недостатков выделим только один: проект, как уже сказано выше, находится в стадии активной разработки. Именно поэтому документация к нему представлена пока что в очень сжатом и лаконичном виде, а плагинов и расширений существуют очень мало (вот их небольшой список на официальном сайте).
Поддерживается деплой на GitHub Pages и Amazon S3.

Будем надеяться, что в будущем этот инструмент получит дальнейшее развитие и станет более удобным в работе.

Pelican

Pelican также написан на Python. По сравнению со многими генераторами статических сайтов он обладает исключительно широким набором функций: работа с черновиками, интеграция с социальными сетями, добавление изображений, конвертация HTML-страниц в PDF, поддержка многоязычности и многое другое. Он очень хорошо подходит для ведения блогов (существует плагин для переноса блогов на WordPress).

Посты можно писать в Markdown, а также в форматах reStructuredText и Asciidoc.

Устанавливается Pelican через pip. При установке пользователю будут заданы несколько вопросов: где хранить файлы сайта, как будет называться сайт, куда и каким способом его нужно деплоить. Поддерживается множество способов деплоя: по FTP, по SSH, на Amazon S3, GitHub Pages, Dropbox и RackSpace Cloud Files.

Grow (см. также официальный репозиторий на GitHub) — очень интересный и перспективный инструмент, обнаруженный нами совсем недавно. Он написан на Python. Чтобы установить Grow, достаточно скачать скрипт с официального сайта — все необходимые пакеты будут установлены в автоматическом режиме.

В основе Grow лежит подход «конфигурация, а не код». Что это значит? Чтобы создать новый проект (в терминологии Grow проекты называются подами — pods), нужно клонировать на локальную машину тему, которая представляет собой репозиторий на GitHub. Тема включает набор конфигурационных файлов, с помощью которых описывается вся архитектура веб-сайта. Никакого программного кода при этом писать не нужно.

Все настройки проекта хранятся в конфигурационном файле podspec.yaml. В нем указываются следующие параметры:

Grow может автоматически переводить текстовые фрагменты — для этого используется библиотека Goslate library, работающая с Google Translate. Чтобы перевести сайт, достаточно просто выполнить команду translate.

В качестве площадки для деплоя можно указать любой веб-сервер. Поддерживается деплой на Dropbox, Google Cloud Storage, Amazon S3, Dropbox, Google AppEngine.

Конечно, в рамках беглого обзора рассказать обо всех особенностях работы с Grow вряд ли возможно. Рекомендуем попробовать — инструмент очень перспективный.

Nanoblogger

Этот генератор статических сайтов, ориентированный на создание блогов, примечателен тем, что написан на bash. В качестве основных инструментов для создания статичных HTML-страниц он использует утилиты командной строки cat, grep и sed.

При всей своей простоте Nanoblogger по возможностям не уступаем многим генераторам, написанным на Python или Ruby. Из его полезных функций можно выделить поддержку Atom/RSS, возможность создания на сайте календаря, сортировку постов по категориям, создание архива постов и другие.

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

С Nanoblogger удобно работать из командной строки. Все команды подробно описаны в документации, их синтаксис прост и понятен.

Исходный код также написан предельно просто, в случае необходимости его всегда можно модифицировать и «подогнать» под нужды конкретного проекта (см., например, публикацию, в которой автор делится собственным опытом конфигурирования блога на основе Nanoblogger).

Для nanoblogger существуют плагины и расширения. Официальный набор плагинов (nanoblogger extras) также включен в официальные репозитории и устаналивается стандартным способом.

К сожалению, в 2013 году работа по развитию и усовершенствованию Nanoblogger была приостановлена на неопределенный срок (см. информацию на официальном сайте).

DocPad

DocPad написан на CoffeeScript. Для работы с ним на клиентской машине должен быть установлен NodeJS.

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

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

Для DocPad написано множество разнообразных плагинов. Из наиболее интересных расширений отметим WYSIWYG-редакторы и веб-интерфейсы, облегчающие публикацию постов в статическом блоге.

На официальном сайте опубликованы скрипты, автоматизирующие деплой на различные площадки: Heroku, Appfog, Windows Azure, Docker, GitHub Pages и другие. Имеется и специализированный скрипт для деплоя в облачные хранилища — Amazon S3 и GoogleStorage.

Заключение

Результаты проделанного обзора можно резюмировать в виде следующей таблицы:

Все перечисленные генераторы интересны и уникальны, однако самым интересным проектом на сегодняшний день нам показался Grow SDK.

Для желающих углубиться в тему пара полезных ссылок:

Какой опыт использования генераторов статических сайтов есть у вас, Хабраюзеры?

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

Источник

Полное руководство по инкрементной регенерации статических сайтов с помощью Next.js

Год назад во фреймворке Next.js 9.3 появилась поддержка генерирования статических сайтов (Static Site Generation, SSG), что сделало его первым гибридным фреймворком. Я к тому моменту уже несколько лет с удовольствием пользовался Next.js. Но тот релиз сделал Next.js моим новым стандартным инструментом. После того, как я много и серьёзно поработал с Next.js, я присоединился к Vercel для того чтобы помогать компаниям, вроде Tripadvisor и Washington Post, в деле внедрения Next.js и расширения того, что у них получилось.

В этом материале мне хотелось бы исследовать новый виток эволюции Jamstack — механизм инкрементной регенерации статических сайтов (Incremental Static Regeneration, ISR). Здесь вы найдёте руководство по ISR, а так же — практические примеры использования этой технологии, демонстрационные проекты и рассказ о сопутствующих внедрению ISR компромиссах.

Если в двух словах описать ISR, то окажется, что эта технология позволяет, при внесении каких-то изменений в материалы сайта, мгновенно обновлять статический контент. Полная пересборка проекта при этом не нужна. Гибридный подход Next.js позволяет использовать ISR в сфере электронной коммерции, при подготовке маркетинговых и рекламных страниц, при организации работы блогов и во многих других случаях.

Проблема SSG

В основе Jamstack лежит привлекательная идея: сайты представляют собой заранее отрендеренные статические страницы, которые можно отправить на CDN, и с которыми, через считанные секунды после этого, смогут работать пользователи со всего мира. Статические страницы быстры, статические сайты устойчивы к сбоям, их очень быстро индексируют поисковые роботы. Но и тут имеются некоторые проблемы.

Если архитектура Jamstack используется при разработке крупномасштабного статического сайта, это значит, что создателям сайта, возможно, придётся тратить долгие часы на его сборку. Если количество страниц сайта удвоится — удвоится и время сборки. Взглянем, например, на Target.com. Реально ли сгенерировать миллионы статических страниц товаров при каждом развёртывании сайта?

Проблема генерирования статических сайтов: так как время сборки линейно зависит от количества страниц — сборка сайта может занять многие часы

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

Системы управления контентом

При работе над многими веб-проектами практикуется отделение контента этих проектов от их кода. Использование систем управления контентом (Content Management System, CMS) без пользовательского интерфейса позволяет редакторам сайтов публиковать новые и изменённые материалы, не привлекая к решению этой задачи программистов. Но если речь идёт о традиционных статических сайтах, то этот процесс может быть довольно медленным.

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

Next.js позволяет создавать или обновлять статические страницы после того, как выполнена сборка сайта. Инкрементная регенерация статических сайтов позволят разработчикам и редакторам использовать механизмы генерирования статических сайтов в применении к отдельным страницам, без необходимости пересобирать весь сайт. Применение ISR позволяет сохранить сильные стороны SSG в масштабах проектов, состоящих из миллионов страниц.

Благодаря использованию ISR статические страницы могут быть сгенерированы во время работы проекта (по запросу), а не во время его сборки. Используя аналитические данные, A/B-тестирование, или другие метрики, разработчик, видя плюсы и минусы ISR и SSG, сознательно идя на определённые компромиссы, получает возможность гибкой настройки процессов сборки проекта.

Вспомним вышеприведённый пример интернет-магазина, в котором имеется 100000 товаров. Если на генерирование страницы для одного товара уйдёт 50 мс, что вполне реально, то без использования ISR на сборку всего сайта понадобится почти 2 часа. Других вариантов тут нет. А вот если применяется ISR — у разработчика сайта появляется возможность выбора одного из сценариев сборки:

Преимущества ISR: у разработчика есть возможность выбора стратегии генерирования страниц во время сборки проекта. Вариант A позволяет ускорить сборки, вариант B позволяет кешировать больше готовых страниц

Теперь давайте подробнее рассмотрим наш пример использования ISR в интернет-магазине.

Разбор примера

▍Загрузка данных

Последовательность запросов, используемых при реализации ISR

▍Генерирование путей

Next.js позволяет настраивать то, какие страницы товаров нужно генерировать во время сборки проекта, а какие — по запросу. Сгенерируем во время сборки проекта лишь страницы для 1000 самых популярных товаров, передав системе в getStaticPath список идентификаторов соответствующих товаров.

Компромиссы

Конечный пользователь — это основной объект внимания Next.js. Понятие «лучший способ работы со статическими страницами» относительно, его смысл зависит от отрасли экономики, к которой принадлежит проект, от его аудитории, от внутренних особенностей приложения. Next.js позволяет разработчикам реализовывать разные стратегии работы со статическим контентом и при этом не покидать границ фреймворка. Благодаря этому, используя Next.js, можно подобрать именно то, что лучше всего подходит для конкретного проекта.

▍Серверный рендеринг

ISR — это не всегда именно то, что нужно некоему проекту. Например, лента новостей Facebook не может выводить устаревшие данные. В данном случае имеет смысл прибегнуть к серверному рендерингу (Server-Side Rendering, SSR) и, возможно, к использованию собственных заголовков Cache-Control с суррогатными ключами для инвалидации содержимого различных кешей. Так как Next.js — это гибридный фреймворк — у разработчика есть возможность пойти на компромисс, связанный с использованием SSR, но при этом не покидать границ фреймворка.

SSR и кеширование данных на пограничных системах напоминает ISR (особенно — при использовании заголовков stale-while-revalidate для управления кешем). Основная разница между ними заключается в том, как именно обрабатывается первый запрос. При использовании ISR можно сделать так, чтобы в ответ на первый запрос к некоей странице, при условии её предварительного рендеринга, гарантированно выдавался бы её статический вариант. Даже если база данных проекта вдруг оказалась недоступной, или если возникли проблемы, относящиеся к взаимодействию с API, пользователь проекта, всё равно, увидит правильную статическую страницу. Но SSR позволяет настраивать страницы, ориентируясь на особенности входящих запросов.

Обратите внимание на то, что использование SSR без кеширования может привести к ухудшению производительности проекта. Когда пользователь ждёт вывода страницы проекта — важна каждая миллисекунда. Использование SSR без кеширования, кроме того, может очень плохо сказаться на показателе TTFB (Time to First Byte, время до первого байта).

▍Генерирование статических сайтов

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

▍Клиентский рендеринг

Если React на сайте используется без Next.js — это значит, что речь идёт о клиентском рендеринге сайта (Client-Side Rendering, CSR). Приложение отдаёт посетителю страницу, пребывающую в некоем исходном состоянии, после чего, из JavaScript-кода, работающего на клиенте, выполняются запросы на загрузку дополнительных данных (например — с применением useEffect ). Хотя это и расширяет возможности по хостингу сайтов (так как при таком подходе нет абсолютной необходимости в сервере приложения), у такого подхода есть и свои недостатки.

Например, то, что в CSR-проектах нет страниц, заранее отрендеренных на основе исходной HTML-разметки, ухудшает возможности по SEO. Кроме того, CSR-страницы не будут работать при выключенном на клиенте JavaScript.

Особенности настройки параметра fallback при применении ISR

ISR — это не только кеширование!

Хотя я, говоря об ISR, всё время обсуждал кеширование, я не могу не отметить того факта, что эта технология спроектирована так, чтобы сохранять сгенерированные страницы между сеансами развёртывания проектов. Это значит, что у владельца проекта есть возможность мгновенного отката на его предыдущую версию и возможность не терять ранее сгенерированные страницы.

Каждому развёртыванию можно назначить ключ, представляющий собой некий идентификатор (ID). Этот ID Next.js использует для организации постоянного хранения сгенерированных страниц. При откате проекта можно поменять ключ так, чтобы он указывал бы на предыдущее развёртывание, что позволяет выполнять атомарные развёртывания проектов. Это значит, что можно заглянуть на предыдущий иммутабельный вариант развёрнутого проекта, и то, что он будет работать так, как ожидается. Вот пример возврата к предыдущей версии кода с помощью ISR:

Примеры применения ISR

Как уже было сказано, ISR находит успешное применение в самых разных проектах. Вот несколько примеров:

Источник