StaticGen. відкритий каталог статичних генераторів сайтів, налічує більше сотні генераторів, що з'явилися останнім часом і ми бачимо, що їх частка і популярність на Github зростає. Спочатку проект налічував півсотні генераторів, зараз їх в два з гаком рази більше і сумарно у них понад 100 тисяч зірок на GitHub.
Статичні веб-сайти це не новина - це те, з чого починався веб. Так звідки цей вибух інтересу до них? Чому він стався саме зараз?
Часи статичних сайтів
З еволюцією браузерів і HTML недоліки статичних сайтів ставали все більш очевидними.
Спочатку сайти містили прості документи без стилів, але з часом дизайн зайняв своє місце, у сайтів з'явилися графічні хедери і складна навігація. З цього моменту управління окремими сторінками сайту як різними документами, перестало мати сенс і на сцену вийшли шаблонизатор.
І так само швидко стало очевидним, що використання тільки HTML для структури і CSS для стилів недостатньо, щоб зберігати вміст сайту (статті, продукти, елементи галерей) окремо від дизайну.
До цього часу бази даних SQL вже стали мейнстримом і для багатьох онлайн-компаній бази даних стали сакральними сховищами всього контенту, що охороняються червоноокими і довгобородими адміністраторами.
І навіть якщо Dreamweaver міг, в деякій мірі інтегруватися з базами даних, в ньому була відсутня тематична модель і не було відділення контенту від дизайну, незважаючи на наявність незалежного редагування того й іншого.
Проблеми з динамікою
Коли я створював свій перший динамічний сайт 15 років тому, я слідував інструкціям по LAMP з документації MySQL. Коли я усвідомив, що вся послідовність взаємодій LAMP виконується кожен раз, коли хтось відвідує сайт, це вразило мене.
Веб-сервер повинен завантажити мій код в інтерпретатор PHP на льоту, потім з'єднатися з базою даних, послати і прийняти запити, потім за допомогою шаблонів скласти отримані рядки в HTML-документ, зроблений спеціально для поточного користувача. Чудово!
Але захоплення поменшало, коли я відвідав сайт пару років по тому і побачив на сторінці повідомлення від хакера, який знайшов дірки безпеки в конфігурації, достатні для дефейса сайту (і це краще, ніж злом сайту з подальшим поширенням через нього шкідливого ПО).
Ми платимо велику ціну за вбудовану складність динамічних сайтів, що обробляють кожен запит на сервері - і цю ціну зовсім не обов'язково платити там, де ця складність не потрібна.
Динамічні сайти і кешування
В деякій мірі ця проблема вирішується за рахунок кешування. Жоден популярний сайт на WordPress не обходиться без плагіна WP Super Cache. Великі сайти використовують проксі-кешування типу Varnish, Nginx і Apache Traffic Server.
Кешування досить складно налаштувати правильно, однак, навіть максимально оптимізований динамічний сайт в звичайних умовах буде набагато повільніше статичного.
Smashing Magazine створений командою, орієнтованої на продуктивність і, в загальному, серйозно оптимізований в цих цілях. Я провів на ньому невеличкий експеримент для цієї статті. Використавши HTTrack. я викачав цей сайт і потім виклав статичну версію на Netlify - платформу для хостингу статики, засновану на CDN. Я не робив нічого, щоб поліпшити продуктивність статичної версії - просто виклав її на хостинг, глибоко інтегрований з CDN.
Smashing Magazine швидше більшості сайтів, але він обробляє всі запити з одного дата-центру. (Збільшена версія)
Потім я запустив кілька тестів, щоб побачити як це впливає на швидкість надходження першого байта і на час повного завантаження сторінки index.html. І ось що показав інструмент для перевірки продуктивності від Sucuri.
Навіть високо-оптимізований динамічний сайт програє в середньому в 6 разів своїй статичної версії. Врахуємо, звичайно, що не кожен статичний хостинг дасть таку різницю, але динамічний сайт навіть з CDN просто не зможе дати порівнянної продуктивності без ручної настройки, зазвичай тягне за собою різні дивні речі з кешуванням.
Статичні сайти фундаментально відрізняються в цьому відношенні. Принцип кешування простий: кожен URL віддає однаковий HTML кожному користувачеві, до того поки відповідний файлу URL буде явно оновлений.
Робота з таким принципом кешування накладає деякі обмеження при розробці, але після створення сайту це все окупиться в продуктивності і в ціні хостингу.
Сучасні генератори статичних сайтів
Останнім часом альтернатива традиційним динамічним сайтам набула реальних обрисів. В ідеї генератора статичного сайту немає нічого нового. Навіть у давнього конкурента WordPress, системи управління контентом Movable Type була опція створення статичного сайту.
Google Trends за запитом "static website generator". (Збільшена версія)
З тих пір багато обмежень, що стримували статичні сайти, стали неактуальні і сучасні генератори це конкурентоспроможні движки, орієнтовані насамперед на фронтенд розробників.
З кожним тижнем генераторів статичних сайтів стає все більше і встигати за ними стає все важче. Загалом, всі популярні генератори статичних сайтів мають такі риси.
Можливість розбивати сайт на окремі шари і фрагменти, щоб уникнути повторення це одна з основ для генератора статичного сайту. Існує вибір з безлічі двигунів шаблонів, у кожного є свої особливості - в деяких з них немає ніякої логіки, в інших шаблон змішується з кодом, але всі вони дозволяють уникнути дублювання хедерів, футер, навігації та іншого.
підтримка Markdown
Більшість генераторів статики підтримує Markdown. Деякі використовують схожі формати типу reStructuredText. Загалом, вони все дозволяють писати простий текст в структурованому вигляді.
метадані
Jekyll заклав основи для генератора статичного сайту: шаблони і Markdown наше все.
Коли творець GitHub Том Престон Вернер написав Jekyll для ведення свого блогу, він знайшов дуже цікаве рішення для подання метаданих в документах Markdown і шаблонах: вступну частину.
Вступна частина це невелика кількість метаданих, зазвичай в форматі YAML, розташованих на самому початку документа:
Вступні спрощують створення анотацій до однофайловий документам і дає простий чіткий формат тексту для всіх даних, зазвичай розкиданих по різних таблицях бази даних.
Файлопровод (Asset Pipeline)
Фронтенд сьогодні неможливий без систем збирання і компіляторів. Ми хочемо об'єднувати і стискати файли. Препроцесори CSS це давно вже не іграшка для гиків, а частина нормального робочого процесу. Те саме можна сказати і до CoffeeScript і ECMAScript 6, для використання яких необхідні компілятори.
У більшості генераторів статичних сайтів вже включений файлопровод, тобто система компіляції, мініфікаціі, збірки та іншої обробки ресурсів. Деякі з них засновані на системах зборки типу Grunt, Gulp або Broccoli і дають вам відразу доступ до всіх можливостей відповідної екосистеми. Інші оптимізують конкретні робочі процеси, роблячи їх доступними "з коробки", без настройки конфігурації. Для багатьох генераторів стандартом стало автоматичне оновлення браузера при збереженні файлів.
Підсумовуємо вищевикладене
Генератор статичного сайту зазвичай надає інтерфейс командного рядка для збирання сайту або запуску локального сервера для розробки.
У Jekyll є команда jekyll build. збирає готовий сайт з наявних файлів проекту і поміщає його в підкаталог.
Ось приблизна структура початкових кодів сайту:
В папці це _site з цих початкових кодів ми отримуємо готовий сайт, який можна завантажити на будь-який статичний або звичайний хостинг.
Чому це актуально зараз?
ОК, все згодні з тим, що генератори статичних сайтів це здорово. Але чому цей сплеск відбувся саме зараз і чому ранні генератори не змогли нічого протиставити того ж WordPress? Що змінилося? І наскільки далеко це зайде?
Сучасні генератори статики працюють в екосистемі абсолютно відмінною від тієї, яка була раніше. Багато обмеження, які робили динамічні сайти безальтернативними для всього більш складного, ніж онлайн брошура, відпали, хоча деякі залишилися.
браузери змінилися
Сьогодні, ми присутні на урочистих похоронах останнього з браузерів старої школи (спочивай з миром, ІЕ8). Сучасний браузер це практично операційна система, не просто показує викачані з мережі документи, а здатна запускати повноцінні веб-додатки, робити зовнішні виклики до будь-якого сумісного з CORS API, зберігати дані локально, відкривати веб-сокети і навіть обробляти peer-to-peer з'єднання з іншими браузерами через WebRTC.
І цей список можна продовжувати - ціла екосистема чисто браузерних розширень вже створена. Крім того, сучасні веб-додатки, побудовані на основі Ember.js, AngularJS або React часто розміщуються як статичні сайти безпосередньо на CDN з чистим API, що зв'язує інтерфейс сайту з мобільним клієнтом.
CDN стали мейнстримом
Хоча розцінки Akamai і раніше високі, сьогодні будь-хто може дозволити собі використовувати Amazon AWS або CloudFront на своєму сайті. Також є компанії типу Fastly, MaxCDN і CloudFlare надають сервіс CDN за доступними цінами для малого бізнесу.
Ви можете використовувати CDN на динамічному сайті, але ви зіткнетеся з проблемою інвалідаціі кеша. Пошук балансу між кешуванням на окремих вузлах і динамічним бекенд, вимагає досить складних розрахунків, якщо не сказати більше.
Статичний сайт з іншого боку, готовий до розміщення безпосередньо на CDN, а значить, і до передачі кешу з вузлів, максимально близьких до кінцевих користувачів. Налаштування конфігурації, звичайно ж, займе певний час, та й інвалідація кеша залишається непростою - але всі ці завдання здійсненні і повністю автоматизовані за сервісами типу Netlify.
Продуктивність перш за все
Мобільні пристрої змінили веб самими різними способами. Все більше користувачів заходить в інтернет з мобільних, іноді з з'єднанням 3G. І ніколи раніше продуктивність не була так важлива.
Не важливо, наскільки ви оптимізуєте свій динамічний сайт і скільки тисяч доларів ви на це витратите - ви ніколи не досягнете такої ж продуктивності, як на правильно налаштованому статичному сайті, розміщеному на CDN за кілька доларів в місяць. З урахуванням постійного підвищення значущості продуктивності не дивно, що розробники шукають способи заздалегідь генерувати HTML, а не витрачати час і ресурси сервера на генерацію сторінки по кожному HTTP-запиту.
Генерація статичного сайту також вирішує безліч проблем продуктивності в процесі розробки.
Якщо ви створюєте динамічний сайт на основі бази даних, для вас вкрай важлива ефективність запитів до бази даних, вони повинні бути досить швидкими, щоб виконуватися один раз для кожного HTTP-запиту. Навіть якщо у вашого сайту є достатній рівень кешування, завжди є ризик, що окремі запити будуть надмірно завантажувати кеш і поступово загальмовує всю систему.
Впровадження інструментів для збірки
Зовсім недавно компілятори і системи збирання цікавили тільки програмістів C і Java і ніяк не зачіпали процес створення сайтів. Але зараз все змінилося, подобається нам це чи ні.
Сьогодні фронтенд розробники адаптували для своїх потреб системи збирання, пакетні менеджери, компілятори і транслятори. Почалася все з Grunt, тепер подібні речі стали основою для більшості нових проектів.
З домінуванням систем збірок, генератори статичних сайтів стали більш природною частиною фронтенд розробки, а традиційні PHP-системи для динамічних сайтів виглядають чужими в сучасному робочому процесі на фронтенді.
Чого бракує
Всі ці фактори створили чудові умови для зльоту популярності генераторів статичних сайтів й не дивно, що все більше сайтів збираються статичними.
Але не все так просто. Щоб остаточно перейти в мейнстрім, генераторів статики треба домогтися прориву в кількох областях.
Вибір генератора статичного сайту і запуск проекту як і раніше залишаються досить проблематичними для першого разу. Можна багато поліпшити починаючи з інструментарію і закінчуючи документацією і доступними ресурсами.
Незважаючи на бурхливий ріст інфраструктури навколо генераторів статичних сайтів, вони як і раніше помітно відстають від серйозних магазинів тим і сервісів підтримки, наявних для традиційних динамічних платформ.
Тому дуже багато сайтів, зібрані на генераторах статики в результаті мігрують на динамічну CMS. Необхідний міст, що з'єднує контент-менеджерів і системи генерації статичних сайтів. Поки цього не станеться, згенеровані статичні сайти будуть займати невелику нішу.
Існують і інші цікаві рішення без CMS. Verge використовує таблиці Google в якості шару контенту для Middleman; StaticGen використовує Gist і GitHub API як заміну бази даних, а Carrot використовує Contentful як статична CMS - все це дозволяє простим користувачам працювати з генеруються статичними сайтами.
Системи типу Contentful. Prismic.io. GatherContent видаляють CMS з процесу веб-розробки. І це робить їх цікавими інструментами для багатоканального управління контентом, коли ви пишете контент не тільки для якогось сайту, але і для мобільного застосування, сторінки в соцмережі або інших цілей. Публікація нового контенту запускає систему збирання; потім генератор статичного сайту виконує отримання даних з API і збірку сайту; готовий результат відправляється безпосередньо на CDN.
Іншим способом редагування контенту є робота безпосередньо в основному репозиторії.
У Netlify розробляється CMS з відкритим кодом. Неприв'язані до якогось конкретного генератору статичних сайтів або хостингу. Її метою є робота з більшістю статичних генераторів і ми думаємо, що це відмінний спосіб вийти за межі, які накладаються сучасними технологіями збирання статичних сайтів.
Очевидно, що завжди будуть існувати сайти, для яких движок генерації статики не придатний в принципі - особливо ті, вмістом яких є постійно оновлювана трансляція або ті, вміст яких значною мірою залежить від пошуку і фільтрації.
Як було сказано, генератори статичних сайтів будуть продовжувати нарощувати можливості і популярність. Їх інфраструктура і екосистема будуть розвиватися. І з вдосконаленням інструментів, ми побачимо, що розробники розширять межі того, що можна реалізувати з генераторами статичних сайтів.
У Netlify ми вже бачимо як великі сайти з контентом, пошуком в реальному часі, багатомовністю і приватними розділами збираються за допомогою генераторів статики і API. З усвідомленням важливості продуктивності і підвищення безпеки, ми розраховуємо, що побачимо набагато більше.