×Закрыть

Фишки JAMstack: почему статические сайты превосходят традиционные динамические

В этой статье мы разберем с вами ключевые моменты разработки статических сайтов и познаем превосходство static site над traditional dynamic site.

Intro

Все больше и больше оборотов набирает довольно новый и нетрадиционный подход в создании сайтов — JAMstack.

Для начала давайте разберемся, что такое JAMStack, с чем его едят и почему он «превосходит» традиционные web-сайты. Дабы не углубляться в подробности и не превращать информационную статью в копипаст из официальных источников, я постараюсь описать в двух словах, что же такое этот JAMstack.

  • JAMstack — не технология. Я бы назвал это методологией или подходом, который предлагает множество инструментов на выбор для создания статических сайтов. Он появился не так давно, но уже набрал довольно приличное комьюнити.
  • JAMstack это — «J» — JavaScript, «A» — API, «M» — markup (так указано на официальном сайте).

Исходя из расшифровки аббревиатуры, становится понятным, что для создания статического сайта, который не будет уступать динамическому, нам необходимо всего 3 компонента:

  1. JavaScript — для придания интерактивности нашему сайту;
  2. API — источник информации, используемый сайтом;
  3. Markup — какой-то контент-генератор или, как некоторые его называют, «шаблонизатор», позволяющий создать разметку страниц.

Детали

JavaScript

Кто сталкивался с JavaScript, тот меня поймет, зачем он нужен и с чем его едят. Для тех, кто не сталкивался, немного поясню.

JavaScript — мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript (стандарт ECMA-262[8]). Тут подробнее. Вкратце — это то, что помогает пользователю взаимодействовать с DOM-элементами на web-страницах. По большому счету для совсем простых сайтов можно обойтись и без него.

API

API, или проще говоря, Application Interface, в данном случае подразумевает собой источник входной информации, контента, необходимого для встраивания в шаблон нашего Markup.

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

Markup

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

Именно для этой цели были созданы SSG — статик сайт-генераторы.

Что делают эти SSG?

Ровным счетом ничего, кроме того, что из обычных файлов, заполненных контентом, генерируют связанные между собой HTML-страницы по заведомо разработанным HTML-шаблонам. Грубо говоря, создают HTML-страницы, подставляя значение этих переменных из контент-файлов на место переменных в шаблоне.

Мы остановили свой выбор на статическом контент-генераторе Hugo (здесь подробнее о нем). Почему?

  • доступная документация;
  • наличие CLI;
  • поддержка мультиязычности;
  • FREE;
  • поддержка роутинга;
  • и полное удовлетворение SEO-потребностей (редиректы, xml ... и т. д).

Все хорошо, но зачем? Есть массы традиционных CMS

Ответ довольно прост. С растущей потребностью в скорости загрузки и простоте поддержки готового продукта традиционные CMS — довольно непростой случай:

  • уязвимость перед хакерскими атаками;
  • при большом наплыве посетителей сервер перестает отвечать;
  • зачастую низкая скорость сайта;
  • требует постоянной поддержки и модерирования сервера.

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

Как JAMstack решет эти проблемы?

Для деплоя статического сайта вам не нужен традиционный web-сервер. Статический сайт можно разместить где угодно, и он будет работать от Git Pages до Amazon CDN или на прочих сервисах для хранения файлов. Их море. То есть проблема с сервером решена — он нам больше не нужен.

Безопасность. Максимум, что может совершить злоумышленник — скопировать наши HTML-файлы. Ну и на здоровье, они и так публичны :)

Скорость сайта. Тут все еще проще — страница уже собрана, она не строится в рантайме. Пользователю при запросе приходит простой HTML-файл, который уже заполнен контентом. Как плюс, приятные фичи Asset Optimization от Netlify позволяют cделать вес нашей страницы минимальным.

Никакой цикличной поддержки, бекапов и модерации. Все хранится в Github/Bitbucket/GitLab или в вашем архиве на жестком диске (ах да, это я об исходниках). А касаемо сгенерированного контента, в случае с Netlify ваш сайт размещен на тысячах CDN-серверов по всему миру :)

Звучит прикольно, но все еще непонятно, как это работает

Процесс работы с JAMstack я попытаюсь описать на личном опыте.

Первым делом мы регистрируемся на GitHub — это бесплатно. Затем создаем репозиторий и добавляем в него наш проект, разработанный на Hugo. После чего регистрируемся в Netlify, выполняем быстрый туториал и деплоим наш сайт.

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

Конечно, нам нужна админ-панель. Для этого можно использовать Netlify CMS — бесплатно, Forestry — условно бесплатно, DatoCMS — условно бесплатно. Сам процесс описывать не буду, но если задаться целью, то все очень просто.

В итоге

Я на личном опыте убедился в том, что, если создавать сайт на JAMstack (я использовал Dato + Hugo + Netlify), время разработки сокращается в 2 раза. У клиента есть бесплатный SSL — сертификат и HTTP2. Нет аптаймов, сайт грузится быстро — можно хвастаться PageSpeed. Клиент по-прежнему может редактировать контент. В итоге из 15 сайтов, созданных на JAMstack, — 15 довольных клиентов.

Примеры:
cantoneri.com <<< ого, да это же интернет-магазин :)
clue.ouraring.com
noiseoftime.merikeskusvellamo.fi

LinkedIn

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Список генераторів статичних сайтів: www.staticgen.com Для себе користувався DocPad — досить зручно і краще ніж збирати сайт сирим gulp/grunt. Hugo не зайшов, бо там golang.

Ну

golang

только в вдижке этого контент генератора) на самом деле в HUGO все очень просто

Так, але якщо треба розширити функціонал — то біда.

Но я уже сделал больше 15 клиентских проектов на HUGO + различные админки, максимум что мне приходилось дописывать это шорткоды — которые довольно просто создаются + у HUGO очень доступная документация) Но тут кому что по душе)

в случае с Netlify ваш сайт размещен на тысячах CDN-серверов по всему миру

Зважаючи на TTFB першого сайта, це або просто неправда, бо більше 180мс — це, явно, сервери у США (ip також вказує на ДЦ Google), або в статті неправильно сформульовано і йдеться про те, що можна обрати лише один сервер із цих «тисяч» CDN (що не вписується, в принципі, в концепцію терміну CDN).

сайт грузится быстро — можно хвастаться PageSpeed

А ви пробували це перевірити:
developers.google.com/...​antoneri.com/&tab=desktop

developers.google.com/...​ouraring.com/&tab=desktop

developers.google.com/...​usvellamo.fi/&tab=desktop

Такий жах не часто можна побачити!
І навіть без PageSpeed очевидно, що швидкість у цих сайтів зовсім не тягне на рівень «статичних» сайтів. У першого ще й скрипт кошика на 583Кб.
І ні, це не «все одно швидше за CMS», бо якщо забути про існування попсового WP і мати прямі руки, то й на CMS можна отримати значно кращі результати, ніж приклади у цій статті.

) а я уже засомневался что кто-то проверит) Я знаю за это и это связано с оптимизацией графического контента) Но я не буду вступать в дискуссию и объяснять почему так)

P/S я ж не написал что эти сайты оптимизированы под PageSpeed) Но главное что есть за что зацепится, я рад этому, что Вы посветили свое время тестированию скорости и определению локации сервера)

Так и не понял, что революционно нового появилось? Статические сайты существовали ещё до динамических, потом на какое-то время всем вскружили голову фреймворки, но сейчас лендинги насколько я знаю опять успешно делают статическим html-м, собирая их простым gulp’ом. Использование js для общения с API — тоже не ново, SPA уже не первый год.

вскружили голову фреймворки

В комментарий вкралась опечатка — имелись в виду CMS, а не фреймворки

Нет опечатки нет) И революции нет) Есть тот факт что на рынок потихоньку возвращается статика но в новом обличии + к ней написали уже довольно много ЦМС которые помогают удобно редактировать контент для этих статических сайтов. А вообще я рекомендую развернуть это все у себя это займет 30 минут максимум, и все станет понятным)

Статья норм. Но JAMSTACK для меня выглядит как переливание из пустого в порожнее. Есть SSG(Static Site Generators) и тут такие модные (хипстеры)ребята из амерички(судя по сайту и расположению сообществ, джем корнями из США) решают за банкой пива:
— А давайте возьмем SSG и продадим как новую парадигму!
— но чем мы будем отличаться?
— нашей фичей будет то, что мы разрешим использовать JS на фортенде для взаимодействия с API! Пусть думают что они не привязаны к бекенду..
— гениально!!
Занавес.

Ну насчет хипстеров из США вы правы) ветер оттуда)))
Но факт остается фактом, заказчики довольны) Они могут редактировать контент, все работает. И нет проблем с сайтом за 300, сделал, отдал, забыл) А с ВП все по-другому: сделал, сдал, но не забыл) Но + за комментарий Вам, довольно справедливо сказано)

Что это я только что прочитал? о_О

360 ms відповідь від сервера

Для тех, кто не сталкивался, немного поясню.
JavaScript — мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript (стандарт ECMA-262[8]).

Сразу все понятно стало.

довольно специфическая вещь. кроме как для простых контентных сайтов применения не вижу. а это вымирающий вид на сегодня.
относительно скорости все верно, большинство на мобильном медленном интернете и скорость с оптимизацией под мобилы вышла на первый план. для этого создаются уже проекты типа google amp и сайты пилятся с подходом mobile first.
что точно будет происходить: сайты будут превращаться в полноценные приложения со все большими возможностями относительно девайсов где их юзают. интернет будет чистится от некачественного контента, а лидеры будут только укрупнятся и со временем распадаться на отдельные сервисы. где место для этой технологии в будущем, хз

Тоесть если вы педалите на ангуляре/реакте и у вас бекэнд это rest api, то это надо называть JAMstack?

Раз все составляющие есть то возможно и можно) Я не автор этого термина, но на оф сайте можно углубится в проблему и докопаться до истины. jamstack.org/best-practices

Но суть не в том что можно, а что не можно называть) А суть в том что этот термин стал на слуху после активного продвижения статических сайтов, и их новых возможностей, именно под названием JAMStack.

CMS — довольно непростой случай:

и

Для этого можно использовать Netlify CMS — бесплатно,

как-то странно)

CMS — довольно непростой случай:

<<< традиционная CMS for ex. WP.
А

Netlify CMS

Это грубо-говоря удобный редактор контента, то-есть CMS (content management system)

Sounds good, doesn’t work.
Получается для обработки корзины покупок, форм обратной связи, комментариев и т.д. нужно пользоваться сервисами третьих сторон. Хорошо если они подходят, если нет — тупик.
Сколько занимает деплой обновленной версии сайта после комита? У меня на гитлабе это занимало до 10 минут без возможности посмотреть прогресс в админке. Не техническим пользователям такое не сильно подходит.
Скорость загрузки (у меня вышло 360мс для cantoneri.com) — в 2 раза больше чем сервер-сайд рендеринг сайта на Nuxt.js + 4 API запроса для подгрузки данных для этого рендеринга. Сравнение не совсем честное, но все таки «скорость работы» — не очевидное преимущество, а при наличии кеша на динамическом сайте, выигрыш статики только за счет CDN.

ИМХО, для простых задач — отличное решение. Но динамика все равно никуда не денется, даже особо не пошатнется, т.к. ограничения статики никуда не денутся, разве что сгладятся костылями типа использования SaaS-корзины.

Спасибо за комментарий) Но Netlify делает бил примерно за 15 — 60 сек (С оптимизацией изображений). Сравнение скорости не уверен что быстрее статики может быть традиционный сайт (WP итд.). Но и явно Ваше приложение не тянет за собой prntscr.com/h5q6bg 5mb контента).

В сравнении с WP даже поставленным на CloudFlare, статика быстрее.

P/s Статика и JAMstack набирают оборотов. И это явно лучший вариант для небольшого блога, корпоративного сайта и тд... так как на них контент меняется реже чем пользователи их посещают). Советую попробовать стек: HUGO + NETLIFY. Проверено на практике: клиенты довольны, плагины обновлять не нужно, проблем с безопасностью нет)

Да и в принципе я не сказал что динамика уйдет в нибытие) Но даже Back, да и в принципе мир wepapps движется к схеме Backend > API > Frontend, но это совершенно другая история)

Но и явно Ваше приложение не тянет за собой prntscr.com/h5q6bg 5mb контента).

А я брал время загрузки только html, не имеет значения сколько там еще контента. В моем приложении html файл весит в 10 раз больше вашего (т.к. кроме разметки содержит жсон данные для гидрации), но грузится в 2 раза быстрее при том что генерируется в рантайме делая 4 запроса к апи на том же сервере. Не говорю что динамика быстрее статики при прочих равных, но видимо ваш CDN или хостинг в этом плане вас подводит.

Вообще, я всеми руками и ногами за схему Backend API > SSR > SPA которую кстати в простых случаях можно использовать для статической генерации, но со своими плюшками типа переходов без перезагрузки и более удобной организации интерактивщины из коробки. Но и недостатки тут есть... Как и везде.

Да но, на сколько я прав, у Вас из исходного

html

пару тегов типа
<—>
another HTML head markup

<div id="maAwesomeApp"></div>
another HTML footer markup
<—>

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

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

Насчет недостатков, согласен — они везде и во всем, и я не утверждаю что JAMStack это лучшее что появилось в веб)

нет, на сервере рендер работает. Т.е. разметка страницы после инициализации приложения никак не меняется и будет работать с отключенным жабаскриптом даже если логика ее отображения написана на этом же жабаскрипте. Это и есть SSR. В моем случае оно сделано на фреймворке Nuxt.js (vue.js как рендерилка).
кстати, серверный рендер отключается в пару кликов в случае непредвиденной нагрузки и сайт начинает работать так как вы говорите.

Ok, ну а как насчет масштабирования? на сколько упадет скорость ответа сервера при заходе на сайт в 1000 юзеров? Тогда нам нужен лоадбалансер или дополнительный сервервер, ну вариантов тут масса. А вот в случае с данных стеком (Который я написал), хоть и 10000 пользователей одновременно зайдет то сервер не ляжет)

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

Я знал что Вы напишите за Lambda))) Но это все платные решения, а стек описанный мною совершенно бесплатный для небольшого среднего сайта) Да и заморачиватся особо не нужно git push 30sec build > Production. )) Ну тут каждый останется при своем, как уже было сказано ранее у всего есть свои плюсы и минусы.

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

P/s я не кого не собираюсь переубеждать, лишь делюсь опытом)

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

Собственно и в этом суть, делится и быть полезным) Другой цели я не преследовал, когда писал статью)

Он не ляжет только потому что у вас сторонний бэкенд на котором уже есть все эти балансировки и кластеры с логикой. В целом весь этот jam выглядит как «а давайте будем использовать сторонний saas бэкенд», то то и всего..

Звучит прикольно, но все еще непонятно, как это работает. Где можно узнать больше об этом?

Подписаться на комментарии