TTFB (time to first byte) или „времето за първия байт“ е времето, в което браузърът изчаква отговор от сървъра.
TTFB е изминалото време между изпращането на заявката от уеб браузъра, до получаването на първия байт от отговора на сървъра.
TTFB е различна метрика от load time (времето за зареждане на страница от сайта). Само малка част от времето за зареждане на дадена страница е TTFB.
TTFB времето се влияе от:
- Мрежовата свързаност. Колкото по-добра е връзката на клиента с интернет (следователно уеб сървъра), толкова по-малко време ще отнеме изпращането на заявката и след това получаването на отговора.
- Времето, за което приложението на сайта генерира съдържанието. В това време влизат процесите по:
- получаване и обработка на клиентската заявка;
- обработка и изпълнение на PHP скриптове;
- изпълняване на обръщенията към базата данни;
- генериране на крайния HTML код.
Уеб сървърът е фактор единствено в получаването на заявката и изпращането на отговора. Това означава, че TTFB пряко зависи от това какъв точно е уеб сайтът, доколко е оптимизиран кода му и какъв е размерът на страницата, която се зарежда.
TTFB и динамичното генериране на страниците в сайта
Когато информацията в сайта се генерира динамично, както е при уеб CMS платформите, преди сървърът да върне отговор към уеб браузъра, той трябва да изчака генерирането на информацията.
Генерирането на информацията за отговора се извършва от допълнителни приложения, не от самия уеб сървър.
Например за генерирането на тази страница, PHP интерпретаторът изпълнява нужните PHP скриптове, които от своя страна комуникират с базата данни и изчакват получаването на определени данни от нея. След като информацията е поставена в подходящата форма и вид (HTML код), тогава тя се предава към уеб сървъра, който от своя страна вече може да изпрати отговор към уеб браузъра.
Много голямо значение за TTFB е доколко PHP интерпретаторът ще може бързо да приключи с оформянето на HTML кода за страницата. Най-новите версии на PHP – 8.0, 7.3 са в пъти по-бързи от предишните версии например 5.6.
Освен динамичното подготвяне на HTML кода на страницата, към времето за изчакване на отговора се прибавя и времето за преминаването му през мрежата.
TTFB се измерва в милисекунди (ms). Ако този показател е близо или повече от 1 секунда, това означава, че има нещо нередно, което забавя отговора от сървъра. Забавянето на отговора от сървъра може да се получи основно поради бавно генериране на динамичната информация или някакво забавяне по мрежовия път.
Измерване на TTFB
TTFB е един от показателите за бързината на сайта, който се измерва от уеб инструментите за тестване на сайтове като PageSpeed, GTmetrix и DevTools в браузъра.
Важно е да отбележим, че TTFB стойността няма отношение с позиционирането на сайта в търсачките. Потвърждение за това е предоставено в публичен туит от Джон Мюлер (старши уебмастър анализатор), важен фактор в Google: https://twitter.com/JohnMu/status/936221054103703553
Намаляване на TTFB чрез кеширане
Един от начините за подобряване (намаляване) на времето за отговор от сървъра, е чрез използване на кеширащи технологии към сайта. Тези технологии намаляват TTFB времето, тъй като елиминират процесите по динамичното генериране на съдържанието. Когато съдържанието на дадена страница е кеширано, то директно се връща като отговор към браузъра.
Кеширащи технологии за сайта може да се активират на три различни нива:
1. Локално при уеб потребителя: Browser Cache
Локалното кеширане на елементи от сайта изключва изпращането на запитване към сървъра. Не влияе на TTFB, защото браузърът изобщо няма да се свърже със сървъра и да очаква отговор от него. Вместо това ще зареди елемента от паметта си. Въпреки това за ускоряване на сайта е препоръчително да се използва кеширането в браузъра.
За да активирате кеширането на елементи от сайта, в уеб браузъра на посетителите, ще е нужно сайтът да подава специалните хедъри за тази цел – ETag (last-modified) и/или Expires (или по-новия му заместител Cache-Control:max-age).
Ако сайтът вече използва валидатора на актуалност ETag (last-modified), браузърът кешира ресурсите от сайта, дори и да не е зададен кеш контрол с хедър Expires (или по-новия му заместител Cache-Control:max-age). Липсата на кеш контрол хедър обаче, не се харесва на уеб инструментите за тестване на сайтове, и в резултатите си ще го посочат като недостатък за отстраняване. За да се повиши оценката в тези инструменти (pagespeed, yslow), може допълнително да се зададе използването на хедъра Expires (или Cache-Control:max-age).
При готовите уеб CMS платформи, активирането на хедър Expires (Cache-Control:max-age) може да се извърши чрез допълнителен плъгин или модул. Например за WordPress, плъгинът W3 Total Cache добавя тези кеш контрол хедъри.
Тези хедъри може да се активират и ръчно, чрез поставяне на няколко директиви в .htaccess файла на сайта. Вижте повече информация в статията: mod_expires – за какво и как се ползва?
2. На ниво приложение: Memcahe/Redis (на самия сървър-източник)
Тези технологии за кеширане се намират и работят на същия сървър, на който се намира сайта. Съществуват различни системи и технологии за кеширане на информация на ниво приложение. Memcache, Redis, APC и eAccelerator са пример за такива кеширащи технологии.
Ако използвате уеб CMS платформа като WordPress, можете да активирате Memcache или Redis през опцията Ускоряване в WordPress Manager.
3. На ниво уеб сървър: Reverse Proxy/Web Accelerator (преди сървъра-източник на уеб съдържанието)
Към услугите на СуперХостинг.БГ, за хостинг план СуперХостинг и всички Managed VPS планове, се предлага супер-инструментът SuperCache в cPanel. Чрез този инструмент можете да активирате кешираща технология на ниво уеб сървър.
SuperCache е уеб ускорител (Web Accelerator), който кешира целия изходен код на уеб страницата, което включва динамичното и статичното ѝ съдържание. За разлика от технологиите Memcached и Redis, които работят на ниво приложение, SuperCache се намира пред реалния уеб сървър, който обслужва сайта.
Вижте повече информация в статията: СуперБърз сайт с новия уеб ускорител SuperCache Manager
Вижте още:
Системи за кеширане и ускоряване в уеб | Blog