TTFB და Core Web Vitals: რას ცვლის ჰოსტინგი სინამდვილეში

ჰოსტინგი web performance ანგარიშში ერთ რიცხვს ფლობს: time to first byte. ეს არის მოცდენა იმ მომენტს შორის, როცა ბრაუზერი გვერდს ითხოვს, და მომენტს, როცა პასუხის პირველი ბაიტი მოდის, და ის შედგება DNS-ისგან, კავშირის დამყარებისგან, მანძილისგან ვიზიტორსა და მანქანას შორის და დროისგან, რომელსაც შენი სერვერი ფიქრში ატარებს. ამ პირველი ბაიტის შემდეგ ყველაფერი - სურათების ზომა, რამდენი JavaScript სრულდება, ხტება თუ არა layout - შენი საიტის პრობლემაა და არცერთი გეგმა, რომელსაც იყიდი, მას არ შეცვლის.

ეს პატარა წილად ჟღერს და ასე არ არის. TTFB არის იატაკი Largest Contentful Paint-ის ქვეშ: თუ სერვერი პასუხობს 1.5 წამში, სრულყოფილი front-end მაინც ვერ გადალახავს 2.5-წამიან ზღვარს. თუ TTFB-ს აკონტროლებ, დანარჩენი გადაიჭრება. თუ იგნორირებას უკეთებ, ვერაფერი, რასაც სხვას გააკეთებ, საკმარისი არ იქნება.

სამი Core Web Vitals და სად დგას TTFB#

Core Web Vitals სამი field მეტრიკის ნაკრებია, რომელიც რეალურ ვიზიტებზე იზომება და 75-ე პერცენტილზე, მოძრავ 28 დღეზე მოგეწოდება. ზღვრები:

INP 2024 წლის მარტში First Input Delay-ის ნაცვლად Core Web Vital გახდა და ის უფრო მკაცრია: ის გვერდზე უარეს ურთიერთქმედებას ზომავს და არა მხოლოდ პირველს, და იზომება მომდევნო frame-ის დახატვამდე და არა მხოლოდ იქამდე, სანამ handler დაიწყებს.

TTFB სამიდან არცერთი არ არის. ეს დიაგნოსტიკური მეტრიკაა და რეკომენდაცია ასეთია: 0.8 წამი ან ნაკლები კარგი შეფასებისთვის, ხოლო 1.8 წამზე მეტი ცუდად ითვლება. ის მნიშვნელოვანია, რადგან LCP ოთხ ნაწილად იშლება, რომლებიც თანმიმდევრობით ხდება: TTFB, დაყოვნება, სანამ ბრაუზერი LCP რესურსს აღმოაჩენს, ამ რესურსის ჩატვირთვის დრო და დაყოვნება, სანამ ის გამოისახება. პირველი მათგანი მთლიანად სერვერის მხარეა და პირდაპირი გამოკლებაა დანარჩენი სამის ბიუჯეტიდან.

75-ე პერცენტილი ის ნაწილია, რომელსაც ხალხი ვერ ამჩნევს. შენი საკუთარი სწრაფი კავშირი თბილ ქეშზე არარელევანტურია. ოთხიდან ერთ ვიზიტორს იმ რიცხვზე უარესი გამოცდილება აქვს, რომლითაც გაფასებენ, და კუდი მობილური კავშირებისგან, ცივი ქეშებისა და ნელი მოწყობილობებისგან შედგება.

რას ელოდება პირველი ბაიტი#

გაზომე თითოეული ნაწილი და არა გამოიცნო. curl მთელ დაშლას ბეჭდავს:

$ curl -s -o /dev/null -w "dns: %{time_namelookup}s  connect: %{time_connect}s \tls: %{time_appconnect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n" \  https://example.com/

ეს კუმულაციური დროებია მოთხოვნის დაწყებიდან, ამიტომ თითოეული ეტაპის ფასი წინასთან სხვაობაა. სწორი ტიპური შედეგი იმავე კონტინენტზე მდგარი მანქანიდან ასე გამოიყურება: DNS 30 მწ-ზე ნაკლები, connect ამატებს 20-40 მწ-ს, TLS კიდევ 20-40 მწ-ს, ხოლო პირველი ბაიტი მოდის ამის შემდეგ 30-150 მწ-ში იმის მიხედვით, რა უნდა გაეკეთებინა სერვერს.

ორი რამ ამახინჯებს ამ გაზომვას. გაუშვი ორჯერ: მეორე გაშვება DNS პასუხს ხელახლა იყენებს და გაძლევს უფრო ზუსტ სურათს დაბრუნებული ვიზიტორისთვის. და გაუშვი სადმე, რაც შენი ოფისი არ არის, რადგან შენი საკუთარი latency სერვერამდე შენი ვიზიტორების არ არის.

სერვერის მხარისთვის Server-Timing ის ინსტრუმენტია, რომელიც გამოცნობას რიცხვად აქცევს. შენი აპლიკაცია მას გამოსცემს და ბრაუზერის devtools აჩვენებს:

Server-Timing: db;dur=53, render;dur=31, cache;desc="MISS"

დაამატე ის შენი ბაზის გამოძახებებისა და შაბლონის render-ის ირგვლივ, გამოაქვეყნე, და კამათი იმაზე, ბაზა ნელია თუ framework, იმავე შუადღეს მთავრდება.

რას ცვლის ჰოსტინგი სინამდვილეში#

ოთხ რამეს, იმის მიხედვით, რამდენად ხშირად მნიშვნელოვანია.

სერვერის მუშაობა. დრო იმ მომენტს შორის, როცა სერვერი მოთხოვნას იღებს, და მომენტს, როცა პასუხს იწყებს. PHP საიტისთვის ეს არის PHP-ის გაშვება, framework-ის boot, ბაზის query-ები და შაბლონის render. აქ არის ადგილი, სადაც სწრაფი გეგმა ნამდვილად უფრო სწრაფია: მეტი CPU წილი ნიშნავს ნაკლებ რიგს, ხოლო მეტი მეხსიერება - რომ ქეშები თბილი რჩება. ასევე აქ არის ყველაზე დიდი უფასო მოგებები - OPcache, object cache და გვერდის გასწორება, რომელიც 400 query-ს უშვებს.

მანძილი. ბოჭკოში სინათლე დაახლოებით 200 კმ-ს გადის მილიწამში და ყოველ მოთხოვნას პირველ ბაიტამდე რამდენიმე round trip სჭირდება. გერმანიაში მდგარი სერვერიდან დაახლოებითი round-trip დროები ასეთია:

გაამრავლე ახალი HTTPS კავშირისთვის საჭირო ორ-სამ round trip-ზე და ხედავ, რატომ იწყებს ავსტრალიელი ვიზიტორი წამით დაგვიანებით, სანამ შენი კოდი გაეშვება. ამას ვერცერთი გეგმა გამოასწორებს; მხოლოდ ვიზიტორთან უფრო ახლოს მდგარი ქეში. სად უნდა იცხოვროს შენმა სერვერმა ამ კომპრომისის პატიოსანი ვერსიაა.

კავშირის დამყარება. HTTP/2 საშუალებას აძლევს ბევრ მოთხოვნას ერთი კავშირი გაინაწილოს, ამიტომ handshake ერთხელ იხდება და არა თითო asset-ზე. TLS 1.3 ერთ round trip-ში სრულდება, სადაც 1.2-ს ორი სჭირდებოდა. Keep-alive იმავე მიზეზითაა მნიშვნელოვანი. ეს ძირითადად შენი web სერვერის ნაგულისხმევებია და ჩვეულებრივ უკვე სწორია.

დისკი და მეხსიერება. NVMe საცავი ამოკლებს ყველაფერს, რაც ფაილურ სისტემას ეხება: ცივი PHP ფაილის წაკითხვა, ბაზის გვერდი, რომელიც მეხსიერებაში არ არის, დიდი ატვირთვა. ის ყველაზე მეტად ჩანს ბაზაზე, რომელიც RAM-ში არ ეტევა. რას ცვლის NVMe სინამდვილეში რიცხვებს გვაძლევს.

RE:NODE-ზე ეს ყველაფერი NVMe-ზე ზის, გერმანიაში ZFS pool-ზე, ხოლო შენს გეგმაზე CPU წილი მკაცრი throttle-ია და არა burst შენაძენი. მკაცრი ლიმიტი ნაკლებად მაამებელია benchmark-ზე და გაცილებით უფრო წინასწარგანჭვრეტადი production-ში: სერვერი, რომელიც 100%-ზე დგას, ნელია და არასოდეს - შეჩერებული, ხოლო კონსოლის გრაფიკები მეხსიერებას, CPU-სა და დისკს ლიმიტებთან აჩვენებს, რომ დაინახო, რომელს ეჯახები სინამდვილეში. გაზიარებული CPU და ხმაურიანი მეზობლები განმარტავს, რატომ არის throttle პატიოსანი მოდელი.

რას ვერ ცვლის ჰოსტინგი#

ამის შესახებაც ისევე გარკვევით იყავი, რადგან სწორედ აქ იხარჯება performance-ის ფულის უმეტესობა ტყუილად.

• სურათის წონა. 3 MB hero სურათი 3 MB-ია ნებისმიერი სერვერიდან. LCP ელემენტი გვერდების უმეტესობაზე სურათია და გამოსწორებაა მისი ექსპორტი ნაჩვენები ზომით WebP-ში ან AVIF-ში.
• JavaScript-ის შესრულება. INP წყდება ვიზიტორის მოწყობილობაზე შენი main thread-ით. უფრო სწრაფი სერვერი 400 მწ ამოცანას ვერ დააკლებს.
• Layout shift. CLS გამოწვეულია სურათებით ზომების გარეშე, რეკლამებითა და embed-ებით, რომლებიც თავს ჩასვამენ, და შრიფტებით, რომლებიც სხვა ზომაზე ცვლიან. ყოველთვის წმინდა front-end.
• მესამე მხარის tag-ები. Analytics, ჩატის ვიჯეტები, თანხმობის მენეჯერები და pixel-ები სხვის სერვერებიდან იტვირთება სხვის განრიგზე.
• Render-ის დამბლოკავი რესურსები. head-ში მდგარი stylesheet render-ს ბლოკავს, სანამ არ მოვა, ვინც არ უნდა ჰოსტავდეს.
• ვიზიტორის მოწყობილობა და ქსელი. ხუთი წლის ტელეფონი მატარებელში 75-ე პერცენტილია.

პრაქტიკული ტესტი გეგმის გაუმჯობესებამდე: შეხედე CPU-სა და მეხსიერების გრაფიკებს შენს ყველაზე დატვირთულ საათში. თუ 20% CPU-ზე ხარ და მეხსიერების ნახევარზე, უფრო დიდი გეგმა არაფერს შეცვლის და time to first byte, რომელიც არ მოგწონს, შენი კოდიდან, შენი query-ებიდან ან მანძილიდან მოდის. როდის გააუმჯობესო შენი გეგმა იგივე არგუმენტია უფრო ვრცლად.

სწორი გაზომვა: field და lab#

ორი სახის მონაცემი, რომლებიც სხვადასხვა კითხვას პასუხობს.

Field მონაცემები რეალური ვიზიტებიდან მოდის. Chrome-ის საჯარო მონაცემთა ნაკრები Search Console-ში Core Web Vitals ანგარიშსა და PageSpeed Insights-ის ზედა ნახევარს უდევს საფუძვლად, 28 დღეზე აგრეგირებული 75-ე პერცენტილით. ეს ის არის, რასაც ძიება რეალურად იყენებს, ის შენს ნამდვილ აუდიტორიასა და მოწყობილობებს ფარავს და ნელა მოძრაობს - დღეს გამოსწორება მომდევნო კვირებში ჩანს.

Lab მონაცემები სინთეტიკური გაშვებიდან მოდის: Lighthouse, PageSpeed Insights-ის ქვედა ნახევარი, WebPageTest. ის განმეორებადია და მყისიერი, რაც მას გვერდის ორი ვერსიის შესადარებლად სწორს ხდის, და INP-ს სათანადოდ ვერ ზომავს, რადგან არავინ ურთიერთქმედებს. Lab გაშვება ასევე სიმულირებულ კავშირს იყენებს, ამიტომ მისი LCP შენი ვიზიტორების LCP არ არის.

საიტისთვის, რომელსაც field მონაცემებისთვის ტრაფიკი საკმარისი არ აქვს, შეაგროვე საკუთარი web-vitals ბიბლიოთეკით, რომელიც იმავე მეტრიკებს რეალური სესიებიდან შენთვის სასურველ endpoint-ზე აგზავნის. ასი რეალური ვიზიტი უფრო მეტს გეუბნება, ვიდრე ათასი lab გაშვება.

როცა კონკრეტულად სერვერის მხარის პრობლემას მისდევ, ყველაზე სწრაფი ციკლია curl გარედან, ციკლში, მშვიდ საათსა და დატვირთულ საათზე. TTFB, რომელიც დილის 3 საათზე კარგია და საღამოს 9-ზე საშინელი, სიმძლავრის პრობლემაა. ის, რომელიც მუდამ ცუდია, კოდის ან query-ის პრობლემაა. ის, რომელიც ცუდია მხოლოდ გარკვეულ გვერდებზე, არის აკლებული ინდექსი ან ნელი მესამე მხარის გამოძახება მოთხოვნის გზაზე.

TTFB-ს გამოსწორება, თანმიმდევრობით#

1. ქეშირება HTML-ის. ქეშიდან მიწოდებული გვერდი გამოტოვებს framework-ს, ბაზას და რისკის უმეტესობას. სრული გვერდის ქეში 600 მწ დინამიკურ პასუხს 20 მწ-მდე ამცირებს. WordPress-ისთვის ეს გვერდის ქეშის plugin-ია პლუს object cache; framework-ისთვის - response cache ან reverse proxy. HTTP ქეშირების ჰედერები ახსნილი განიხილავს, რა გააგზავნო მასთან ერთად, რომ ბრაუზერები და CDN-ები ითანამშრომლონ.
2. ჩართე OPcache და თავი დაანებე. OPcache-ის გარეშე PHP ყოველ მოთხოვნაზე ყველა ფაილს ხელახლა აკომპილირებს. opcache.enable=1-ითა და საკმარისი opcache.memory_consumption-ით ეს მუშაობა ერთხელ ხდება. production-ში opcache.validate_timestamps=0 ფაილზე stat გამოძახებას აშორებს, deploy-ზე reset-ის საჭიროების ფასად. php.ini პარამეტრები, რომლებიც მნიშვნელოვანია დანარჩენს შეიცავს.
3. დათვალე query-ები. 900 მწ TTFB-ის ყველაზე გავრცელებული მიზეზია ციკლი, რომელიც თითო მწკრივზე ერთ query-ს უშვებს. განვითარებაში ლოგირება გაუკეთე query-ების რაოდენობას გვერდზე; ნორმალურ გვერდზე დაახლოებით 30-ზე მეტს ახსნა სჭირდება.
4. მოკალი დამბლოკავი მესამე მხარის გამოძახება. გარე API-ზე მოთხოვნა გვერდის render-ის შიგნით შენს TTFB-ს სხვისი uptime-ისგან დამოკიდებულს ხდის. გადაიტანე რიგში, დაქეშე შედეგი ან შეგნებულად მიიღე რისკი.
5. მოაშორე გადამისამართებების ჯაჭვები. ყოველი ნახტომი სრული round trip-ია, ხოლო გადამისამართება სხვა hostname-ზე ისევ DNS-სა და TLS-ს ამატებს. http://example.com-იდან https://example.com-ზე და შემდეგ https://www.example.com-ზე ყოველ პირველ ვიზიტზე ორი თავიდან ასაცილებელი მოცდენაა.
6. შეკუმშე და კავშირები თბილად შეინახე. gzip ან brotli ტექსტისთვის, HTTP/2 ჩართული, keep-alive ჩართული. ეს ჩვეულებრივ ნაგულისხმევებია, მაგრამ შეამოწმე და არ დაუშვა.
7. მხოლოდ ამის შემდეგ იყიდე მეტი სერვერი. თუ CPU ტრაფიკისას მაქსიმალურია ან მეხსიერება ლიმიტზეა, გეგმაა პრობლემა და ყველაფერი ზემოთ ავეჯის გადალაგებაა. ვებ აპის ზომა გაშვების დღისთვის განიხილავს, როგორ გაარკვიო, რა გჭირდება თავად დღემდე.

LCP-ს გამოსწორება, როცა TTFB კარგია#

სწრაფი პირველი ბაიტით LCP წყდება იმით, რამდენად სწრაფად პოულობს და ხატავს ბრაუზერი ყველაზე დიდ ელემენტს - თითქმის ყოველთვის სურათს ან ტექსტის დიდ ბლოკს.

• LCP სურათს lazy-load ნუ გაუკეთებ. loading="lazy" hero-ზე ზუსტად იმას აგვიანებს, რაც იზომება. Lazy-load გააკეთე მხოლოდ იმას, რაც ფოლდის ქვემოთაა.
• მიეცი პრიორიტეტი. fetchpriority="high" LCP სურათზე ბრაუზერს ეუბნება, გადმოწეროს ის სხვა სურათებამდე, ხოლო preload ბმული ეხმარება, როცა სურათი გვიან აღმოჩნდება, მაგალითად CSS-იდან.
• Preconnect იმ origin-ებთან, რომლებსაც ვერ აიცილებ. rel="preconnect" შრიფტის ან სურათის ჰოსტთან DNS-სა და TLS ფასს პარალელურად იხდის და არა თანმიმდევრობით.
• შრიფტები შენი origin-იდან მიაწოდე `font-display: swap`-ით. ტექსტი, რომელიც შრიფტის ჩატვირთვისას უხილავია, ტექსტია, რომელიც არ გამოსახულა.
• დააყენე `width` და `height` ყველა სურათზე. ეს ერთადერთი ყველაზე დიდი CLS გამოსწორებაა და არაფერი ღირს.
• შეამცირე render-ის დამბლოკავი CSS. ჩააშენე ის, რაც პირველ ეკრანს სჭირდება და დანარჩენი ასინქრონულად ჩატვირთე, თუ შენი კონფიგურაცია ამას გადაწერის გარეშე გაძლევს.

Static საიტი ამის უმეტესობას უფასოდ იღებს, რაც არგუმენტის ნაწილია მისი აშენებისთვის, სადაც კონტენტი ამის საშუალებას იძლევა - იხილე static საიტის ჰოსტინგი. CMS ამას იღებს ქეშირების ფენიდან პლუს plugin-ებთან დისციპლინიდან; WordPress-ის სიჩქარე და ქეშირება კონკრეტული ვერსიაა.

FAQ#

რა არის კარგი TTFB?

75-ე პერცენტილზე 800 მწ-ზე ნაკლები არის გამოქვეყნებული ზღვარი კარგი შეფასებისთვის, მაგრამ ეს ჭერია და არა მიზანი. ახლომდებარე სერვერზე ქეშირებული გვერდი 30-80 მწ-ში პასუხობს; დინამიკური გვერდი, რომელიც ნამდვილ მუშაობას აკეთებს, მაინც 300 მწ-ზე ნაკლებს უნდა აღწევდეს. თუ წამზე მეტი გაქვს, რაღაც არასწორია და არა უბრალოდ ოპტიმიზაციას მოკლებული.

გააუმჯობესებს თუ არა ჩემს Core Web Vitals უფრო ძვირი გეგმა?

მხოლოდ თუ რესურსებში შეზღუდული ხარ. მეტი CPU და მეხსიერება ამოკლებს TTFB-ის სერვერის მუშაობის ნაწილს, რაც LCP-ს ეხმარება. ისინი არაფერს აკეთებენ INP-სთვის, CLS-სთვის, სურათის წონისთვის ან მესამე მხარის სკრიპტებისთვის, საიდანაც ჩავარდნილი შეფასებების უმეტესობა მოდის. შეამოწმე გამოყენების გრაფიკები, სანამ დახარჯავ.

გამოასწორებს თუ არა CDN TTFB-ს?

ქეშირებული პასუხებისთვის - დიახ, მკვეთრად, რადგან პასუხი ვიზიტორთან ახლოს მდგარი მანქანიდან მოდის. ყველაფერზე, რასაც CDN ვერ ქეშავს - ავტორიზებული გვერდი, checkout, API გამოძახება - მოთხოვნა მაინც origin-მდე და უკან მიდის, ამიტომ origin-ის სიჩქარე და მისი მანძილი კვლავ განსაზღვრავს რიცხვს.

არის თუ არა TTFB რანკინგის ფაქტორი?

პირდაპირ არა. LCP, INP და CLS page experience სიგნალებში შედის, ხოლო TTFB LCP-ში. მიიჩნიე ის საშუალებად და არა მიზნად: მისი გამოსწორების მიზეზი ისაა, რომ ვიზიტორები ნელ გვერდებს ტოვებენ, და ეს ეფექტი ნებისმიერ რანკინგულ კორექტირებაზე დიდია.

რატომ მაქვს Lighthouse 100 და Search Console-ის ანგარიში ვარდება?

რადგან ისინი სხვადასხვა რამეს ზომავენ. Lighthouse არის ერთი სინთეტიკური გაშვება სიმულირებულ კავშირზე datacenter-იდან. Search Console გვატყობინებს, რა განიცადეს რეალურმა ვიზიტორებმა რეალურ მოწყობილობებსა და ქსელებზე ბოლო 28 დღის განმავლობაში, 75-ე პერცენტილზე. ენდე field მონაცემებს და lab გაშვება გამოიყენე ცვლილებების შესადარებლად.

რამდენი ხნის შემდეგ უმჯობესდება ანგარიში გამოსწორების შემდეგ?

Field მონაცემები მოძრავი 28-დღიანი ფანჯარაა, ამიტომ ცვლილებას მოძრაობის საჩვენებლად დღეები სჭირდება და სრულად ასახვისთვის დაახლოებით თვე. დაუყოვნებლივ გადაამოწმე lab ინსტრუმენტებითა და შენი real-user გაზომვებით; ოფიციალური ანგარიში მიიჩნიე დადასტურებად და არა უკუკავშირად.