Що таке HTML і CSS: з чого складається будь-який сайт

HTML описує зміст і структуру вебсторінки, CSS задає її вигляд, адаптивність і частину візуальної поведінки. Разом вони не «роблять сайт повністю»: браузер перетворює HTML і CSS на внутрішні дерева документа та стилів, JavaScript додає інтерактивність, а швидкість сторінки часто більше залежить від зображень, скриптів, шрифтів, сервера й кешування.

Що таке HTML і CSS: з чого складається будь-який сайт

Будь-який сайт складається щонайменше з документа, правил відображення, ресурсів і середовища виконання в браузері. HTML задає, що є на сторінці: заголовок, меню, форма, кнопка, стаття, зображення, відео. CSS задає, як це виглядає: розмір, колір, сітка, відступи, поведінка на різних екранах, анімації та стани елементів.

Спрощена схема така:

• HTML формує документ і семантичну структуру: браузер розуміє, де головний контент, навігація, форма, кнопка або підвал.
• CSS описує правила відображення: від базових кольорів до складних сіток, адаптивності й реакції на налаштування користувача.
• Браузер будує DOM із HTML, CSSOM із CSS, поєднує їх і рендерить сторінку.
• JavaScript додає поведінку: відкриття меню, валідацію, динамічні дані, взаємодію з API. Але він не замінює HTML і CSS.
• Інші ресурси — зображення, шрифти, відео, аналітика, рекламні скрипти — часто визначають реальну вагу й швидкість сайту.

Фраза «HTML — це каркас, CSS — це дизайн» корисна для першого знайомства, але неповна. HTML також впливає на доступність, SEO, форми, мову документа й завантаження ресурсів. CSS — це не лише «краса», а й layout, каскад, адаптивність, стабільність інтерфейсу та частина продуктивності.

Якщо тема сайтів для вас нова, корисно паралельно розібрати, чим Frontend відрізняється від Backend: HTML і CSS належать саме до фронтенд-частини, яку бачить користувач у браузері.

Що саме робить HTML на сторінці

HTML є мовою розмітки документа, а не мовою програмування для обчислень чи бізнес-логіки. Актуальна модель розвитку HTML — Living Standard, а не лінійка «HTML5, HTML6 і далі». Тому формулювання «HTML5 — остання версія HTML» краще не використовувати. Коректніше казати, що HTML розвивається як живий стандарт, а браузери поступово реалізують його можливості.

Мінімальна HTML-сторінка може виглядати так:

<!doctype html>
<html lang="uk">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Приклад сторінки</title>
    <link rel="stylesheet" href="/styles.css">
  </head>
  <body>
    <header>...</header>
    <main>
      <article>...</article>
    </main>
    <footer>...</footer>
  </body>
</html>

У цьому фрагменті немає нічого зайвого:

• <!doctype html> переводить браузер у стандартний режим обробки документа.
• lang="uk" повідомляє мову сторінки скринридерам, перекладачам і мовним інструментам.
• charset="utf-8" потрібен для коректного відображення українських літер.
• viewport дає базу для мобільної адаптивності.
• <main>, <article>, <header>, <footer> описують роль частин документа.
• <link rel="stylesheet"> підключає зовнішній CSS-файл.

HTML впливає не тільки на те, як код виглядає для розробника. Наприклад, <button> і <div>, стилізований як кнопка, не рівнозначні. Кнопка має вбудовану семантику, очікувану поведінку з клавіатури та зрозуміла допоміжним технологіям. <div> — універсальний контейнер без такої поведінки, і її доведеться відтворювати вручну.

Те саме стосується форм. Поле введення, підпис, повідомлення про помилку й кнопка відправлення мають бути пов’язані семантично, а не лише намальовані як блоки. Інакше сторінка може виглядати правильно, але бути незручною або недоступною для частини користувачів.

Що робить CSS у сучасному вебі

CSS є набором модулів для опису відображення документа, а не одним монолітним стандартом. Окремо розвиваються специфікації Selectors, Cascade, Flexbox, Grid, Media Queries, Fonts, Color, Transforms та інші. Статус функції у специфікації не означає автоматично, що вона однаково працює в усіх браузерах, тому практичну сумісність потрібно перевіряти окремо.

CSS вирішує кілька різних задач:

• Каскад і специфічність. Браузер визначає, яке правило переможе, якщо кілька селекторів описують той самий елемент.
• Блочна модель. Кожен елемент має content, padding, border і margin; помилки в цих шарах часто ламають макет.
• Потік документа. Елементи розміщуються за певними правилами навіть без Flexbox, Grid чи позиціонування.
• Flexbox. Зручний для одного основного напрямку: меню, груп кнопок, вирівнювання елементів у ряд або колонку.
• Grid. Підходить для двовимірних сіток: сторінок, карток, складних макетів із рядками та колонками.
• Media Queries. Адаптують сторінку до viewport, типу пристрою або налаштувань користувача.
• Container Queries. Дають компоненту реагувати на розмір контейнера, а не всього екрана.
• Custom Properties. Змінні на кшталт --brand-color допомагають керувати темами й повторюваними значеннями.
• Transitions та animations. Додають візуальні зміни без обов’язкового JavaScript.
• Accessibility preferences. Наприклад, prefers-reduced-motion дозволяє зменшити рух для користувачів, які цього потребують.

Нові можливості CSS зменшують потребу в JavaScript для частини UI-задач. Наприклад, container queries корисні для компонентів дизайн-системи, :has() дозволяє стилізувати елемент залежно від вмісту, а CSS Anchor Positioning допомагає декларативно прив’язувати один елемент до іншого. Рекомендація: використовувати такі можливості для спрощення інтерфейсу, але перед запуском перевіряти підтримку в цільових браузерах.

Власний розрахунок: де насправді шукати вагу сторінки

Дані станом на липень 2025 року показують: HTML і CSS зазвичай не є головною частиною ваги сторінки. За Page Weight у Web Almanac 2025 медіанна мобільна домашня сторінка передавала 22 КБ HTML, 77 КБ CSS, 122 КБ шрифтів, 632 КБ JavaScript, 911 КБ зображень і 2 559 КБ загалом; десктопна — 22 КБ HTML, 82 КБ CSS, 139 КБ шрифтів, 697 КБ JavaScript, 1 058 КБ зображень і 2 862 КБ загалом. Усі значення — transfer size, тобто обсяг переданих ресурсів. Вихідні числа наведені в Page Weight Web Almanac 2025.

Сценарій оптимізації	Вихідний обсяг	Якщо зменшити на 20%	Економія від усієї мобільної сторінки	Практичний висновок
CSS	77 КБ	15,4 КБ	0,60%	Корисно чистити, але це рідко змінює всю картину ваги
JavaScript	632 КБ	126,4 КБ	4,94%	Дає приблизно у 8,2 раза більшу економію, ніж CSS при тому самому відсотку скорочення
Зображення	911 КБ	182,2 КБ	7,12%	Найбільший кандидат на швидку економію transfer size

Як рахували. Взято медіанні transfer size для мобільної домашньої сторінки з Web Almanac 2025: CSS — 77 КБ, JavaScript — 632 КБ, зображення — 911 КБ, загальна сторінка — 2 559 КБ. Формула: економія ресурсу = обсяг ресурсу × 20%; частка від сторінки = економія / 2 559 × 100. Припущення: порівнюється однакове відносне скорочення на 20% для різних типів ресурсів; не враховано кеш, порядок завантаження, стиснення після розпакування, вплив на LCP, INP і CLS. Межа застосування: це орієнтир для пріоритизації, а не доказ, що кожен конкретний сайт має таку саму структуру.

Що випливає для рішення: якщо сторінка повільна, починайте не з гасла «стиснути CSS», а з вимірювання ваги й впливу зображень, JavaScript, шрифтів і CSS окремо. Для типової медіанної сторінки скорочення зображень або JavaScript на той самий відсоток дає значно більшу економію transfer size, ніж скорочення CSS.

Є ще один важливий перерахунок. HTML і CSS разом на медіанній мобільній сторінці важать 99 КБ: 22 КБ HTML + 77 КБ CSS. Їхня частка — 99 / 2 559 × 100 ≈ 3,9%. JavaScript важчий за CSS приблизно у 632 / 77 ≈ 8,2 раза, а зображення важчі за HTML приблизно у 911 / 22 ≈ 41,4 раза. Це не скасовує оптимізацію CSS, але ставить її на правильне місце в черзі робіт.

Як браузер перетворює HTML і CSS на видиму сторінку

Браузер показує сторінку не прямо з HTML-файлу, а через послідовність побудови структури, стилів, макета й пікселів. Спершу він отримує HTML, будує DOM, знаходить підключені ресурси, завантажує CSS, будує CSSOM, поєднує структуру зі стилями, рахує layout і малює результат.

Цей ланцюжок пояснює, чому помилки в HTML і CSS можуть проявлятися не там, де їх очікують. Некоректна структура заголовків погіршує навігацію для скринридерів і розуміння контенту. Відсутні розміри зображень можуть спричинити зміщення макета. Великий CSS-файл може затримати перше відображення, бо CSS часто блокує рендеринг. Невдалий JavaScript може заблокувати головний потік і погіршити взаємодію.

Дані станом на травень 2025 року: Google рекомендує оцінювати Core Web Vitals на 75-му перцентилі реальних переглядів. LCP вважається добрим до 2 500 мс, INP — до 200 мс, CLS — до 0,1; поганими є LCP понад 4 000 мс, INP понад 500 мс, CLS понад 0,25. Пороги описані в методиці Core Web Vitals від Google.

Метрика	Добрий результат	Що може зламати HTML/CSS	Що перевірити першим
LCP	≤ 2 500 мс	Затримка рендерингу через CSS, важке головне зображення, повільний сервер	Розмір hero-зображення, критичний CSS, час відповіді сервера
INP	≤ 200 мс	CSS рідко є головною причиною; частіше взаємодію блокує JavaScript	Довгі JS-задачі, обробники подій, зайві бібліотеки
CLS	≤ 0,1	Немає розмірів зображень, пізно підвантажуються шрифти, нестабільні блоки	width/height, резерв місця, font loading

Lighthouse і CrUX не треба сприймати як одне й те саме. Lighthouse — лабораторний тест у контрольованому сценарії. CrUX — агреговані дані реальних користувачів Chrome. INP особливо складно повноцінно оцінити в простому лабораторному завантаженні, бо ця метрика пов’язана з реальними взаємодіями.

Для повної картини знадобляться також знання про мережу й інфраструктуру: що таке кеш, CDN, HTTPS, DNS і хостинг впливають на перше завантаження сторінки ще до обробки CSS.

Зведена структура: що вибрати для макета, адаптивності й стилів

Вибір між HTML-елементами, Flexbox, Grid, media queries, container queries і способом підключення CSS залежить від задачі, а не від моди чи універсального правила.

Задача	Краще рішення	Коли підходить	Коли змінити підхід	Головний ризик
Кнопки, форми, навігація, основні області сторінки	Семантичний HTML	Потрібні доступність, клавіатура, зрозуміла структура, менше ARIA	Для нейтральної обгортки без власної ролі можна використати div	Імітація кнопок через div ламає очікувану поведінку
Меню, ряд кнопок, вирівнювання елементів	Flexbox	Є один основний напрямок: ряд або колонка	Якщо треба незалежно керувати і рядками, і колонками — беріть Grid	Складні двовимірні макети обростають зайвими обгортками
Сітка карток, сторінка з колонками, складний layout	Grid	Потрібна двовимірна структура	Для простого горизонтального меню Grid може бути зайвим	Можна ускладнити прості компоненти
Адаптація всієї сторінки до екрана	Media Queries	Змінюється загальна структура залежно від viewport	Якщо один компонент живе в різних контейнерах — краще container queries	Забагато брейкпоінтів маскують слабкий макет
Компонент у sidebar, main-контенті або модальному вікні	Container Queries	Компонент має реагувати на власний контейнер	Для старших цільових браузерів перевіряйте підтримку	Потрібна дисципліна в архітектурі компонентів
Критичні стилі першого екрана	Малий вбудований CSS	Стилів небагато, важливо швидко показати перший екран	Спільні стилі багатьох сторінок краще винести в зовнішній файл	Вбудований CSS не кешується окремо між сторінками
Спільний дизайн сайту	Зовнішній CSS-файл	Є багато сторінок, повторювані компоненти, кешування	Для дуже малого критичного фрагмента можна інлайнити	Зовнішній CSS може блокувати рендеринг

Цю матрицю варто читати як дерево рішення. Якщо потрібно зробити кнопку — починайте з <button>, а не з <div>. Якщо макет іде в одному напрямку — Flexbox. Якщо потрібні рядки й колонки — Grid. Якщо адаптація залежить від екрана — media queries. Якщо компонент має бути незалежним від місця вставки — container queries.

Якщо сайт робиться на CMS, частину HTML і CSS генерує тема або конструктор. Це не скасовує принципи: навіть у WordPress якість теми, семантика шаблонів, зайві CSS-файли й важкі шрифти впливають на результат. Детальніше про типові сценарії можна прочитати в матеріалі що таке WordPress.

Чому доступність починається з HTML і CSS

Доступність сторінки залежить від семантики HTML, видимих станів CSS, контрасту, клавіатурної навігації та коректної мови документа. Для державних цифрових сервісів в Україні доступність також пов’язана з нормативними вимогами, але навіть для комерційного сайту це практичне питання: користувач має мати змогу прочитати сторінку, пройти форму й виконати дію незалежно від пристрою та способу взаємодії.

Для HTML це означає:

• використовуйте одну логічну ієрархію заголовків, а не заголовки лише заради розміру шрифту;
• додавайте змістовний альтернативний текст до інформативних зображень;
• не замінюйте інтерактивні елементи нейтральними контейнерами без ролей і поведінки;
• пов’язуйте підписи з полями форм;
• зазначайте мову документа через lang.

Для CSS це означає:

• забезпечуйте достатній контраст тексту й фону;
• не прибирайте focus без заміни на видимий стан;
• не передавайте критичну інформацію лише кольором;
• підтримуйте prefers-reduced-motion для інтерфейсів із рухом;
• резервуйте місце під зображення й динамічні блоки, щоб не створювати зміщення макета.

Доступність не конфліктує з дизайном. Вона конфліктує з підходом, коли сторінку оцінюють тільки за скріншотом. Якщо користувач не може пройти форму з клавіатури або скринридер не розуміє структуру, «гарний» CSS не виправляє проблему.

Як HTML і CSS пов’язані зі швидкістю сайту

HTML і CSS впливають на швидкість, але типова причина повільного сайту часто лежить у зображеннях, JavaScript, шрифтах або серверній частині. За Web Almanac 2025 медіанний мобільний CSS становив 77 КБ, тоді як шрифти — 122 КБ, JavaScript — 632 КБ, а зображення — 911 КБ.

Дані станом на серпень 2026 року з поточного звіту HTTP Archive додають ще один кут: медіанне число зовнішніх CSS-файлів становило 8 для desktop і 8 для mobile, а 90-й перцентиль — 37 CSS-запитів на desktop і 36 на mobile. Ці значення не означають, що потрібно прагнути саме до 8 CSS-файлів. Методика рахує зовнішні таблиці стилів за розширенням .css або CSS MIME-типом; вбудований CSS і стилі, згенеровані JavaScript, можуть не потрапити до цього показника. Поточні показники наведені у звіті Page Weight HTTP Archive.

Шрифти теж не варто ігнорувати. У тому самому звіті медіанна вага шрифтів становила 154,1 КБ на mobile і 168,4 КБ на desktop, а медіанна кількість шрифтових запитів — 4 на обох типах пристроїв. Це пояснює, чому підключення кількох накреслень, мовних підмножин і стороннього шрифтового сервісу іноді коштує дорожче, ніж уся таблиця стилів.

Порядок дій для оптимізації:

1. Виміряйте transfer size за типами ресурсів: HTML, CSS, JS, fonts, images.
2. Перевірте LCP, INP і CLS окремо, не зводьте все до «сторінка важка».
3. Для зображень перевірте формат, розміри, lazy loading і резерв місця.
4. Для JavaScript перевірте зайві бібліотеки, довгі задачі й код, який можна замінити CSS або HTML-можливостями.
5. Для CSS перевірте невикористані правила, критичні стилі, порядок підключення й дублікати.
6. Для шрифтів залиште потрібні накреслення, підмножини й стратегію завантаження.

Якщо сайт використовує CMS або конструктор, частина проблем може бути в темі, плагінах і зовнішніх віджетах. Тут корисно розуміти, що таке CMS і як вона керує шаблонами, стилями та контентом.

Поширені міфи про HTML і CSS

Міф: HTML — це програмування, а CSS — програмування дизайну

HTML — мова розмітки, CSS — мова стилів. Вони описують структуру та представлення документа. Обчислення, складна логіка, робота з API й обробка станів зазвичай належать JavaScript або серверному коду. Це не робить HTML і CSS другорядними: помилка в семантиці або каскаді може зламати доступність, SEO й інтерфейс.

Міф: HTML5 — поточна остання версія

Актуальна модель — HTML Living Standard. Це важливо для навчання й документації: замість запам’ятовування «останньої версії» треба дивитися, які можливості підтримуються браузерами та як їх правильно застосовувати.

Міф: сайт повільний через CSS

Без вимірювання це лише припущення. У медіанній мобільній домашній сторінці Web Almanac 2025 CSS становив 77 КБ, JavaScript — 632 КБ, зображення — 911 КБ. Якщо скоротити CSS на 20%, економія становитиме 15,4 КБ; таке саме відносне скорочення зображень дасть 182,2 КБ. Висновок: CSS треба оптимізувати, але не слід починати й закінчувати аудит тільки ним.

Міф: якщо сторінка виглядає як у макеті, вона доступна

Візуальна відповідність не доводить доступність. Потрібно перевірити клавіатуру, скринридерну структуру, підписи форм, контраст, focus state, альтернативні тексти й залежність від кольору. Саме тут HTML і CSS працюють разом: перший дає семантику, другий — видиме й стабільне представлення.

Міф: CSS-фреймворк обов’язковий для будь-якого сайту

Фреймворк може прискорити розробку, особливо коли потрібні готові компоненти та єдина дизайн-система. Але для малого сайту він може додати зайві стилі, класи й залежності. Власний CSS іноді легший, прозоріший і достатній. Якщо ж проєкт великий, фреймворк або дизайн-система можуть зменшити хаос, але лише за умови дисципліни в компонентах.

Міф: більше брейкпоінтів означає кращу адаптивність

Десятки точкових media queries часто приховують слабку структуру. Flexbox, Grid, відносні одиниці, clamp(), minmax() і container queries можуть дати плавнішу адаптацію без надмірної кількості умов.

Що вивчати першими, якщо ви починаєте з HTML і CSS

Починати варто не з фреймворку, а з документа, семантики, каскаду, блочної моделі й базового layout. Такий порядок швидше дає розуміння, чому сторінка працює або ламається.

1. HTML-документ. Doctype, html, head, body, мова, кодування, viewport, title.
2. Семантичні елементи. main, header, footer, nav, article, section, button, form.
3. Форми. Поля, підписи, стани помилок, доступне відправлення.
4. CSS-селектори й каскад. Як браузер обирає правило та чому «не працює стиль».
5. Блочна модель. Content, padding, border, margin, box-sizing.
6. Flexbox і Grid. Один напрямок проти двовимірної сітки.
7. Адаптивність. Media queries, відносні одиниці, зображення, viewport.
8. Доступність. Клавіатура, focus, контраст, alt, логічна структура.
9. Продуктивність. Вага ресурсів, критичний CSS, шрифти, зображення, вплив JS.
10. Інструменти браузера. Elements, Styles, Network, Performance, Lighthouse.

JavaScript варто додавати після того, як зрозуміло, що можна зробити нативним HTML і CSS. Інакше є ризик писати скрипти для задач, які вже вирішуються елементами details, dialog, CSS-станами, transitions або сучасними селекторами. Якщо хочете рухатися далі в розробку, корисно також зрозуміти, навіщо розробникам контроль версій: навіть прості HTML/CSS-проєкти швидко потребують історії змін.

Короткий висновок

HTML відповідає за зміст, структуру й семантику сторінки; CSS — за вигляд, layout, адаптивність і частину візуальної поведінки. Базова рекомендація: спочатку будуйте правильний документ, потім стабільний адаптивний layout, а оптимізацію починайте з вимірювання. Якщо сторінка повільна через важкі зображення, JavaScript або шрифти, скорочення лише CSS не дасть вирішального ефекту. Якщо ж CSS блокує перше відображення, містить багато невикористаних правил або створює зміщення макета, саме він стає пріоритетом для виправлення.