Лендінг на чистому HTML/CSS: хедер, можливості, тарифи, FAQ (у стилі документації)
Не потрібен фреймворк, щоб опублікувати переконливий лендінг. Потрібні дисциплінований HTML, стриманий CSS і операційна підозрілість, щоб він залишався швидким, коли маркетинг неодмінно додасть «ще один бейдж».
Це продукційна схема: сторінка в стилі документації, що читається як інженерна документація, продає як лендінг і поводиться як статичний контент — передбачувано, кешовано й корисно нудно.
- Без JavaScript
- Доступність за замовчуванням
- Порядок метаданих для SEO
- SRE‑рівень усунення проблем
Зміст
- Цілі дизайну для лендінгу в стилі документації
- HTML‑структура, що масштабується без драм
- Секція можливостей, яка відповідає на реальні заперечення
- Тарифи, що зменшують звернення в підтримку
- FAQ, що знижує шум у продажах
- Факти та історія: чому «лише HTML/CSS» продовжує перемагати
- Практичні операторські завдання: команди, виводи, рішення
- План швидкої діагностики
- Поширені помилки: симптом → корінь → виправлення
- Три міні-історії з практики
- Чеклісти / покроковий план
- Наступні кроки
Цілі дизайну для лендінгу в стилі документації
Лендінг у стилі документації — це те, що відбувається, коли ви поважаєте час читача. Мета не загипнотизувати когось градієнтами, щоб він натиснув кнопку. Мета — дозволити швидко самокваліфікуватися: «Чи це для мене?» і «Чи працюватиме це в моєму середовищі?»
Якщо ви коли-небудь були на виклику, коли маркетинг запустив 5 МБ відео в хедері, ви вже розумієте підґрунтя: надійність — це фіча, а лендінг — частина системи. Він бере участь у ваших SLO, хоч би хто що говорив на плануванні.
Думка: чистий HTML/CSS — це за замовчуванням, а не фішка. Додавайте JavaScript тільки коли він дає виміряну користь (конверсія, доступність або юзабіліті) і тримайте його опціональним.
Що означає «стиль документації»
Стиль документації — це не тільки типографіка. Це інформаційний контракт. Ви вказуєте, що робить продукт, як він поводиться, скільки коштує і чого він не робить — без маркетингових метафор, які треба розшифровувати.
Зокрема:
- Навігація передбачувана: TOC, анкерні посилання і стабільні заголовки.
- Тарифи явні: що включено, що ні, що відбувається при досягненні лімітів.
- FAQ написаний так, ніби підтримка вже отримала тікет.
- Продуктивність розглядається як бюджетна інфраструктура, а не як настрій.
Обмеження, що роблять сторінку кращою
Чистий HTML/CSS дає обмеження, які рятують вас від власних помилок. Немає ланцюжка збірки, немає дрейфу залежностей, немає «хтось оновив роутер і лендінг зламався». Поверхня ризику зменшується. Історія деплою стає: завантажити файл, встановити заголовки кешу, перевірити.
Обмеження також інструмент дизайну. Коли ви не можете покластися на компонент фреймворка для всього, ви пишете менше і вибираєте уважніше: менше шрифтів, менше макетів, менше брейкпоінтів, менше див.
HTML‑структура, що масштабується без драм
Лендінги деградують, коли вони ростуть. Хтось додає ще секцію, потім сайдбар, потім «плаваючий CTA», і раптом ваші заголовки в неправильному порядку, а CSS — археологічна ділянка.
Виправлення — не фреймворк. Виправлення — це структура: семантичний HTML, передбачувана номенклатура класів і макет, який деградує граціозно.
Використовуйте семантичні орієнтири, щоб сторінка мала інструкцію з експлуатації
Використовуйте <header>, <nav>, <main>, <section> і <footer> по-справжньому. Сторінка в стилі документації має бути керованою без миші і без вгадування, де автор сховав контент.
Заголовки — це API: не ламайте їх
Тримайте один <h1>. Використовуйте <h2> для основних секцій: Можливості, Тарифи, FAQ та оперативні секції як діагностика і помилки. Усередині кожної — <h3> для підтем. Це важливо для доступності, SEO і для людей, що сканують сторінку.
Зробіть TOC реальним, а не декоративним
Зміст з анкерними посиланнями робить три речі: зменшує відтік, бо люди можуть перейти до потрібного питання; робить сторінку «задокументованою»; і дає стабільні цілі для внутрішніх посилань з листів, тікетів і чату.
Хитрість — стабільність. Не базуйте анкери на контенті, що змінюється щотижня. Використовуйте id, які переживуть редагування тексту. Якщо треба перейменувати заголовок, збережіть id, доки не підготуєте підтримку старих посилань.
Pure CSS FAQ: використовуйте details/summary навмисно
Елемент details — недооцінений герой інтерактивності без JS. Він доступний з клавіатури і працює без сценаріїв. Стилізуйте його помірно. Не перетворюйте на крихкий імітатор JavaScript‑акордеону.
Два правила, що запобігають 80% багів макета
- Встановіть розміри зображень (або співвідношення сторін), щоб макет не стрибав. CLS — це податок для SEO і для довіри користувача.
- Використовуйте контейнери з
max-width. Повноекранні фони — ок. Текст потребує читабельної ширини, а не злітно-посадкової смуги.
Короткий жарт: CSS легкий, поки не стає важким, а тоді перетворюється на релігійну дискусію з гіршими інструментами.
Секція можливостей, яка відповідає на реальні заперечення
Можливості — це не список покупок. Це заперечення. На сторінці в стилі документації кожна можливість має пояснювати: що вона робить, що замінює і який режим відмови вона запобігає. Якщо вона не змінює рішення — це декорація.
Статичне доставляння з сильним кешуванням. HTML може мати короткий термін життя; ресурси можуть мати довгий і immutable.
Переклад: швидше глобальне завантаження і менше випадків «чому лендінг недоступний?».
Семантичний HTML, що працює з клавіатурою і зчитувачами екрана без пластирів ARIA.
Навігація в стилі документації — це фіча зручності, а не театральна відповідність.
Низька поверхня залежностей. Не потрібен пайплайн збірки. Доставляйте як конфіг.
Менше інструментів — менше сюрпризів у ланцюжку постачання і менше проблем з локальною збіркою.
Парність title і description, послідовні заголовки і стабільні анкери.
Пошукові системи віддають перевагу сторінкам, що поводяться як добре організовані документи. Люди теж.
Правдиві твердження з вказаними обмеженнями. Ви уникаєте дорогих розмов «але ж ви не сказали…».
Тарифи і FAQ стають відведенням підтримки, що ввічливо означає «менше хаосу».
Діагностована доставка: чітка політика кешування, зрозумілі шляхи ресурсів, точки спостереження.
Коли щось ламається, причину можна знайти за хвилини, а не за легендами.
Копі для можливостей, яке не старіє
Уникайте версіонованих тверджень на кшталт «найшвидший на ринку», якщо ви не готові доводити це щотижня. Віддавайте перевагу твердженням, які ви можете підтримувати процесами: «static-first», «без необхідності JS», «доступні орієнтири», «передбачуване кешування».
Тут корисний ops‑погляд для маркетингу. Обіцянки стають обмеженнями. Обмеження — надійністю.
Тарифи, що зменшують звернення в підтримку
Тарифи — це операційна справа. Якщо вони нечіткі, ви заплатите в передпродажних дзвінках, поверненнях коштів, сердитих листах і тим, що інженерів затягуватимуть у «швидкі питання». Секція тарифів у стилі документації має читатися як контракт: що ви отримуєте, що не отримуєте і що відбувається при досягненні лімітів.
Starter
$0
Для внутрішніх прототипів і персональних сторінок.
- Односторінкова верстка
- Базовий TOC + анкери
- FAQ з
details/summary - Без кастомних шрифтів (використовувати системні)
Team
$29/mo
Для продуктових сторінок, що мають працювати під навантаженням.
- Хедер + сітка можливостей + тарифи + FAQ
- Чекліст бюджетів продуктивності
- Рекомендації щодо кешу та CDN
- Патерни доступної навігації
Enterprise
$Custom
Для організацій з високими вимогами до відповідності та закупівель.
- Перевірка контенту: юридично + доступність
- Патерни деплою для мульти-регіонів
- Діагностика готова до інцидентів
- Шаблони контролю змін
Правила проєктування тарифів, які варто прийняти
| Правило | Що це запобігає | Як це писати |
|---|---|---|
| Чітко вказуйте ліміти | Несподівані оверейджі та ескалації «це не те, що ми думали» | Використовуйте числа й значення за замовчуванням: кількість сторінок, розмір збірки, очікування відповіді підтримки |
| Зробіть середній план реальним | Воронки тільки для Enterprise, що марнують час | Помістіть корисний план посередині; дайте йому достатньо деталей, щоб обрати його |
| Уточніть виключення | Тіньові вимоги, що стають скоп‑криплом | Перелічіть «не включено»: кастомна аналітика, A/B тестування, індивідуальний дизайн |
| Використовуйте стабільну термінологію | Тікети підтримки через зміну назв | Не перейменовуйте «Team» щоквартально; стабільність — це довіра |
Другий короткий жарт (обмеження вичерпано): «Необмежено» зазвичай означає «необмежено зустрічей», і вас виставлятимуть рахунок увагою.
FAQ, що знижує шум у продажах
Ваш FAQ — не збірка випадкових питань. Це щит. Він блокує передбачувані «а що якщо…» розмови до того, як вони стануть календарними запрошеннями. Тримайте відповіді лаконічними, тестованими і написаними так, ніби ви вже зустрічали цього клієнта.
Чи може лендінг у стилі документації все ще конвертувати?
Так, якщо читач технічний або обмежений у часі. Чітка структура зменшує когнітивне навантаження. Люди клікають, коли довіряють сторінці. Довіра формується конкретними твердженнями і передбачуваною навігацією.
Чи потрібен JavaScript для акордеону в FAQ?
Ні. Використовуйте details/summary. Воно інтерактивне, доступне і працює в сучасних браузерах. Якщо потрібна аналітика відкривань/закривань, додайте JS пізніше і збережіть базу функціональною.
Як уникнути зсуву макета (CLS) без фреймворка?
Встановіть ширину/висоту для зображень, резервуйте простір для медіа і уникайте пізнього завантаження шрифтів. Використовуйте font-display: swap для шрифтів і віддавайте перевагу системним шрифтам, коли це можливо.
Яка найпростша стратегія деплою?
Сервіруйте статичні файли через Nginx (або CDN). Кешуйте immutable ресурси довго. HTML кешуйте коротко. Використовуйте атомарні деплої, щоб ніколи не віддавати HTML з посиланням на відсутні ресурси.
Як зберегти стабільність анкерних посилань, якщо заголовки змінюються?
Зберігайте id стабільним, навіть якщо видимий заголовок змінюється. Ставтесь до анкерів як до API: зворотна сумісність важлива, бо зовнішні посилання існуватимуть.
Яка правильна стратегія шрифтів?
Починайте з системних шрифтів. Додавайте кастомний шрифт тільки якщо він суттєво покращує сприйняття бренду. Якщо додаєте — хостьте його самі, зробіть субсет і відповідально preload.
Як писати тарифи, щоб підтримка не ненавиділа вас?
Визначайте ліміти, вказуйте, що трапиться при їх перевищенні, і перелічуйте виключення. Якщо «чесне використання» вирішує багато питань, переформулюйте, поки воно не перестане бути розпливчастим.
Чи добре чистий HTML/CSS для SEO?
Часто — відмінно. Контент доступний одразу, заголовки чисті, рендер швидкий. Проблеми з SEO зазвичай походять від відсутніх метаданих, дублів title або зламаних canonical.
Як забезпечити швидкість сторінки під час еволюції?
Встановіть бюджет продуктивності (байти, запити, найбільший елемент контенту). Переглядайте зміни як інфраструктуру: виміряйте до/після і відкатуйте, якщо потрібно.
Факти та історія: чому «лише HTML/CSS» продовжує перемагати
Трохи контексту допоможе відстоювати простоту в кімнатах, що люблять складність. Ось конкретні факти, що мають значення при виборі чистого HTML/CSS для лендінгу.
details/summary існує для вбудованих видимих віджетів. Це нативний спосіб поступово відкривати контент без скриптів.«Сподівання — не стратегія.» — генерал Гордон Р. Салліван
Цей вислів має висіти поруч із запитом «давайте додамо третій скрипт аналітики». Якщо ви не можете пояснити режим відмови і план відкату — ви не релізите фічу; ви релізите сюрприз.
Практичні операторські завдання: команди, виводи, рішення
Це та частина, якої більшість лендінгів не містить: як запускати сторінку так, ніби це важливо. Нижче — практичні завдання для Linux‑хоста, що сервить ваш статичний HTML, з командами, реалістичними виводами і рішеннями на їх основі.
Припустимо, Nginx сервить /var/www/landing, і ви деплоїте на хост з ім’ям server. Підлаштуйте шляхи під своє середовище, але збережіть логіку прийняття рішення.
Завдання 1: Перевірити, що HTML дійсно віддається
cr0x@server:~$ curl -I http://127.0.0.1/
HTTP/1.1 200 OK
Server: nginx/1.24.0
Content-Type: text/html
Content-Length: 48231
Last-Modified: Mon, 29 Dec 2025 10:15:44 GMT
ETag: "67713d10-bc67"
Accept-Ranges: bytes
Що це означає: Ви отримуєте 200 і контент — HTML. ETag і Last‑Modified присутні, тому умовні запити можуть працювати.
Рішення: Якщо це не 200, виправте маршрутизацію/віртуальний хост до того, як шукати привиди продуктивності. Якщо Content‑Type неправильний — налаштування сервера або файли некоректні.
Завдання 2: Перевірити заголовки кешування для HTML (короткий термін за дизайном)
cr0x@server:~$ curl -I http://127.0.0.1/ | grep -i cache-control
Cache-Control: public, max-age=60
Що це означає: HTML кешується 60 секунд. Це поширений компроміс: уникає трешу і дозволяє швидко бачити оновлення.
Рішення: Якщо HTML кешується годинами, ви повільно шипите фікси і плутаєте користувачів. Якщо взагалі не кешується — ваш origin працюватиме важче, ніж треба.
Завдання 3: Перевірити заголовки кешування для immutable ресурсів (довгоживучі)
cr0x@server:~$ curl -I http://127.0.0.1/assets/app.3f2c1a9e.css | egrep -i 'cache-control|content-type'
Content-Type: text/css
Cache-Control: public, max-age=31536000, immutable
Що це означає: CSS кешується рік і позначено як immutable, що правильно тільки якщо ім’я файлу містить хеш контенту.
Рішення: Якщо у вас немає хешованих імен файлів, не використовуйте immutable. Інакше ви створите питання «чому стиль не оновився?».
Завдання 4: Підтвердити, що gzip/brotli ефективні (байти важливі)
cr0x@server:~$ curl -I -H 'Accept-Encoding: gzip' http://127.0.0.1/ | egrep -i 'content-encoding|content-length'
Content-Encoding: gzip
Content-Length: 8421
Що це означає: HTML стиснуто. Менші передачі — швидший перший рендер на повільних мережах.
Рішення: Якщо стиснення відсутнє — увімкніть його для текстових типів. Якщо включено, але Content‑Length залишається величезним — перевірте, чи контент вже скомпресований або немає помилки в налаштуванні.
Завдання 5: Переконатися, що ви не віддаєте випадкові 404 (зламані шляхи ресурсів)
cr0x@server:~$ tail -n 20 /var/log/nginx/access.log
127.0.0.1 - - [29/Dec/2025:10:27:05 +0000] "GET /assets/app.3f2c1a9e.css HTTP/1.1" 200 21844 "-" "curl/8.5.0"
127.0.0.1 - - [29/Dec/2025:10:27:06 +0000] "GET /assets/hero.webp HTTP/1.1" 200 148920 "-" "curl/8.5.0"
127.0.0.1 - - [29/Dec/2025:10:27:07 +0000] "GET /assets/font.woff2 HTTP/1.1" 404 153 "-" "curl/8.5.0"
Що це означає: Запитуваний шрифт відсутній. Це може викликати FOIT/FOUT, зсуви макета і некрасиву відрисовку.
Рішення: Виправте шлях або видаліть посилання. Не ігноруйте 404, «бо сторінка в основному працює». 404 — це також проблема продуктивності.
Завдання 6: Виявити повільні запити на origin (таймінги Nginx)
cr0x@server:~$ awk '{print $NF}' /var/log/nginx/access.log | tail -n 5
0.001
0.002
0.001
0.089
0.001
Що це означає: Один запит зайняв 89 мс на Nginx. Якщо це часто — є проблеми з IO, CPU або upstream‑сервісами.
Рішення: Якщо статичний контент повільно віддається локально, перевірте затримку диска, файлову систему і чи випадково не проксуєте динамічний контент.
Завдання 7: Підтвердити, що конфіг Nginx — це те, що ви думаєте
cr0x@server:~$ nginx -T 2>/dev/null | sed -n '1,40p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
Що це означає: Завантажена конфігурація валідна і ви бачите реально запущену конфігурацію.
Рішення: Якщо не можна відтворити заголовок або поведінку маршрутизації — почніть звідси. Багато «таємничих» проблем — це «змінений не той файл».
Завдання 8: Перевірити TLS і дати дії сертифікату (не чекайте алертів)
cr0x@server:~$ echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar 10 23:59:59 2026 GMT
Що це означає: Дати сертифіката видимі. Якщо ви близькі до notAfter, у вас скоро буде публічний інцидент.
Рішення: Поновіть заздалегідь, автоматизуйте поновлення та стежте за терміном. Відмови сертифікатів — найлегше уникнути, тому вони особливо прикрі.
Завдання 9: Перевірити час розв’язання DNS (затримка до встановлення з’єднання)
cr0x@server:~$ dig example.com +stats | egrep 'Query time|SERVER'
;; Query time: 42 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
Що це означає: Локальний DNS‑запит зайняв 42 мс. Для кінцевих користувачів DNS може бути значно гіршим. Повільний DNS надуває сприйняття повільності.
Рішення: Якщо DNS повільний — перевірте резолвери, кешування і здоров’я записів. Не звинувачуйте CSS у DNS‑проблемах.
Завдання 10: Перевірити розміри ресурсів на диску (дотримання бюджету)
cr0x@server:~$ du -h /var/www/landing/assets | sort -h | tail -n 8
56K /var/www/landing/assets/app.3f2c1a9e.css
148K /var/www/landing/assets/hero.webp
320K /var/www/landing/assets/logo.svg
1.2M /var/www/landing/assets/screenshot.png
Що це означає: Скриншот PNG — 1.2 МБ. Це кандидат на конвертацію в WebP/AVIF і зміну розміру.
Рішення: Встановіть бюджет розмірів ресурсів і контролюйте його під час рев’ю. Якщо одне зображення важить більше кількох сотень КБ — воно має це виправдати.
Завдання 11: Підтвердити, що посилання в HTML коректні (без пропущених хешів)
cr0x@server:~$ grep -nE 'assets/.*\.(css|js|png|webp|woff2)' /var/www/landing/index.html | head
34: <link rel="stylesheet" href="/assets/app.3f2c1a9e.css">
66: <img src="/assets/hero.webp" width="1200" height="700" alt="...">
Що це означає: Сторінка посилається на хешовані ресурси, а зображення мають явні розміри. Добре.
Рішення: Якщо ресурси не хешовані і довго кешуються — виправте пайплайн. Якщо зображення без розмірів — додайте їх, щоб зменшити CLS.
Завдання 12: Перевірити ліміти відкритих файлів і здоров’я воркерів (навіть статичне треба ОС‑гігієни)
cr0x@server:~$ cat /proc/$(pgrep -n nginx)/limits | egrep 'Max open files|Max processes'
Max open files 1024 1024 files
Max processes 62967 62967 processes
Що це означає: Nginx може відкривати тільки 1024 файли на процес воркера. Під навантаженням це може викликати помилки або затримки.
Рішення: Якщо очікується висока конкуренція, підвищте ліміти через systemd overrides і конфіг Nginx. Статичні сторінки також можуть піддатися DoS через популярність.
Завдання 13: Підтвердити, що CDN (або reverse proxy) дійсно кешує
cr0x@server:~$ curl -I https://example.com/ | egrep -i 'age|via|x-cache|cache-control'
cache-control: public, max-age=60
via: 1.1 varnish
age: 38
x-cache: HIT
Що це означає: Відповідь віддається з кешу (HIT) і має Age 38 секунд.
Рішення: Якщо завжди MISS — ви платите за CDN, який не використовується. Виправте ключі кешу, куки або заголовки, що перешкоджають кешуванню.
Завдання 14: Виявити ефективність стиснення для ресурсів (не стискайте вже стиснуте)
cr0x@server:~$ curl -I -H 'Accept-Encoding: gzip' http://127.0.0.1/assets/hero.webp | egrep -i 'content-encoding|content-type'
Content-Type: image/webp
Що це означає: Content‑Encoding відсутній, що правильно. WebP вже стиснутий; gzipping даремно споживає CPU без значного виграшу.
Рішення: Стискайте текст; не витрачайте ресурси на вже стиснуті зображення.
Завдання 15: Підтвердити рівень логування і видимість помилок (не летіть в темряві)
cr0x@server:~$ tail -n 20 /var/log/nginx/error.log
2025/12/29 10:27:07 [error] 1402#1402: *91 open() "/var/www/landing/assets/font.woff2" failed (2: No such file or directory), client: 127.0.0.1, server: _, request: "GET /assets/font.woff2 HTTP/1.1", host: "127.0.0.1"
Що це означає: Явні докази відсутнього файлу і шляху, де Nginx шукав його.
Рішення: Виправте шлях файлу і повторно деплойте. Додайте перевірку деплою, яка падає, якщо вказані ресурси відсутні.
План швидкої діагностики
Якщо лендінг повільний або зламаний, вам не потрібна брейнштормінг‑сесія. Потрібна послідовність, що швидко знаходить вузьке місце. Цей план упорядковано, щоб виключити цілі класи проблем швидко.
Перше: підтвердіть, що означає «повільно» і де саме
- Глобально чи локально? Тестуйте з сервера (curl до localhost) і з клієнтської мережі.
- Перший байт чи рендер? Якщо TTFB високий — дивіться на origin/proxy. Якщо TTFB нормальний, але сторінка «здається» повільною — дивіться payload і рендер (зображення, шрифти).
- Постійно чи зі спайками? Спайки означають конкуренцію ресурсів, лімітинг або хитання кешу.
Друге: відкиньте помилки кешування і маршрутизації
- Перевірте 404 в access/error логах. Зламані ресурси виглядають як «повільні» через повторні спроби і механізми відновлення.
- Перевірте
Cache-Controlі чи CDN повертає HIT. - Переконайтесь, що ви віддаєте правильний білд (немає змішаних версій по хостах).
Третє: шукайте класичні винуватці продуктивності
- Зображення: найбільший ресурс домінує. Зменшіть, конвертуйте і lazy‑load нижче фолду, якщо треба.
- Шрифти: пізнє завантаження шрифтів може блокувати рендер або викликати зсуви. Віддавайте перевагу системним шрифтам або правильно субсетним WOFF2.
- Забагато запитів: кожний запит коштує латентністю. Інлайньте невеликий критичний CSS, але не інлайньте все, щоб не роздути HTML.
Четверте: перевірте, чи ОС і диск не є прихованим вузьким місцем
- Якщо Nginx довго віддає локальні файли — перевірте затримку диска, ліміти файлів і завантаження CPU.
- Якщо TLS‑ручні налаштування повільні — перевірте ланцюжок сертифікатів, CPU і чи включено HTTP/2.
Операційна позиція: ставтесь до лендінгу як до міні‑сервісу. Дайте йому бюджети, логи і план відкату. Це дешевше, ніж пояснювати інциденти керівництву.
Поширені помилки: симптом → корінь → виправлення
Більшість збоїв лендінгів не містять таємниць. Це повторювані шаблони з конкретними симптомами. Ось ті, що я бачу повторно, коли команди релізять «прості статичні сторінки», а потім випадково ускладнюють їх.
| Симптом | Корінь | Виправлення (конкретно) |
|---|---|---|
| Сторінка «оновилася», але деякі користувачі бачать старі стилі | CSS довго кешується, але ім’я файлу не хешоване | Використовуйте хешовані імена файлів для ресурсів і Cache-Control: immutable. Або скоротіть час кешування, якщо не можете хешувати. |
| Макет стрибає після завантаження (CLS) | Зображення без width/height; пізнє завантаження шрифтів; інжектовані банери | Встановіть розміри зображень; резервуйте місце для банерів; віддавайте перевагу системним шрифтам або preload/subset WOFF2. |
| Повільне перше завантаження на мобільних | Занадто велика медіа в хедері; багато ваг шрифтів; нестиснутий HTML/CSS | Стискайте текст; зменшіть варіанти шрифтів; конвертуйте зображення в WebP/AVIF; обмежте розмір hero. |
| CDN ніколи не кешує (завжди MISS) | Куки змінюють ключ кешу; заголовки перешкоджають кешуванню; HTML помічено як private | Видаліть куки для статичних шляхів; встановіть явний Cache‑Control; підтвердіть заголовки на краю. |
| Анкерні посилання ламаються після перепису | IDs виробляються з заголовків і перевиробляються; id перейменовуються необачно | Тримайте стабільні ID; додайте редиректи, якщо треба змінити шляхи; вважайте анкери як публічне API. |
| SEO заголовки/описи виглядають некоректно у прев’ю | Title у <title> відрізняється від H1; meta description відсутній або занадто довгий |
Вирівняйте H1 з наміром; тримайте description 140–160 символів і стабільним між релізами. |
| Користувачі скаржаться на «порожній» контент коротко | Завантаження шрифтів блокує текст (FOIT), агресивні font‑display за замовчуванням | Використовуйте font-display: swap; preload лише критичні шрифти; подумайте про відмову від кастомних шрифтів. |
| Переривчасті 404 після деплою | Неатомарний деплой: HTML посилається на нові ресурси, яких ще нема на всіх нодах | Деплойте ресурси першими, потім HTML; або використовуйте атомарні релізні директорії і підмінку симлінку. |
| Сканер безпеки вказує «mixed content» | Жорстко зашиті http‑посилання на ресурси або сторонні включення | Використовуйте https скрізь; хостьте критичні ресурси; подумайте про CSP для контролю. |
Три міні‑історії з практики
Ці історії анонімізовані, правдоподібні й болісно знайомі. Кожна має урок, який можна застосувати до вашого чистого HTML/CSS лендінгу до того, як Pager це зробить за вас.
Міні‑історія 1: Інцидент через хибне припущення
Середня SaaS‑компанія випустила новий лендінг для запуску продукту. Він був «статичний», за CDN, і всі вважали, що це означає майже незламність. Команда зробила звичне: хедер, сітку можливостей і тарифну таблицю. Вони також додали кастомний шрифт з стороннього хосту через «брендінг».
Вранці трафік прийшов. Сторінка повільно завантажувалась у частини користувачів, а в частини — відображення шрифтів було зламане і макет стрибав. Воронка конверсій виглядала так, ніби хтось вимкнув живлення посеред шляху. Маркетинг звинуватив CDN. Інженери — «мобільні девайси». Підтримка звинуватила всіх.
Хибне припущення було тонким: вони думали, що CDN стабільно кешує HTML. Але origin ставив cookie для A/B тестування на кореневому шляху. CDN враховував цей cookie і варіював ключ кешу, фактично вимкнувши кешування HTML. Тепер кожний запит йшов до origin, який мусив перший раз завантажити віддалений шрифт, щоб прогріти з’єднання.
Зі зростанням навантаження латентність origin підскочила. CDN перестав бути акселератором і став делікатним пересилочником. Першою очевидною метрикою став підйом TTFB. Далі — логи з тайм‑аутами при отриманні шрифтів з зовнішнього хосту, бо сторонні залежності не масштабуються під ваш календар запуску.
Виправлення було нудним: перестати ставити cookie на статичних шляхах і хостити шрифт локально. Коли HTML знову став кешованим, а третій‑парті шрифт видалено як вузьке місце, TTFB стабілізувався і макет перестав стрибати. Сторінка не стала «фешенебельною». Вона стала надійною. Саме це бізнес і потребував.
Міні‑історія 2: Оптимізація, що відкотилася назад
Інша організація, більша і «процесно зріла», вирішила оптимізувати лендінг, інлайннувши весь CSS всередину HTML. Аргумент здавався розумним: зменшити запити, пришвидшити перший рендер. Хтось заміряв невелике покращення локально і оголосив перемогу. Вони випустили зміни в прод.
Два тижні по тому дизайнер змінив стилі кнопок. Проста зміна перетворилася на інцидент релізу: кеші поводилися непередбачувано, і користувачі бачили мікс старого і нового стилів залежно від вузла краю. Через інлайн CSS не можна було кешувати окремо з довгим TTL. Кожна зміна HTML інвалідовувала все. Хіт‑рейт CDN танув щоразу, як хтось правив кому.
Гірше, HTML‑відповіді роздулися. TTFB лишався ок, але час завантаження на повільних мережах виріс, бо кожний запит ніс повний CSS‑пейлоуд. «Оптимізація» зробила сторінку чутливою до змін контенту. Як тільки маркетинг почав експерименти, продуктивність стала непередбачуваною.
Вони врешті прийшли до розумного поділу: невеликий критичний CSS інлайн (тільки те, що потрібно для above‑the‑fold), плюс зовнішній, хешований CSS для всього решта. Тепер CDN міг агресивно кешувати ресурси, а HTML залишався меншим і короткоживучим. Сторінка стала швидшою і простішою у змінах без кешової рулетки.
Урок: не всі зменшення кількості запитів — перемоги. Кешованість — це фіча продуктивності. Ставтесь до CDN як до союзника, а не як до тупого каналу.
Міні‑історія 3: Нудна, але правильна практика, що врятувала вечір
Фінтех‑компанія підтримувала набір статичних сторінок: маркетинг, статус і огляд продукту у стилі docs. Вони деплоїли через атомарну схему релізних директорій: завантажити білд у версійну директорію, перевірити локально, потім переключити симлінк, який сервить Nginx.
Однієї п’ятниці оновлення контенту включало перейменовану директорію ресурсів. HTML посилався на /assets/app.9c0a...css, але скрипт деплою випадково вивантажив ресурси в /static/ для цього релізу. Якби компанія робила неатомарні in‑place оновлення, сторінка б сервила зламані посилання поки файли з’являлися й зникали під час деплою.
Натомість атомарний підхід не дозволив частково стану стати живим. Крок перевірки — curl до localhost і grep на 404 в access‑логах — провалився до того, як симлінк було переключено. Реліз ніколи не пішов у прод. Жодного інциденту. Жодного нічного реворту. Просто інженер підправив скрипт і пішов додому.
Це той вид «нудної коректності», що рідко святкують, але часто рятує ваш уікенд. Тримайтеся нудного. Нудне масштабується.
Чеклісти / покроковий план
Це план, який я віддав би команді, що хоче лендінг у стилі документації на чистому HTML/CSS і хоче, щоб він залишався здоровим після релізу. Дотримуйтесь його в порядку. Не «оптимізуйте» доти, поки не матимете даних.
Крок 1: Структура контенту до стилізації
- Напишіть H1 як обіцянку, яку ви дійсно можете виконати.
- Зробіть 1–2 абзаци лід‑тексту, що називають реальну проблему.
- Створіть TOC зі стабільними анкерами.
- Пишіть можливості як відповіді на заперечення, а не як прикметники.
- Пишіть тарифи як витяг із контракту: включення, виключення, ліміти.
- Пишіть FAQ із реальних тікетів і дзвінків продажів.
Крок 2: CSS, що витримує зміни
- Використовуйте контейнер з max‑width і читабельну довжину рядка.
- Використовуйте
clamp()для типографіки, щоб уникнути супу брейкпоінтів. - Віддавайте перевагу grid/flex з простими брейкпоінтами.
- Уникайте глобальних ресетів, що дивують елементи форм і інструменти доступності.
- Тримайте імена класів описовими; уникайте хитрих вкладень, які майбутній ви не зможе дебажити.
Крок 3: Політика ресурсів (де живе продуктивність)
- Вирішіть: спочатку системні шрифти; кастомні — лише з обґрунтуванням.
- Встановіть бюджет зображень для секції сторінки; контролюйте під час рев’ю.
- Використовуйте WebP/AVIF для великих зображень; SVG — для логотипів/ілюстрацій, де це корисно.
- Хешуйте імена файлів для кешованих ресурсів.
Крок 4: Деплой, що запобігає частковому стану
Деплойте статичні сторінки як бінарі: атомарно і з перевіркою. Один чистий патерн — директорії релізів + підміна симлінку.
cr0x@server:~$ sudo mkdir -p /var/www/landing/releases/2025-12-29_1015/assets
cr0x@server:~$ sudo rsync -a ./site/ /var/www/landing/releases/2025-12-29_1015/
cr0x@server:~$ sudo ln -sfn /var/www/landing/releases/2025-12-29_1015 /var/www/landing/current
cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
cr0x@server:~$ sudo systemctl reload nginx
Що означає вивід: Конфіг валідний; перезавантаження безпечне. Підміна симлінку атомарна, тому користувачі ніколи не бачать напівдеплоюваного стану.
Рішення: Якщо nginx -t падає — не перезавантажуйте. Виправте конфіг, потім протестуйте знову. Якщо не можете пояснити режими відмов вашого деплою — ви деплоїте надії.
Крок 5: Ворота верифікації (просто, але суворо)
- Запустіть
curl -Iі перевірте заголовки кешування. - Завантажте HTML і grep на очікувані посилання на ресурси.
- Проскануйте логи на 404 одразу після деплою.
- Перевірте термін дії TLS, якщо змінювали домен або сертифікати.
Крок 6: Операційна відповідальність
Призначте відповідального за бюджет продуктивності сторінки і процес деплою. «Маркетинг володіє» — рецепт для 12 трекерів і автохедеру з автозапуском. «Інженери володіють» — як правило, сторінка ніколи не релізиться. Правильна відповідь — спільна: маркетинг відповідає за контент, інженери — за обмеження доставки.
Наступні кроки
Якщо ви хочете лендінг у стилі документації, який працює в проді, зробіть три речі цього тижня:
- Заморозьте структуру: семантичні секції, стабільні анкери і FAQ, що відповідає на реальні питання.
- Встановіть бюджети: розміри зображень, кількість шрифтів і правила кешування для HTML vs ресурсів.
- Зробіть деплои атомарними: директорії релізів і підміна симлінків, плюс постдеплой‑перевірка на 404 і заголовки.
Чистий HTML/CSS — не ностальгія. Це рішення зменшити ризик. Ви завжди можете додати складність пізніше. Видалити її — боляче.