Генераторы статических сайтов – это большой шаг вперед?

От автора: за последний год мы следили за более чем сотней генераторов статических сайтов на нашем open-souce проекте StaticGen. За это время мы отметили возрастающую популярность и амбициозность этих проектов на GitHub, начиная с 50 проектов и до более 100 генераторов на данный момент. В общей сумме все проекты собрали более 100 000 звезд.

Влиятельные компании, заточенные под веб-дизайн, такие как Nest и MailChimp используют генераторы статических веб-сайтов для своих основных сайтов. Vox Media вокруг Middleman построили целую систему публикаций. Агентство Carrot в Нью Йорке, являющееся в том числе частью империи Vice, создают веб-сайты для величайших мировых брендов с помощью своего собственного генератора с открытым кодом Roots. Среди статичных веб-сайтов даже оказались некоторые сервисы Google, такие как Год в поиске и Web Fundamentals.

График роста StaticGen за последний год.

Статические веб-сайты далеко не новы и ведут нас к истокам интернета. Так почему же такой внезапный интерес? Что произошло, почему сейчас?

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

Первый в мире веб-сайт от Tim Berners-Lee был, естественно, статическим и имел имя «original home page for the World Wide Web». На тот момент веб-сайт представлял собой папку с HTML документами, в которых было всего лишь 18 тегов. Браузеры представляли собой простые навигаторы по документам, которые скачивались с сервера. Процесс перехода от одного документа к другому осуществлялся по гиперссылкам. Интернет был полностью статичным. С развитием браузеров, как и HTML, стали всплывать явные недостатки и ограничения статичных веб-сайтов.

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

Также пришло понимание, что невозможно просто добавлять новый HTML код и стили CSS (для создания постов, товаров, галерей) без должной привязки к дизайну.

В то же самое время в моду вошли реляционные базы данных. Для многих онлайн компаний они стали святым местом хранения всех их данных, а охраняли эти данные «длиннобородые» администраторы.

Десктопные приложения типа Dreamweaver и FrontPage стали предлагать создавать сайты через WYSIWYG редакторы, в которых можно разбивать на составляющие: меню, хедер и футер, которые можно повторно использовать. Контент на таких сайтах отчасти хранился в базе данных. В некоторых отношениях, первые генераторы статических веб-сайтов имели смертельные недостатки: сайт создавался из шаблонов, медиа библиотек с подключением к базам данных. Файлы публиковались через FTP канал и были полностью статичными. Еще в далеком 2004 году у меня был опыт работы с крупным сайтом, состоящим из более 10 тысяч страниц, разбросанных по разным группам. Все страницы управлялись через Dreamweaver!

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

Самым подходящим решением всех этих проблем были LAMP и CMS WordPress, Drupal и Joomla. Все эти cms сыграли ключевую роль в развитии интернета, породив такое явление как Web 2.0. Основным движущим фактором для большинства сайтов стал контент, генерируемый самими пользователями. Пользователи стали переходить по ссылкам и покупать товары, вступать в сообщества и создавать контент.

Динамические проблемы

Когда я более 15 лет назад создавал свой первый динамический сайт, я пользовался уроками по LAMP из документации MySQL. И потом я понял, что все, что я пишу, происходит при каждом посещении пользователем моего сайта, и это не укладывается в голове!

Веб-сервер загружал мой код в PHP интерпретатор налету, затем открывал соединение с БД, посылал туда и обратно запросы, использовал различные шаблоны, соединял текст с HTML кодом. Все это делалось в момент посещения пользователем страницы. Потрясающе!

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

Архитектура динамических веб-сайтов дала толчок для развития всей индустрии, но не обошлось и без серьезных проблем. По самым скромным подсчетам больше 70% сайтов на WordPress уязвимы (а доля WordPress в интернете составляет 23%). Всего лишь несколько месяцев назад всего за пару дней было заражено около 1.2 миллиона сайтов на Drupal 1.2 миллиону сайтов на Drupal потребовалось срочно установить патч, устраняющий брешь в системе безопасности. Все те, кто не успел пропатчить свой сайт за 7 часов с объявления об уязвимости, были заражены. Не проходит и недели, как я перехожу по ссылкам из социальных сетей на сайты с надписью «Ошибка подключения к БД». Масштабирование динамических веб-сайтов может быть довольно дорогим занятием. Агентства, развертывающие сайты для компаний, для противодействия вирусам предпринимают избыточные усилия – или отчаянно пытаются поднять сайт, когда он уже упал (за рабочий день, кажется, это вообще невозможно сделать).

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

Динамические веб-сайты и кэширование

В некоторой степени все кэшируется. Ни один сайта на WordPress не запустится без плагина WP Super Cache. Крупные сайты кэшируют содержимое с помощью Varnish, Nginx и Apache Traffic Server. На кэширование достаточно сложно получить нужные права, а самые оптимизированные динамические сайты, как правило, во много раз медленнее статических решений.

Наш веб-сайт, Smashing Magazine, тоже работает благодаря команде, которая постоянно работает над производительностью. Для статьи я провел маленький эксперимент. С помощью HTTrack я снял копию этого сайта и развернул статичную версию на сервисе Netlify, хостинге статичных сайтов, работающих по технологии CDN. Я ничего не делал для повышения производительности статичной версии сайта, кроме как развертывания сайта на хостинге с глубокой интеграцией CDN.

Smashing Magazine быстрее многих сайтов, но все запросы обрабатываются из одного цента обработки данных.

Затем я проверил, сколько займет времени загрузка первого байта index.html и страницы целиком. Вот, что мне показал сервис Sucuri super-user performance.

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

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

На динамических веб-сайтах очень сложно получить права на кэширование, а еще сложнее обновлять кэш. Особенно сложно работать с распределенным кэшированием, тут необходимо в полной мере использовать преимущества CDN. В WordPress нет гарантии того, что тот же самый URL не вернет совершенно другую страницу. Это может зависеть от авторизации пользователя, параметров запроса и A/B тестов. Также весьма сложной задачей является определение устаревания кэша: любые изменения в комментариях, основных настройках, тегах, категориях или в контенте в БД могут повлиять на список похожих постов, домашнюю страницу, архив, счетчик комментариев и т.д.

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

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

За последние годы данная альтернатива традиционным динамическим сайтам довольно далеко продвинулась. Идея генераторов статических веб-сайтов не нова. Даже у самого крупнейшего конкурента WordPress Movable Type была опция работы в качестве генератора статического веб-сайта.

Доля запросов «генератор статического веб-сайта» в Google Trends.

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

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

Поддержка markdown. Популярность облегченного языка разметки Markdown стала основной причиной бешеной популярности генераторов статических веб-сайтов. Мало кому захочется писать контент в обычном BBCode или чистом HTML, вот именно для таких случаев и был разработан Markdown. Число редакторов Markdown растет взрывным образом, его используют для серьезных статей, конспектирования и блогов.

Все основные генераторы поддерживают Markdown. Но некоторые все же рекомендуют reStructuredText или что-то еще. В основном все эти инструменты позволяют создателям контента писать обычный структурный текст.
При таком подходе контент полностью отделяется от дизайна, а все файлы содержат только текст. Как разработчики, мы уже привыкли к огромному набору инструментов для написания текста. Это большой шаг, теперь не нужно сбрасывать весь контент в БД в двоичном виде.

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

Jekyll еще дальше продвинул идею генераторов статических сайтов: теперь их можно писать через Markdown.

Когда владелец GitHub Tom Preston Werner обратился к Jekyll, чтобы они запустили его блог, он нашел достаточно необычный способ представления мета данных, работаю напрямую в Markdown: front matter. Front matter это часть мета данных, преимущественно в YAML формате, в самом верху документа:

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

Asset Pipeline. Сегодня front-end разработка не может обойтись без подключения сторонних инструментов и компиляторов. Нам нужно, чтобы все ресурсы нашего сайта были минифицированы и скомпонованы. CSS препроцессоры перешли из разряда новинок в мейнстрим. И такие транспилеры как CoffeeScript и ECMAScript 6 сделали компиляторы неотъемлемой частью веб-программирования.

Большинство современных генераторов имеют встроенный asset pipeline для компиляции, минификации и создания ресурсов. Некоторые из них основаны на Grunt, Gulp или Broccoli, позволяя вам рассмотреть всю систему планирования задач изнутри. Другие же инструменты сосредоточены на оптимизации конкретного процесса и проверке слаженной работы нескольких инструментов без каких-либо дополнительных настроек. Моментальное обновление страницы при каждом сохранении файла стало неписаным правилом для множества генераторов.

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

В командной строке Jekyll, к примеру, для создания статического веб-сайта, необходимо запустить команду jekyll build прямо из директории с исходниками. Сайт будет располагаться в подпапке _site. Типичная папка с исходниками:

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

Почему именно сейчас?

Если это и звучит немного удивительно, то это, потому что так оно и есть. Но почему именно сейчас технология создания статических веб-сайтов набрала такую популярность? Почему первые генераторы не снизили долю WordPress на рынке? Что изменилось? Как долго это будет продолжаться?

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

Браузеры развиваются

На момент запуска первого веб-сайта Тимом Бернерсом-Ли браузеры представляли из себя простые обозреватели документов. Они распознавали гипертекст, ссылки и еще пару вещей.

Сегодня же мы, наконец, хороним с почестями последний браузер, сдерживавший развитие интернета (Покойся с миром, Internet Explorer 8). Современные браузеры это полноценные операционные системы. Теперь это не просто обозреватели документов, загружающихся из интернета, они способны запускать полноценные веб-приложения, делая внешниезапросы CORS-совместимых API, способные хранить данные на локальных носителях, работая с стримминговыми сервисами и даже обрабатывая p2p соединения с другими браузерами через WebRTC.

Браузеры, развиваясь, перенесли множество функций, которые раньше запускались на сервере, на сторону клиента. Нужны комментарии на сайте? Воспользуйтесь Disqus, Isso или Facebook* комментариями. Нужна интеграция с социальными сетями? Добавьте JS виджет Twitter или Facebook*. Хотите, чтобы данные обновлялись в реальном времени? Добавьте щепотку Firebase. Нужен поиск? Есть Swiftype. Хотите живой чат? Olark в помощь. С помощью Snipcart можно даже добавить целый магазин!

Список можно продолжать до бесконечности, это целая экосистема браузерных аддонов. Кроме того, современные веб-приложения на основе Ember.js, AngularJS или React зачастую полностью статичны и управляются напрямую через CDN с помощью чистого back-end API, которое представляет из себя UI сайта и мобильного клиента.

CDN теперь в моде

Когда в 1999 году Akamai запустили первую в мире сеть доставки контента, ее могли себе позволить для доставки контента по всему миру только крупнейшие мировые гиганты. На самом деле это было не так уж и давно, когда CDN могли себе позволить только компании уровня CNN и Facebook*.

Цены в Akamai все еще очень высокие, но сегодня уже любой может позволить себе сервис CloudFront на Amazon AWS. Также существуют компании, предлагающие демократичные цены на CDN даже по меркам маленьких компаний, Fastly, MaxCDN и CloudFlare.

CDN можно использовать и на динамических веб-сайтах, но там есть довольно распространенная проблема с обновлением кэша. Вычисления для каждого запроса становятся очень сложными, если балансировать между кэшированием и динамической системой на стороне back-end’а.

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

Производительность – важнейшая задача

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

Мы все уже слышали про эти цифры: 57% пользователей покидают страницу, если она грузится более 3 секунд. Раньше люди могли ждать и по 10 секунд, но сегодня потребности существенно возросли. На мобильных устройствах отсутствует многозадачность, которая может занять пользователя на время загрузки страницы, и ожидание загрузки страницы может оказаться очень утомительным. 4% людей признались, что они бросали свои телефоны, когда сайт медленно работал!

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

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

Если ваш сайт использует базу данных, то очень важно, чтобы эффективность ваших запросов к БД была очень высокая. Каждый HTTP-запрос должен обрабатываться очень быстро. Даже если во главе угла у вас лежит кэширование, всегда есть риск того, что некоторые запросы будут обходить кэш, тем самым вызывая непредвиденные случаи на стороне back-end’а.

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

Вспомогательные инструменты повсюду

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

Сегодня на вооружении front-end разработчика стоят различные инструменты для создания веб-сайтов, менеджеры и компиляторы. Grunt стал первым популярным front-end инструментом. Теперь большинство новых проектов можно разделить на этапы создания.

С таким бурным развитием различных инструментов разработки, генераторы статических веб-сайтов стали чувствовать себя на своем месте, а традиционные PHP инструменты для создания динамических сайтов постепенно вытесняются на задворки front-end разработки.

Чего не хватает

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

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

Экосистема генераторов все еще развивается, но ее размеры еще не дотягивают до крупных магазинов тем и традиционных динамических платформ.

Самая большая проблема это редактирование контента. Если для front-end разработчика работа в MarkDown и загрузка на GitHub это почти идеальный вариант, то для обычного пользователя это совершенно не так.

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

Существуют достаточно интересные решения без использования CMS. Verge использует Google Sheets в Middleman; StaticGen в качестве БД использует Gist и GitHub API; а Carrot в качестве статичной CMS используют Contentful для людей, которые не дружат с техникой.

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

Системы типа Contentful, Prismic.io и GatherContent вырезают CMS из этапов разработки сайта. Такой подход позволяет использовать многоканальное управление контентом – когда вы пишите контент не только на веб-странице, но и на страничке в Facebook* и мобильном приложении. Во время публикации контента запускается хук в системе создания; затем запускается построение статического сайта и ресурсов из API; результат выкладывается прямо на CDN. Также контент можно редактировать, работая напрямую из репозитория.

Markdown редактор на Prose.io, интегрированный с GitHub API.

Prose.io был и раньше, но теперь, когда появилась интеграция с GitHub API, интерфейс стал намного привлекательнее.
На Netlify мы работаем над open-source CMS. В ней мы стараемся не привязываться к какому-то конкретному генератору статических сайтов, Git хостингу или хостинг платформе. Задача – заставить работать нашу систему с почти всеми известными на сегодняшний момент генераторами. Мы считаем, что это повысит сложность сайтов, которые можно создать с помощью статических генераторов.

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

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

На Netlify мы уже замечаем крупные сайты с поиском в реальном времени, поддержкой нескольких языков, личными кабинетами, и все это создано с помощью генераторов статических сайтов и контентных API. Люди все больше беспокоятся о производительности и безопасности данных, а значит, таких сайтов будет все больше и больше.

Автор: Mathias Biilmann Christensen

Источник: //www.smashingmagazine.com/

Редакция: Команда webformyself.

* Признана экстремистской организацией и запрещена в Российской Федерации.

Комментарии Вконтакте:

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