Korporativ saytları yavaşladan 5 əsas hosting xətası

26 mar 2026 · Müəllif: Netspare komandası

Hosting izahı

Korporativ saytları yavaşladan 5 əsas hosting xətası

Yavaş səhifə adətən tək böyük şəkildən yox, cache miss, çoxsaylı DB sorğusu, bloklayan üçüncü tərəf skriptləri və stagingdə yaxşı görünən TLS/HTTP ayarlarının birləşməsindən yaranır.

Core Web Vitals və RUM göstəriciləri bounce və orgaik görünürlüklə əlaqəlidir. Əsas üç darboğazı düzəltmək çox vaxt kor-koranə daha böyük server almaqdan yaxşıdır.

Aşağıda istehsal korporativ saytlarda gördüyümüz beş xəta və iki həftəlik sprint üçün prioritet plan var.

RUM sintetik monitorların qaçırdığı coğrafi gecikmə ləkələrini açır — ödəniş və hesab səhifələrində əvvəlcə aktiv edin, çünki gəlir bu şablonlarla əlaqəlidir.

HTTP/3 yalnız TLS və origin sağlam olduqdan sonra kömək edir — QUIC qazancından əvvəl render-bloklayan resursları aradan qaldırın.

Xəta 1 — sıxılmamış hero media

Tam enlikdə PNG/4K JPEG LCP-ni məhv edir. AVIF/WebP, `srcset` və fold altı lazy ilə responsiv `<picture>` istifadə edin.

Mobil LCP şəkli üçün ~200KB hədəf və Lighthouse filmstrip ilə yoxlama.

Xəta 2 — köhnə PHP/Node və OPcache

Dəstəksiz runtime təhlükəsizlik və performans itkisi deməkdir. PHP 8.x + OPcache prod üçün `validate_timestamps=false` ilə tənzimlənməlidir.

Node-da cluster/proses meneceri CPU sayına uyğun olmalıdır; SSR yaddaş sızması cavab müddətini artırır.

Xəta 3 — plugin SQL fırtınası və indeks

Bəzi pluginlər səhifə başına onlarla sorğu göndərir. Slow log ilə EXPLAIN, örtük indeks əlavə edin. Boz sorğunu əbədi keşləməyin.

Redis/Memcached yalnız SQL sağlam olduqdan sonra faydalıdır.

Xəta 4 — TTFB və CDN

Yüksək TTFB çox vaxt PHP/ASP gözləmə və ya soyuq konteynerdir. Origin və kənarı ayrı ölçün. Statik üçün CDN-də cache-control və mümkündərsə stale-while-revalidate.

HTTP/2/3 təkbaşına kömək etmir əgər hələ də çox render-bloklayan CSS varsa.

Xəta 5 — üçüncü tərəf teqləri

  • Rüblük teq inventarı; istifadə olunmayan piksel silin.
  • Kritik olmayan skript async/defer.
  • Render yolunu bloklamayan cookie consent rejimi.
  • Lighthouse CI ilə performans büdcəsi.

İki həftəlik plan

  • 1-ci həftə: LCP media, statik CDN, runtime + OPcache.
  • 2-ci həftə: SQL/indeks, ağır pluginlər, RUM dashboard.

RUM və sintetik monitorinq

Sintetiklər uptime bazasını verir; RUM cihaz sinfi problemlərini (zəif Android, 3G) göstərir. İkisini bir dashboardda birləşdirin.

RUM-u marketinq kanalına görə seqmentləyin: ödənişli trafik bəzən daha ağır üçüncü tərəf skriptləri daşıyır.

Kənar keş tələləri

Fərdiləşdirilmiş HTML ictimai keşlənməməlidir — edge include və ya mikro-fragment ehtiyatla.

Buraxılışdan sonra köhnə keş surrogate-key purge çəngəllərinin çatışmazlığını göstərir — CI boru xəttinə qoşun.

Tez-tez verilən suallar

TTFB hədəf nə olmalıdır?
Dinamik HTML üçün origin-də keşlənmiş marşrutlarda ~200–400 ms yaxşı başlanğıcdır; p95 600 ms-i keçəndə araşdırın.
HTTP/3 indi mütləqdir?
İtkili mobil şəbəkələrdə faydalıdır, amma böyük şəkillər və server gecikməsinin əvəzi deyil.

Bəyənə bilərsiniz