Core Web Vitals reytinqinizi niyə həll edir

LCP, INP və CLS həqiqətən nəyi ölçür

Largest Contentful Paint əsas məzmunun nə qədər tez göründüyünü, Interaction to Next Paint klik və ya toxunuşda səhifənin nə qədər tez cavab verdiyini, Cumulative Layout Shift isə yüklənmə zamanı məzmunun nə qədər «sıçradığını» ölçür. Hər biri real ziyarətçinin qalıb-qalmayacağı konkret anla bağlıdır.

Bu göstəricilər Google-un Chrome İstifadəçi Təcrübəsi Hesabatından (CrUX) real ziyarətçi məlumatı əsasında, 75-ci faizlik dilim üzrə ölçülür — yəni ziyarətçilərinizin ən azı 75%-i "yaxşı" göstərici alması lazımdır ki, səhifə keçid balı alsın.

Bazarın real mənzərəsi göstərir ki, bu, hələ də həll olunmamış problemdir

HTTP Archive-in son Web Almanac hesabatına görə, mobil saytların yalnız 48%-i və desktop saytların 56%-i hər üç göstəricidə "yaxşı" bal alır. INP xüsusilə çətin göstəricidir — saytların 43%-i 200 millisaniyəlik həddi keçə bilmir. Bu o deməkdir ki, Core Web Vitals-a diqqət yetirən biznes artıq rəqiblərinin əksəriyyətindən üstündür.

Google niyə reytinqi real təcrübəyə bağladı

Texniki cəhətdən mükəmməl, amma praktikada yavaş və ya «səkərək» işləyən səhifə yenə də istifadəçini əsəbləşdirir — Google-un bütün biznesi insanların axtarış nəticələrinə güvənməsindən asılıdır. Core Web Vitals Google-a təcrübəni yalnız crawler datasından təxmin etmək əvəzinə real Chrome istifadəçilərindən birbaşa ölçmək imkanı verir.

Ən çox nəticə verən düzəlişlər

Praktikada ən böyük qazanc qısa bir siyahıdan gəlir: düzgün ölçülü və sıxılmış şəkillər, kritik olmayan JavaScript-in gecikdirilməsi, asinxron yüklənən elementlər üçün yer ayrılması və ziyarətçilərə yaxın infrastrukturda hosting. Bunlardan əvvəl xırda optimizasiyaların dalınca qaçmaq boş vaxt itkisidir.

• LCP üçün: ən böyük şəkli WebP formatında, düzgün ölçüdə sıxın; kritik CSS-i inline edin; server cavab vaxtını azaldın (CDN/edge hosting).
• INP üçün: böyük JavaScript bloklarını kiçik hissələrə bölün; üçüncü tərəf skriptlərini (analitika, chat widget) gecikdirilmiş yükləyin.
• CLS üçün: şəkil və reklam bloklarına əvvəlcədən ölçü (width/height) təyin edin; fontları `font-display: swap` ilə yükləyin ki, mətn sıçramasın.

Optimizasiyadan əvvəl düzgün ölçün

Lighthouse kimi lab alətləri debaq üçün faydalıdır, amma Google Search Console-un Core Web Vitals hesabatındakı real ziyarətçi (field) datasına görə reytinqləyir. Düzəlişi uğurlu elan etməzdən əvvəl həmişə real rəqəmləri yoxlayın — yaxşı lab nəticəsi zəif field data ilə reytinq üçün heç nəyi dəyişmir.

Texnologiya seçimi ilə əlaqə

Statik generasiya (SSG) ilə qurulan saytlar Core Web Vitals-da təbii üstünlüyə malikdir, çünki HTML əvvəlcədən hazırdır və server tərəfi hesablama sorğu zamanı baş vermir — bu mövzunu statik vs dinamik arxitektura yazısında daha ətraflı izah etmişik. Praktikada bu, optimallaşdırılmamış WordPress saytların LCP-də 4-6 saniyəyə çatdığı halda, yaxşı qurulmuş statik Next.js saytın 1-2 saniyə aralığında qalmasına səbəb olur.

Sürət təkcə istifadəçi təcrübəsi deyil, birbaşa gəlirə təsir edir — bu əlaqəni redizaynın ROI-si yazısında rəqəmlərlə göstərmişik. Texniki SEO-nun digər tərəflərini isə texniki SEO checklist yazısında tam yoxlaya bilərsiniz.

Ölçmə alətləri: hansını nə vaxt istifadə etməli

LCP-ni yaxşılaşdırmağın addım-addım yolu

LCP adətən ən böyük təsirə malik göstəricidir, çünki ziyarətçinin gördüyü ilk böyük elementi ölçür. Praktik addımlar: əvvəlcə PageSpeed Insights-də "LCP element"in nə olduğunu müəyyənləşdirin (adətən hero şəkli və ya başlıq); əgər şəkildirsə, onu WebP formatına çevirin, düzgün ölçüdə (ekran ölçüsündən böyük olmayan) ixrac edin və `preload` ilə prioritetləşdirin; əgər mətndirsə, fontun sürətli yüklənməsini təmin edin. Server cavab vaxtı da (Time to First Byte) LCP-yə birbaşa təsir edir — buna görə edge/CDN hosting mühüm rol oynayır.

INP-ni yaxşılaşdırmaq: ən çətin göstərici

INP 2024-cü ildə FID-i (First Input Delay) əvəz etdi və ölçdüyü şey daha genişdir — təkcə ilk deyil, səhifə həyatı boyu bütün interaksiyaların cavab sürətini qiymətləndirir. Bu, onu ən çətin optimizasiya edilən göstəriciyə çevirir, çünki bütün JavaScript icra vaxtına həssasdır. Praktik həll: böyük JavaScript funksiyalarını kiçik hissələrə bölmək ("yield to main thread"), üçüncü tərəf skriptlərini (chat widget, analitika) təxirə salmaqla yükləmək və lazımsız re-render-lərdən qaçmaq.

CLS-i sıfıra yaxınlaşdırmaq

CLS-in əsas səbəbi ölçüsü əvvəlcədən bilinməyən elementlərdir — şəkil yüklənənə qədər yer ayrılmayıb, reklam bloku sonradan yüklənib məzmunu itələyib, ya da veb-font dəyişəndə mətn ölçüsü sıçrayıb. Həll: hər şəkil və video elementinə `width`/`height` atributu (və ya CSS `aspect-ratio`) təyin etmək, dinamik məzmun (reklam, banner) üçün əvvəlcədən sabit hündürlük ayırmaq, fontlar üçün `font-display: optional` və ya `swap` istifadə etmək.

Üçüncü tərəf skriptlərin gizli xərci

Analitika alətləri, chat widget-lər, reklam trackerləri, sosial media düymələri — hər biri əlavə JavaScript yükü gətirir və çoxu saytın öz kodu üzərində sizin nəzarətinizdə deyil. Praktikada bir çox saytda Core Web Vitals problemlərinin əsas səbəbi öz kodu deyil, məhz bu üçüncü tərəf skriptlərdir. Həll: yalnız həqiqətən lazım olan skriptləri saxlamaq, onları `async`/`defer` atributları ilə yükləmək və mümkünsə istifadəçi hərəkətindən sonra (məsələn, chat widget-i yalnız istifadəçi bir dəfə scroll etdikdən sonra) yükləməyə keçirmək.

Mobil və desktop arasındakı fərq

Google mobil və desktop üçün ayrı-ayrı qiymətləndirmə aparır və mobil nəticələr adətən daha zəifdir, çünki mobil cihazların prosessor gücü aşağıdır və şəbəkə sürəti daha dəyişkəndir. Bir çox biznes yalnız desktopda test edib "hər şey yaxşıdır" nəticəsinə gəlir, amma Google-un mobile-first indeksləməsi əsasən mobil versiyaya əsaslanır — buna görə optimallaşdırma prioriteti həmişə mobil olmalıdır, desktop deyil.

Davamlı monitorinq: bir dəfəlik iş deyil

Sayt yeniləndikcə (yeni bölmə, yeni plugin, yeni şəkil) Core Web Vitals göstəriciləri dəyişə bilər — buna görə bir dəfə optimallaşdırıb unutmaq səhvdir. Google Search Console-un Core Web Vitals hesabatını aylıq yoxlamaq və böyük dəyişiklikdən sonra (redizayn, yeni funksiya) PageSpeed Insights ilə yenidən test etmək davamlı yaxşı nəticəni təmin edir.

Şəkil formatları müqayisəsi

JavaScript bundle ölçüsünün gizli təsiri

Hər əlavə JavaScript kitabxanası brauzerin endirməli, parse etməli və icra etməli olduğu kod deməkdir — bu proses xüsusilə zəif prosessorlu mobil cihazlarda INP-yə birbaşa təsir edir. Böyük UI kitabxanalarını tam yükləmək əvəzinə yalnız istifadə olunan hissələri daxil etmək ("tree shaking"), lazımsız asılılıqları (dependency) müntəzəm audit etmək və code-splitting tətbiq etmək bundle ölçüsünü əhəmiyyətli azalda bilər.

Real nümunə: kiçik dəyişikliklərin kumulyativ effekti

Tək bir optimizasiya nadir hallarda böyük fərq yaradır, amma bir neçəsinin birləşməsi ölçülə bilən nəticə verir. Nümunə üçün: hero şəkli WebP-ə keçirilib düzgün ölçüləndirilir (LCP-də -0.8s), chat widget gecikdirilmiş yüklənir (INP-də -50ms), şəkillərə width/height təyin edilir (CLS-də -0.15). Bu üç kiçik dəyişiklik birlikdə saytı "zəif" kateqoriyadan "yaxşı" kateqoriyaya keçirə bilər.

Reytinqdən başqa niyə əhəmiyyətlidir

Core Web Vitals-a diqqət yetirməyin faydası yalnız SEO ilə məhdudlaşmır. Sürətli, sabit sayt ziyarətçi məmnuniyyətini artırır, bounce rate-i azaldır və brend algısını yaxşılaşdırır — bunların hamısı dönüşüm nisbətinə birbaşa təsir edir, Google-un reytinq alqoritmindən asılı olmadan. Başqa sözlə, Core Web Vitals-ı yaxşılaşdırmaq "Google üçün" deyil, əsasən real insanlar üçün edilən işdir — SEO faydası bunun əlavə bonusudur.

Yeni layihədə əvvəlcədən düşünmək

Core Web Vitals-ı sonradan düzəltmək mövcud problemi araşdırmaq, prioritetləşdirmək və düzəltmək tələb edir — bu, vaxt aparan prosesdir. Yeni layihə qururkən bu standartları əvvəlcədən arxitektura seçimində (statik generasiya, şəkil optimizasiyası, minimal üçüncü tərəf skript) nəzərə almaq isə demək olar ki, əlavə xərcsiz gəlir, çünki düzgün əsaslarla qurulan sayt bu göstəriciləri təbii şəkildə keçir.

Sürətli özünüzü yoxlama siyahısı

• Ən böyük şəkil WebP/AVIF formatındadırmı və düzgün ölçüdədirmi?
• Üçüncü tərəf skriptlər (chat, analitika) gecikdirilmiş yüklənirmi?
• Bütün şəkil/video elementlərində width/height təyin olunubmu?
• PageSpeed Insights mobil balı 70-dən yuxarıdırmı?
• Search Console-da Core Web Vitals hesabatı aylıq yoxlanılırmı?

Rəqib saytlarla müqayisə etmək

Öz saytınızın Core Web Vitals göstəricilərini təcrid olunmuş şəkildə deyil, əsas rəqiblərinizlə müqayisədə qiymətləndirmək daha realist mənzərə verir. PageSpeed Insights-da rəqib URL-lərini də test edin — əgər onlar da zəif göstərici alırsa, bu, sənayenin ümumi problemi ola bilər və sizin üçün fürsətdir; əgər onlar yaxşı nəticə göstərirsə, bu, sizin üçün təcili prioritet siqnalıdır.

Server seçiminin rolu

Bütün frontend optimizasiyaları edilsə belə, zəif hosting server cavab vaxtını (TTFB — Time to First Byte) yavaşladıb bütün göstəricilərə mənfi təsir edə bilər. Coğrafi olaraq əsas auditoriyaya yaxın data mərkəzi seçmək, edge/CDN infrastrukturundan istifadə etmək və paylaşılan, ucuz hostinqdən qaçmaq — bunlar frontend kodundan asılı olmayan, amma Core Web Vitals-a birbaşa təsir edən infrastruktur qərarlarıdır.

Fontların yüklənməsi: gözə görünməyən amma hiss olunan detal

Xüsusi veb-fontlar brend kimliyinə töhfə versə də, düzgün yüklənmədikdə həm LCP-yə, həm CLS-ə mənfi təsir edə bilər. Fontları öncədən yükləmək (`preload`), sistem fontlarına yaxın "fallback" seçmək (ki, font dəyişəndə layout kəskin sıçramasın) və lazımsız font çəkilərini (bold, italic variantları istifadə olunmursa) yükləməmək bu təsiri minimuma endirir.

Sifarişçi üçün əsas mesaj

Core Web Vitals texniki mövzu kimi görünsə də, sifarişçi üçün əsas sual sadədir: "Saytımız real ziyarətçilər üçün sürətli işləyirmi?" Bu sualın cavabını almaq üçün mütəxəssis olmağa ehtiyac yoxdur — pagespeed.web.dev ünvanına öz sayt linkinizi daxil etmək və mobil balı yoxlamaq kifayətdir. 90+ bal əla, 50-89 orta, 50-dən aşağı isə təcili diqqət tələb edən nəticədir.

Prefetch və prerendering: gələcək naviqasiyanı əvvəlcədən sürətləndirmək

Core Web Vitals ilk yüklənməni ölçür, amma real ziyarətçi təcrübəsi bir səhifə ilə bitmir — sayt daxilində keçidlər də əhəmiyyətlidir. Next.js kimi framework-lər ekranda görünən linklər üçün arxa planda avtomatik "prefetch" edir — ziyarətçi linkə klik etməzdən əvvəl həmin səhifənin məlumatı artıq yüklənməyə başlayır, nəticədə klikdən sonra keçid demək olar ki, ani hiss olunur. Bu, ilk səhifə yükləməsindən sonrakı bütün naviqasiya təcrübəsini gücləndirən, amma çox vaxt nəzərə alınmayan optimizasiya qatıdır.

Təcrübədə bunun fərqi böyükdür: prefetch olmadan hər klik yeni server sorğusu və render gözləməsi deməkdirsə, prefetch ilə ziyarətçi saytda demək olar ki, fasiləsiz, tətbiq kimi davamlı təcrübə yaşayır. Statik generasiya (SSG) ilə qurulan saytlarda bu, əlavə mühəndislik işi tələb etmədən, framework-in özü tərəfindən default olaraq işləyir — bu da statik arxitekturanın Core Web Vitals-dan kənar, amma birbaşa hiss olunan digər üstünlüyüdür.

Real istifadəçi datası (Field Data) vs laboratoriya datası

PageSpeed Insights nəticələri iki fərqli mənbədən gəlir və bunları qarışdırmaq tez-tez yayılan bir səhvdir. "Laboratoriya datası" (Lab Data) — nəzarətli, simulyasiya edilmiş bir mühitdə (sabit şəbəkə sürəti, sabit cihaz) aparılan tək test nəticəsidir; təkrarlana bilər, amma real dünya şərtlərini tam əks etdirmir. "Sahə datası" (Field Data, CrUX) isə Chrome istifadəçilərinin son 28 gündə real şəraitdə (müxtəlif cihaz, şəbəkə sürəti) yaşadığı təcrübənin toplanmış statistikasıdır — Google-un reytinq üçün əsasən istifadə etdiyi də məhz bu datadır. Laboratoriya balı yüksək olsa belə, sahə datası zəifdirsə, real ziyarətçilərin əksəriyyəti zəif təcrübə yaşayır deməkdir — buna görə hər iki rəqəmi ayrıca izləmək vacibdir.

Kritik CSS və render-blocking resurslar

Səhifə HTML-i yüklənsə belə, brauzer CSS faylını tam çəkib emal etməyənə qədər heç nə göstərmir — bu, "render-blocking" adlanır və LCP-yə birbaşa təsir edir. Həll yolu "kritik CSS"i (yalnız ilk görünən ekran hissəsi üçün lazım olan stillər) səhifənin `<head>`-inə birbaşa daxil etmək, qalan CSS-i isə asinxron yükləməkdir. Müasir framework-lər (Next.js daxil olmaqla) bunu build zamanı avtomatik həll edir, amma əlavə edilən üçüncü tərəf stil kitabxanaları bu optimizasiyanı bəzən sakitcə pozur — yeni kitabxana əlavə edildikdən sonra LCP-ni yenidən yoxlamaq faydalıdır.

Xülasə

LCP, INP və CLS — bu üç göstərici real istifadəçi təcrübəsini ölçür və birbaşa Google reytinqinə, həm də dönüşüm nisbətinə təsir edir. Şəkil optimizasiyası, üçüncü tərəf skript idarəetməsi və layout sabitliyi kimi nisbətən sadə addımlar əksər saytlarda əhəmiyyətli fərq yaradır. Davamlı monitorinq isə bu nəticələrin zaman keçdikcə qorunmasını təmin edir.