Time to First Byte (İlkin Baytın Gəlmə Müddəti və ya TTFB) kimi ölçülən server cavab müddətinin azaldılması veb serverin sorğuları necə emal etməsini və istifadəçi brauzerinə məlumatları necə göndərməsini optimallaşdırmağı əhatə edir. Google Web Vitals təlimatları First Byte (TTFB) müddətini 800 millisaniyədən aşağı olduqda yaxşı hesab edir və siz bu məqsədə server tərəfli keşləmə və effektiv CDN istifadəsi vasitəsilə nail ola bilərsiniz. Bu metrikaya diqqət yetirmək vacibdir, çünki o, istifadəçinin səhifə tələb etməsi ilə serverin məlumat ötürülməsi prosesinə başlaması arasındakı vaxt gecikməsini təmsil edir.
İlkin Baytın Gəlmə Müddəti nədir və nə üçün vacibdir?
TTFB brauzerin HTTP sorğusu göndərdiyi an ilə serverdən ilk məlumat baytını aldığı an arasında keçən müddətdir. Bu vaxta ilkin DNS axtarışı, TCP əlaqəsinin qurulması (handshake), təhlükəsiz saytlar üçün TLS danışıqları və serverin real cavab yaratmağa sərf etdiyi vaxt daxildir. Serverinizin cavab verməsi çox uzun çəkdikdə, bütün səhifənin yüklənmə prosesi hələ başlamazdan əvvəl dayanır. Adi bir hesabda istifadəçilər ilkin əlaqə tez idarə olunduqda qavranılan sürətdə əhəmiyyətli yaxşılaşma hiss edirlər, çünki brauzer CSS və JavaScript faylları kimi vacib resursları lazımsız gözləmə müddəti olmadan yükləməyə başlaya bilər.
Uzun server cavab müddəti çox vaxt arxa fondakı infrastrukturun səhifə məzmununu toplamaqda çətinlik çəkdiyini göstərir. Bu, səmərəsiz verilənlər bazası sorğuları, ağır server tərəfli emal və ya keşləmə mexanizmlərinin olmaması səbəbindən baş verə bilər. Əgər server HTML strukturunu geri göndərməzdən əvvəl sadəcə düşünməyə üç saniyə sərf edirsə, istifadəçi ağ ekrana baxmalı olur. Bu server tərəfli prosesləri optimallaşdırmaqla siz brauzerin sənəd strukturunu dərhal almasını təmin edir və səhifənin vizual komponentlərini daha sürətli render etməyə başlamasına imkan yaradırsınız.
Niyə 800 millisaniyə həddi saytınız üçün vacibdir?
Google tərəfindən təqdim edilən 800 millisaniyəlik təlimat cavabdeh təcrübə təmin edən saytları müəyyən etmək üçün standart meyardır. TTFB ardıcıl olaraq bu həddən aşağı düşdükdə arxa fondakı əməliyyatlar səmərəli hesab olunur. Saytınızın tez-tez bu rəqəmi üstələdiyini görsəniz, bu, adətən server konfiqurasiyanızın və ya verilənlər bazası arxitekturanızın diqqətə ehtiyacı olduğunun əlamətidir. Zəif işləyən saytlarda ümumi model hər səhifə yüklənməsində işləyən və sorğu dövrünə lazımsız gecikmə əlavə edən mürəkkəb, optimallaşdırılmamış arxa fon məntiqinin mövcudluğudur.
Server cavabınızdakı ləngimələri necə müəyyən edə bilərsiniz?
Serverinizin gecikmə mənbəyi olub olmadığını müəyyən etmək üçün brauzerin tərtibatçı alətlərindən və ya xarici məhsuldarlığı izləmə xidmətlərindən istifadə etməlisiniz. Brauzerinizin elementin yoxlanılması alətinin Şəbəkə (Network) tabında əsas sənəd sorğunuz üçün vaxt bölgüsünə baxın. Siz DNS axtarışı, ilkin əlaqə və server cavabının gözlənilməsi üçün xüsusi seqmentlər görəcəksiniz. Əgər ‘Waiting (TTFB)’ seqmenti yüksəkdirsə, deməli, ləngimə mənbəyi sizin serverinizdir. Xüsusi skriptlərin və ya verilənlər bazası çağırışlarının həddindən artıq yaddaş və ya emal vaxtı sərf edib-etmədiyini görmək üçün həmçinin server qeydlərini (log) yoxlamalısınız.
| Metrika | Təsvir | Hədəf |
|---|---|---|
| DNS Axtarışı | Domenin IP-yə tərcümə edilməsi | 50 millisaniyədən az |
| TCP Əlaqəsi | Əlaqənin qurulması | 100 millisaniyədən az |
| TTFB | Server cavabının gözlənilməsi | 800 millisaniyədən az |
Sürəti artırmaq üçün server tərəfli keşləmədən necə istifadə etməli
Server tərəfli keşləmə TTFB-ni aşağı salmağın ən effektiv yollarından biridir, çünki o, hər bir ziyarətçi üçün səhifə məzmununun yenidən hesablanmasının qarşısını alır. İstifadəçi səhifə tələb etdikdə server yaddaşda və ya disk keşi üzərində əvvəlcədən yaradılmış versiyanın olub-olmadığını yoxlayır. Əgər varsa, server verilənlər bazasına sorğu göndərmədən və ya mürəkkəb məntiq işlətmədən həmin versiyanı dərhal göndərir. Bu, iş yükünü əhəmiyyətli dərəcədə azaldır və cavabın mümkün qədər tez geri göndərilməsini təmin edir, adətən tipik hesab parametrlərində cavab müddətini yüzlərlə millisaniyə qısaldır.
- Verilənlər bazası sorğuları üçün obyekt keşi tətbiq edin.
- Səhifə keşi plaginlərindən və ya Nginx FastCGI keşi kimi server səviyyəli modullardan istifadə edin.
- Təravəti təmin etmək üçün uyğun keşin bitmə vaxtı başlıqlarını təyin edin.
- Məzmun yeniləmələri baş verdikdə keşi avtomatik olaraq təmizləyin.
CDN server cavab müddətini necə azalda bilər?
Məzmun Çatdırılma Şəbəkəsi (CDN) son istifadəçiyə daha yaxın yerləşən serverlərdə saytınızın məzmununu keşləməklə TTFB-ni azaldır. Londondakı istifadəçi sizin saytınıza daxis olduqda, sorğu Kaliforniyadakı mənşə serverinizə qədər bütün yolu qət etməli deyil. Bunun əvəzinə Londondakı CDN qovşağı keşlənmiş HTML məzmununu dərhal təqdim edir. Bu coğrafi yaxınlıq ilkin əlaqə və sonrakı məlumat çatdırılması üçün tələb olunan dövrə vaxtını kəskin şəkildə azaldır və qlobal ziyarətçilər üçün TTFB-ni effektiv şəkildə aşağı salır.
Alien Road server optimallaşdırma üsullarını necə tətbiq edir
Alien Road olaraq, komandamız server performansının ilk gündən prioritet olaraq qalmasını təmin etmək üçün hər bir veb layihəyə arxa fon arxitekturasını audit etməklə başlayır. Biz ilkin cavabı tez-tez ləngidən təkrar sorğuları aradan qaldırmaq üçün verilənlər bazası sxemini təhlil etməklə başlayırıq. Daha sonra tez-tez daxil edilən məlumatları RAM-da saxlamaq üçün Redis və ya Memcached kimi server səviyyəli keşləmə mexanizmlərini konfiqurasiya edirik. Bu yanaşma hətta yüksək trafik dövrlərində belə serverin cavabdeh qalmasını təmin edir və TTFB-ni tövsiyə olunan hədlər daxilində saxlayır.
Standart iş prosesimiz zamanı biz həmçinin üçüncü tərəf inteqrasiyalarının performansını izləyirik. Bir çox saytda TTFB artımları baş verir, çünki onlar səhifənin yaradılması başa çatmazdan əvvəl xarici API-lərin cavab verməsini gözləyirlər. Biz ilkin server cavabını bloklamalarını təmin etmək üçün bu inteqrasiyalar üçün asinxron yükləmə üsullarını tətbiq edirik. Əsas sənəd generasiyasını yüngül və sürətli saxlamaqla biz səhifə yüklənməsinin qalan hissəsi üçün möhkəm təməl təmin edirik. Sayt miqyaslandıqca ortaya çıxan hər hansı təkrarlanan ləngimələri müəyyən etmək üçün müntəzəm olaraq server qeydlərini nəzərdən keçiririk.
Serverin ləngiməsinə təsir edən başqa amillər varmı?
Bəli, sadə keşləmə ehtiyaclarından başqa, yüksək server cavab müddətinə səbəb olan bir neçə başqa amil də var. Verilənlər bazasının sağlamlığı çox vaxt gizli günahkardır, xüsusən də düzgün indekslənməsi olmayan milyonlarla sətrə malik cədvəlləriniz varsa. İndekslər olmadıqda, verilənlər bazası tək bir nəticə tapmaq üçün bütün cədvəli skan etməlidir ki, bu da serverin daha uzun müddət məşğul olmasına səbəb olur. Bundan əlavə, istifadə etdiyiniz PHP versiyası və ya işləmə mühiti (runtime) vacibdir. Proqramlaşdırma dillərinin köhnə versiyaları çox vaxt performans düzəlişləri ehtiva edən müasir, yenilənmiş versiyalardan daha yavaş və səmərəsiz olur.
- Server tərəfli dil versiyasını mütəmadi olaraq yeniləyin.
- Sorğuları sürətləndirmək üçün verilənlər bazası cədvəllərini optimallaşdırın və indeksləşdirin.
- Hər səhifə yüklənəndə işləyən ağır plaginlərin istifadəsini minimuma endirin.
- Server səviyyəsində Gzip və ya Brotli istifadə edərək cavabları sıxışdırın.
Bu həftə haradan başlamaq lazımdır
Cari TTFB göstəricinizi qeyd etmək üçün PageSpeed Insights kimi alətdən istifadə edərək baza xəttinin yoxlanılması ilə optimallaşdırma səyahətinizə başlayın. Bu rəqəmi əldə etdikdən sonra, hələ aktiv deyilmişsə, server tərəfli keşləməni aktivləşdirməyə diqqət yetirin. Hostinq panelinizdə ‘Full Page Caching’ və ya ‘Redis’ inteqrasiyası kimi seçimləri yoxlayın. Əgər CMS-dən istifadə edirsinizsə, həddindən artıq verilənlər bazası çağırışlarına səbəb olmayan yüngül temaya sahib olduğunuzdan əmin olun. Bu iki sahəyə diqqət yetirməklə, siz konfiqurasiyadan cəmi birkaç saat sonra TTFB-nizdə ölçülə bilən azalma görəcəksiniz.
Tez-tez Verilən Suallar
TTFB səhifənin yüklənmə vaxtı ilə eynidirmi?
Xeyr, onlar fərqli meyarlardır. TTFB serverin məlumatların ilk baytını göndərməsinə qədər keçən vaxtı ölçür, səhifənin yüklənmə vaxtı isə səhifədəki bütün məzmunun tam yüklənməsi və render edilməsinin nə qədər vaxt apardığını ölçür. TTFB bütün səhifənin yüklənmə prosesinin sadəcə başlanğıc nöqtəsidir.
Yüksək trafik daha yüksək TTFB-yə səbəb olurmu?
Əgər serverinizin eyni vaxtda gələn sorğuları idarə etmək üçün resursları yoxdursa, yüksək trafik daha yüksək TTFB ilə nəticələnə bilər. Prosessor və ya yaddaş dolduqda, server hər bir fərdi sorğunu emal etmək üçün daha çox vaxt sərf edir. Keşləmə trafik pikləri zamanı aşağı TTFB saxlamaq üçün əsas üsuldur.
Paylaşılan hostinqdə (shared hosting) 800 millisaniyədən az TTFB əldə edə bilərəmi?
Bu mümkündür, lakin paylaşılan hostinq mühitləri çox vaxt sıx olur ki, bu da qeyri-sabit performansa səbəb ola bilər. Saytınız keşləmə ilə yaxşı optimallaşdırılıbsa, tez-tez hədəfə çata bilərsiniz, lakin xüsusi server (dedicated) və ya VPS TTFB-ni ardıcıl olaraq aşağı saxlamaq üçün lazım olan resurslar üzərində daha çox sabitlik və nəzarət təmin edir.
Server cavab müddətimi nə qədər tez-tez izləməliyəm?
Serverinizin cavab müddətini fasiləsiz olaraq və ya ən azı həftəlik izləməlisiniz. Performans yeni kod yeniləmələri, verilənlər bazasının böyüməsi və ya trafik həcmindəki dəyişikliklər səbəbindən dəyişə bilər. Avtomatlaşdırılmış monitorinq alətləri TTFB-niz 800 millisaniyəlik həddən yuxarı qalxmağa başladıqda sizi xəbərdar edə bilər ki, bu da sizə tez reaksiya verməyə imkan yaradır.
Gzip sıxılması TTFB-yə təsir edirmi?
Gzip sıxılması əsasən ilkin TTFB-yə deyil, ümumi səhifə ölçüsünün ötürülməsi müddətinə təsir edir. Lakin, ümumi sayt performansı üçün server səviyyəsində sıxılmanı aktivləşdirmək yenə də ən yaxşı təcrübədir. O, server məlumat göndərməyə başladıqdan sonra onun brauzerə mümkün qədər tez çatmasını təmin edir.
Oxumağa davam edin: Veb Dizayn və Hazırlanması · Veb Dizayn