Як паменшыць час водгуку сервера (TTFB)? Фактары, якія на гэта ўплываюць

Час водгуку сервера (TTFB) — гэта прамежак паміж адпраўкай браўзэрам запыту на вэб-старонку і атрыманнем першага байта ад сервера. Каб яго скараціць, неабходна выкарыстоўваць якасную хостынгавую інфраструктуру, ужываць поўнастаронкавае кэшаванне, паменшыць колькасць запытаў да базы дадзеных, укараніць CDN, аптымізаваць DNS і SSL-працэсы. У якасці практычнага арыенціру лічыцца, што для статычных ці добра закэшаваных старонак TTFB павінен знаходзіцца ў дыяпазоне 100-300 мс, а для дынамічнага кантэнту — звычайна ніжэй за 500 мс. Значэнні вышэй за 800 мс варта разглядаць як сігнал да неабходнасці аптымізацыі з пункту гледжання карыстальніцкага досведу і эфектыўнасці сканавання.

TTFB сам па сабе не тлумачыць усю хуткасць сайта, але з'яўляецца крытычна важнай стартавай метрыкай, бо вызначае, як хутка пачне загружацца астатняя частка старонкі. Асабліва гэта актуальна для WordPress, WooCommerce, навінавых сайтаў, сістэм з рэгістрацыяй і карпаратыўных рэсурсаў з высокім трафікам, дзе затрымкі на баку сервера напрамую ўплываюць на LCP і агульны час адкрыцця старонкі. У гэтым кіраўніцтве мы разгледзім фактары, якія павялічваюць TTFB, метады вымярэння і практычныя крокі па аптымізацыі тэхнічнай, але зразумелай мовай для блога Hostragons.

Што такое TTFB і што ён вымярае?

TTFB — гэта абрэвіятура ад англійскага Time to First Byte. На беларускую мову гэта можна перакласці як час да першага байта ці час водгуку сервера. Калі карыстальнік адкрывае старонку, браўзэр спачатку выконвае DNS-пошук, затым усталёўвае злучэнне з серверам, пры неабходнасці праводзіць TLS/SSL-рукapацісканне, вэб-сервер апрацоўвае запыт і адпраўляе першую порцыю дадзеных. TTFB лічыцца завершаным, калі першы байт дасягае браўзэра ў канцы гэтага ланцужка.

Было б няправільна разглядаць гэтую метрыку толькі як паказчык вылічальнай магутнасці сервера. TTFB адлюстроўвае сукупны ўплыў мноства слаёў: сеткавай адлегласці, хуткасці DNS, TCP-злучэння, SSL-працэсу, канфігурацыі вэб-сервера, кода праграмы, запытаў да базы дадзеных, дыскавага ўводу/вываду і стратэгіі кэшавання. Таму паспяховая аптымізацыя TTFB не зводзіцца да ўсталёўкі аднаго плагіна; яна патрабуе сістэмнага кантролю ад інфраструктуры да прыкладання.

Якое значэнне TTFB лічыцца добрым?

Згодна з агульнапрынятымі падыходамі да прадукцыйнасці, ідэальныя мэтавыя паказчыкі TTFB можна інтэрпрэтаваць наступным чынам:

• 0-200 мс: Вельмі добра. Звычайна сведчыць аб наяўнасці статычнага кантэнту, магутнага кэша або блізкага CDN-сервера.
• 200-500 мс: Добра. Прымальны дыяпазон для большасці карпаратыўных сайтаў і аптымізаваных установак WordPress.
• 500-800 мс: Можна палепшыць. Магчыма, прысутнічаюць дынамічныя запыты, аддалены сервер або недастатковае кэшаванне.
• 800 мс і вышэй: Сігнал трывогі. Неабходна праверыць рэсурсы хостынгу, код прыкладання, базу дадзеных або сеткавы ўзровень.

Важна не прымаць рашэнне на падставе аднаго тэсту. Вымярэнне, зробленае з Мінска, будзе адрознівацца ад вымярэння з Варшавы, Франкфурта ці Нью-Ёрка. Акрамя таго, галоўная старонка, старонка тавару, блогавы запіс, кошык і экран уваходу могуць мець розныя значэнні TTFB. Таму лепш праводзіць вымярэнні на розных тыпах старонак, у розны час і, па магчымасці, з розных лакацый.

Чаму час водгуку сервера (TTFB) павялічваецца?

Высокі TTFB звычайна з'яўляецца вынікам не адной прычыны, а спалучэння некалькіх невялікіх затрымак. Ніжэй прыведзены фактары, якія сустракаюцца часцей за ўсё.

1. Недастатковыя рэсурсы хостынгу

Віртуальны хостынг можа быць эфектыўным для малых і сярэдніх сайтаў пры правільнай канфігурацыі, аднак інтэнсіўнае выкарыстанне суседнімі сайтамі на тым жа серверы, абмежаванні CPU, недахоп RAM або нізкая хуткасць дыска могуць павялічыць TTFB. Асабліва гэта дакранаецца пікавага трафіку падчас акцый, інтэнсіўнага ботавага трафіку або такіх дынамічных працэсаў, як афармленне замовы ў WooCommerce. У такім выпадку можа спатрэбіцца перайсці на больш аптымізаваны тарыф, выкарыстоўваць інфраструктуру з NVMe-дыскамі або абраць VPS-рашэнне. Для выбару прыдатнай інфраструктуры на баку Hostragons можна азнаёміцца з Вэб-хостынг Paketleri, а для праектаў, якія растуць — з VPS Server Çözümleri.

2. Адсутнасць кэшавання

Калі старонка генеруецца з нуля для кожнага наведвальніка — з запускам PHP, запытамі да базы дадзеных і паўторнай апрацоўкай кампанентаў тэмы — гэта сур'ёзна павялічвае TTFB. Поўнастаронкавае кэшаванне, кэшаванне аб'ектаў і браўзэрнае кэшаванне зніжаюць гэтую нагрузку. Напрыклад, блогавы запіс на WordPress можа паказваць TTFB у 900 мс без кэша, а з правільнай канфігурацыяй кэша — знізіцца да дыяпазону 180-250 мс.

3. Праблемы з запытамі да базы дадзеных

Павольныя запыты з'яўляюцца значнай прычынай высокага TTFB, асабліва ў праектах на WordPress, Magento, Laravel або індывідуальных распрацоўках. Вялікія табліцы опцый, неаптымізаваны пошук, адсутнасць індэксаў, лішнія JOIN-аперацыі і празмернае выкарыстанне плагінаў падаўжаюць час апрацоўкі на баку сервера. У сайтах на WooCommerce аперацыі з кошыкам, запасамі, фільтрацыяй і сесіямі карыстальнікаў больш рэсурсаёмістыя, чым статычныя блогавыя старонкі.

4. Сеткавая адлегласць і адсутнасць CDN

З павелічэннем фізічнай адлегласці паміж карыстальнікам і серверам расце і затрымка. Размяшчэнне сайта, арыентаванага на Беларусь, у аддаленым цэнтры апрацоўкі дадзеных можа павялічыць TTFB, асабліва на этапе ўстанаўлення злучэння. CDN зніжае гэтую затрымку, аддаючы статычныя файлы, а ў некаторых выпадках і HTML-вывад з бліжэйшых да карыстальніка памежных вузлоў. Аднак няправільная канфігурацыя CDN можа даць адваротны эфект; напрыклад, калі кэшаванне HTML адключана, паскараецца толькі загрузка відарысаў, а паляпшэнне TTFB будзе абмежаваным.

5. Затрымкі DNS і SSL

Павольны DNS-пошук або залежнасць канфігурацыі SSL/TLS ад састарэлых пратаколаў таксама могуць уплываць на час першага водгуку. Падтрымка сучаснага TLS 1.3, правільны ланцужок сертыфікатаў і хуткі DNS-правайдар скарачаюць час злучэння. Выкарыстанне SSL абавязковае для бяспечнага злучэння, але няправільная ўстаноўка сертыфіката можа прывесці да страты прадукцыйнасці. У гэтым кантэксце можна ацаніць Сертыфікаты SSL і для кіравання даменамі Даменны запыт ve Kayıt.

Як вымераць TTFB?

Перш чым пачынаць аптымізацыю TTFB, неабходна правесці дакладныя вымярэнні. Інакш немагчыма будзе зразумець эфект ад унесеных змен. Рэкамендуецца выкарыстоўваць вынікі з некалькіх розных крыніц, а не абапірацца на адзін інструмент.

Даступныя інструменты

• Chrome DevTools: На ўкладцы Network у раздзеле Timing для запыту дакумента можна прааналізаваць поле Waiting for server response.
• PageSpeed Insights: Дае агульную карціну прадукцыйнасці на аснове рэальных карыстальніцкіх і лабараторных дадзеных.
• WebPageTest: Прапануе дэталёвы waterfall-аналіз для розных лакацый, браўзэраў і хуткасцяў злучэння.
• GTmetrix: Спрыяе выяўленню запытаў з затрымкамі, асабліва дзякуючы графіку waterfall.
• Каманда curl: Для тэхнічных спецыялістаў дае хуткі замер у тэрмінале. Напрыклад, каманда curl -w '%{time_starttransfer}' -o /dev/null -s https://siteadi.com паказвае час, аналагічны TTFB.

Пры вымярэнні варта выбіраць розныя тыпы URL-адрасоў, такія як галоўная, катэгорыя, тавар, блогавы запіс, кошык і старонка ўваходу. Таксама перад тэстам варта занатаваць, у якім стане знаходзіцца кэш CDN і асноўны кэш — "халодным" ці "гарачым". Першы запыт можа быць павольным з-за халоднага кэша, а наступныя — хуткімі; гэтая розніца важная для стратэгіі аптымізацыі.

Метады скарачэння TTFB: Пакрокавае кіраўніцтва

Наступныя крокі размешчаны ў парадку, які на практыцы дае найбольшы эфект. Пасля выканання кожнага кроку рэкамендуецца паўторнае вымярэнне, каб зразумець уклад кожнай змены.

1. Выберыце правільную хостынгавую інфраструктуру

Аснова аптымізацыі TTFB — гэта сервер, здольны хутка апрацоўваць запыты. Сервер павінен мець сучасны працэсар, дастатковы аб'ём RAM, NVMe SSD, LiteSpeed або аптымізаваную канфігурацыю Nginx/Apache, актуальную версію PHP і добрую ізаляцыю рэсурсаў. Для невялікага карпаратыўнага сайта можа быць дастаткова якаснага віртуальнага хостынгу, у той час як для інтэрнэт-крамы з высокім трафікам лепш падыдзе VPS або кіраваны сервер. Напрыклад, патрэбы ў рэсурсах у сайта-візітоўкі з 500 наведваннямі ў дзень і ў крамы, дзе 200 карыстальнікаў адначасова афармляюць кошык, зусім розныя.

Пры выбары хостынгу памылкова арыентавацца толькі на аб'ём дыскавай прасторы. Варта таксама ацэньваць абмежаванні CPU, RAM, ліміт inode, прадукцыйнасць уводу/вываду, структуру рэзервовага капіравання, размяшчэнне цэнтра апрацоўкі дадзеных і якасць падтрымкі. Калі ваша мэтавая аўдыторыя знаходзіцца ў Беларусі, выбар цэнтра апрацоўкі дадзеных, размешчанага паблізу, часта станоўча ўплывае на TTFB.

2. Выкарыстоўвайце актуальныя версіі PHP і HTTP-пратаколаў

Паміж PHP 7.4 і PHP 8.2 ці 8.3 можна ўбачыць істотную розніцу ў прадукцыйнасці, асабліва на WordPress і сучасных фрэймворках. Калі тэма і плагіны сумяшчальныя, пераход на актуальную версію PHP скарачае час апрацоўкі на баку сервера. Падтрымка HTTP/2 і HTTP/3 таксама можа павысіць эфектыўнасць злучэння. HTTP/3, дзякуючы пратаколу QUIC, патэнцыйна можа зменшыць затрымку пры злучэнні, асабліва ў мабільных сетках.

Тым не менш, перад абнаўленнем неабходна правесці тэсціраванне ў асяроддзі staging. Калі стары плагін або карыстацкі код выдасць памылку на новай версіі PHP, замест павышэння прадукцыйнасці можна атрымаць праблемы з даступнасцю. Таму спачатку варта зрабіць рэзервовую копію, а затым праверыць сумяшчальнасць.

3. Укараніце поўнастаронкавае кэшаванне

Адзін з метадаў, які найхутчэй уплывае на TTFB, — гэта выкарыстанне поўнастаронкавага кэша. На сайтах WordPress можна захоўваць HTML-вывад з дапамогай такіх рашэнняў, як LiteSpeed Cache, WP Rocket, W3 Total Cache ці аналагічных. Такім чынам, пры кожным наведванні адной і той жа старонкі працэсы PHP і MySQL не запускаюцца паўторна. На сайтах, якія працуюць на LiteSpeed Web Server, LiteSpeed Cache звычайна дае вельмі добрыя вынікі.

Правілы кэшавання трэба вызначаць асцярожна. Блогавыя запісы, старонкі катэгорый і статычныя карпаратыўныя старонкі добра падыходзяць для кэша. Аднак кошык, афармленне замовы, уліковы запіс карыстальніка і персаналізаваныя панэлі часцей за ўсё варта выключыць з кэшавання. Памылковае правіла кэшавання можа прывесці да сур'ёзных памылак, напрыклад, да паказу карыстальніку чужога кошыка.

4. Аптымізуйце базу дадзеных

За высокім TTFB часта стаіць база дадзеных. Для WordPress эфектыўна будзе для пачатку ачысціць рэвізіі, спам-каментары, часовыя дадзеныя і непатрэбныя опцыі з аўтазагрузкай. На буйных сайтах у табліцы wp_options лішнія запісы з пазнакай autoload=yes загружаюцца ў памяць пры кожнай загрузцы старонкі і могуць павялічваць TTFB.

Для больш глыбокай аптымізацыі варта прааналізаваць логі павольных запытаў, дадаць індэксы для часта выкарыстоўваных палёў фільтрацыі і пошуку, выдаліць непатрэбныя плагіны і паменшыць колькасць запытаў. Напрыклад, калі на старонцы катэгорыі выконваецца 180 запытаў, можна перагледзець структуру тэмы і плагінаў, каб скараціць гэты лік да 60-80. Такая розніца дасць прыкметны прырост прадукцыйнасці пры высокім трафіку.

5. Выкарыстоўвайце кэшаванне аб'ектаў

Такія рашэнні для кэшавання аб'ектаў, як Redis ці Memcached, захоўваюць у памяці вынікі часта выконваемых запытаў да базы дадзеных. Асабліва гэта карысна для сайтаў з рэгістрацыяй, інтэрнэт-крам, дошак аб'яваў, сістэм дыстанцыйнага навучання і шматмоўных сайтаў. Поўнастаронкавы кэш не заўсёды можна ўжываць для дынамічных старонак, але кэшаванне аб'ектаў можа паменшыць колькасць паўтаральных запытаў нават у дынамічных аперацыях.

Тут важны аб'ём сервернай RAM. Агрэсіўная канфігурацыя кэша аб'ектаў пры недастатковым аб'ёме RAM можа даць адваротны эфект. Таму неабходна адсочваць статыстыку выкарыстання, кантраляваць долю кэш-хітоў і спажыванне памяці.

6. Паменшыце геаграфічную затрымку з дапамогай CDN

CDN аддае відарысы, CSS, JavaScript і, у некаторых выпадках, HTML-кантэнт з бліжэйшых да карыстальнікаў вузлоў. Найбольш моцны эфект CDN для TTFB назіраецца пры выкарыстанні HTML edge caching або reverse proxy cache. Перанос толькі статычных файлаў у CDN павялічвае агульную хуткасць старонкі, але калі асноўны HTML-запыт усё яшчэ ідзе з аддаленага паходнага сервера, TTFB паляпшаецца нязначна.

Пры наладзе CDN неабходна правільна сканфігураваць DNS-запісы, рэжым SSL, загалоўкі кэша і правілы абыходу. Панэль кіравання, экран аплаты і персаналізаваныя старонкі варта выключыць з кэшавання. Акрамя таго, IP-адрас паходнага сервера трэба абараніць з меркаванняў бяспекі, наладзіўшы правілы так, каб доступ быў дазволены толькі праз CDN.

7. Паменшыце нагрузку ад тэмы і плагінаў

На сайтах WordPress цяжкія структуры тэм, лішнія канструктары старонак, празмерная колькасць плагінаў і знешнія API-выклікі могуць павялічваць TTFB. Не кожны плагін дрэнны сам па сабе, але кожны азначае патэнцыйныя PHP-працэсы, запыты да базы дадзеных і знешнія запыты. Невыкарыстоўваныя плагіны варта не проста дэактываваць, а цалкам выдаляць.

У якасці практычнага тэсту можна па чарзе адключаць плагіны ў асяроддзі staging і вымяраць TTFB. Напрыклад, плагіны бяспекі, рэзервовага капіравання, аналітыкі, SEO, формаў, перакладу і канструктары старонак варта ацэньваць паасобку. Калі модуль курса валют, стужка сацыяльных сетак або інструмент жывой падтрымкі, якія звяртаюцца да знешніх API, выклікаюць затрымку на серверы, іх варта зрабіць асінхроннымі або ўжыць да іх кэшаванне.

8. Кантралюйце ботавы трафік і шкоднасныя запыты

Інтэнсіўны ботавы трафік, спробы грубага перабору пароляў, XML-RPC-атакі і лішнія запыты краўлераў спажываюць рэсурсы сервера, павялічваючы TTFB для рэальных карыстальнікаў. WAF, абмежаванне частаты запытаў, плагіны бяспекі, аптымізацыя robots.txt і аналіз логаў тут вельмі важныя. Асабліва інтэнсіўныя спробы ўваходу на старонку адміністравання WordPress могуць павялічыць выкарыстанне CPU.

Меры бяспекі неабходныя не толькі для прадухілення нападаў, але і для захавання прадукцыйнасці. SSL, бяспечны DNS, актуальнае праграмнае забеспячэнне і правільныя правілы файрвола павінны разглядацца ў комплексе. Для атрымання дадатковай інфармацыі па бяспецы можна звярнуцца да Кіраўніцтва па бяспецы сайта.

Параўнальная табліца для аптымізацыі TTFB

Спецыяльныя парады па TTFB для сайтаў на WordPress

WordPress — гэта гнуткая платформа, якая можа працаваць хутка пры правільнай канфігурацыі, але з-за экасістэмы тэм і плагінаў яна лёгка можа стаць цяжкай. У першую чаргу варта выкарыстоўваць актуальную версію PHP, надзейную тэму, абмежаваную колькасць плагінаў і кэшаванне на ўзроўні сервера. Затым неабходна правесці ачыстку базы дадзеных, наладзіць кэш аб'ектаў, аптымізацыю відарысаў і кантроль крон-задач.

WP-Cron па змаўчанні спрацоўвае пры наведванні сайта. На рэсурсах з высокім трафікам гэта можа выклікаць непатрэбныя затрымкі. Больш эфектыўна вызначыць сапраўдную cron job для выканання запланаваных задач праз зададзеныя інтэрвалы. Акрамя таго, варта праверыць частату Heartbeat API, выкарыстанне admin-ajax.php і такія працэсы, як WooCommerce cart fragments. Невялікія налады ў гэтых галінах могуць прыкметна палепшыць працу, асабліва ў панэлі кіравання і на дынамічных старонках.

Чаму TTFB асабліва важны для інтэрнэт-крам?

Інтэрнэт-крамы выконваюць больш дынамічных аперацый у параўнанні са звычайнымі кантэнтнымі сайтамі. Кошык, аплата, праверка наяўнасці, разлік дастаўкі, прымяненне купонаў, сесіі карыстальнікаў і персаналізаваныя рэкамендацыі часцей за ўсё не кэшуюцца. Таму недастаткова разлічваць толькі на поўнастаронкавы кэш. Для інтэрнэт-крамы неабходны магутны хостынг, аптымізаваная база дадзеных, кэш аб'ектаў, добра напісаная тэма і хуткі водгук API аплаты і дастаўкі.

Напрыклад, калі на старонцы спісу тавараў кошт, наяўнасць і фільтры разлічваюцца з дапамогай складаных запытаў пры кожным звароце, TTFB расце. Гэтыя дадзеныя можна падрыхтоўваць загадзя з пэўным інтэрвалам, запыты можна індэксаваць, а для пошуку і фільтрацыі выкарыстоўваць спецыялізаваныя пошукавыя рухавічкі. На перыяд акцый варта загадзя прадумаць план маштабавання рэсурсаў.

Узаемасувязь TTFB і Core Web Vitals

Метрыкі Core Web Vitals непасрэдна сканцэнтраваны на карыстальніцкім досведзе. Хоць TTFB не з'яўляецца афіцыйнай метрыкай Core Web Vitals, ён аказвае значны ўплыў, асабліва на LCP. Калі HTML позна прыходзіць з сервера, браўзэр таксама позна выяўляе крытычныя рэсурсы CSS, відарысы і JavaScript. Гэта можа прывесці да затрымкі загрузкі самага вялікага элемента кантэнту.

Карацей кажучы, калі TTFB дрэнны, аптымізаваць астатнюю частку старонкі становіцца складана. Нават калі відарысы сціснутыя, CSS мінімізаваны, а JavaScript адкладзены, карыстальнік будзе даўжэй бачыць пусты экран, калі першы HTML затрымліваецца. Таму ў працы над прадукцыйнасцю спачатку трэба разглядаць водгук сервера, а затым рэсурсы, якія блакуюць рэндэрынг, і аптымізацыю відарысаў.

Практычны кантрольны спіс для TTFB

• Правядзіце вымярэнне TTFB для галоўнай і іншых важных старонак з розных лакацый.
• Праверце версію PHP і тэхналогію вэб-сервера.
• Наладзьце поўнастаронкавае і браўзэрнае кэшаванне.
• Вывучыце непатрэбныя запісы, павольныя запыты і нагрузку ад аўтазагрузкі ў базе дадзеных.
• Ацаніце магчымасці кэшавання аб'ектаў, такіх як Redis ці Memcached.
• Выкарыстоўвайце цэнтр апрацоўкі дадзеных, блізкі да вашай аўдыторыі, і CDN пры неабходнасці.
• Праверце падтрымку DNS, SSL і HTTP/2-HTTP/3.
• Выдаліце невыкарыстоўваныя плагіны, тэмы і інтэграцыі з вонкавымі сэрвісамі.
• Правядзіце аналіз логаў на прадмет ботавага трафіку і спроб нападаў.
• Пасля кожнай змены праводзіце паўторнае тэсціраванне ў тых жа ўмовах.

Частыя памылкі

Самая распаўсюджаная памылка пры аптымізацыі TTFB — гэта ўсталёўка выпадковых плагінаў без папярэдняга вымярэння крыніцы праблемы. Адначасовае выкарыстанне некалькіх плагінаў кэшавання, няправільны выбар рэжыму SSL у CDN ці памылковае кэшаванне дынамічных старонак могуць не паскорыць, а зламаць сайт. Яшчэ адна памылка — засяроджванне выключна на ацэнцы PageSpeed. Гэта карысны паказчык, але без аналізу waterfall, серверных логаў і дадзеных рэальных карыстальнікаў знайсці першапрычыну складана.

Акрамя таго, нерэалістычна чакаць цуду ад прасунутых аптымізацый на танным, але перагружаным віртуальным хостынгу. Якой бы добрай ні была праграмная частка, калі рэсурсаў сервера недастаткова, TTFB не апусціцца ніжэй за пэўны ўзровень. Таму аптымізацыю інфраструктуры і прыкладання неабходна планаваць сумесна.

Выснова: Сістэмнае паляпшэнне — залог ніжэйшага TTFB

Час водгуку сервера (TTFB) з'яўляецца адной з ключавых адпраўных кропак вэб-прадукцыйнасці. Нізкі TTFB азначае больш хуткі першы водгук, лепшы карыстальніцкі досвед, больш эфектыўнае сканаванне і мацнейшую аснову для Core Web Vitals. Для дасягнення найлепшага выніку неабходна сумесна ўжываць якасны хостынг, правільнае кэшаванне, аптымізацыю базы дадзеных, актуальнае праграмнае забеспячэнне, CDN і меры бяспекі.

Калі бягучыя значэнні TTFB вашага сайта высокія, спачатку правядзіце вымярэнні, а затым рухайцеся крок за крокам, пачынаючы з самага вузкага месца. Калі вам патрэбна больш магутная інфраструктура, здольная вытрымаць рост трафіку, вы можаце закласці правільны падмурак для вашага сайта, азнаёміўшыся з рашэннямі Hostragons у галіне хостынгу, VPS, даменаў і SSL: Hostragons рашэнні для хостынгу.

Часта задаваныя пытанні

Што трэба зрабіць у першую чаргу для зніжэння TTFB?

Першы крок — правесці дакладнае вымярэнне. Пратэстуйце розныя тыпы старонак, такія як галоўная, катэгорыя, тавар ці блог. Затым паслядоўна вывучыце рэсурсы хостынгу, стан кэша, запыты да базы дадзеных і канфігурацыю CDN.

Якое значэнне TTFB лічыцца добрым?

Агульнапрыняты арыенцір — 200-500 мс. Значэнні ніжэй за 200 мс лічацца вельмі добрымі, у той час як паказчыкі вышэй за 800 мс звычайна паказваюць на неабходнасць аптымізацыі. Для дынамічных старонак інтэрнэт-крам мэтавыя паказчыкі могуць вар'іравацца ў залежнасці ад тыпу старонкі.

Ці заўсёды выкарыстанне CDN зніжае TTFB?

Не. CDN паскарае загрузку статычных файлаў, але калі HTML-запыт па-ранейшаму паступае з паходнага сервера, TTFB можа знізіцца нязначна. Для памяншэння TTFB неабходна правільна наладзіць функцыі HTML-кэшавання ці reverse proxy у CDN.

Ці могуць плагіны WordPress павялічваць TTFB?

Так, асабліва цяжкія тэмы, непатрэбныя плагіны, знешнія API-выклікі і вялікая колькасць запытаў да базы дадзеных могуць павялічваць TTFB. Невыкарыстоўваныя плагіны варта выдаляць, а кампаненты, якія генеруюць павольныя запыты, — аналізаваць.

Ці дакладна TTFB знізіцца пасля змены хостынгу?

Хостынг — важны фактар, але сам па сабе ён не дае гарантыі. Калі рэсурсаў сервера недастаткова, змена хостынгу можа мець вялікі эфект. Але калі праблема ў кодзе прыкладання, базе дадзеных або няправільнай канфігурацыі кэша, гэтыя вобласці таксама неабходна аптымізаваць.