Коли данському малому бізнесу потрібен новий сайт, розмова майже завжди одразу переходить до WordPress, Wix чи подібної CMS-системи, просто тому що це типовий вибір, до якого всі звично звертаються. Для багатьох сайтів це правильне рішення. Але у звичному випадку — сторінка компанії з п'яти-десяти розділів, список послуг, контактна форма і, можливо, блог, де контент змінюється кілька разів на рік — CMS приносить із собою низку постійних витрат, про які рідко згадують у першій розмові: базу даних і адмін-логін, які обидва потребують оновлень, екосистему плагінів, де одне оновлення може тихо зламати сторінку, і рахунок за хостинг, що зростає разом із відвідуваністю, хоча сам контент практично не змінюється. Жодна з цих витрат не проявляється в перший день. Вони проявляються через півтора року — як повільний сайт, попередження про безпеку, чи рахунок розробника за виправлення чогось, що зламалося під час рутинного оновлення, яке ніхто не просив.
Статичний сайт уникає більшості цього самою своєю побудовою. Сторінки генеруються один раз, під час збірки, у звичайний HTML, CSS і JavaScript, і відтоді єдина робота сервера — віддавати ці файли браузеру: немає бази даних, яку можна запитувати, немає адмін-панелі, до якої можна вломитися, і немає дерева залежностей плагінів, яке треба тримати синхронізованим. Практичні результати — ті, що мають значення для малого бізнесу: сторінки, що завантажуються майже миттєво, бо немає кроку серверного рендерингу при кожному відвідуванні, хостинг, що коштує частку від керованого CMS-плану, бо статичні файли дешево віддавати за будь-якого обсягу, і значно менша поверхня для атаки, бо немає ні форми входу, ні застарілого плагіна, на які зловмисник міг би націлитися. До слова, саме на такій архітектурі, трьома мовами, працює й сам сайт LynBro — саме з цих причин.
Це не універсальна рекомендація. Сайт, де нетехнічні співробітники мають публікувати новий запис у блозі щодня, інтернет-магазин із залишками на складі в реальному часі та оформленням замовлення, або сторінка, де відвідувач справді має залогінитися й побачити персоналізований контент, гірше підходить для чисто статичної збірки — тут натомість правильний інструмент це headless CMS, що живить статичний фронтенд, або повноцінний веб-застосунок. Чесний тест простий: якщо оновлення сайту означає редагування кількох сторінок пару разів на рік, статичний варіант виграє за ціною й безпекою; якщо це означає, що маркетологу потрібно публікувати новий контент без розробника щотижня, то ні.
Поширене заперечення — що статичний сайт не може робити нічого динамічного — здебільшого застаріле. Контактна форма може надсилати дані на невелику serverless-функцію чи сервіс обробки форм без потреби у власному сервері. Поле адреси може автозаповнюватися, коли клієнт вводить адресу доставки чи рахунку, звертаючись до данського API адрес прямо з браузера; Danadresse.dk — безкоштовний, сумісний із DAWA API, що охоплює 2,7 мільйона данських адрес і робить саме це, без потреби в backend на боці самого сайту. Віджети бронювання, чат-віджети й аналітика підключаються так само — як скрипти, завантажені на інакше статичну сторінку. Для відвідувача результат виглядає й поводиться як динамічний сайт, лишаючись під капотом статичним — тобто дешевим і важким для зламу.
Статичні сайти також добре поєднуються з друкованим і офлайн-маркетингом так, що це легко пропустити: флаєр, наклейка на фургоні чи чек можуть містити короткий лінк і QR-код від Gyk.dk, що веде прямо на конкретну сторінку сайту, з статистикою кліків, яка показує, чи хтось справді відсканував код — і все це без зміни маршрутизації сайту чи додавання серверної логіки. Для данського малого бізнесу, що зважує новий сайт чи редизайн, питання, варте того, щоб поставити його до того, як обрати CMS за замовчуванням, — просто наскільки часто контент дійсно змінюється. А якщо відповідь — кілька разів на рік, зв'яжіться з нами, щоб дізнатися, чи статична збірка слугувала б бізнесу краще.