Эта статья является второй из серии, в которой рассматриваются технические причины возобновившегося интереса к статическим веб-сайтам с точки зрения как автора контента, так и разработчика.

Он также предоставляет вам полезные инструменты и услуги для создания статического веб-сайта. Если вы хотите узнать больше о макроперспективе, стоящей за сдвигом в сторону статического веба, не стесняйтесь читать: Статический веб — назад к корням?

Статические веб-сайты лучше выполняют свою задачу

Давайте на секунду отвлечемся от технологий и сделаем шаг назад. Какова главная цель веб-сайта? Позвольте мне рискнуть и ответить «чтобы вас видели и читали». Так как же тогда можно так пренебрегать скоростью и производительностью? Это прямой фактор в уравнении.

Рассмотрим, например, New York Times, которая далеко не худшая с точки зрения практик разработки. Давайте загрузим одну и ту же страницу ( раздел «Здоровье» ) в двух разных «версиях»:

1. Полный, включая все трекеры, рекламу и ненужные скрипты. Рендеринг с использованием Chrome, приватный просмотр без расширений. ¹
2. Очищенный, использующий Firefox и несколько расширений для удаления большинства рекламных объявлений, отслеживания и других ненужных скриптов. ²

Тесты проводились на моем ноутбуке со скоростью соединения ~7 Мбит/с на загрузку/выгрузку.

Вот красноречивые результаты:

Результаты, которые мы наблюдаем, согласуются с нашими экспериментами. Динамические веб-сайты склонны быть переполненными ненужными скриптами и раздутыми. Хотя очищенная версия NYT, которую мы анализируем, все еще не является статическим веб-сайтом, она дает нам представление о том, как может выглядеть оптимизированный и легкий веб-сайт NYT.

Статические веб-сайты примерно в 10 раз легче своих динамических аналогов. Так как же динамические стали стандартом, особенно в период 2005-2015 годов, когда скорость соединения все еще была ограничена?

Из динамической ереси

Если вы подумаете об этом с сегодняшней точки зрения, то все это абсурдно — само существование WordPress по сути бессмысленно, учитывая его основное применение. Вместо того, чтобы рассматривать вопрос с точки зрения релевантности статических веб-сайтов, все становится гораздо яснее, если сместить таблицы: динамические веб-сайты не нужны в 95% их текущих сценариев использования.

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

Действительно, если ваш контент статичен (= редко изменяется после публикации, как и большинство веб-сайтов), зачем выбирать динамический движок? Все ваши пользователи видят одни и те же страницы каждый раз. Таким образом, использование динамического движка означает, что он заставляет выполнять вычисления как на стороне сервера, так и на стороне пользователя каждый раз при отображении страницы : это невероятно расточительно и безответственно.

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

Так как же мы этого достигли?

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

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

К статическому спокойствию

Органическая производительность

Общая скорость и использование ресурсов веб-сайта оказывают огромное влияние на его органическую производительность. Это было верно 10 лет назад, но сейчас это еще больше с ростом мобильных устройств — плохая производительность уничтожает среднее время на странице, тем самым уничтожая CTR (Click-Through-Ratio)… Это если странице удается занять первое место.

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

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

С другой стороны, большинство статических генераторов веб-сайтов способны создавать веб-сайты, соответствующие лучшим практикам SEO, из коробки . Это включает в себя sitemap.xml/ robots.txtgeneration, OpenGraph, Twitter Cards, Schema.org (богатые предварительные просмотры), таксономии, href lang/многоязычную разметку и другие.

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

Статические веб-сайты — ресурсы и услуги

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

С момента выпуска Jekyll в 2008 году, фреймворка, принятого GitHub, статические веб-сайты набирают обороты. Были разработаны новые фреймворки и сервисы для облегчения концепции статического веб-сайта:

Движки статических веб-сайтов

Логотип	Рамки	Язык	Описание
	Джекилл	Рубин	Доступен как Gem или интегрирован с GitHub Pages. Jekyll быстр и эффективен, но предлагает минимальные функции из коробки. Многие плагины предлагают дополнительные функции.
	Гэтсби	Реагировать	Наряду с Jekyll, Gatsby является самым популярным статическим веб-фреймворком. Он предлагает очень хорошую производительность и большой выбор плагинов, а также интеграцию со многими сторонними сервисами.
	Хьюго	Идти	Hugo демонстрирует свою впечатляющую производительность, особенно при создании крупных веб-сайтов. Он предлагает все необходимое для создания веб-сайта, соответствующего лучшим практикам SEO, из коробки.
	Гексо	NodeJS	Еще один быстрый генератор статических сайтов со встроенным менеджером пакетов для установки плагинов и тем.
	Пеликан	Питон	Pelican — еще одна интересная альтернатива для любителей Python, однако в ней не так много сторонних ресурсов (тем, плагинов…), как в предыдущих версиях.

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

Наконец, если вы хотите изучить все потенциальные варианты, проверьте эту превосходную, исчерпывающую базу данных, поддерживаемую Netlify (подробнее о ней ниже).

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

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

Репозиторий Git, базовая CMS

Использование репозитория Github (или Gitlab) в качестве CMS имеет множество преимуществ по сравнению с традиционной CMS, среди которых:

• Контроль версий,
• Управление пользователями и разрешениями,
• Филиалы (подготовка, предварительная продукция, продукция),
• Доступ к полной истории файлов.

Это может показаться пугающим, если у вас есть нетехнические профили, взаимодействующие с вашим сайтом, но это не обязательно: им не нужно использовать Git CLI для отправки коммита, они могут сделать все это с сайта Github. Мы подробно рассмотрим поток написания/редактирования статических сайтов в Static web — back to the roots? .

Альтернативная CMS

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

Логотип	Имя	Описание
	Система управления контентом Netlify	CMS, созданная для генератора статических веб-сайтов, способная интегрироваться с наиболее распространенными фреймворками. Netlify — это довольно исчерпывающий набор услуг для статических веб-сайтов, включая инструменты для CD/CI, управления пользователями (CMS), форм и управления изображениями.
	Лесное хозяйство	Убедительная альтернатива Netlify, которая фокусируется на UX редактора. Forestry — отличный выбор, если вы ищете визуальную CMS для упрощения вклада нетехнических профилей в статический веб-сайт. Forestry также включает в себя другие инструменты, как и Netlify.
	Бессмысленный	третья альтернатива, которая фокусируется на простоте. Vapid — это «чистая» CMS, созданная «для людей, которые создают веб-сайты для других людей». Vapid легко настраивать и поддерживать, поскольку для работы он использует только HTML-теги.

Непрерывная интеграция и развертывание

Netlify и Forestry предлагают услугу непрерывного развертывания, интегрированную с их CMS. Обычно это два наиболее подходящих варианта , если вы создаете веб-сайт, который будет поддерживаться кем-то другим.

Однако если вы просто ищете решение CI/CD и вам не нужна CMS, вы можете использовать Netlify без компонента CMS или рассмотреть обычные сервисы CI/CD, которые предлагают ресурсы, облегчающие поддержку статических веб-сайтов:

Логотип	Имя	Ресурс
	СемафорCI	Официальная документация — Непрерывное развертывание статического веб-сайта
	CircleCI	Запись в блоге — Автоматизируйте развертывание статического сайта с помощью CircleCI
	КодШип	Запись в блоге — Непрерывная доставка для статических сайтов

Как мы создаем собственный технический блог

Ознакомьтесь с этим постом, чтобы узнать несколько советов о том, как мы создали собственный технический блог с помощью Hugo, Docker и GitLab .

Ссылки