TTFB над секунда на LiteSpeed сървър почти винаги значи липсващ кеш

TL;DR

Ако сайтът ви е на LiteSpeed и първият байт идва след повече от секунда, в деветдесет процента от случаите причината не е слаб сървър, а липсващ кеш. Проверката отнема три команди. Поправката е безплатна, но не е „инсталирай и забрави” — на сайт с конструктор и многоезичие може да счупи неща.

Какво е TTFB и кога е проблем

Time To First Byte е времето от изпращането на заявката до пристигането на първия байт от отговора. Всичко останало — изображения, шрифтове, скриптове — чака това време да мине.

Google смята за добро под 800 ms. Между 800 и 1800 е „нужно подобрение”.

TTFB не е Core Web Vital сам по себе си, но влиза директно в LCP. Ако първият байт идва на 1100 ms, вие започвате рисуването с 1100 ms дълг, а таванът за добър LCP е 2500 ms. Остават ви 1400 ms за всичко останало.

Проверката, която отнема три команди

Пуснете тази заявка три пъти подред към една и съща страница:

curl -so /dev/null -w 'TTFB %{time_starttransfer}s · общо %{time_total}s\n' https://example.com/

Тук е важното: гледайте как се променят числата.

Ако видите нещо от рода на:

TTFB 0.912s
TTFB 0.559s
TTFB 0.444s

това е подписът на липсващ кеш. Първата заявка е бавна, защото PHP се компилира наново. Втората и третата са по-бързи, защото OPcache вече държи компилирания байткод. Но PHP пак се изпълнява всеки път — свързва се с базата, върти заявките, сглобява страницата.

При работещ кеш и трите заявки са еднакво бързи и обикновено под 200 ms, защото сървърът връща готов файл и изобщо не докосва PHP.

Втората проверка е една глава:

curl -sI https://example.com/ | grep -i 'x-litespeed-cache\|cf-cache-status'

• x-litespeed-cache: hit — кешът работи
• главата липсва изцяло — няма кеш плъгин
• cf-cache-status: DYNAMIC — Cloudflare не кешира HTML-а, тоест всяка заявка стига до сървъра

Защо Cloudflare не решава това

Разпространено недоразумение. Cloudflare пред сайта не значи, че страниците се кешират.

По подразбиране Cloudflare кешира статичните файлове — изображения, CSS, скриптове — но не и HTML. Точно HTML-ът е скъпият, защото той изпълнява PHP.

Затова cf-cache-status: DYNAMIC на началната страница е нормално и очаквано. То значи, че кеширането трябва да стане при вас, на сървъра.

Защо точно на LiteSpeed е нелепо да няма кеш

LiteSpeed има вграден кеш на ниво сървър. Плъгинът LiteSpeed Cache за WordPress не е трето решение, а мост към нещо, което вече работи под вас — и е безплатен.

Тоест сайт на LiteSpeed без LiteSpeed Cache плаща пълната цена на PHP при всяко зареждане, докато машината под него има готов механизъм да не го прави.

Виждал съм сайт с двайсет и четири активни плъгина и нито един за кеш, на LiteSpeed сървър, с полево TTFB над секунда. Никой не го беше пропуснал нарочно — просто на никой не му беше хрумнало да провери.

Кога причината НЕ е кешът

Преди да инсталирате нещо, изключете другите три възможности.

Наистина натоварена машина. Погледнете товара, но задължително заедно с броя ядра. Товар 30 на 64 ядра е 0.47 на ядро и е спокойно. Товар 30 на 4 ядра е катастрофа. Числото само по себе си не значи нищо.

Бавни заявки към базата. Ако кешът е включен, а TTFB пак е висок, включете SAVEQUERIES за кратко и вижте кой плъгин пуска заявка на всяко зареждане. Обикновено е нещо, което брои посещения или проверява лиценз.

Външно обръщение при зареждане. Плъгин, който при всяко зареждане пита чужд API — курсове, наличности, карти — държи PHP да чака отговор. Кешът го скрива от посетителя, но първата заявка след изчистване пак ще е бавна.

Географско разстояние. Ако сървърът е в Германия, а мерите от Австралия, част от времето е физика. Затова полевите данни от реални потребители значат повече от еднократна проверка от вашия лаптоп.

Инсталирането не е тривиално навсякъде

На обикновен блог LiteSpeed Cache се пуска за пет минути.

На сайт с конструктор, многоезичие и тежка тема — не.

Комбинацията Elementor Pro плюс приставка за превод плюс тема със собствен кеш е мястото, където нещата се чупят. Виждал съм тема с агресивен двайсет и четиричасов кеш да събори галериите на имотите, защото двата кеша са държали различни версии на една и съща страница.

Разумният ред:

1. Бекъп на базата преди всичко останало. mysqldump | gzip, проверен с gunzip -t. Не разчитайте на бекъпа на хостинга, без да сте го отваряли.
2. Пуснете кеша само за неавтентикирани посетители в началото.
3. Изключете от кеша количката, плащането, профила и всяка страница с форма, която зависи от сесия.
4. Не пипайте минификацията и обединяването на CSS и JS на същия ден. Ако нещо се счупи, няма да знаете кое от двете.
5. Проверете в реален браузър, не само с curl. Curl не изпълнява JavaScript, не носи бисквитки и не вижда кеша на браузъра — може да ви покаже зелено, докато посетителят вижда счупена страница.

Какво да очаквате

При сайт, който досега е изпълнявал PHP при всяка заявка, кешът обикновено сваля TTFB от над секунда до под двеста милисекунди за посетителите, които попадат на кеширана страница.

Това е най-евтиното ускорение, което съществува. Няма ново желязо, няма пренаписване, няма месечна такса.

Струва си да се направи внимателно, веднъж, с бекъп — вместо бързо и три пъти.

Ако ви трябва помощ

Правим сайтове, които издържат реален трафик, и оправяме бавни сайтове, които вече съществуват.

Вижте какво правим или пишете ни.