14 технік оптимізації швидкості сайту для завантаження до 2 секунд

Сайт, який завантажується за 2 секунди, конвертує відвідувачів краще за той, що вантажиться 4 секунди. Це не теорія. Дані Google показують, що одна секунда затримки на мобільному знижує конверсію на 20%. Дослідження Portent взагалі називає цифру 4.42% за кожну додаткову секунду.

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

У цьому гайді 14 конкретних технік, які допоможуть досягти завантаження до 2 секунд. До кожної додано практичні кроки, приклади коду де це доречно, і очікуваний бізнес-ефект. Чи ви створюєте новий сайт, чи оптимізуєте існуючий, ці техніки ми використовуємо у Vezert для покращення продуктивності в кожному проєкті.

Швидкість і конверсії пов'язані напряму, і дані тут однозначні:

• Amazon виявили, що кожні 100 мс затримки коштують їм 1% продажів.
• Walmart отримали 2% зростання конверсії за кожну секунду покращення часу завантаження.
• Дослідження Portent зафіксувало середнє зниження конверсії на 4.42% за кожну додаткову секунду завантаження в 20 галузях.

Швидкість також впливає на SEO напряму. Google використовує Core Web Vitals (LCP, CLS, INP) як сигнали ранжування. Повільний сайт втрачає не тільки відвідувачів, але й видимість у пошуку. SEO та розробка сайтів вже не окремі розмови.

Висновок простий: час завантаження сторінки та конверсія рухаються разом. Кожна техніка в цьому гайді оцінюється через цю призму, не просто технічна продуктивність, а що це дає бізнесу.

Перш ніж щось оптимізувати, потрібен базовий рівень. Ось інструменти, які дають найчіткішу картину:

Google PageSpeed Insights (pagespeed.web.dev) надає дані Core Web Vitals від реальних користувачів (field data) та лабораторні тести. Це найважливіший інструмент, бо показує, що Google насправді вимірює для ранжування.

Lighthouse (вбудований у Chrome DevTools, вкладка Audits) запускає детальні аудити продуктивності з конкретними рекомендаціями. Відкрийте DevTools, перейдіть у панель Lighthouse і запустіть тест продуктивності на мобільному.

WebPageTest (webpagetest.org) генерує waterfall-діаграми, які показують, де саме витрачається час під час завантаження сторінки. Корисно для діагностики конкретних вузьких місць.

GTmetrix (gtmetrix.com) поєднує дані Lighthouse із візуальною шкалою часу та історичним відстеженням.

Ключові метрики для відстеження

• LCP (Largest Contentful Paint): коли основний контент стає видимим. Ціль: менше 2.5 секунд.
• CLS (Cumulative Layout Shift): наскільки сторінка зміщується під час завантаження. Ціль: менше 0.1.
• INP (Interaction to Next Paint): як швидко сторінка реагує на кліки. Ціль: менше 200 мс.
• TTFB (Time to First Byte): як швидко відповідає сервер. Ціль: менше 800 мс.

Запускайте ці тести і на мобільному, і на десктопі. Мобільна версія це те, що Google переважно використовує для ранжування, і там найчастіше виявляються проблеми зі швидкістю.

Ось куди мають потрапити ваші цифри. Якщо будь-яка метрика потрапляє у колонку "Погано", це ваш пріоритет номер один.

Ці техніки розташовані приблизно за впливом. Починайте зверху і рухайтесь вниз. До кожної додано що робити, як це зробити, і що це означає для вашого прибутку.

Зображення зазвичай становлять найбільшу частку ваги сторінки. На середній веб-сторінці вони складають понад 40% загальних байтів за даними HTTP Archive.

Виправлення просте:

• Конвертуйте зображення у формат WebP або AVIF, які на 25-50% менші за JPEG/PNG при тій же якості.
• Використовуйте адаптивні зображення через srcset, щоб мобільні користувачі не завантажували файли розміру десктопу.
• Встановлюйте явні атрибути width та height для запобігання зміщень макету (покращує CLS).
• Стиснюйте агресивно. Більшість зображень може втратити 40-60% розміру файлу без видимої різниці.

<img
  src="/hero.webp"
  srcset="/hero-480.webp 480w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 800px) 100vw, 1200px"
  width="1200" height="630"
  alt="Скріншот продукту"
  loading="lazy"
/>

Бізнес-вплив: Оптимізація зображень зазвичай зменшує вагу сторінки на 30-50%, що напряму покращує LCP та загальний час завантаження. Для лендінгів, де hero-зображення є елементом LCP, це часто найбільший виграш.

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

Встановіть заголовки Cache-Control на статичні ресурси:

# Статичні ресурси (зображення, шрифти, JS, CSS)
Cache-Control: public, max-age=31536000, immutable

# HTML-сторінки
Cache-Control: public, max-age=0, must-revalidate

Прапорець immutable каже браузерам навіть не перевіряти оновлення для версійованих файлів. Для HTML використовуйте must-revalidate, щоб користувачі завжди отримували свіжий контент, поки ресурси залишаються в кеші.

Якщо ви використовуєте фреймворк на кшталт Next.js (який ми використовуємо у Vezert), статичні ресурси отримують імена файлів з хешем контенту за замовчуванням, що робить довгий термін кешування безпечним.

Бізнес-вплив: Кешування браузера може прискорити повторне завантаження сторінки на 80%. Для сайтів, де користувачі відвідують кілька сторінок за сеанс, як корпоративні сайти чи веб-портали, це накопичується у помітно плавніший досвід.

Мережа доставки контенту (CDN) кешує сайт на серверах по всьому світу, щоб користувачі отримували контент з найближчого розташування. Без CDN відвідувач у Токіо робить запит на сервер у Вірджинії для кожного ресурсу.

Популярні варіанти:

• Vercel Edge Network (вбудований у розгортання Next.js)
• Cloudflare (безкоштовний тариф покриває більшість сайтів)
• AWS CloudFront (для власної інфраструктури)

CDN зменшує затримку на 50-70% для користувачів, які далеко від сервера походження. Вона також розвантажує трафік від вашого хосту, що означає кращу продуктивність під навантаженням.

Для міжнародних сайтів з користувачами в кількох регіонах CDN не опціональна. Це єдиний спосіб стабільно досягати швидкості завантаження сайту до 2 секунд для глобальної аудиторії.

Бізнес-вплив: Розгортання CDN зазвичай скорочує TTFB на 100-300 мс для віддалених користувачів. Якщо ваш сайт обслуговує кілька країн, це часто різниця між оцінками "Добре" та "Потребує роботи" для TTFB.

Мініфікація видаляє пробіли, коментарі та непотрібні символи з файлів CSS та JavaScript. Це не змінює, що робить код, лише робить файли меншими.

Сучасні інструменти збірки роблять це автоматично:

• Next.js / Webpack / Vite: мініфікація увімкнена за замовчуванням у production-збірках.
• Окремий CSS: використовуйте cssnano або lightningcss.
• Окремий JS: terser або esbuild.

Якщо ви не використовуєте інструмент збірки, онлайн-інструменти на кшталт Minifier.org працюють для разових файлів.

Бізнес-вплив: Мініфікація зазвичай зменшує розмір файлів на 10-20%. Саме по собі це звучить скромно, але в поєднанні зі стисненням (техніка 8) ефект множиться. Кожен кілобайт має значення на мобільних з'єднаннях.

CSS та JavaScript, що блокують рендеринг, перешкоджають браузеру відмальовувати щось до завершення завантаження та виконання. Це одна з найпоширеніших причин високого показника LCP.

Виправлення:

• Вбудуйте критичний CSS напряму в <head>, щоб перший рендер не чекав зовнішньої таблиці стилів.
• Відкладіть некритичний CSS використовуючи media="print" onload="this.media='all'".
• Додайте async або defer до тегів скриптів, щоб JavaScript не блокував рендеринг.

<!-- Відкласти некритичний CSS -->
<link rel="stylesheet" href="/non-critical.css" media="print" onload="this.media='all'">

<!-- Відкласти JavaScript -->
<script src="/analytics.js" defer></script>

Lighthouse спеціально позначає ресурси, що блокують рендеринг. Відкрийте аудит, знайдіть можливість "Eliminate render-blocking resources" і працюйте через перелічені файли.

Бізнес-вплив: Видалення ресурсів, що блокують рендеринг, може покращити First Contentful Paint на 1-3 секунди, що напряму прискорює, як швидко користувачі бачать значущий контент. Це критично для якісних сайтів, яким потрібне сильне перше враження.

Ліниве завантаження відкладає зображення та відео нижче visible area до того моменту, поки користувач не прокрутить до них. Це означає, що браузер завантажує лише те, що видно одразу, значно скорочуючи початкову вагу сторінки.

Найпростіший підхід — нативний атрибут loading="lazy":

<img src="/team-photo.webp" loading="lazy" width="800" height="600" alt="Фото команди" />

НЕ використовуйте ліниве завантаження для hero-зображення чи будь-якого контенту вище visible area. Вони мають завантажуватись одразу (використовуйте loading="eager" або просто опустіть атрибут), бо вони зазвичай є елементом LCP.

Для більшого контролю використовуйте Intersection Observer API для запуску завантаження, коли елементи входять у viewport.

Бізнес-вплив: Ліниве завантаження зазвичай зменшує початкову вагу сторінки на 30-40%. Для контентно-важких сторінок на кшталт блогів чи сторінок портфоліо економія ще більша, бо більшість зображень знаходиться нижче visible area.

TTFB (Time to First Byte) вимірює, скільки часу серверу потрібно, щоб почати відповідати. Усе інше, рендеринг, зображення, скрипти, чекає на це. Якщо TTFB повільний, ніщо інше не може компенсувати.

Поширені причини та виправлення:

• Повільний хостинг: Дешевий shared-хостинг часто має TTFB понад 1 секунду. Перейдіть на керованого провайдера або edge-розгортання (Vercel, Netlify, Cloudflare Pages).
• Неоптимізовані запити до бази даних: Профілюйте повільні запити, додавайте індекси, кешуйте часті читання.
• Відсутність кешування на стороні сервера: Додайте Redis або Memcached для динамічного контенту. Для статичних сайтів використовуйте попередній рендеринг під час збірки.
• Відсутність CDN: Дивіться техніку 3.

За даними web.dev, цільовий TTFB — менше 800 мс. Менше 200 мс — те, що ви отримуєте зі статичним хостингом або edge-функціями.

Бізнес-вплив: TTFB впливає на кожне завантаження сторінки. Скорочення з 1.5 с до 300 мс дає вам понад секунду запасу для всього іншого, часто це різниця між завантаженням до 2 секунд чи ні.

Текстові файли (HTML, CSS, JavaScript, JSON, SVG) стискаються надзвичайно добре. Gzip зменшує їхній розмір на 60-80%. Brotli, новіша альтернатива, стискає на 15-20% краще за Gzip.

Більшість хостинг-провайдерів та CDN увімкнюють Gzip за замовчуванням. Brotli вимагає HTTPS і може потребувати явного налаштування на власних серверах.

Для перевірки: відкрийте Chrome DevTools, перейдіть у вкладку Network і перевірте заголовок Content-Encoding у ваших відповідях. Ви маєте побачити br (Brotli) або gzip.

Бізнес-вплив: Якщо стиснення не увімкнено, ви подаєте файли в 3-5 разів більші за необхідне. Це одне з найпростіших виправлень з найвищою віддачею, особливо для сайтів з великою кількістю JavaScript.

Кожен файл, який браузер має завантажити, кожна таблиця CSS, кожен скрипт, кожне зображення — це HTTP-запит. Більше запитів означає більше поїздок туди-назад, більше затримки та довший час до готовності сторінки.

Кроки для зменшення запитів:

• Об'єднуйте файли CSS де можливо (більшість бандлерів роблять це).
• Вбудовуйте критичний CSS напряму в HTML <head>, щоб усунути одну поїздку туди-назад.
• Використовуйте CSS-спрайти або inline SVG для малих іконок замість окремих файлів зображень.
• Видаліть невикористаний CSS та JavaScript. Інструменти на кшталт вкладки Coverage у Chrome DevTools показують, який код виконується, а який ні.

Бізнес-вплив: Зменшення з 80 HTTP-запитів до 40 може скоротити час завантаження на 500 мс-1 с на повільніших з'єднаннях. Це найбільш актуально для мобільних користувачів, які все ще становлять більшість веб-трафіку.

Власні шрифти — поширене джерело невидимого тексту (FOIT) чи зміщень макету (FOUT). Якщо файл шрифту завантажується 2 секунди, користувачі або нічого не бачать, або бачать спалах запасного шрифту.

Виправте це так:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0000-00FF;
}

• font-display: swap показує запасний текст одразу, потім замінює, коли шрифт завантажиться.
• Субсетуйте свої шрифти, щоб включати лише символи, які ви насправді використовуєте (unicode-range).
• Використовуйте змінні шрифти де можливо. Один файл замінює 4-6 варіантів ваги/стилю.
• Хостіть шрифти самостійно замість завантаження з Google Fonts, щоб уникнути додаткового DNS-запиту.

Бізнес-вплив: Оптимізація шрифтів запобігає невидимому тексту під час завантаження та зменшує CLS. Для брендових корпоративних сайтів це зберігає перше враження чистим замість глючного.

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

<!-- Попереднє завантаження hero-зображення (елемент LCP) -->
<link rel="preload" as="image" href="/hero.webp" type="image/webp">

<!-- Попереднє завантаження критичного шрифту -->
<link rel="preload" as="font" href="/fonts/inter-var.woff2" type="font/woff2" crossorigin>

<!-- Попереднє з'єднання зі сторонніми джерелами -->
<link rel="preconnect" href="https://fonts.googleapis.com">

Будьте вибірковими. Попереднє завантаження занадто багатьох ресурсів суперечить меті, бо все конкурує за пропускну здатність. Попередньо завантажуйте лише LCP-зображення, основний шрифт та критичні сторонні з'єднання.

Бізнес-вплив: Попереднє завантаження LCP-зображення саме по собі може покращити Largest Contentful Paint на 200-500 мс. У поєднанні з попереднім з'єднанням зі сторонніми джерелами це мало зусиль, висока віддача.

Постачання одного величезного JavaScript-бандлу означає, що кожен користувач завантажує код для сторінок, які він може ніколи не відвідати. Розбиття коду ділить цей бандл на менші частки, що завантажуються за потребою.

У фреймворках на кшталт Next.js та React:

// Динамічний імпорт — завантажується лише коли потрібно
const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <Skeleton />,
});

Tree-shaking видаляє невикористані експорти з вашого бандлу під час збірки. Сучасні бандлери (Webpack 5, Vite, Turbopack) роблять це автоматично для ES-модулів, але це ламається з синтаксисом CommonJS require().

Перевіряйте розмір бандлу інструментами на кшталт @next/bundle-analyzer або source-map-explorer, щоб знайти найбільших порушників.

Бізнес-вплив: Добре розбитий додаток може зменшити початкове JavaScript-навантаження на 40-60%. Менше JavaScript означає швидший час до інтерактивності, що напряму впливає на те, як швидко користувачі можуть взаємодіяти з сайтом.

Аналітика, чат-віджети, рекламні скрипти, соціальні вбудовування: сторонні скрипти часто є найважчими елементами на сторінці, і ви маєте найменший контроль над ними.

Кроки для керування ними:

• Проаудитуйте все. Відкрийте Chrome DevTools, перейдіть у вкладку Network, відфільтруйте за "third-party" і перевірте, скільки кожен скрипт коштує в розмірі та часі.
• Відкладайте некритичні скрипти. Аналітика та чат-віджети не мають завантажуватись до того, як сторінка стане придатною до використання.
• Використовуйте loading="lazy" для вбудувань (YouTube, карти, соціальні стрічки).
• Замінюйте важкі віджети легшими альтернативами. Чат-віджет на 300 КБ може мати альтернативу на 30 КБ.
• Встановіть бюджет скриптів. Якщо сторонній скрипт додає більше 50 мс до часу завантаження, запитайте себе, чи він виправдовує своє існування.

Бізнес-вплив: Ми бачили сайти, де сторонні скрипти складали 60%+ загального JavaScript. Прибирання цього може скоротити час завантаження на секунди та значно покращити INP (відгук на взаємодію).

Оптимізація швидкості — не разовий проєкт. Нові функції, оновлення контенту та оновлення залежностей можуть непомітно погіршити продуктивність, якщо ніхто не стежить.

Налаштуйте постійний моніторинг:

• Google Search Console відстежує Core Web Vitals від реальних користувачів з часом. Перевіряйте звіт "Core Web Vitals" щомісяця.
• Lighthouse CI (чи аналог) запускає тести продуктивності у вашому пайплайні розгортання, щоб регресії виявлялись до потрапляння до користувачів.
• Real User Monitoring (RUM) інструменти на кшталт Vercel Analytics або бібліотеки web-vitals захоплюють реальні дані поля від ваших відвідувачів.

Створіть бюджет продуктивності: визначте максимальні значення для ваги сторінки, розміру JavaScript та LCP, які запускатимуть сповіщення при перевищенні.

Бізнес-вплив: Команди, які моніторять продуктивність, виявляють регресії в 10 разів швидше за тих, хто проводить аудити щоквартально. Пост-запускова оптимізація працює лише якщо у вас є дані, щоб бачити, що змінилось і коли.

Використовуйте це як швидку перевірку так/ні для вашого сайту. Якщо вам бракує більше кількох пунктів, починайте з тих, що впливають на Core Web Vitals.

Сервер та інфраструктура

• TTFB менше 800 мс у всіх регіонах
• Мережа доставки контенту (CDN) обслуговує статичні ресурси
• Час відповіді сервера стабільний під піковим навантаженням
• Gzip або Brotli стиснення увімкнено для текстових файлів

Зображення та медіа

• Усі зображення у форматі WebP або AVIF
• Адаптивні зображення використовують srcset для різних розмірів екрану
• Зображення нижче visible area використовують loading="lazy"
• Усі зображення мають явні атрибути width та height

CSS та JavaScript

• CSS та JS мініфіковані в production
• Критичний CSS вбудований в <head>
• JavaScript-бандли розбиті за маршрутами
• Невикористаний CSS та JS видалено (перевірте вкладкою Coverage)
• Скрипти, що блокують рендеринг, використовують async або defer

Шрифти

• Веб-шрифти використовують font-display: swap
• Шрифти субсетовані до необхідних діапазонів символів
• Основний шрифт попередньо завантажений через <link rel="preload"

Моніторинг

• Core Web Vitals відстежуються в Google Search Console
• Тести продуктивності запускаються в CI/CD пайплайні
• Сторонні скрипти аудитуються щоквартально
• Бюджет ваги сторінки визначений та дотримується

Цей чекліст охоплює ту саму область, що й повний аудит сайту. Якщо ваш сайт проходить усі ці пункти, продуктивність вашого сайту в хорошій формі.

Оптимізація швидкості сайту — це не одне велике виправлення. Це 14 менших, які складаються. Зображення, кешування, CDN, стиснення, ресурси, що блокують рендеринг, шрифти, ліниве завантаження, відповідь сервера, розбиття коду та моніторинг, кожне віднімає час, і разом вони дають вам менше 2 секунд.

Почніть зі свого скору PageSpeed Insights. Виправте те, що він позначить першим. Працюйте через цей список від техніки 1 до 14, вимірюючи після кожної зміни. Вам не потрібно робити все одразу, але ви маєте це зробити.

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

Якщо потрібна допомога, Vezert вбудовує швидкість в кожен проєкт з самого початку. Ми застосовуємо ті самі техніки, перелічені тут, у нашому процесі розробки сайтів, і ви можете побачити результати в нашому портфоліо. Швидкість — не те, що ми виправляємо потім. Це те, як ми будуємо.