Hostinq və məhsuldarlıq
WordPress-i necə sürətləndiririk: LiteSpeed Enterprise, LSCache və hər sayt üçün Redis
Ən sürətli WordPress sorğusu heç vaxt icra olunmayan sorğudur — PHP və ya MySQL işə salınmazdan əvvəl strukturumuzun əksər ziyarətləri keşdən necə cavablandırdığı və bunun Core Web Vitals üçün nə demək olduğu burada təqdim olunur.
Ən sürətli sorğu heç vaxt icra olunmayan sorğudur
Standart bir WordPress sorğusu resurs baxımından bahalıdır. Veb server sorğunu PHP-yə ötürür, PHP WordPress-i yükləyir, qoşmaları işə salır, MySQL bazasına bir neçə onlarla sorğu göndərir, HTML yığır və yalnız bundan sonra baytları geri göndərir. Yüksək trafikli bir saytda bütün bu proses hər bir ziyarətçi üçün baş verir və sizin ilk bayta qədər olan vaxtınızın (TTFB) demək olar ki, hamısı burada sərf olunur.
Bizim cavabımız əksər ziyarətlər üçün bunların heç birinin baş verməməsini təmin etməkdir. Hostinq etdiyimiz saytlarda — 100 000-dən çox PBN saytı və əsas idarə olunan WordPress — ön tərəf səhifə baxışlarının böyük əksəriyyəti PHP-ni çağırmadan və ya verilənlər bazasına toxunmadan birbaşa keşdən əvvəlcədən tərtib edilmiş tam səhifə kimi təqdim olunur. Bu yazının qalan hissəsi bunu reallaşdıran təbəqələrin bir-birinə necə uyğunlaşdığı və hər birinin öz yerini necə qazandığı haqqındadır.
Əsas məqam odur ki, bunlar aralarından seçim edəcəyiniz rəqib keşlər deyil. Tam səhifə keşi, obyekt keşi və CDN kənarı (edge) hər biri fərqli sorğu növünü qarşılayır və əsas dəyər onların bir-birinə ötürülmə tərzindədir.
LiteSpeed Enterprise + LSCache: tam səhifə təbəqəsi
Hər bir sayt server səviyyəli LSCache ilə LiteSpeed Enterprise üzərində işləyir. Ön tərəf (front-end) cavabı keşlənə bildikdə, veb-server onu LiteSpeed cache-control və etiket başlıqları ilə möhürləyir və LiteSpeed növbəti müraciətdə tam səhifəni birbaşa təqdim edir — heç bir PHP prosesi başladılmır, heç bir MySQL sorğusu verilmir. Bu, WordPress TTFB göstəricisinə ən böyük təsir edən faktordur, çünki o, tətbiqin bütün yüklənmə prosesini ən kritik icra yolundan çıxarır.
LSCache PHP qoşmasında deyil, birbaşa veb-serverin daxilində yerləşdiyi üçün sorğu dövrəsində daha erkən işə düşür və səhifələri serverin dərhal təmizləyə biləcəyi formada saxlayır. Keş quraşdırıcısı (crawler) populyar səhifələri aktiv saxlayır, beləliklə təmizlənmədən sonrakı ilk ziyarətçi səhifənin yenidən yaradılması xərcini çəkmir. Nəticədə, keşin hələ də PHP arxasında qaldığı ümumi sistemə əlavə edilmiş yalnız qoşmalı keşlə müqayisədə nəzərəçarpacaq dərəcədə daha aşağı və daha stabil TTFB əldə edilir.
Bizim öz repozitoriya səviyyəli keş plaginimiz hər bir saytda əvvəlcədən quraşdırılmış və avtomatik yenilənən şəkildə təqdim olunur və WordPress sistemini birbaşa LSCache ilə düzgün əlaqələndirir. LiteSpeed olmayan mənbədə o, sadəcə olaraq heç bir tam səhifə başlığı buraxmır və mane olmur, eyni zamanda obyekt keşi və istisna qaydaları öz işini davam etdirir — beləliklə, köçürülmüş sayt heç vaxt nasaz, yarı konfiqurasiya edilmiş vəziyyətdə qalmır.
Köhnəlmiş məzmun təqdim etmədən sürətli qalmaq: ESI və ağıllı avtomatik təmizləmə
Aqressiv tam səhifə keşləməsinin iki klassik uğursuzluq rejimi var: daxil olmuş istifadəçiyə başqasının səhifəsini təqdim etmək və hər kəsə dəyişməli olan bir səhifəni təqdim etmək. Hər ikisi daha az keşləməklə deyil, keşləmə səviyyəsində həll edilir.
ESI (Edge Side Includes) canlı qalmalı olan hissələr üçün boşluqlar açarkən səhifəni keşləməyimizə imkan verir. WooCommerce mağazasında kataloq, məhsul və kateqoriya səhifələri mümkün olan ən sürətli TTFB üçün tam səhifə keşi kimi təqdim olunur, ESI isə hər sorğu üçün səbət fraqmentini, mini-səbət cəmlərini və hesab vəziyyətini tərtib edir. Səbət, sifariş rəsmiləşdirmə, hesabım və hər hansı nonce və ya sessiya səhifələri standart olaraq xaric edilir. Alıcılar həmişə öz səbətlərini və işlək sifariş rəsmiləşdirmə səhifəsini görürlər; hər kəs isə vitrini yenə də keşdən əldə edir.
Təzəlik ağıllı avtomatik təmizləmə ilə idarə olunur. Məzmun, məhsullar, qiymətlər və ya sifarişlər dəyişdikdə təmizləmə qarmaqları (purge hooks) avtomatik işə düşür, beləliklə müvafiq keşlənmiş səhifələr taymer üzrə deyil, dərhal yenilənir və siz həmçinin idarəetmə panelindən və ya WordPress daxilindən tələb üzrə təmizləyə bilərsiniz. Teq əsaslı təmizləmə o deməkdir ki, bir yazını redaktə etmək həmin yazını və onun arxivlərini təmizləyir — bütün keşi yox — beləliklə, tək bir redaktə bütün saytın soyuq işə salınmasına (cold-start) səbəb olmur.
Hər sayt üçün Redis obyekt keşləməsi: tam səhifə ola bilməyənlər üçün
Hər sorğu statik tam səhifə ola bilməz. Giriş edilmiş seanslar, WordPress inzibatçısı, WooCommerce səbətləri, axtarış və ESI-nin canlı saxladığı dinamik fraqmentlərin hamısı PHP işlətməlidir. Onlar üçün məqsəd 'tətbiqi ötürmək'dən 'verilənlər bazasını ötürmək' məqsədinə keçir.
Hər bir sayt özünəməxsus ayrılmış Redis obyekt keşini əldə edir. WordPress təkrarlanan verilənlər bazası oxumalarının nəticələrini — seçimləri, keçici məlumatları (transients), yazı və termin axtarışlarını, WooCommerce məhsul və sessiya məlumatlarını — yaddaşda saxlayır, beləliklə hər müraciət zamanı eyni sorğu MySQL üzərində icra olunmur. Təsir ən çox tam səhifə keşinin kömək edə bilmədiyi yerlərdə aydın görünür: daha sürətli idarəetmə panelləri, daha sürətli səbətlər və yüksək trafik zamanı verilənlər bazasında xeyli az yük.
Obyekt keş yaddaşı paylaşılan deyil, hər sayt üçün fərdidir; bu da həm performans, həm də təcrid baxımından vacibdir. Hər sayt üzrə verilənlər bazası məhdudlaşdırılması ilə birlikdə, bir saytın ağır və ya düzgün yazılmamış sorğuları qonşu saytları verilənlər bazası resurslarından məhrum edə bilməz. Çoxqatlı quraşdırmanın bütövlükdə necə işlədiyi barədə keşləmə funksiyaları səhifəmizdə, təcrid şəraitində istifadəçilər arasındakı sərhədlər haqqında isə ətraflı oxuya bilərsiniz.
Kənar və onun altındakı nəqliyyat
Mənbə serverdə yerləşən keş hələ də şəbəkəni keçməlidir. Serverin önündə CDN kənarı dayanır, buna görə də statik resurslar və keşlənə bilən səhifələr ziyarətçiyə yaxın olan mövcudluq nöqtəsindən təqdim olunur və mənbə server hətta yüksək yüklənmə altında belə sakit qalır. Bizim footprint-siz hostinq xəttimiz üçün eyni kənar bir neçə provayder arasında paylanmış multi-CDN hovuzudur və bu, performans hədəfi ilə yanaşı axtarış motoru izi (footprint) hədəfinə də xidmət edir; ənənəvi WordPress-də isə bu, sadəcə mənbə serverləri boş saxlayan sürətli, nizamlı bir qatdır.
Əsaslarda heç bir qənaətə yol verilməyib. Saytlar HTTP/3 dəstəkli NVMe yaddaşında işləyir, buna görə də keşin göndərdiyi baytlar hər hansı bir keş çatışmazlığının (cache miss) arxasında sürətli yaddaş olan müasir, multipleksləşdirilmiş daşıyıcı vasitəsilə çatır. Bu təbəqələrin heç biri əlavə ödənişli modul deyil: LiteSpeed, LSCache, hər sayt üçün Redis, NVMe və HTTP/3 hər planda əsas standartdır, əlavə satış səviyyəsi deyil.
Core Web Vitals göstəricilərinə həqiqətən nə təsir edir
Dəqiq olmaq vacibdir, çünki hostinq tez-tez Core Web Vitals üzrə həddindən artıq şişirdilir. TTFB tənliyin serverə aid olan hissəsidir və yuxarıdakı keşləmə steki onu aşağı salan amildir — HTTP/3 vasitəsilə kənardan təqdim edilən keşlənmiş tam səhifə TTFB-nin çatacağı ən aşağı səviyyəyə yaxındır. TTFB Largest Contentful Paint göstəricisinin aparıcı kənarı olduğundan, sürətli mənbə hər bir sonrakı metrikə başqa cür əldə edə bilməyəcəyi bir üstünlük qazandırır.
Lakin LCP, CLS və INP əsasən brauzerdə, səhifənin özü tərəfindən müəyyən edilir: optimizasiya olunmamış hero şəkli, renderi bloklayan CSS və JavaScript, şriftlər və reklamlar yükləndikcə sürüşən tərtibat, və plaginlərdən qaynaqlanan ağır əsas axın (main-thread) işi. Heç bir server keşləməsi 2 MB ölçüsündəki hero şəklini və ya meqabaytlarla JavaScript təqdim edən mövzunu düzəldə bilməz. Dürüst hostinq serverin töhfəsini faktiki olaraq nəzərəçarpmayan və sabit edir, bundan sonra isə ön tərəfi (front end) yüngül saxlamaq saytın öhdəsinə düşür.
Bu əmək bölgüsü faydalı düşüncə modelidir. Sorğunun brauzerə sürətlə çatacağına və yüksək trafik altında sürətli qalacağına zəmanət veririk; siz isə yükün kiçik və sabit qalmasını təmin edirsiniz. İkisinin kəsişdiyi məqam — keşin qızdırılması, kənar çatdırılma və dinamik səhifələrin ləngiməməsi üçün verilənlər bazasının cavabdehliyinin qorunması — texnoloji infrastrukturumuzun məhz tənzimləndiyi yerdir və bu platformadakı idarə olunan WordPress həllini ümumi hostinqdəki eyni saytdan daha sürətli edən də məhz budur.
Tez-tez verilən suallar
Mənə hələ də WP Rocket kimi keş plagini lazımdırmı?
Xeyr. Tam səhifə keşlənməsi veb-serverdə LiteSpeed-in LSCache vasitəsilə həyata keçirilir və əvvəlcədən quraşdırılmış və avtomatik yenilənən şəxsi keş qoşmamız WordPress-i ona düzgün şəkildə bağlayır, arxasında isə hər sayt üçün Redis obyekt keşi yerləşir. Üzərinə ikinci bir tam səhifə keşləmə qoşması əlavə etmək kömək etmək əvəzinə server səviyyəsindəki keşlə toqquşur, buna görə də buna ehtiyac yoxdur və tövsiyə edilmir.
Keşləmə mənim WooCommerce səbətimi və ya daxil olunmuş səhifələrimi pozacaq?
Xeyr. Səbət, sifarişin rəsmiləşdirilməsi, my-account və hər hansı nonce və ya sessiya səhifələri standart olaraq keşdən çıxarılır və ESI digər tərəfdən keşlənmiş səhifələrdə səbət fraqmentini və yekun məbləğləri canlı saxlayır. Vitrin hələ də keşdən yükləndiyi halda, alıcılar həmişə öz səbətlərini və işlək sifariş səhifəsini görürlər.
Dərc etdikdə və ya redaktə etdikdə keş necə yenilənmiş qalır?
Ağıllı avtomatik təmizləmə müvafiq WordPress qarmaqlarında işə düşür, beləliklə məzmun dərc etmək, redaktə etmək və ya məhsulu, qiyməti yaxud sifarişi dəyişdirmək bütün keş yaddaşı deyil, yalnız təsirlənən səhifələri və onların arxivlərini təmizləyir — və axtarış robotu onları yenidən hazırlayır. Siz həmçinin idarəetmə panelindən və ya WordPress daxilindən tələb üzrə təmizləyə bilərsiniz.
Yalnız hostinq mənə mükəmməl Core Web Vitals təmin edə bilərmi?
Bu, sizə ən yaxşı mümkün TTFB təqdim edir, hansı ki, serverin payıdır və Largest Contentful Paint üçün ilkin üstünlükdür. Lakin LCP, CLS və INP əsasən səhifənin özü tərəfindən müəyyən edilir — şəkil ölçüləri, render bloklayan resurslar, tərtibat sabitliyi və əsas icra xəttindəki JavaScript. Bizim texnologiya yığınımız server töhfəsini sürətli və ardıcıl edir; ön hissənin yükünü yüngül saxlamaq isə qalan fərqi aradan qaldırır.
Əlaqəli
14 gün ərzində pulsuz sınaqdan keçirin
İlk saytlarınızı 14 gün ərzində pulsuz istifadəyə verin — kart tələb olunmur. Mövcud şəbəkəni köçürürsünüz? Miqrasiyalar tamamilə pulsuzdur və heç bir məhdudiyyət yoxdur.
Pulsuz başlayın