TTFB, кеш і стиснення: три кити, на яких тримається швидкість вашого хостингу

Уявіть: ви замовили піцу. Кур'єр приїхав за 8 хвилин - гаряча, хрустка, ідеальна. А тепер уявіть, що він їхав 45 хвилин. Та сама піца, той самий рецепт, але ви вже роздратовані, голодні й думаєте про конкурентів. Саме так працює хостинг. Ваш контент може бути геніальним, але якщо сервер віддає сторінку повільно - відвідувач пішов. Google зафіксував. Позиції впали. Гроші випарувались. Сьогодні розберемо три конкретні механізми, які визначають, наскільки швидко ваш хостинг доставляє «піцу» кожному відвідувачу.

TTFB: перший байт, який вирішує все

TTFB - Time To First Byte - це час від моменту, коли браузер відправив запит до сервера, до моменту, коли отримав перший байт відповіді. Звучить як дрібниця? Це як перше рукостискання на співбесіді. Воно формує враження ще до того, як ви відкрили рот.

Google вважає TTFB одним з ключових показників серверної продуктивності. Рекомендація - менше 800 мс. Ідеал - до 200 мс. Але реальність інша: дешеві тарифи віртуального хостингу часто видають 1200-2500 мс у пікові години. Це як кур'єр, який спершу п'є каву, потім шукає ключі від скутера, а вже потім їде.

Що впливає на TTFB:

• Якість серверного заліза - NVMe SSD проти звичайних HDD дають різницю в 3-5 разів
• Географія дата-центру - сервер у Франкфурті для українського трафіку працює швидше, ніж у Лос-Анджелесі
• Навантаження від сусідів - якщо 200 сайтів ділять один процесор, ваш TTFB стрибає як курс долара в листопаді
• Версія PHP та конфігурація - PHP 8.3 обробляє запити на 30-40% швидше за PHP 7.4

Перевірити TTFB просто: відкрийте Chrome DevTools (F12), перейдіть у вкладку Network, перезавантажте сторінку й подивіться на стовпець «Waiting (TTFB)» для головного документа. Якщо бачите цифру понад 600 мс - час розбиратись.

Серверний кеш: чому ваш сайт кожного разу готує суп з нуля

Ось парадокс: більшість сторінок вашого сайту змінюються раз на тиждень, а може й рідше. Але сервер щоразу генерує їх заново. Кожен відвідувач запускає ланцюжок: PHP обробляє код, робить 30-50 запитів до бази MySQL, збирає HTML, віддає браузеру. Це як варити борщ з нуля для кожного гостя, хоча в холодильнику стоїть каструля вчорашнього.

Серверний кеш зберігає готовий результат і віддає його наступним відвідувачам миттєво. Різниця - колосальна. Без кешу сторінка WordPress генерується за 800-2000 мс. З OPcache + Redis або Memcached - за 50-150 мс. Це не маркетинг, це фізика.

«Кешування - це найефективніший спосіб покращити продуктивність веб-додатку. У 90% випадків правильне кешування дає більший приріст швидкості, ніж перехід на потужніший сервер.» - Ілля Григорик, автор книги «High Performance Browser Networking», інженер Google

Які типи кешу мають бути на вашому хостингу:

1. OPcache - кешує скомпільований PHP-код. Якщо його вимкнено, кожен запит компілює скрипти заново. Увімкнення OPcache пришвидшує PHP-додатки на 25-70%
2. Object cache (Redis/Memcached) - зберігає результати запитів до бази даних у оперативній пам'яті. WordPress робить десятки SQL-запитів на сторінку - Redis скорочує це до мілісекунд
3. Page cache (Varnish, FastCGI Cache) - зберігає повністю готову HTML-сторінку. Сервер навіть не запускає PHP - просто віддає файл. Час відповіді падає до 10-30 мс
4. CDN-кеш - копії статичних файлів (картинки, CSS, JS) розподілені по серверах світу. Cloudflare, BunnyCDN чи Fastly забирають 60-80% навантаження з вашого хостингу

Важливий нюанс: не кожен хостинг дає доступ до Redis чи Memcached. На бюджетних тарифах часто доступний лише OPcache, і той з мінімальним обсягом пам'яті. Перед покупкою - перевіряйте.

Стиснення і оптимізація: як відправити слона поштою

Навіть якщо сервер згенерував сторінку за 50 мс, вона ще має дістатися до браузера. HTML-документ середнього інтернет-магазину важить 80-200 КБ. CSS - ще 150-400 КБ. JavaScript - від 300 КБ до 2 МБ. Картинки - окрема трагедія.

Gzip-стиснення зменшує обсяг текстових файлів (HTML, CSS, JS) на 60-80%. Тобто файл у 200 КБ перетворюється на 40-50 КБ. А Brotli - новіший алгоритм від Google - стискає ще на 15-25% краще за Gzip.

Як перевірити, чи працює стиснення на вашому хостингу? Зайдіть на сервіс gtmetrix.com або просто подивіться HTTP-заголовки відповіді. Шукайте рядок Content-Encoding: gzip або Content-Encoding: br. Якщо його немає - ваш сервер відправляє дані «як є». Це як відправляти книгу, розклавши кожну сторінку в окремий конверт.

Що можна оптимізувати на рівні сервера:

• Gzip/Brotli - вмикається в конфігурації Nginx або Apache за пару рядків
• HTTP/2 або HTTP/3 - мультиплексування запитів, менше затримок. HTTP/3 з QUIC працює ще швидше на нестабільних з'єднаннях
• Keep-Alive з'єднання - браузер не розриває TCP-з'єднання після кожного файлу, а використовує одне для серії запитів
• Мініфікація на льоту - деякі хостинги (наприклад, з LiteSpeed) вміють автоматично мініфікувати CSS та JS

Велика таблиця: як ці три фактори працюють разом

Теорія - добре. Але давайте подивимося на цифри. Ми змоделювали чотири типові конфігурації хостингу і виміряли продуктивність одного й того ж WordPress-сайту з 50 записами, 12 плагінами і темою Astra.

Бачите різницю? Той самий сайт. Той самий контент. Але четверта конфігурація завантажується в 9 разів швидше за першу. А різниця в ціні - може бути всього $5-10 на місяць. Це не питання бюджету, це питання знань.

Як перевірити продуктивність свого хостингу за 15 хвилин

Не потрібно бути DevOps-інженером. Вам знадобляться три безкоштовні інструменти і трохи уваги.

1. GTmetrix (gtmetrix.com) - введіть URL, оберіть сервер у Лондоні або Франкфурті, запустіть тест. Зверніть увагу на TTFB, Largest Contentful Paint і Total Page Size
2. Google PageSpeed Insights - покаже реальні дані від користувачів Chrome (CrUX) плюс лабораторні виміри. Якщо TTFB у червоній зоні - проблема серверна
3. Ping та traceroute - з терміналу або через сервіс ping.pe перевірте затримку до вашого сервера з різних точок. Для України нормальний ping до європейського дата-центру - 15-40 мс

Після тестів порівняйте свої результати з таблицею вище. Якщо ваш TTFB понад 800 мс, а Gzip навіть не увімкнений - ви в першому рядку таблиці. І ваш сайт програє конкурентам ще до того, як відвідувач побачить перший рядок тексту.

Що робити прямо зараз: план дій без зайвих слів

Якщо після тестів ви побачили проблеми - не панікуйте. Більшість речей можна виправити за вечір.

Крок перший: увійдіть у панель хостингу, перевірте версію PHP. Якщо менше 8.1 - оновіть. Це безкоштовно і дає миттєвий приріст.

Крок другий: перевірте, чи увімкнений OPcache. У cPanel це зазвичай у розділі «Select PHP Version» або «PHP Options». Значення opcache.memory_consumption має бути мінімум 128 МБ.

Крок третій: увімкніть Gzip. Для Apache додайте в .htaccess:

AddOutputFilterByType DEFLATE text/html text/css application/javascript

Для Nginx - попросіть підтримку хостингу або додайте gzip on; у конфіг.

Крок четвертий: встановіть плагін кешування. Для WordPress - WP Super Cache (безкоштовний і простий), LiteSpeed Cache (якщо сервер на LiteSpeed) або W3 Total Cache (для просунутих). Навіть базове сторінкове кешування скоротить TTFB у 3-5 разів.

Крок п'ятий: підключіть безкоштовний Cloudflare. Навіть на Free-тарифі ви отримаєте CDN, базовий кеш статики, HTTP/2 і автоматичний Brotli. Налаштування - 20 хвилин.

Якщо після всього цього TTFB залишається понад 500 мс - проблема в самому хостингу. Сервер перевантажений, залізо застаріле, або провайдер економить на всьому. Час мігрувати.

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