Veb saytın yavaşlığının əsas səbəbi adətən tək bir şəkil deyil, əksinəMüraciət yönləndirmə + server tərəfində yaradılma + statik resurs çatdırılmasıÜst-üstə düşmədən yaranan:
- İstifadəçilər serverinizdən çox uzaqdadır, nəticədə şəbəkə RTT dəyəri yüksək olur (bu, qitələrarası əlaqədə daha çox nəzərə çarpır)
- WordPress hər bir sorğu üçün PHP işlətməli, verilənlər bazasına sorğu göndərməli və şablonu render etməlidir → TTFB (Birinci bayta qədər vaxt) artıb.
- Səhifə həmçinin JavaScript, CSS, şriftlər və üçüncü tərəf skriptlərini yükləməlidir ki, bu da renderlənməni və qarşılıqlı əlaqəni ləngidir.
Keşləmə plaginBu problemin həllinin açarı “təkrar hesablama” tələb edən səhifələrin nəticələrini saxlamaqdır ki, server onları hər dəfə yenidən hesablamağa məcbur qalmasın; həmçinin uyğun strategiyalar tətbiq etməklə daha çox istifadəçinin keşdən yararlanmasını təmin edib TTFB-ni əhəmiyyətli dərəcədə azaltmaqdır.WordPress Rəsmi SənədləşdirməO həmçinin W3 Total Cache və WP Super Cache kimi plaginlərin səhifələri statik fayllar şəklində keşləyib birbaşa istifadəçilərə təqdim etməklə server yükünü azalda biləcəyini göstərir.
Bu səhifəni oxumazdan əvvəl bu üç qızıl qaydanı yadda saxlayın
1. Eyni anda yalnız bir səhifə keşləmə plagini istifadə edin
Birdən çox keşləmə plagini eyni anda aktivləşdirildikdə, ən çox rast gəlinən nəticə daha sürətli performans deyil, əksinə:
- Kəşlərin üst-üstə düşməsi, kəşlərin bir-birini üst-üstə yazması və kəş uğur nisbətinin azalması
- Giriş statusu, dil, alış-veriş səbəti və qiymətlər kimi dinamik məzmun keşlənir, bu isə “səhv məzmun” xətalarına səbəb olur.
Bir çox plugin sənədləşməsi və təlimatlar müəyyən bir keşləmə pluginından istifadə edərkən,Digər keşləmə plaginslərini deaktiv edinMünaqişənin qarşısını almaq üçün.
2. E-ticarət/Üzvlük/Çoxdilli Saytlar: Keşləmə “aç-söndür düyməsi” deyil, “qaydalar sistemi'dir”
WooCommerce Rəsmi Performans SənədləşdirilməsiZəhmət olmasa nəzərə alın: keşləmə plaginində təmin edin ki Alış səbəti / Ödəmə / Hesab Bu səhifələrin keşlənmədiyinə əmin olun və JavaScript fayllarının minifikasiyadan qaçınmasını tövsiyə edirik (çünki bu, asanlıqla uyğunluq problemlərinə səbəb ola bilər).
3. “Keşləmə plagini ≠ CDN”, lakin keşləmə plagini CDN-nin təməlini təşkil edir.
Kəşləmə plaginı mənbə serverdə az sayma problemini həll edir;CDN Həll məzmunu istifadəçilərə daha yaxın gətirməkdir. Bu iki yanaşma bir-birini tamamlayır: əvvəlcə mənbə serverin TTFB-sini azaltmaq, sonra statik resursları CDN vasitəsilə paylamaq. Bu, dünya üzrə istifadəçilərə xidmət göstərməyin ən etibarlı yoludur.
Sürətli Seçim: Vebsaytların 4 ən yayılmış ssenarisi
Əgər bütün məqaləni oxumaq istəmirsinizsə, sadəcə aşağıdakı dörd seçimdən birini seçin—yanılmayacaqsınız:
- Ruhi rahatlıq, etibarlılıq və qlobal əlçatanlıq axtarıram → WP Rocket(Ödənilmiş)
- Server mütləq LiteSpeed/OpenLiteSpeed ilə işləyir. → LiteSpeed Kəş(Pulsuz, lakin server tutumundan çox asılıdır): Kəşləmə funksionallığı tələb olunur LiteSpeed server komponentləriişləyə bilmək
- Məzmun saytları/bloglar/sənəd anbarları pulsuz və etibarlı həll axtarır → WP Super Cache(Statik HTML keşlənməsi)Sistemə daxil olmamış əksər istifadəçilər üçün statik HTML faylları yaradın
- Sizin texniki komandanız var və dəqiq nəzarət (CDN/obyekt keş/bir neçə modul) həyata keçirməyə ehtiyacınız var → W3 Ümumi Keş(Güclü, lakin mürəkkəb)Əhatəli performans çərçivəsi və CDN inteqrasiyası ilə
Keş dəqiq nəyi keşləyir?
“Niyə bəzi vebsaytlar keş quraşdırdıqdan sonra belə hələ də yavaşdır?” Biz WordPress performansını beş qatda təhlil etmişik:
- Brauzer keşiİstifadəçilər üçün sonrakı ziyarətləri daha sürətli edin (statik resurslar üçün keş başlıqları, versiya nömrələri)
- Səhifə keşləmə: Səhifənin çıxışını HTML kimi keşləyin (bu səhifənin diqqət mərkəzidir)
- Obekt keş: Verilənlər bazası sorğularının nəticələrinin keşlənməsi (xüsusilə dinamik vebsaytlar üçün dəyərlidir)
- PHP OPcache: Bytekodun PHP baytını keşləyin (adətən server tərəfindən konfiqurasiya olunur; plaginin əsas xüsusiyyəti deyil)
- CDN/Kənar keş: Resursları istifadəçilərə daha yaxın olan düyünlərə yerləşdirin
Bu məqalə aşağıdakılara fokuslanır: səhifə keşləmə plaginləri;
Amma biz sizə xatırlatmağa davam edəcəyik: vebsaytlar “həqiqətən sürətli” olmaq üçün çox vaxt 2 və 5-in kombinasiyasına ehtiyac duyur.
Plugin 1:WP Rocket(Ödənişli) — “Dərdsiz” hərtərəfli həll
WP Rocket WordPress icmasında sehirli olduğu üçün deyil, performans optimallaşdırmasının ən çox yayılmış üç növünü “idarəolunan paketlər” şəklində bir araya gətirdiyi üçün populyardır:
- Səhifə keşləmə (mənbə serverin TTFB-sini azaltmaq)
- Kəşin öncədən yüklənməsi/isitilməsi (dünyanın müxtəlif yerlərindən sayta daxil olan istifadəçilərin ilk ziyarət təcrübəsini yaxşılaşdırmaq üçün)
- Əsas front-end optimallaşdırmaları (xüsusilə JS-in təxirə salınması, CSS emalı və s.)

onunRəsmi sənədlərHəmçinin açıq şəkildə bildirilir ki, səhifə keşləməsini söndürsəniz belə, ön yükləməni aktivləşdirmək hələ də müəyyən optimallaşdırma proseslərini (məsələn, CSS və JavaScript ilə bağlı optimallaşdırmaları) işə sala və ya idarə edə bilər.
1.1 WP Rocket kimlər üçün uyğundur?
WP Rocket xüsusilə aşağıdakı növ vebsaytlar üçün uyğundur:
- Korporativ vebsaytlar, brend vebsaytları, məzmun marketinqi saytları, landing səhifələri (bir neçə ölkə və regiondan trafik)
- Mən sabitliyi ən yüksək prioritet tutan sürətli işə salışı, pulsuz plaginslər qarışığına güvənməkdən daha üstün tuturam.
- Bizdə xüsusi əməliyyat və ya performans mühəndisi yoxdur, lakin istifadəçi təcrübəsi və SEO ilə bağlı tələblərimiz var.
- Vuçkomers Onu istifadə etmək olar, lakin daha ehtiyatla (bu bölmədə sonra müzakirə olunacağı kimi)Qaydalar və risklər)
1.2 Vebsayt gəzintisi ssenarilərində onun əsas dəyəri (yalnız “keş açma/söndürmə” funksiyasından daha çox)
A. Kəşin əvvəlcədən yüklənməsi: Paylanmış vebsayt trafiki səbəbindən ilk ziyarətlər zamanı yaranan sabitlik problemlərinin həlli“
Vebsayt istifadəçiləri müxtəlif yerlərdə olduqda, çox yayılmış bir yavaşlıq növü ilə qarşılaşacaqsınız:
Belə bir bölgədəki istifadəçi bir səhifəni ilk dəfə açdıqda və həmin səhifənin keş müddəti bitmişdirsə və ya əvvəlcədən yüklənməmişdirsə, o istifadəçi PHP/DB-nin tam render xərci ilə üzləşir.
Əvvəlcədən yükləmə mexanizmiMənası budur:“İlkin tikinti” xərclərini əvvəlcədən ödəyin, beləliklə ilk dəfə gələn ziyarətçilərin təcrübə siçanları kimi müalicə olunma ehtimalını azaldır.
- Ön yükləmə yoxdur: kim əvvəl gəlirsə, ona verilir
- Əvvəlcədən yükləmə: Sistem arxa planda mərkəzləşdirilmiş şəkildə keşlənmiş məzmunu yaradır və ilk dəfə ziyarət edənlər üçün daha sabit təcrübə təmin edir.
B. JavaScript icrasını gecikdirmək: Bu, istifadəçi təcrübəsinə ən dərhal nəzərə çarpan yaxşılaşmanı təklif edən xüsusiyyətdir, lakin eyni zamanda ən böyük riski daşıyır.
WP Rocket rəsmi olaraq “JavaScript icrasını gecikdirin”Ən güclü JavaScript optimallaşdırması kimi təsvir olunur: istifadəçi səhifə ilə qarşılıqlı əlaqə qurana qədər (siçanı hərəkət etdirərək, ekrana toxunaraq, sürüşdürərək, düyməni basaraq və s.) skriptin icrasını təxirə salır, beləliklə səhifə əvvəlcə göstərilir.
Bu, vebsaytın performansını yaxşılaşdırmaq üçün vacibdir, çünki skriptlərin yüklənməsi və icrasının bloklanması qitələrarası şəbəkələrdə daha asan güclənə bilər:
- Resurs yükləmələri bir az yavaşdır → Əsas iplik skriptlərlə daha çox yüklənə bilər
- Üçüncü tərəf skriptləri (məsələn, analitika, reklam və söhbət plaginləri) INP-ni və qarşılıqlı əlaqə gecikməsini daha da pisləşdirməyə meyllidir.
Lakin bu da bəzi problemlərə səbəb ola bilər:
- JavaScript-də gecikmələr ehtimal ki, menyular, karuselər, pop-uplar, formaların yoxlanılması, ödənişlər və izləmə kodu tətbiqinə təsir edəcək.
- Bu səbəbdən o, “addım-addım + qara siyahı istisnası” strategiyasına yaxşı uyğundur.
C. Digər plaginlər/tematlarla uyğunluq: Problemsiz olmaq “sıfır toqquşma” demək deyil.”
WP Rocket xüsusi olaraq “Uyğun gəlməyən plaginlər/təqdimatlar”siyahı, çünki bu, WP Rocket-in keşləmə və optimallaşdırma mexanizmlərinə, məsələn çıxış buferləşdirməsinə təsir edə bilər.
- Əgər veb saytınızda çoxsaylı plagınlar və resurs-yoğun mövzu varsa, “performans optimallaşdırmasını” kiçikmiqyaslı yerləşdirmə layihəsi kimi qəbul edin: hər dəyişiklikdən sonra (formalar, giriş, ödəniş, dil dəyişimi və s.) geriləmə testləri aparın.
1.3 WooCommerce və dinamik vebsaytlarla bağlı xüsusi qeydlər
Keş plaginini konfiqurasiya edərkən rəsmi WooCommerce sənədlərində vurğulanmış əsas məqam budur:
- Alış səbəti / Ödəmə / Hesab Keşləməyin
- və tövsiyə edirJavaScript fayllarını kiçiltməkdən çəkinin
Niyə?:
- Alış səbəti, kassaya keçid və hesab səhifələri cookie / sessiya / nonce-dən güclü şəkildə asılıdır.
- Keş bu səhifələri “statik səhifələr” kimi qəbul etdikdə nəticələr düymələrin işləməməsindən tutmuş ən pis hallarda qiymətlərdə, stok səviyyələrində və ya hesab məlumatlarında uyğunsuzluqlara qədər dəyişə bilər.
- Ən pis tərəfi odur ki, bir bölgədə hər şeyin qaydasınca işlədiyini görə bilərsiniz, ancaq CDN və ya keş zərbələrindəki fərqlər səbəbindən başqa bir bölgədə problemlər yarana bilər.
1.4 Kəş plugin siyasətləri üçün tövsiyələr
Səviyyə 1: Əsas təhlükəsizlik tədbirləri (demək olar ki, hər vebsaytın tətbiq etməli olduğu)
- Səhifə keşləməni aktivləşdirin
- AçıqKəşin əvvəlcədən yüklənməsi(İlk dəfə ziyarət edənlər üçün sabitliyi yaxşılaşdırmaq)
- Ağıllı brauzer keş strategiyası (WP Rocket, server və ya CDN səviyyəsində tətbiq oluna bilər)
2-ci səviyyə: Orta gəlir, orta risk (əksər məzmun saytları üçün uyğundur)
- Şəkillərin tənbəl yüklənməsi / iframe (Şəkil optimallaşdırılmasına daha dərindən baxış)
- CSS faylının ölçüsünü idarə edin (məsələn, istifadə olunmayan CSS-i silməklə)
3-cü səviyyə: yüksək gəlir, lakin yüksək risk (geri test yoxlama siyahısı daxil edilməlidir)
- JavaScript icrasını təxirə salın (renderləməni üstün tutun, lakin bu interaktivliyə təsir edə bilər)
- JS/CSS minifikasiyası/birləşdirilməsi: Elektron ticarət, üzvlük və çoxdilli saytlarda xüsusilə ehtiyatlı olun (WooCommerce həmçinin JavaScript minifikasiyasının riskləri barədə də xəbərdar edib.)
1.5 Qiymətləndirmə və lisenziyalaşdırma
- WP Rocket ödəməli lisenziya modelinə əsaslanır, saytların sayından asılı olaraq müxtəlif lisenziyalar mövcuddur.
Plugin 2:LiteSpeed Cache (LSCWP)“Pulsuz yüksək səviyyə” təklifi yalnız server həqiqətən LiteSpeed işlədikdə keçərlidir.

LiteSpeed Cache haqqında geniş yayılmış yanlış təsəvvür ondan ibarətdir ki, o, quraşdırıldıqdan sonra istənilən hosting platformasında WP Rocket qədər effektiv işləyəcək. Əslində isə bu belə deyil.
LiteSpeed Rəsmi SənədləşdirməAydın olsun: LSCWP-nin keş funksionallığının LiteSpeed Server-ə ehtiyacının səbəbi onun LiteSpeed Web Server-in daxili səhifə keş funksiyası (LSCache) ilə ünsiyyət qurmasıdır; plagin serverə hansı səhifələrin keşlənə biləcəyini, nə qədər müddətə keşlənəcəyini bildirmək və etiketlərdən istifadə edərək təmizləməni işə salmaq məsuliyyətini daşıyır.
LiteSpeed Cache-in əsas üstünlüyü “Server tərəfində səhifə keşləməsi (LSCache)”LiteSpeed/OpenLiteSpeed serverləri olmasaydı, bu əsas üstünlük mövcud olmazdı.
2.1 LiteSpeed KəşBu kim üçün uyğundur?
Uyğun gəlir:
- Sizin hosting idarəetmə panelinizdə açıq-aydın göstərilir LiteSpeed / OpenLiteSpeed(Məsələn, bir çox cPanel serveri bunu göstərəcək)
- Siz pulsuz planın əla TTFB və eyni anda çoxsaylı əməliyyatları işləmə qabiliyyətini təmin etməsini istəyirsiniz.“
- Bunu qəbul etməyə hazırsınızmı ki, o çox güclü olsa da, bir çox texniki anlayış (TTL, Tag, Purge, ESI, Crawler…) da özündə birləşdirir?
Xüsusi olaraq uyğun deyil:
- Siz hostun hansı veb serverdən istifadə etdiyini bilmirsiniz, ya da onun Nginx və ya Apache olduğunu təsdiqləmisiniz (yalnız bəzi front-end optimallaşdırma xüsusiyyətlərindən istifadə etmək istəyirsinizsə, bu halda xərci-səmərəliliyi və mürəkkəbliyi bəlkə də buna dəyər olmaya bilər)
- Sizdə mürəkkəb e-ticarət/üzvlük/çoxdilli sayt var, amma test prosesi yoxdur (LSCWP güclüdür, amma səhv məzmunu keşləməyə daha meyllidir)
2.2 Onun keşləmə mexanizmi: niyə bu serverin imkanlarının bir hissəsinə daha çox bənzəyir“
LiteSpeed Cache-in necə işlədiyini tək bir “texniki izah” şəklində belə xülasə edə bilərsiniz:
- WP Rocket / WP Super Cache Bu əsasən WordPress/PHP tərəfində keşləmə və optimallaşdırmanı əhatə edir;
- LSCWP Bu, “WordPress idarəetmə paneli + LiteSpeed Server-in daxili LSCache”-nin birləşməsidir: plagin qaydaların tətbiqi və siqnalların təmizlənməsi ilə məsuliyyət daşıyır, əsl yüksək sürətli səhifə keşləməsi isə baş verirServer qat。
Bu, istifadəçi təcrübəsinə birbaşa təsir göstərir: server tərəfində keşləmə ümumiyyətlə daha yüngül, daha sürətli və eyni vaxtda daxil olan sorğuları (xüsusilə trafikdə qəfil artımlar və ya axtarış motoru robotlarının tez-tez ziyarətləri zamanı) daha yaxşı idarə edə bilir.
2.3 Vebsayt istifadəçisi kontekstində LSCWP-dən istifadə etməyin “düzgün yolu”
Biz “düzgün yanaşmanı” dörd səviyyəyə bölmüşük:
Qat 1: Səhifə keşləmə strategiyası (TTFB-nin həqiqətən azaldılıb-azaldılamayacağını müəyyən edir)
- Hansı səhifələrin keşlənə biləcəyini göstərin (əksər ictimai məzmun səhifələri)
- Heç vaxt keşlənməməli səhifələri göstərin (giriş, hesab, alış-veriş səbəti, ödəmə və dil/valyuta dəyişimi üçün cookie-dən çox asılı olan səhifələr)
- Kəş üçün məqbul TTL təyin edin (məzmun nə qədər tez-tez yenilənirsə, TTL bir o qədər qısa; əksinə, bir o qədər uzun olmalıdır)
- Təmizlik siyasəti yaradın: məzmun yeniləndikdən sonra müvafiq teqləri təmizləyin (sayt üzrə ümumi təmizlik aparmaq əvəzinə)
Əgər bu qat düzgün icra olunarsa, veb sayt üçün ən dərhal fayda TTFB azalıb və ilk ekran yüklənməsi daha sabitdir.。
Qat 2: Öncədən yükləmə/bot gəzintisi (az trafikli səhifələrə ilk ziyarətin yavaş olub-olmadığını müəyyən edir)
Veb saytlarda “uyğun olmayan istifadəçi təcrübəsi”nin yayılmış səbəbi “isti-soyuq keş fərqlilikləri”ndən qaynaqlanır:
- Populyar səhifələr daim ziyarət olunduğu üçün keş həmişə yenilənmiş qalır.
- Çox trafiki olmayan səhifələr uzun müddətdir laqeyd qalıb, ona görə də ilk dəfə ziyarət edənlər üçün çox yavaş yüklənir.
Ön yükləmə sadəcə tortun üzərinə çəkilən bəzək deyil; vebsaytda ardıcıl istifadəçi təcrübəsini təmin etməyin açarıdır.
Qat 3: Dinamik məzmun üçün təhlükəsizlik həlləri (e-ticarət/üzvlük/çoxdilli)
LSCWP-nin gücü ondadır ki, o sizə aşağıdakı kimi geniş çeşiddə “qabaqcıl alətlər” təqdim edir:
- Sistemə daxil olmuş istifadəçilər, şərhçilər və s. üçün fərqləndirilmiş keş strategiyaları.
- Edge-Side Inclusion (ESI)-nin əsas konsepti səhifəni 'keşlənə bilən ortaq bədən' və 'keşlənməyən dinamik parçalar'a bölmək, onları ayrı-ayrılıqda emal etmək və sonra kənar düyünündə yenidən birləşdirməkdir.
Qat 4: Onlayn xidmətlər və seçməli təkmilləşdirmələr
Bir çox vebsayt administratoru LSCWP daxilində QUIC.cloud-nin onlayn xidmətləri (məsələn, səhifə optimallaşdırma xidmətləri) ilə qarşılaşacaq.QUIC.cloud sənədləşdirməAçıq şəkildə bildirilir ki, o, LSCWP-yə səhifə optimallaşdırma xidmətləri təqdim edir, o cümlədən Kritik CSS (CCSS), Unikal CSS (UCSS) və Görünüş Sahəsinə Optimallaşdırılmış Şəkillər (VPI).
- Bu xidmətlər könüllüdürOnlayn optimallaşdırmanı aktivləşdirmədən yalnız server tərəfində keşdən istifadə edə bilərsiniz.
- Onlayn xidmətlər aktivləşdirildikdən sonra saytınızın resursları və səhifələri üçün emal axını dəyişəcək (bu, bizneslər və məxfiliyə önəm verən müştərilər üçün vacib məlumatdır)
2.4 LSCWP-də ümumi səhvlər
- Server LiteSpeed-də işləmir, amma LSCWP-ni tam funksiyalı keşləmə plagin kimi qəbul edir.
Nəticə: Kəşlənmə gözlənildiyi kimi işləmədi və konfiqurasiyanın mürəkkəbliliyini də artırdı. Həll: İlk növbədə host yığınını yoxlayın; əgər o deyil Ləngər sürəti... WP Rocket və ya WP Super Cache-i nəzərdən keçirin. - Çoxlu front-end optimallaşdırmalarının aktivləşdirilməsi funksionallıq problemlərinə səbəb olub.
Səhifə optimallaşdırması (CSS/JS) çox vaxt keşləmədən daha asan uyğunluq problemlərinə səbəb olur. Tövsiyə: Əvvəlcə səhifə keşləməsinin problemsiz işlədiyinə əmin olun, sonra optimallaşdırmaları bir-bir aktivləşdirin və geriləmə testinin yoxlama siyahısını (formalar, menyular, ödəniş, izləmə, dil dəyişimi və s.) tərtib edin. - Dəyişkən səhifələr üçün istisna/şardinq strategiyalarının olmaması
Ümumi problemlər: alış səbətləri, ödəmə səhifələri və hesab səhifələrinin keşlənməsi; yaxud dillər və ya valyutalar arasında düzgün olmayan keçidlər. E-ticarət saytları bunu işə salmadan əvvəl yoxlama kimi qəbul etməlidir (WooCommerce-in də vurğuladığı kimi).Vacib səhifələri keşləməyin)。
Plugin 3:WP Super Cache(Pulsuz) — Kontent saytları üçün klassik “aşağı riskli, yüksək gəlirli” strategiya

WP Super Cache Niyə bu bu qədər uzun müddətdir populyar qalıb? Çünki o, problemləri çox sadə, “server-dostu” şəkildə həll edir:
Dinamik WordPress səhifələrini statik HTML fayllarına çevirin...ondan sonra veb server bu HTML fayllarını birbaşa təqdim edir və beləliklə bahalı PHP emalını atlayır.
Plugin səhifəsində həmçinin qeyd olunur ki, autentifikasiya edilməmiş istifadəçilərin böyük əksəriyyətinə statik HTML təqdim olunur və çox aydın izah verilir: “99% ziyarətçilərə statik HTML faylları təqdim ediləcək”; tək bir keşlənmiş fayl minlərlə dəfə təqdim oluna bilər.
3.1 WP Super Cache kimlər üçün uyğundur?
Çox tövsiyə olunur:
- Bloglar, məzmun saytları, sənədləşdirmə saytları, korporativ veb-saytlar, açılış səhifələri
- Ziyarətçilər əsasən sistemə daxil olmamış istifadəçilərdir.
- Siz istəyirsiniz: pulsuz, sabit və aşağı texniki xidmət xərcləri
Diqqətlə istifadə edin / Daha möhkəm strategiya tələb olunur:
- Yüksək dinamik vebsaytlar: çoxlu fərdiləşdirilmiş məzmuna malik və istifadəçinin statusuna görə dəyişən səhifələri olan vebsaytlar
- Böyük e-ticarət platformaları: Bu qəbul ediləndir, lakin əsas səhifələrin keşlenmədiyinə və bunun sınaq prosesinizə inteqrasiya olunduğuna əmin olun.
3.2 Onun üç keşləmə üsulu:
WP Super Cache plagininin təsviri sürət sırasına görə üç keşləmə üsulunu sadalayır və onların arasındakı fərqləri izah edir:
- mod_rewrite (Mütəxəssis)Ən sürətli üsul PHP-ni tamamilə yan keçir, lakin .htaccess faylının dəyişdirilməsini tələb edir; düzgün konfiqurasiya edilmədikdə saytın əlçatmaz olma riski artır.
- Sadə (tövsiyə olunan üsul)PHP statik fayllar üçün “super keş” təmin edir, mod_rewrite-in sürətlərinə yaxın sürətlər təklif edir, lakin konfiqurasiyası daha asandır.
- WP-Cache keşləməDaha çevik, tanınmış istifadəçilər, parametrli URL-lər, lentlər və s. üçün uyğundur, lakin daha yavaşdır
Tövsiyə olunan seçimlər:
- Başlayanlar/Sabitlik axtaranlar: Tövsiyə olunan (sadə) üsuldan istifadə edin
- Əgər server qaydaları ilə çox yaxından tanışsınızsa və onları yenidən yazmaq riskini götürməyə hazırsınızsa, o zaman Ekspert Rejimini nəzərdən keçirin.
- “Məlum istifadəçilər/parametrlər'in daha çevik idarə edilməsinə ehtiyacınız var: WP-Cache-in rolunu anlamaq
3.3 WP Super Cache-in güclü və zəif tərəfləri
Üstünlüklər:
- CDN ilə istifadəsi üçün idealdır
Əsasən “statik HTML yaradılmasını” əhatə etdiyindən, bu təbii olaraq CDN/edge keşləmə yanaşması ilə üst-üstə düşür. - Mənbə serveri CPU və verilənlər bazasının yüklənməsindəki yaxşılaşma çox nəzərə çarpır.
Vebsayt trafiki yayğın olduqda, axtarış motoru və sosial media robotları da dünyanın hər yerindən gələ bilər. Statikləşdirmə “təkrar renderləmə” ilə mübarizədə son dərəcə effektivdir.
Zəifliklər:
- Bu, hər şeyi əhatə edən performans optimallaşdırma paketi deyil.“
Onun əsas gücü səhifə keşləməsindədir; WP Rocket-dən fərqli olaraq, CSS və JavaScript üçün dərin optimallaşdırmalar paketini təklif etmir. Sizə “Şəkil Optimizasiyası” və “Front-end Optimizasiyası” səhifələri vasitəsilə əlavə optimallaşdırmalar aparmaq lazım gələ bilər (və ya digər plaginslərdən və ya mövzu səviyyəli optimallaşdırmalardan istifadə edin). - Biz “dinamik fərdiləşdirmə” ilə bağlı daha ehtiyatlı olmalıyıq.
Məsələn, bölgəyə görə fərqli məzmun göstərmək, yaxud istifadəçi statusuna əsasən fərqli qiymətlər, dillər və ya tövsiyələr təqdim etmək. Belə hallarda istisna qaydaları müəyyən etməli və ya daha uyğun bölünmüş keşləmə həllini tətbiq etməlisiniz.
3.4 WooCommerce Uyğunluğu: Niyə Daha “Təhlükəsiz'dir”
Rəsmi WooCommerce sənədləriQeyd etmək lazımdır ki, WooCommerce WP Super Cache ilə doğma uyğunluğa malikdir və WooCommerce WP Super Cache-ə siqnal göndərir ki, Səbət, Ödəmə və Mənim Hesabım səhifələri standart olaraq keşlənməsin.
- Hətta yeni başlayan olsanız belə, WP Super Cache və WooCommerce-in kombinasiyası “kritik səhifələrin keşlənməsi” tələsinə düşməyinizin ehtimalını azaldır.
- Lakin biz hələ də işə salınmadan əvvəl (ödəniş, kuponlar, çatdırılma haqları, vergi dərəcələri, çoxlu valyutalar və s. daxil olmaqla) geriləmə testinin aparılmasını tövsiyə edirik.
Plugin 4:W3 Total Cache (W3TC)— Mühəndislik komandaları üçün ideal olan ən əhatəli “səmərəlilik çərçivəsi”

W3 Ümumi Keş WordPress.org-da bu, “tək bir keşləmə plagini” kimi deyil, daha çox “sayt performansının optimallaşdırılması çərçivəsi” kimi təqdim olunur: o, CDN inteqrasiyası və ən yaxşı təcrübələr vasitəsilə SEO-nu, Core Web Vitals-ı və ümumi istifadəçi təcrübəsini yaxşılaşdırmağı vurğulayır.
Plugin təsviri geniş imkanlar spektrini sadalayır: səhifə/ səhifə/yazının keşlənməsi, CSS/JS keşlənməsi, lent keşlənməsi, axtarış nəticələrinin keşlənməsi, verilənlər bazası obyektlərinin keşlənməsi, obyekt keşlənməsi, fraqment keşlənməsi və Redis, Memcached və APC kimi müxtəlif keşləmə üsullarını dəstəkləməyi. Həmçinin istifadəçi agenti və refererə görə qruplaşdırılmış mobil keşləmə, AMP dəstəyi və tərs proxy (Nginx/Varnish) inteqrasiyasını da əhatə edir.
4.1 W3 Total Cache kimlər üçün uyğundur?
Üçün idealdır:
- Sizdə inkişaf və əməliyyat bacarıqları var və addım-addım yerləşdirmə, yük testləri və geriləmə testlərini həyata keçirməyə hazırsınız.“
- Sizin saytınız mürəkkəbdir: o, çoxsaylı dilləri, mövzu dəyişməsini, mobil üçün xüsusi optimallaşdırmanı və mürəkkəb məzmun strukturunu əhatə edir.
- Siz yalnız səhifə keşləməsini tətbiq etmək istəmirsiniz, həm də obyekt keşləməsini və fragment keşləməsini (xüsusilə dinamik vebsaytlar üçün) sistemə daxil etmək istəyirsiniz.
Uyğun deyil:
- Siz onun qutudan çıxarar-çıxmaz sürətli olmasını istəyirsiniz və keş pillələndirməsini başa düşməyə məcbur olmaq istəmirsiniz.
- Sizin test prosesi yoxdur, amma kompressiya və gecikdirilmiş skriptlər kimi yüksək riskli funksiyaları bir anda aktivləşdirmək istəyirsiniz.
4.2 Niyə bu “güclü, lakin mürəkkəb” kimi təsvir olunur? Veb saytlar “idarəolunma'ya üstünlük verirlər”
W3TC-nin dəyəri onun “mütləq başqalarından daha sürətli olması”nda deyil, əksinə sizə performans strategiyanızı mühəndislik çərçivəsinə çevirməyə imkan verən kifayət qədər idarəetmə seçimi təqdim etməsindədir:
- Səhifə keş: yaddaşda, diskin üzərində və ya 1TB–220TB həcmli yaddaşda saxlanıla bilər
- Verilənlər bazası obyektlərinin keşlənməsi, obyekt keşlənməsi: Redis, Memcached və s. istifadə oluna bilər.
- Fragment keşləmə: xüsusilə “yarım dinamik səhifələr” üçün faydalıdır
- Mobil dəstək: Səhifələri referer və ya istifadəçi agent qrupu üzrə ayrı-ayrılıqda keşləyin
- CDN İdarəetmə: Media kitabxanalarının, mövzu fayllarının və s. şəffaf idarə edilməsi. CDN İdarəetmə
Bu imkanlar veb-saytlar üçün xüsusilə dəyərlidir, çünki qlobal trafik tez-tez rastlaşır:
- Fərqli cihazlarda, regionlarda və dillərdə eyni səhifənin variantları
- Bəzi məzmun keşlənə bilər, digər məzmun isə real vaxtda yenilənməlidir (məsələn, qiymətlər, stok səviyyələri, istifadəçi statusu)
4.3 W3TC-nin “Tövsiyə olunan aktivləşdirmə qaydası”
Tövsiyə olunan sıra:
- Üçüncül mərhələdə yalnız səhifə keşləməsini aktiv edin.
Təsdiqlə: TTFB-nin azaldığını, məzmunun ardıcıl olduğunu və giriş vəziyyətinin, çoxdilli funksionallığın və əsas e-ticarət iş axınlarının düzgün işlədiyini. - Brauzerin keşini yenidən aktivləşdirin
Məqsəd: Səhifələrin yenidən yüklənməsini və statik resursların yüklənməsini sürətləndirmək, həmçinin qitələrarası artıq yükləmələri azaltmaq. - Obekt keşini / verilənlər bazası obekt keşini yenidən qiymətləndirin
Uyğun gəlir: Dinamik vebsaytlar (WooCommerce, üzvlük sistemləri, mürəkkəb sorğular).
Tətbiq olunmur: Təmiz məzmunlu saytlar məhdud gəlir əldə edə bilər və hətta resurs istifadəsini artıra bilər. - Nəhayət, sıxılma, skriptlərin təxirə salınması və ön tərəf optimallaşdırmasını həyata keçirin.
Bu qat funksional problemlərə ən çox meylli olduğundan, geriləmə testinin yoxlama siyahısı tərtib edilməlidir (ödənişlər, formalar, izləmə, pop-uplar, menyular, dil dəyişimi və s.).
WooCommerce “keş plagin konfiqurasiyası” ilə bağlı xatırlatmaKritik səhifələri keşləməyin və JavaScript fayllarını minimallaşdırmaqdan çəkinməyiniz tövsiyə olunur.
Dörd plagin müqayisə matrisi
Zəhmət olmasa nəzərə alın: bu “kim daha güclüdür” barədə deyil, daha çox “kim sizin vəziyyətinizə daha uyğundur” barədədir.
| ölçü | WP Rocket | LiteSpeed Kəş | WP Super Cache | W3 Ümumi Keş |
|---|---|---|---|---|
| Əsas mövqeləşdirmə | Hər şeyi əhatə edən həll (keşləmə + optimallaşdırma) | Server səviyyəli keşləmə (LSCache-dən istifadə etməklə) | Statik HTML keşlənməsi | Performans çərçivəsi (çoxqatlı keş + 1TB + 220TB) |
| Host asılılığı | Aşağı (universal) | Yüksək (əsas keşləmədən istifadə etmək üçün LiteSpeed/OpenLiteSpeed tələb olunur) | Aşağı (universal) | Orta (universal, lakin daha çox mühitə/konfiqurasiya imkanlarına bağlı) |
| Öyrənmə xərcləri | Aşağıdan orta | Orta | Aşağı | Yüksək |
| Məzmun saytının tövsiyə xalı | çox yüksək | Çox yüksək (şərtlər yerinə yetirildiyi təqdirdə) | çox yüksək | Orta səviyyədən yüksək (komandadan asılı olaraq) |
| E-ticarət/Üzvlük saytı | İstifadə oluna bilər, lakin ehtiyatlı olun (WooCommerce əsas səhifələri keşlənmir) | Mövcuddur, lakin qaydalar/şardinq strategiyaları tələb olunur | Mövcuddur və WooCommerce bildirir ki, o, yerli olaraq uyğundur və əsas səhifələri standart olaraq keşləmir. | Mövcuddur; mühəndislik tətbiqləri üçün uyğundur |
| Büdcə | Ödə | Pulsuz | Pulsuz | Pulsuz + ödəməli versiyalar |
“Kəş hadisələri” və qarşısının alınması üçün yoxlama siyahısı
1. Keşləmə səbəbindən yaranan “düzgün olmayan məzmun'un üç əsas səbəbi
A. “Dövlətli” səhifələri “dövlətdən azad statik səhifələr” kimi müalicə etmək”
Məsələn: Hesab səhifəsi, alış səbəti və ödəmə səhifəsi keşlənir. WooCommerce Hakimiyyət orqanları dəfələrlə vurğulayıblar Alış səbəti / ödəmə / hesab səhifələri keşlənməməlidir.
B. Çoxdilli, valyuta və regional variantlar üçün keşləmə düzgün fərqləndirilmir.
Əgər saytınız cookie, sorğu parametrləri və ya coğrafi mövqeyə əsasən fərqli məzmun göstərirsə, keşləmə zamanı “variant ölçüləri” nəzərə alınmalıdır. Əks halda A regionundakı istifadəçi üçün yaradılan keş B regionundakı istifadəçi tərəfindən təkrar istifadə oluna bilər.
C. Front-end optimallaşdırması (JS/CSS) yenidən yazılması funksionallıq problemlərinə səbəb olub
Xüsusilə JavaScript-in minifikasiyası, paketlənməsi və tənbəl yükləmə. WooCommerce hətta tövsiyə edirJavaScript fayllarını kiçiltməkdən çəkinin。
2. Yerləşdirmədən əvvəlki geriləmə testi yoxlama siyahısı
- Giriş/çıxış funksiyası düzgün işləyirmi?
- Formaların göndərilməsi (əlaqə formaları, abunəliklər, giriş və qeydiyyat) düzgün işləyirmi?
- Elektron ticarət prosesi: Səbətə əlavə et → Vauçer → Çatdırılma haqları/vergilər → Ödəniş → Sifariş səhifəsi
- Dil dəyişdirmə funksiyası (məzmun, URL-lər, hreflang teqləri və valyuta baxımından) sabitdirmi?
- Mobil menyu, pop-uplar, sürüşmə və tənbəl yükləmə düzgün işləyirmi?
- İzləmə skriptlərinin (GA, Meta Pixel, konversiya hadisələri) hələ də işə salınıb-salınmadığını yoxlayın
Tez-tez verilən suallar
Q1: Xaricdən daxil olanda sayt hələ də niyə yavaşdır, baxmayaraq ki, mən keşləmə plaginini quraşdırmışam?
Ən çox rast gəlinən səbəb odur ki, siz yalnız “mənbə serverində təkrar renderləməni” həll etmisiniz, lakin “qitələrarası şəbəkə gecikməsini” aradan qaldırmamısınız.
Keşləmə plaginləri serverin məzmunu daha sürətli çatdırmasına imkan verir (TTFB-ni azaldır), lakin statik resurslar (şəkillər, CSS, JS, şriftlər) və qlobal əlaqələrin RTT-si hələ də tələb olunur CDN Fərqi aradan qaldırmaq üçün.
👉 Beləliklə, düzgün yanaşma belədir:Əvvəlcə, mənbə serverinin keşləməsinin düzgün işlədiyinə əmin olun,Qlobal paylanma üçün CDN-yə yükləyin。
Q2: Məzmun kəşlənmiş halda niyə yenilənmir?
Bu, “köhnə keş'i gördüyünüz üçündür. Həll:
- Kəş təmizləmə siyasəti yaradın: Bütün saytın kəşini təmizləmək əvəzinə, müvafiq yazı və ya səhifə yeniləndikdən sonra onun kəşini təmizləyin.
- Ön isitmə və ya sürünmə tələb edən həllər üçün: təmizləmədən sonra ön isitməni yenidən həyata keçirməlisiniz, yoxsa ilk ziyarət ləng olacaq.
- CDN ilə bağlı: nəzərə almaq lazımdır ki, CDN kənarı köhnə resursları da keşləyə bilər.
Q3: WP Rocket və WP Super Cache-i eyni vaxtda quraşdıra bilərəmmi?
Bu tövsiyə edilmir. Ən sabit performans üçün eyni anda yalnız bir səhifə keşləmə plagini istifadə etmək daha yaxşıdır. “Keşləmə üçün biri, optimallaşdırma üçün digəri” ideyasını “əmək bölgüsü” kimi başa düşə bilərsiniz, lakin praktikada onlar səhifə keşləməsinə və ya resursların yenidən yazılmasına müdaxilə edir və bu, toqquşma ehtimalını artırır. Əsas keşləmə plagininı seçib əlavə tələbləri həll etmək üçün daha ixtisaslaşmış, tək məqsədli alətlərdən istifadə etmək daha məqsədəuyğundur.
Q4: Elektron ticarət saytlarında keşdən istifadə risklidirmi?
Bu təhlükəli deyil; təhlükəli olan “qaydaların olmamasıdır”.WooCommerce tövsiyələriZəhmət olmasa nəzərə alın: alış səbəti, ödəmə və hesab səhifələri keşlənməməlidir, JavaScript sıxılmasından isə çəkinilməlidir.
Bundan əlavə, WooCommerce həmçinin uyğun olduğunu qeyd edir WP Super Cache ilə yerli uyğunluqvə standart olaraq açar səhifələri keşləməkdən qaçınır.
Beləliklə, e-ticarət saytları əlbəttə keşlənə bilər, lakin bunu “canlı dəyişiklik” kimi qəbul edirsinizsə, onu mütləq sınaqdan keçirməlisiniz.
Q5: LiteSpeed Cache-i yoxsa WP Rocket-i seçməliyəm?
- Siz serverin LiteSpeed/OpenLiteSpeed üzərində işlədiyini təsdiqləmisinizmi?LiteSpeed Cache-ı üstün tutun (pulsuz və güclü, əsas üstünlükləri server səviyyəli LSCache-dən götürülüb)
- Server konfiqurasiyası barədə əmin deyilsiniz / əziyyət çəkmək istəmirsiniz / problemsiz, hər şeyi əhatə edən bir həll istəyirsinizWP Rocket daha sabitdir
- Siz məzmun saytını idarə edirsiniz və büdcəyə diqqətli olmaq istəyirsiniz.WP Super Cache daha sabit və yüngüldür.
CDN ilə birlikdə keşləmə plagin
Keşləmə plagini “əsas serverdən məzmunun az çatdırılması” və “daha yüksək TTFB” problemlərini həll edir; CDN isə 'statik resursların dünya üzrə istifadəçilərə daha yaxın olmasını' təmin edir. Yalnız bu ikisi birləşdikdə qlobal giriş üçün ən geniş yayılmış optimal həll təmin edilir.
- Məzmun saytlarında yayılmış kombinasiyalar:Səhifə keşləmə + CDN statik məzmunun çatdırılması
- Dinamik veb saytlar üçün ümumi kombinasiyalar:Səhifə keşləmə (sərt nəzarətli və istisna olunmuş) + obyekt keşləmə (tələb üzrə) + CDN statik məzmun çatdırılması
👉 Oxu:CDN Sürətlənmə (Qlobal düyünlər və keşləmə siyasəti)
Tövsiyə olunan vebsayt keşinq konfiqurasiyaları
1. Məzmun saytları / Bloqlar / Sənəd saytları
Məqsəd: TTFB-ni azaldın, ilk ekran təcrübəsini daha hamar edin, server yükünü yüngülləşdirin və qlobal paylama üçün CDN-dən istifadə edin.
1.1 Ən problemsiz biznes paketi
- WP Rocket (səhifə keşləmə + ön yükləmə + front-end optimallaşdırma)
- CDN (CDN səhifəsində əhatə olunacaq)
Aşağıdakılara aiddir:
- Siz minimal quraşdırma tələb edən, sürətli nəticələr verən və aşağı riskli bir şey istəyirsiniz.“
- Çoxlu mövzu və plagin var və uyğunluq problemlərini minimuma endirmək istəyirəm.
Qeyd edilməli məqamlar:
- Front-end optimallaşdırması (xüsusilə JavaScript-in təxirə salınması) funksionallıq problemlərinin (məsələn, menyular, formalar və izləmə) qarşısını almaq üçün mərhələli şəkildə aktivləşdirilir.
- Tez-tez yenidən dizayn edilən və ya mütəmadi olaraq məzmun yayımlayan saytlar “təmizlik və isinmə” strategiyasını qəbul etməlidir; əks halda, az trafikli səhifələrə ilk ziyarətlər yavaş olacaq.
1.2 Həm pulsuz, həm də etibarlı klassik kombinasiya
- WP Super Cache (Statik HTML keşləmə)Daxili səhifələrdən statik HTML yaradın, əsasən sistemə daxil olmayan istifadəçilərə xidmət etmək üçün
Aşağıdakılara aiddir:
- Büdcəyə diqqətli, amma sabitlik axtarır
- Ziyarətçilər nadir hallarda daxil olurlar
- İdarə oluna bilən məzmun yeniləmələri cədvəli
Qeyd edilməli məqamlar:
- Bu “səhifə keşini birinci” yanaşmadır; onun yan təsir kimi bütün mürəkkəb CSS və JavaScript problemlərini həll edəcəyini gözləməyin.
2. Korporativ vebsaytlar / Brend vebsaytları / Giriş səhifələri
Məqsəd: Sürət vacibdir, amma daha vacib olan odur ki, optimallaşdırma konversiya axınını pozmamalıdır.
2.1 Sərt və idarəolunan (qlobal kampaniyalar/konversiya enmə səhifələri üçün tövsiyə olunur)
- WP Rocket
- + (İstəyə bağlı) yüngül şəkil optimallaşdırması (sizdə “Şəkil Optimallaşdırması” səhifəsi var)
- CDN
Niyə bu konversiya saytı üçün uyğundur:
- Konversiya platformaları optimallaşdırma nəticəsində formaların, pop-up pəncərələrin və izləmə skriptlərinin pozulmasına qarşı ən çox həssasdır.“
- WP Rocket daha “inteqrasiya olunmuş” yanaşma tətbiq edir, tək bir sistem daxilində xüsusiyyətləri bir-bir aktivləşdirməyə və geriləmə testləri aparmağa imkan verir.
Korporativ vebsaytın işə salınması üçün prinsiplər:
- Performans optimallaşdırılması “deployment dəyişikliyi” hesab olunur və regresiya testi yoxlama siyahısı ilə müşayiət edilməlidir.
- JavaScript-in təxirə salınması, paketlənməsi və ya minifikasiyası ilə bağlı hər hansı parametrlər tətbiq edilməzdən əvvəl ön-istehsal mühitində sınaqdan keçirilməlidir.
3. WooCommerce e-ticarət saytı (sifarişlərin idarə edilməsi + dinamik səhifə təhlükəsizliyi)
Məqsəd: Alış səbəti, ödəmə və hesab səhifələri kimi səhifələrin tam dəqiq olmasını və eyni zamanda sürətin qorunmasını təmin etmək vacibdir.
WooCommerce-in keş plaginləri ilə bağlı rəsmi mövqeyi çox aydındır:Alış səbəti / ödəmə / hesab səhifələrini keşləməyinUyğunluq problemlərini minimuma endirmək üçün JavaScript fayllarını kiçiltməməyiniz tövsiyə olunur.
3.1 Daha “başlanğıc üçün əlverişli” pulsuz təhlükəsizlik yolu
- WP Super Cache + WooCommerce
- CDN
Niyə bu “başlayanlar üçün daha təhlükəsiz seçim” kimi göstərilib?
- WooCommerce bildirir ki, o, WP Super Cache ilə doğma uyğunluğa malikdir və qeyd edir ki, WP Super Cache alış-veriş səbəti, ödəmə və hesab səhifələri kimi əsas səhifələri standart olaraq keşləmir.
- E-ticarətə yeni başlayan vebsaytlar üçün “dayanma vaxtından qaçınmaq” “maksimum performans”dan daha vacibdir.
3.2 Əgər LiteSpeed hostinqdən istifadə edirsinizsə (pulsuz, lakin çox güclü)
- LiteSpeed Cache (əsas server keşləmə imkanlarından tam istifadə etmək üçün LiteSpeed/OpenLiteSpeed hostinq mühiti tələb olunur)
- + (İsteğe bağlı) obyekt keşləmə (serverin tutumundan və saytın ölçüsündən asılı olaraq Redis/Memcached)
- CDN
Aşağıdakılara aiddir:
- Host yığınını aydın şəkildə müəyyən etmisiniz və keşləmə qaydalarını və istisna strategiyalarını qurmağa hazırsınız.
- Sifarişlər və məhsulların həcmi yüksək olduğundan, mənbə serveri daha böyük yükləməni idarə edə bilməlidir.
3.3 Mühəndislik komandaları / Çoxsaylı idarə olunan modullara malik mürəkkəb e-ticarət platformaları
- W3 Total Cache (səmərəlilik çərçivəsi, CDN ilə inteqrasiya olunmuş çoxsəviyyəli keş)
- Obekt keşləmə (tələb üzrə)
- CDN
Aşağıdakılara aiddir:
- Əgər DevOps komandanız varsa, sistemi “addım-addım modul aktivləşdirmə + yük testi + geriləmə testi” yanaşması ilə işə sala bilərsiniz.
- Parça keşləmə və ya daha mürəkkəb variant strategiyaları (məsələn, cihaz, region və ya dil üzrə incə həcmli keşləmə) tələb edir.
4. Üzvlük saytları / icmalar / onlayn kurslar (tez-tez giriş tələb edən və yüksək səviyyədə fərdiləşdirmə təklif edən)
Məqsəd: İctimai məzmunun sürətlə yüklənməsini təmin edin, eyni zamanda daxil olmuş istifadəçilər üçün məzmunun ayrı qalmasını təmin edin.
4.1 Əziyyətsiz, lakin ciddi istisna strategiyası tələb edir
- WP Rocket
- + (İstəyə bağlı) obyekt keşləmə (əgər çoxlu dinamik sorğular varsa)
- CDN
Əsas məqamlar:
- Aşağıdakı səhifələri keşdən kənarlaşdırmalısınız, çünki onlar istifadəçiyə görə dəyişir: Hesabım, Sifarişlər, Təhsil İrəliləyişi, Mesajlar, Alış Səbəti və s.
- Bu cür saytlar “digər istifadəçilərin məzmununu izləmək” və ya 'icazə səhvləri' kimi problemlərə ən çox məruz qalır; risklər səhifədə aydın şəkildə izah edilməlidir.
4.2 LiteSpeed Hosting + Gelişmiş Siyasətlər
- LiteSpeed Cache (server keşləmə + daha inkişaf etmiş siyasət alətləri)
- + (Tələb üzrə) obyekt keşləmə
- CDN
Əsas məqamlar:
- Üzvlük saytları tez-tez “keşlənə bilən bədən + keşlənməyən fragment” yanaşmasını tələb edir.
- Ön yükləmə və təmizləmə strategiyaları daha incə tənzimlənməlidir; yoxsa istifadəçilər yeniləmədən sonra belə tez-tez köhnə məzmunu görməyə davam edəcəklər.
Vebsayt keş: “Tələlərdən qaçmaq üzrə iş nümunələri”
Hadise 1: Keşləmə plagin quraşdırıldı, lakin sürətdə demək olar ki, heç bir dəyişiklik olmadı.
Simptomlar:
- Yerli ərazi və ya region daxilində sürət testləri qənaətbəxşdir, lakin xaricdə (qitələrarası) sürətlər hələ də yavaş qalır.
- TTFB yaxşılaşıb, lakin ümumi yükləmə müddətində əhəmiyyətli azalma olmayıb.
Ümumi səbəblər:
- Siz yalnız mənbə server keşləməsini (TTFB) tətbiq etmisiniz, lakin statik resurslar (şəkillər, JavaScript, CSS və şriftlər) hələ də qitələrarası məsafədəki mənbə serverdən yüklənir.
- Üçüncü tərəf skriptləri (reklamlar, söhbət, analitika) səhifənin yüklənməsini və interaktivliyi ləngidir.
- Şəkil çox böyükdür, bu da yükləmə sürətinin yavaşlamasına səbəb olur (keşləmə ilkin yükləmə zamanı böyük fayl ölçüsü problemini həll etmir)
Yanaşma:
- Kəşləmə plagin əsasən server yükünü azaltmaq və hit nisbətlərini yaxşılaşdırmaq üçün cavabdehdir.“
- CDN vasitəsilə statik resurslar
- Şəkil optimallaşdırılması
- Gecikdirmə/ayırma strategiyaları üçün üçüncü tərəf skriptləri
Oxu:
- CDN Sürətlənmə: Qlobal düyünlər və keşləmə strategiyaları
- Şəkil optimallaşdırılması: formatlama/sıxılma/tənbəl yükləmə
Hadise 2: Keşləməni aktivləşdirdikdən sonra səhifə dəyişdirildi, lakin frontend yenilənmədi.
Simptomlar:
- Məzmun/dizayn admin panelində yenilənib, lakin front-end hələ də köhnə versiyanı göstərir.
- Yoxsa bəlkə yalnız bəzi regionlar yenilənib, digərləri isə dəyişməz qalıb (bu, qlobal saytda olduqca yaygındır)
Ümumi səbəblər:
- Səhifə keş yaddaşı təmizlənməyib, ya da təmizləmə əməliyyatının diapazonu düzgün deyil.
- Əvvəlcədən isitmə/crawling prosesi işə düşməyib; keşin təmizlənməsi sistemi "soyuq" vəziyyətə salıb, nəticədə səhifələr ilk dəfə yüklənərkən yavaş olur, siz isə yanıldaraq düşünürsünüz ki, heç bir yeniləmə edilməyib.
- Əgər CDN kənar keşini aktivləşdirmişsinizsə, kənar köhnə resursları da saxlaya bilər.
Yanaşma:
- Nəşr/təhrir tamamlandıqdan sonra təmizlik siyasəti yaradın: bütün saytı tamamilə təmizləmək əvəzinə müvafiq səhifələri təmizləyin
- “Təmizlik = daha yavaş performans'ın qarşısını almaq üçün əsas səhifələr (ana səhifə, əsas enmə səhifələri) üçün ön yükləmə strategiyası hazırlayın.”
- CDN qatında kənar təmizləməni lazım olduqda həyata keçirin
3-cü hal: Dillər və ya valyutalar arasında keçid etdikdən sonra məzmun nümayişində problemlər
Simptomlar:
- Səhifə dilləri dəyişdikdən sonra hələ də əvvəlki dili göstərir
- Alternativ olaraq, bəzi regionlarda istifadəçilər səhv valyuta və ya düzgün olmayan məzmun görə bilərlər.
Ümumi səbəblər:
- Kəş “variant ölçüləri” (cookie / parametrlər / dil prefiksləri / alt domenlər) arasında fərq qoymur.
- Kəş tapılması A dilindəki bir səhifəni B dilindən istifadəçiyə təqdim etdi.
Yanaşma:
- Çoxdilli strategiyanızı müəyyən edin: Directory/Subdomain/Parameter/cookie
- Keşləmə qaydalarına “variant siyasəti” tətbiq edin və ya əsas səhifələri istisna edin
- Bəzi saytlar daha inkişaf etmiş “şarded keşləmə” yanaşmasını tələb edir (W3TC mühəndislik yönümlü idarəetməyə daha uyğundur)
4-cü hal: Elektron ticarət saytında keşin aktivləşdirilməsindən sonra alış-veriş səbəti və ödəmə prosesi ilə bağlı problemlər
Simptomlar:
- Alış səbətindəki miqdar səhvdür, qiymət səhvdür və ödəmə düyməsi işləmir.
- Giriş etdikdən sonra mənə aid olmayan məzmunu görmək (ciddi)
Ümumi səbəblər:
- Səbət, Ödəmə və Mənim Hesabım kimi əsas səhifələr keşlənir.
- JS minifikasiyası/konkatenasiyası ödəniş/davamlı komponentlərlə uyğunluq problemlərinə səbəb olur
Yanaşma:
- WooCommerce rəsmi olaraq bildirir ki, alış-veriş səbəti, ödəmə və hesab səhifələri keşlənməməlidir və JavaScript fayllarının sıxılmasının qarşısını almağı tövsiyə edir.
- Əvvəlcə “səhifə keşləmə + istisna” funksiyasını düzgün işlədin, sonra ön tərəf optimallaşdırmasını nəzərdən keçirin.
- Əgər WP Super Cache-dən istifadə edirsinizsə, WooCommerce bildirir ki, o, yerli olaraq uyğundur və standart olaraq əsas səhifələri keşləmədən kənarlaşdıracaq.
Hadise 5: Menyular, formalar və pop-uplar “JS-i təxirə sal/Skriptləri birləşdir” aktivləşdirildikdən sonra işləməyi dayandırır.
Simptomlar:
- Navigasiya menyusu açılmır
- Formanın təsdiqi uğursuz oldu və ya form göndərilə bilmədi
- Pop-up/karusel problemləri
- Statistika/konversiya hadisələri işə düşmür (nəşriyyatçılar üçün ən böyük baş ağrısı)
Ümumi səbəblər:
- JavaScript dəyişikliklərini skript işə salındıqda gecikdirmək: skript istifadəçi onunla qarşılıqlı əlaqə qurana qədər işə düşmür, halbuki bəzi komponentlər səhifə yüklənən kimi təşəbbüs edilməsinə güvənir.“
- Birləşdirmə və ya sıxma skriptlərin sırasını dəyişə və ya asılılıqları poza bilər.
WP Rocket rəsmi olaraq “JS icrasını təxirə salmağı” özünün ən güclü JS optimallaşdırmalarından biri kimi təsvir edir: skriptlər istifadəçi qarşılıqlı əlaqəsindən sonra işə salındığından, səhifə əvvəlcə render olunur. Bu güclü xüsusiyyət olsa da, uyğunluq problemləri riski daha yüksəkdir.
Yanaşma:
- Mərhələli tətbiq edin: əvvəlcə keş, sonra şəkillər, sonra CSS, nəhayət JavaScript
- Əsas skriptləri (ödəniş, formalar, menyular, izləmə) istisna edin
- Hər dəyişiklik üçün geriləmə testi yoxlama siyahısı tərtib edilməlidir.
6-cı hal: Mən yalnız LiteSpeed Cache quraşdırmışam, amma o, çox iş görmür kimi görünür.
Simptomlar:
- LiteSpeed Cache-ı aktivləşdirmişəm, amma TTFB çox yaxşılaşmayıb.
- Uğur nisbəti də xüsusilə yüksək deyil.
Ümumi səbəblər:
- Sizin serveriniz LiteSpeed və ya OpenLiteSpeed işləmir, buna görə də LSCache-in əsas xüsusiyyətlərindən istifadə edə bilməzsiniz.
- Yoxsa bəlkə siz bir çox optimallaşdırmaları aktivləşdirmişsiniz, amma “səhifə keş siyasəti/öncədən isitmə/istisnalar” qurulmayıb.
Yanaşma:
- Əvvəlcə veb server yığınını yoxlayın: LiteSpeed-dir, yoxsa OpenLiteSpeed? (Bu, zəruri şərtdir.)
- Səyləri səhifə keşləmə strategiyaları + ön yükləmə + problemlərin aradan qaldırılması + optimallaşdırmaya yenidən yönəldin“
- Əgər LiteSpeed hostinqdən istifadə etmirsinizsə, WP Rocket və ya WP Super Cache-i nəzərdən keçirin.