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əsi + server tərəfində yaradılması + 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ə xüsusilə nəzərə çarpır)
  • WordPress hər sorğuda PHP işlətməli, verilənlər bazasını sorğulamalı 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, bu isə renderinqi və interaktivliyi ləngidir.

Keşləmə plaginBu problemin həllinin açarı “yenidən hesablanmış” 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 edə biləcəyini, beləliklə 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 aktiv edildikdə, ə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əri və təlimatlar müəyyən bir keşləmə pluginindən 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ı minimallaşdırmaqdan çəkinin (çünki bu, asanlıqla uyğunluq problemlərinə səbəb ola bilər).

3. “Keş plagini ≠ CDN”, amma keş plagini CDN-nin təməlidir

Kəşləmə plaginı mənbə serverdə az sayma problemini həll edir;CDN “Kontenti istifadəçiyə daha yaxın etmək” problemini həll edin. Bu ikisi üst-üstə düşən münasibətdir: əvvəl mənbə saytın TTFB-sini aşağı salın, sonra statik resursları CDN-yə verib yaydırın — qlobal istifadəçilərə yönəlik ən sabit yol məhz budur.

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:

  1. Ruhi rahatlıq, etibarlılıq və qlobal əlçatanlıq axtarıram → WP Rocket(Ödənilmiş)
  2. Server mütləq LiteSpeed/OpenLiteSpeed üzərində 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
  3. 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
  4. Texniki komandanız var, detallı idarəetmə (CDN/obyekt keşləmə/çoxmodullu) → W3 Ümumi Keş(Güclü, lakin mürəkkəb): Hərtərəfli performans çərçivəsi və CDN inteqrasiyası əsas üstünlükdür

Kəş nəyi dəqiq saxlayır?

“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:

  1. 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)
  2. Səhifə keşləmə: Səhifənin çıxışını HTML kimi keşləyin (bu səhifənin diqqət mərkəzidir)
  3. 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)
  4. PHP OPcache: PHP baytkodu keşə (adətən server tərəfindən konfiqurasiya olunur, plaqinin əsas mövzusu deyil)
  5. 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 həsr olunub: səhifə keşləmə plaginslə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ğuna görə deyil, performans optimallaşdırmasının ən çox rast gəlinən üç növünü “idarəolunan paketlər” şəklində bir araya gətirdiyinə görə 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.)
WordPress keşinin optimallaşdırılması - HOSTFO

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ı və açılış səhifələri (bir neçə ölkə və regiondan trafik)
  • Mən sabitliyi ən yüksək prioritet tutan sürətli işə salını seçərdim, pulsuz plaginslər qarışığına güvənməkdənsə.
  • 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əzmə 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:
Müəyyən bir bölgədə bir istifadəçi ilk dəfə bir səhifəni açanda, həmin səhifənin keşinin vaxtı bitibsə və ya heç vaxt əvvəlcədən qızdırılmayıbsa, bu istifadəçi PHP/DB render xərclərinin tamını daşıyır.
Əvvəlcədən yükləmə mexanizmiMənası belədir:“İ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
  • Ön yükləmə: Sistem arxa planda mərkəzləşdirilmiş şəkildə keşlənmiş məlumat yaradır, bu da ilk dəfə ziyarətçilə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/təqdimat mövzuları ilə 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ı plaginlər və resurs-yoğun tema varsa, “performans optimallaşdırmasını” kiçikmiqyaslı tətbiq 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şləmə plaginini konfiqurasiya edərkən rəsmi WooCommerce sənədlərində vurğulanmış əsas məqam budur:

Niyə?:

  • Alış səbəti, ödəmə və hesab səhifələri kukilərə, sessiyalara və nonslara çox güvənir.
  • 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ə hesab məlumatlarında çaşqınlığa qədər dəyişə bilər.
  • Ən qorxulusu budur: bir bölgədə test problemsiz keçə bilər, amma başqa bölgədə CDN/keş uyğunluğu fərqlərinə görə problem yarana bilər

1.4 Keş plagin 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 öncədən yüklənməsi(İlk dəfə ziyarət edənlər üçün sabitliyi yaxşılaşdırmaq)
  • Məntiqli brauzer keş strategiyası（WP Rocket/server/CDN istənilən səviyyədə tətbiq oluna bilər）

2-ci səviyyə: Orta gəlir, orta risk (əksər məzmun saytları üçün uyğundur)

  • Gecikmiş şəkil yüklənməsi/iframe（şəkil optimallaşdırma səhifəsinin daha dərin hissəsi）
  • 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)

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-də işləyirsə keçərlidir.

WordPress keşinin optimallaşdırılması - HOSTFO

LiteSpeed Cache haqqında geniş yayılmış yanlış təsəvvür odur 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ə və etiketlərdən istifadə edərək təmizləməni işə salmağı təmin edir.

LiteSpeed Cache-in əsas üstünlüyü “Server səviyyəli səhifə keşləmə (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ə paralel işləmə performansını 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üsusilə 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 onun sərfəli olması 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”da belə xülasə edə bilərsiniz:

  • WP Rocket / WP Super Cache Bu cür işlər daha çox WordPress/PHP tərəfində keşləmə və optimallaşdırma ilə edilir.
  • 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 sıçrayışlar və ya axtarış motoru robotlarının tez-tez ziyarətləri zamanı) daha yaxşı idarə edə bilir.

2.3 Vebsayt istifadəçi ssenarisində 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 kukilərə əsaslanan 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 həyata keçirilərsə, vebsayt üçü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ə/Gəzinti (az populyar səhifələrə ilk dəfə daxil olmağın yavaş olub-olmadığını müəyyən edir)

Vebsaytları ziyarət edərkən “uyğun olmayan istifadəçi təcrübəsinin” ümumi səbəbi “isti-soyuq keş fərqliliklərində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 sayt idarəçisi LSCWP-də QUIC.cloud-in onlayn xidmətləri ilə (məsələn, səhifə optimallaşdırma xidmətləri) tanış olur.QUIC.cloud SənədAydın şəkildə yazılıb: o, LSCWP-yə səhifə optimallaşdırma xidmətləri təqdim edir, buraya Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) və s. daxildir.

  • Bu xidmətlər könüllüdür.Onlayn 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

  1. Server LiteSpeed-də işləmir, amma LSCWP-ni tam funksiyalı keşləmə plagini kimi qəbul edir.
    Nəticə: Keş gözlənildiyi kimi işləmədi və həm də konfiqurasiyanın mürəkkəbliyini 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.
  2. Ç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ə eyni zamanda geriləmə testinin yoxlama siyahısını (formalar, menyular, ödəniş, izləmə, dil dəyişimi və s.) hazırlayın.
  3. 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 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

WordPress keşinin optimallaşdırılması - HOSTFO

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 çevirinbundan sonra bu HTML faylları birbaşa Web serveri tərəfindən təqdim edilir və bununla da bahalı PHP emalından yan keçilir.

Plugin səhifəsində həmçinin qeyd olunur ki, autentifikasiya olunmamış 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 olunacaq”, yəni tək bir keşlənmiş fayl minlərlə dəfə təqdim edilə 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ə əmin olun və bunu test prosesinizə daxil edin.

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, PHP-ni tamamilə yan keçir, lakin .htaccess faylını dəyişmək lazımdır, düzgün konfiqurasiya edilməzsə saytın əlçatmaz olma riski daha yüksəkdir
  • Sadə (tövsiyə olunan üsul)PHP tərəfindən təqdim olunan “Super Keş” statik faylları, mod_rewrite-a yaxın sürət, lakin daha asan konfiqurasiya
  • 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:

  1. CDN ilə istifadə üçün çox uyğundur
    Çünki onun mahiyyəti elə “statik HTML yaratmaq”dır və bu, təbii olaraq CDN/kənar keş yanaşmasına uyğundur.
  2. Mənbə saytında CPU/verilənlər bazası yükünün yaxşılaşdırılması çox birbaşadı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:

  1. 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 tema səviyyəli optimallaşdırmalardan istifadə edin).
  2. 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ş 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 hərtərəfli “səmərəlilik çərçivəsi”

WordPress keşinin optimallaşdırılması - HOSTFO

W3 Ümumi Keş WordPress.org-da yerləşdirmə “tək bir keş plagini” deyil, daha çox “veb-sayt performansının optimallaşdırılması çərçivəsi” kimidir: o, CDN inteqrasiyası və ən yaxşı təcrübələr vasitəsilə SEO-nu, Core Web Vitals göstəricilərini və ümumi təcrübəni yaxşılaşdırmağı vurğulayır.

Plugin təsviri geniş imkanlar spektrini sadalayır: səhifə/ səhifə/yazı keşləmə, CSS/JS keşləmə, lent keşləmə, axtarış nəticələri keşləmə, verilənlər bazası obyektləri keşləmə, obyekt keşləmə, fraqment keşləmə və Redis, Memcached və APC kimi müxtəlif keşləmə üsullarını dəstəkləmə. Həmçinin User-Agent və Referrer üzrə qruplaşdırılmış mobil keşləmə, AMP dəstəyi və tərs proxy (Nginx/Varnish) inteqrasiyası daxildir.

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 veb 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, performans strategiyanızı mühəndislik çərçivəsinə çevirməyiniz üçün kifayət qədər idarəetmə seçimi təqdim etməsindədir:

  • Səhifə keşlənməsi: yaddaşda, diskdə və ya CDN-də 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 idarəetməsi: media kitabxanası, mövzu faylları və s. üçün şəffaf CDN idarəetməsi

Bu imkanlar vebsaytlar üçü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ə ardıcıllığı”

Tövsiyə olunan sıra:

  1. Üçüncül mərhələdə yalnız səhifə keşləməsini aktiv edin
    Təsdiqləyin: TTFB-nin azaldığını, məzmunun ardıcıl olduğunu və giriş vəziyyətinin, çoxdillilik funksionallığının və əsas e-ticarət iş axınlarının düzgün işlədiyini.
  2. 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.
  3. Obekt keşini yenidən qiymətləndirin / Verilənlər bazası obyekt keşini
    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.
  4. 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-up pəncərələr, 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ı kiçiltməkdən çə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 RocketLiteSpeed KəşWP Super CacheW3 Ü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əməPerformans çərçivəsi (çoxsəviyyəli keş + CDN)
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əriAşağıdan orta中低高
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əkOrta 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 olunurMö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əPulsuzPulsuzPulsuz + ö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 kukilər, sorğu parametrləri və ya coğrafi mövqeyə əsasən fərqli məzmun göstərirsə, keş strategiyanız “variant ölçülərini” nəzərə almalı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ə plagin quraşdırmışam?

Ən çox rast gəlinən səbəb odur ki, siz yalnız “əsas serverdə təkrar renderləmə” problemini həll etmisiniz, amma “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ə olmalıdır. 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,CDN-də yenidən qlobal yayımla。

Q2: Məzmun kəşlənmiş halda niyə yenilənmir?

Bu, “köhnə keş'i baxdığınız üçündür. Həll:

  • Kəş təmizləmə siyasəti yaradın: məqaləni və ya səhifəni yenilədikdən sonra müvafiq kəşi təmizləyin (bütün saytı təmizləmək əvəzinə)
  • Ö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 üçün: CDN kənarında da köhnə resursların keşlənmiş ola biləcəyini nəzərə almaq lazımdır

Q3: WP Rocket və WP Super Cache-i eyni anda 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 tez-tez 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şin istifadəsi riskli hesab olunurmu?

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 və JavaScript sıxılmasından çə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 əgər 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ülmüşdür)
  • 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.

Keş plaqini və CDN ilə uyğunlaşdırılır

Keş plagini “orijin serverin daha az hesablaması və daha aşağı TTFB” problemini həll edir; CDN isə “statik resurslar və səhifələrin qlobal istifadəçilərə daha yaxın olması” problemini həll edir. Bu ikisinin birlikdə tətbiqi qlobal giriş üçün ən çox rast gəlinən optimal həlldir.

  • Məzmun saytları üçün ümumi kombinasiyalar:Səhifə keşi + CDN statik paylama
  • Dinamik veb saytlar üçün ümumi kombinasiyalar:Səhifə keşi (ciddi istisna nəzarəti) + Obyekt keşi (tələbat üzrə) + CDN statik paylama

👉 Oxu:CDN Sürətləndirmə (qlobal qovşaqlar və keş strategiyası)

Tövsiyə olunan vebsayt keşləmə konfiqurasiyaları

1. Məzmun saytları / Bloqlar / Sənəd saytları

Məqsəd: TTFB-ni azaltmaq, ilk ekranı daha stabil etmək, server yükünü azaltmaq, CDN ilə birlikdə qlobal paylama həyata keçirmək.

1.1 Ən problemsiz biznes paketi

  • WP Rocket (səhifə keşləmə + ön yükləmə + front-end optimallaşdırma)
    • CDN səhifəsinə köçürün

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, lakin optimallaşdırmanın konversiya axınını pozmasına imkan verməmək daha da vacibdir.

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 testləri yoxlama siyahısı ilə birlikdə təqdim edilməlidir.
  • JavaScript-in təxirə salınması, paketlənməsi və ya minifikasiyası ilə bağlı hər hansı parametrlər yerləşdirilmə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şləmə 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 siyahıya salınıb?

  • WooCommerce bildirir ki, o, WP Super Cache ilə doğma uyğunluğa malikdir və qeyd edir ki, WP Super Cache alış 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ə (server tutumundan və saytın ölçüsündən asılı olaraq Redis/Memcached)
    • CDN

Aşağıdakılara aiddir:

  • Host yığını aydın şəkildə müəyyən edilib və siz 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 modulları olan mürəkkəb e-ticarət platformaları

  • W3 Total Cache (performans çərçivəsi, çoxsaylı keşləmə qatları və CDN inteqrasiyası)
    • Objekt keşləmə (tələb üzrə)
    • CDN

Aşağıdakılara aiddir:

  • Əgər DevOps komandanız varsa, sistemi mərhələli yanaşma ilə yerləşdirə bilərsiniz: modulları bir-bir aktivləşdirərək, sonra isə yük testləri və geriləmə testləri apararaq.
  • 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ə səviyyəli 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 Çətinliksiz, 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 edə bilmir)

Yanaşma:

  • Kəşləmə plagin əsasən server yükünü azaltmaq və hit nisbətlərini yaxşılaşdırmaq üçün cavabdehdir.“
  • Statik resurslar CDN ilə keçir
  • Şəkil optimallaşdırılması
  • Gecikdirmə/ayırma strategiyaları üçün üçüncü tərəf skriptləri

Oxu:

Hadise 2: Keşləmə aktivləşdirildikdə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şə salınmayıb; keşin təmizlənməsi onu "soyuq" vəziyyətə salıb və səhvən heç bir yeniləmənin edilmədiyini düşünərkən ilk dəfə səhifələrin yavaş yüklənməsinə səbəb olur.
  • Əgər CDN kənar keşini aktiv etmisinizsə, köhnə resurslar kənarda da qala 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
  • Əsas səhifələr (ana səhifə, əsas enmə səhifələri) üçün öncədən yükləmə strategiyası hazırlayın ki, “təmizləmə” işlərin daha ləng getməsinə səbəb olmasın.”
  • CDN qatında lazım olduqda kənar təmizliyi aparın

3-cü hal: dillər və 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” arasında fərq qoymur (peçenye / parametrlər / dil prefiksləri / alt domenlər)
  • 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: kataloq / alt domen / parametr / kukidən istifadə
  • 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şləməni aktivləşdirdikdən sonra alış-veriş səbəti və ödəmə prosesi ilə bağlı problemlər

Simptomlar:

  • Alış səbətindəki miqdar düzgün deyil, qiymət düzgün deyil 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əri yaradır.

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ından çəkinməyi 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: “JS-i təxirə sal/Skriptləri birləşdir” aktivləşdirildikdən sonra menyular, formalar və pop-uplar nasaz işlədi.

Simptomlar:

  • Navigasiya menyusu açılmır
  • Formanın təsdiqi uğursuz oldu və ya form göndərilə bilməz.
  • 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ərinin yaranma 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-də 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.