Hosting 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 işə düşməyəndir — budur bizim stekimizin hər hansı PHP və ya MySQL işə salınmazdan əvvəl əksər ziyarətlərə keşdən necə cavab verdiyi və bunun Core Web Vitals üçün nə demək olduğu.

Neil Lock tərəfindən · 15 iyul 2026 · daxil ol Hostinq və məhsuldarlıq

Heç vaxt icra olunmayan sorğu ən sürətli sorğudur

Standart WordPress sorğusu baha başa gəlir. Veb-server işi PHP-yə ötürür, PHP WordPress-i işə salır, plaqinləri işlədir, MySQL-ə bir neçə düzən dəfə sorğu göndərir, HTML yığır və yalnız bundan sonra baytları geri göndərir. Məşğul saytda həmin bütün proses hər bir ziyarətçi üçün baş verir və ilk bayta qədər sərf olunan vaxtın demək olar ki, hamısı buna gedir.

Bizim cavabımız əmin olmaqdır ki, əksər ziyarətlər zamanı bunların heç biri baş vermir. Hosting etdiyimiz saytlarda — 100 000-dən çox PBN saytı və əsas idarə olunan WordPress daxil olmaqla — ön səhifə baxışlarının böyük əksikliyi PHP işə salınmadan və ya verilənlər bazasına toxunulmadan birbaşa keşdən əvvəlcədən hazırlanmış tam səhifə kimi təqdim olunur. Bu yazının qalan hissəsi bunu təmin edən təbəqələrin bir-biri ilə necə uyğunlaşması və hər birinin öz yerini harada qazanması haqqındadır.

Vacib məqam ondan ibarətdir ki, bunlar aralarından seçəcəyiniz rəqabət aparan keşlər deyil. Tam səhifə keşi, obyekt keşi və CDN kənarı hərəsi fərqli sorğu sinfini əhatə edir və əsas dəyər onların bir-birinə necə ötürülməsindədir.

LiteSpeed Enterprise + LSCache: tam səhifə qatı

Hər bir sayt server səviyyəsində LSCache ilə təchiz olunmuş LiteSpeed Enterprise üzərində işləyir. Ön hissə cavabı keşlənə bilən olduqda, veb-server onu LiteSpeed cache-control və teq başlıqları ilə qeyd edir və LiteSpeed növbəti sorğuda tam səhifəni birbaşa təqdim edir — heç bir PHP prosesi işə düşmür, heç bir MySQL sorğusu göndərilmir. Bu, WordPress TTFB-yə təsir edən ən böyük amildir, çünki o, bütün tətbiqi işəsalma prosesini sürətli yoldan kənarlaşdırır.

LSCache veb-serverin özündə, PHP plaginində deyil, birbaşa yerləşdiyindən, sorğu həyat dövrünün daha əvvəlində işə düşür və səhifələri serverin dərhal ötürə biləcəyi formada saxlayır. Keş skaneri (crawler) populyar səhifələri aktiv saxlayır ki, təmizləmədən sonra gələn ilk ziyarətçi səhifəni yenidən yaratmaq məcburiyyətində qalmasın. Nəticə etibarilə, keşin hələ də PHP-nin arxasında yerləşdiyi ümumi stekə bərkidilmiş yalnız plaginli keşlə müqayisədə nəzərəçarpacaq dərəcədə aşağı və daha sabit TTFB əldə olunur.

Bizim repoya uyğun kəş pliginimiz hər saytda əvvəlcədən quraşdırılmış və avtomatik yenilənən şəkildə gəlir, bu da WordPress-i LSCache ilə qutudan çıxan kimi düzgün şəkildə birləşdirir. LiteSpeed olmayan mənbədə o, sadəcə olaraq heç bir tam səhifə başlıqları ötürmür və yoldan çəkilir, obyekt kəşfiyyatı və istisna qaydaları isə öz işini davam etdirir — ona görə də köçürülmüş sayt heç vaxt yarımçıq quraşdırılmış nasaz vəziyyətdə qalmır.

Sürətli qalaq, lakin köhnəlmiş məlumat verməyək: ESI və ağıllı avtomatik təmizləmə

Aqressiv tam səhifə keşlənməsinin iki klassik nasazlıq rejimi mövcuddur: daxil olmuş istifadəçiyə başqasının səhifəsini təqdim etmək və dəyişməli olan səhifəni istənilən şəxsə göstərmək. Hər iki problem daha az keşləməklə deyil, birbaşa keşləmə səviyyəsində həll edilir.

ESI (Edge Side Includes) səhifəni keşləməyə imkan verir və eyni zamanda canlı qalmalı olan hissələr üçün boşluqlar saxlayır. 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əli keş kimi xidmət edir, ESI isə səbət fraqmentini, mini-səbət cəmi məbləğlərini və hesabın statusunu hər sorğu üzrə render edir. Səbət, sifarişin rəsmiləşdirilməsi, mənim-hesabım və istənilən nonse və ya sessiya səhifələri defolt olaraq istisna 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ə mağazanı keshdən əldə etməyə davam edir.

Təravət ağıllı avtomatik təmizləmə vasitəsilə idarə olunur. Məzmun, məhsullar, qiymətlər və ya sifarişlər dəyişdikdə təmizləmə qarmaqları 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 əsasında təmizləyə bilərsiniz. Etiket əsaslı təmizləmə o deməkdir ki, bir yazının redaktə edilməsi bütün kəşi deyil, yalnız həmin yazını və onun arxivlərini təmizləyir, ona görə də tək bir redaktə bütün saytı soyuq başlatmır.

Hər sayt üzrə Redis obyekt keşi: tam səhifə ola bilməyən hallar üçün

Hər bir sorğu statik tam səhifə ola bilməz. Daxil olunmuş sessiyalar, WordPress admin, WooCommerce səbətləri, axtarış və ESI-nin saxladığı dinamik fraqmentlər — hamısı PHP işlətməlidir. Onlar üçün məqsəd "tətbiqi atlamaq"dan "verilənlər bazasını atlamaq" səviyyəsinə keçir.

Hər bir sayt özünə məxsus xüsusi Redis obyekt kȩ̧inə malikdir. WordPress təkrar edilən verilənlər bazası oxumalarının nəticələrini — seçimlər, tranziyentlər, yaz və termin sorğuları, WooCommerce məhsul və sessiya məlumatları — yaddaşda kȩ̧ləyir ki, hər müraciət zamanı eyni sorğu MySQL-ə qarşı işlədilməsin. Bunun effekti tam səhifə kȩ̧inin kömək edə bilmədiyi yerlərdə daha aydın görünür: daha sürətli idarəetmə panelləri, daha sürətli səbətlər və trafik altında xeyli aşağı verilənlər bazası yükü.

Obyekt keşi ümumi deyil, hər sayt üçün ayrıcadır ki, bu da həm performans, həm də izolyasiya baxımından vacibdir. Hər sayt üçün verilənlər bazası axınının tənzimlənməsi ilə birlikdə, bir saytın ağır və ya zəif yazılmış sorğuları qonşu saytlar üçün verilənlər bazasını tükəd bilməz. Bütün çoxqatlı quraşdırmanın necə işlədiyi barədə keşi xüsusiyyətləri səhifəmizdə, tenantlar arasındakı sərhədlər barədə isə izolyasiya bölməsində ətraflı oxuya bilərsiniz.

Kənar və onunaltı nəqliyyat şəbəkəsi

Mənşə serverdə saxlanılan keş həm də şəbəkədən keçməlidir. Serverin qarşısında CDN kənarı yerləşir, ona görə də statik resurslar və keşlənə bilən səhifələr ziyarətçiyə yaxın olan iştirak nöqtəsindən xidmət olunur və mənşə server yük altında belə sakit qalır. Footprint-Free hostinq xəttimiz üçün həmin kənar bir neçə təminatçı arasında paylanmış multi-CDN hovuzudur ki, bu da performans məqsədi ilə yanaşı footprint məqsədinə də xidmət edir; əsasən WordPress üzərində o, sadəcə olaraq mənşəyini boş saxlayan sürətli, yaxşı işləyən təbəqədir.

Altında əsaslar əsirgənmir. Saytlar NVMe yaddaşında HTTP/3 ilə işləyir, beləliklə, keşin göndərdiyi baytlar hər hansı kэş ötürülməsi (cache miss) zamanı sürətli yaddaş dəstəyi ilə müasir, multipleks nəqliyyat vasitəsilə çatdırılır. Bu təbəqələrdən heç biri əlavə xidmət deyil: LiteSpeed, LSCache, sayt üzrə Redis, NVMe və HTTP/3 hər bir planda başlanğıc səviyyəsidir, əlavə ödənişli səviyyə deyil.

Core Web Vitals göstəricilərini əslində nə dəyişir

Core Web Vitals üzrə hostinq çox vaxt həddindən artıq tərifləndiyi üçün dəqiq olmaq dəyər. TTFB serverin məsuliyyət daşıdığı tənliyin bir hissəsidir və onu aşağı salan onun üzərindəki keşləmə yığınıdır — kənardan (edge) HTTP/3 vasitəsilə təqdim olunan keşlənmiş tam səhifə demək olar ki, mümkün olan ən aşağı TTFB səviyyəsini təmin edir. TTFB Ən Böyük Məzmunlu Şəbəkənin (Largest Contentful Paint) başlanğıc nöqtəsi olduğundan, sürətli mənbə bütün sonrakı göstəricilərə başqa cür əldə edə bilməyəcəkləri ilkin ü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: optimallaşdırılmamış qəhrəman şəkli, renderi bloklayan CSS və JavaScript, şriftlər və reklamlar yüklənməyən zaman sürüşən tərtibat və plaginlərin əsas axındakı ağır işi. Heç bir server keşi 2 MB-lıq qəhrəman şəklini və ya meqabaytlarla JavaScript daşıyan temanı düzəldə bilməz. Dürüst hostinq serverin töhfəsini faktiki olaraq pulsuz və sabit edir, bundan sonra isə ön hissəni yüngül saxlamaq saytın öhdəsinə düşür.

Əmək bölgüsünün bu prinsipi faydalı bir zehni modeldir. Biz sorğunun brauzerə sürətlə çatmasını və trafik altında sürətli qalmasını təmin edirik; siz isə payload həcmini kiçik və stabil saxlayırsınız. İkisinin kəsişdiyi nöqtə — keşin ilkin doldurulması, kənar çatdırılma (edge delivery) və dinamik səhifələrin dayanmaması üçün verilənlər bazasının operativ saxlanılması — məhz stekimizin tənzimləndiyi yerdir və bu platformada idarə olunan WordPress saytını ümumi hostinqdəki eyni saytdan daha sürətli edən də məhz budur.

Tez-tez verilən suallar

WP Rocket kimi keşləmə plaginə hələ də ehtiyacım varmı?

Xeyr. Tam səhifə keşlənməsi veb-serverdə LiteSpeed məhsulunun LSCache modulu tərəfindən idarə olunur və əvvəlcədən quraşdırılmış və avtomatik yenilənən öz keş pliginimiz WordPress sistemini ona düzgün şəkildə qoşur, arxa fonda isə hər sayt üçün ayrılmış Redis obyekt kəşi işləyir. Bunun üzərinə ikinci bir tam səhifə keşlənməsi pliginini əlavə etmək kömək etməkdənsə, adətən server səviyyəsindəki keşlə ziddiyyət təşkil edir, buna görə də ona ehtiyac yoxdur və tövsiyə olunmur.

Keşləmə mənim WooCommerce səbətimi və ya daxil olunmuş səhifələrimi pozacaqmı?

Xeyr. Səbət, sifariş, hesabım səhifələri və istənilən nonc və ya sessiya səhifələri standart olaraq keşa daxil edilmir və ESI keşilən digər səhifələrdə səbət fraqmentini və yekunları aktiv saxlayır. Alıcılar mağazanın ön hissəsi hələ də keşdən yükləndiyi halda həmişə öz səbətlərini və işlək ödəniş səhifəsini görürlər.

Mən nəşr edəndə və ya redaktə edəndə keş necə təzə qalır?

Ağıllı avtomatik təmizləmə müvafiq WordPress hook-larında işə düşür, ona görə də məzmunun dərc edilməsi, redaktəsi və ya məhsulun, qiymətin və ya sifarişin dəyişdirilməsi bütün keşi deyil, yalnız təsirlənmiş səhifələri və onların arxivlərini təmizləyir və skaner onları yenidən qızdırır. Siz həmçinin idarə panelindən və ya WordPress daxilindən tələb əsasında təmizləyə bilərsiniz.

Yalnız hostinq mənə mükəmməl Core Web Vitals verə bilərmi?

O, server payı olan və Ən Böyük Məzmunlu Boyama üçün başlanğıc üstünlüyü qazandıran mümkün olan ən yaxşı TTFB-ni təmin edir. Lakin LCP, CLS və INP əsasən səhifənin özü tərəfindən müəyyən edilir — şəkil ölçüləri, renderi bloklayan resurslar, səhifə düzəninin sabitliyi və əsas axındakı JavaScript. Bizim stek serverin töhfəsini sürətli və sabit edir; front-end payını yüngül saxlamaq isə qalan fərqi aradan qaldıran amildir.

Əlaqədar

14 gün ərzində pulsuz sınayın

İLK 14 gün ərzində ilk saytlarınızı pulsuz yaradın — kart tələb olunmur. Mövcud şəbəkəni köçürürsünüz? İlk miqrasiya xərcini biz qarşılayırıq.

Pulsuz başlayın