Від автора: за останній рік ми стежили за більш ніж сотнею генераторів статичних сайтів на нашому 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 форматі, в самому верху документа:
title: Title of the document
categories:
– Category B
—
# Actual content
This is the document
Такий спосіб дозволяє легко додавати анотації до документів з мета-даними. Файли подаються у простому, що читається для людини форматі, а зазвичай, такі дані зберігаються в незрозумілому форматі в базі даних.
Asset Pipeline. Сьогодні front-end розробка не може обійтися без підключення сторонніх інструментів та компіляторів. Нам потрібно, щоб всі ресурси нашого сайту були минифицированы і скомпоновані. CSS препроцессоры перейшли з розряду новинок у мейнстрім. І такі транспилеры як CoffeeScript та ECMAScript 6 зробили компілятори невід’ємною частиною веб-програмування.
Більшість сучасних генераторів мають вбудований asset pipeline для компіляції, минификации і створення ресурсів. Деякі з них засновані на Grunt, Gulp або Broccoli, дозволяючи вам розглянути всю систему планування завдань зсередини. Інші ж інструменти зосереджені на оптимізації конкретного процесу та перевірці злагодженої роботи декількох інструментів без будь-яких додаткових налаштувань. Миттєве оновлення сторінки при кожному збереженні файлу стало неписаним правилом для безлічі генераторів.
Збираємо всі разом. Для створення свого веб-сайту або підняття локального сервера генератори статичних веб-сайтів зазвичай використовують командний рядок.
У командному рядку Jekyll, наприклад, для створення статичної веб-сайту, необхідно запустити команду jekyll build прямо з директорії з вихідними кодами. Сайт буде розташовуватися в папці _site. Типова тека з цими кодами:
_posts/
2015-03-01-first-post.md
2015-03-11-amazing-post.md
_layouts/
default.html
_includes/
main-nav.html
index.html
about.md
js/
app.coffee
css/
style.scss
_config.yml
У цій папці зберігається статичний веб-сайт, який можна завантажити на будь-який хостинг статичних сайтів або нормальний веб-сервер.
Чому саме зараз?
Якщо це й звучить трохи дивно, то це, тому що так воно і є. Але чому саме зараз технологія створення статичних веб-сайтів набрала таку популярність? Чому перші генератори не знизили частку 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, max-cdn і 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. Люди все більше турбуються про продуктивності і безпеки даних, а значить, таких сайтів буде все більше і більше.
