Core Web Vitals: LCP, INP və CLS Nədir?

Core Web Vitals — Google-un səhifə təcrübəsini ölçdüyü üç göstəricidir: səhifə nə qədər tez görünür, istifadəçiyə nə qədər tez cavab verir və yüklənərkən elementlər yerini dəyişirmi. Bu göstəricilər sıralama amilidir, amma çəkisi məzmun uyğunluğu qədər böyük deyil. Bu yazı hər göstəricinin nə demək olduğunu, necə ölçüldüyünü və praktikada nəyin düzəldilməli olduğunu izah edir.

Üç göstərici nədir?

LCP (Largest Contentful Paint) — səhifədəki ən böyük görünən elementin (adətən örtük şəkli və ya əsas başlıq) yüklənmə vaxtı. İstifadəçi üçün bu, "səhifə açıldı" hissi deməkdir. Yaxşı sayılan hədd 2,5 saniyəyə qədərdir.

INP (Interaction to Next Paint) — istifadəçi düyməyə basanda, menyunu açanda və ya forma doldurmağa başlayanda səhifənin cavab vermə sürəti. Köhnə FID göstəricisini əvəz edib və bütün qarşılıqlı əlaqələri ölçdüyü üçün daha real mənzərə verir. Yaxşı hədd 200 millisaniyəyə qədərdir.

CLS (Cumulative Layout Shift) — yükləmə zamanı elementlərin sıçraması. Klikləmək istədiyin düymənin reklam yüklənəndə yerini dəyişməsi məhz budur. Yaxşı hədd 0,1-dən aşağıdır.

Göstəricilər harada ölçülür?

İki ölçmə növü var və onları qarışdırmaq geniş yayılmış səhvdir.

Laboratoriya ölçməsi — alət sənin brauzerində səhifəni sabit şəraitdə açır və nəticə verir. Sürətlidir, düzəlişi dərhal yoxlamağa imkan verir, amma real istifadəçilərin şəraitini əks etdirmir.

Sahə ölçməsi (real istifadəçi məlumatı) — Chrome istifadəçilərinin faktiki təcrübəsindən toplanır. Sıralamada məhz bu məlumat işlədilir. Amma o, son 28 günün toplusu olduğu üçün düzəlişin təsiri dərhal görünmür.

Praktik nəticə: düzəlişi laboratoriya ölçməsi ilə yoxla, nəticəni isə sahə məlumatında bir neçə həftə sonra gözlə. Search Console-un "Səhifə təcrübəsi" hesabatı sahə məlumatını səhifə qrupları üzrə göstərir.

LCP-ni nə yavaşladır?

Ən çox rast gəlinən dörd səbəb:

• Böyük örtük şəkli. 3 MB-lıq foto ekranda 900 piksel enində göstərilirsə, faylın 90 faizi boş yerə yüklənir. Şəkli göstəriləcək ölçüdə hazırlamaq və müasir formatda (WebP/AVIF) vermək ən böyük qazancdır.
• Yavaş server cavabı. Səhifə istəyinə serverin ilk baytı göndərmə müddəti uzundursa, qalan hər şey gecikir. Keşləmə burada həlledicidir.
• Render-i bloklayan resurslar. Səhifənin başında yüklənən böyük CSS və JS faylları məzmunun görünməsini gözlədir.
• Şrift yükləmələri. Şrift gələnə qədər mətnin gizlədilməsi görünmə vaxtını uzadır. Şriftin əvvəlcədən yüklənməsi və müvəqqəti sistem şrifti ilə göstərilməsi bunu həll edir.

INP-i nə pozur?

INP əsasən JavaScript problemidir. Səhifədə çoxlu skript işləyirsə, brauzer "məşğul" olur və istifadəçinin klikini emal etməyə gec başlayır. Ən çox rast gəlinən mənbələr: izləmə və analitika skriptləri, çat pəncərələri, sosial media vidjetləri, açılan pop-up-lar və ağır kitabxanalar.

Praktik həllər: üçüncü tərəf skriptlərini səhifə yükləndikdən sonra işə salmaq, işlədilməyən skriptləri tamamilə silmək, ağır hesablamaları hissələrə bölmək. Ən çox qazandıran addım isə adətən ən sadəsidir — illər ərzində yığılmış, artıq heç kimin işlətmədiyi skriptləri təmizləmək.

CLS necə düzəldilir?

CLS demək olar ki, həmişə eyni səbəblərdən yaranır və hər birinin sadə həlli var:

• Ölçüsü göstərilməyən şəkillər. Şəkil yüklənənə qədər yer tutmur, sonra birdən yer tutub mətni aşağı itələyir. Həll: şəklin en/hündürlük nisbətini əvvəlcədən elan etmək.
• Sonradan yüklənən reklam və vidjet blokları. Həll: onlar üçün əvvəlcədən sabit yer ayırmaq.
• Şrift dəyişməsi. Sistem şriftindən brend şriftinə keçəndə mətnin ölçüsü dəyişir. Həll: oxşar ölçülü ehtiyat şrift seçmək.
• Yuxarıdan əlavə olunan banner. Səhifə açıldıqdan sonra yuxarıya bildiriş əlavə edilməsi bütün məzmunu aşağı itələyir.

Sürət sıralamaya nə qədər təsir edir?

Real cavab: az, amma sıfır deyil. Google özü bildirir ki, səhifə təcrübəsi göstəriciləri məzmun uyğunluğundan zəif siqnaldır. Yəni yavaş, lakin sualı yaxşı cavablandıran səhifə sürətli, lakin səthi səhifədən yuxarıda dayana bilər.

Buna baxmayaraq, sürəti gözardı etmək olmaz — çünki onun əsas təsiri sıralamada deyil, davranışdadır. Yavaş açılan səhifədən istifadəçi gözləmədən çıxır; bu, reklam büdcəsini birbaşa itirir və dolayı yolla axtarış nəticələrinə də təsir edir.

Praktik tarazlıq: göstəriciləri "zəif" zonadan çıxarmaq mütləqdir; "yaxşı" zonadan sonra mükəmməl bala doğru mübarizə isə adətən sərf etdiyi vaxta dəymir.

Haradan başlamalı?

Ardıcıllıq belədir. Əvvəlcə Search Console-un səhifə təcrübəsi hesabatına bax və hansı səhifə qrupunun "zəif" olduğunu müəyyən et — bütün saytı deyil, problemli qrupu düzəltmək lazımdır. Sonra həmin qrupdan bir tipik səhifəni laboratoriya aləti ilə ölç və ən böyük üç problemi qeyd et.

Adətən siyahının başında şəkillər durur — və bu, ən ucuz düzəlişdir. Ondan sonra skriptlər, sonra server cavab müddəti gəlir. Hər düzəlişdən sonra yenidən ölç: bəzən bir dəyişiklik gözlənilməz şəkildə başqa göstəricini pisləşdirir.

Hansı sayt tipində hansı göstərici problem olur?

Təcrübədə problemlər sayt növünə görə kifayət qədər proqnozlaşdırıla biləndir və bu, harada axtarmalı olduğunu bilməyə kömək edir.

Onlayn mağazalarda ən çox LCP problem olur: məhsul şəkilləri çoxdur və çox vaxt lazımi ölçüdən böyük verilir. Buna əlavə olaraq siyahı səhifələrində onlarla şəkil eyni anda yüklənir. Həll adətən şəkil boru xəttindədir — ölçüləndirmə, müasir format və ekranın altındakıların gec yüklənməsi.

Bloq və media saytlarında əsas problem CLS-dir: reklam blokları, sonradan yüklənən vidjetlər və abunə pəncərələri məzmunu aşağı itələyir. Həll — bu elementlər üçün əvvəlcədən sabit yer ayırmaq.

Korporativ saytlarda ən çox INP problemi görünür, çünki illər ərzində çat pəncərəsi, bir neçə analitika sistemi, istilik xəritəsi və sosial vidjetlər yığılır. Həll — skript inventarizasiyası: hansının real olaraq işlədildiyini yoxlamaq və qalanını silmək.

Landing səhifələrində isə problem adətən şrift və animasiyalardır: brend şriftinin gec yüklənməsi mətnin görünməsini gecikdirir, ağır animasiyalar isə cavab müddətini uzadır.

Sürət düzəlişini necə prioritetləşdirməli?

Bütün səhifələri eyni anda düzəltməyə çalışmaq lazım deyil. Praktik ardıcıllıq belədir: əvvəlcə ən çox trafik alan beş səhifə tipini müəyyən et (ana səhifə, kateqoriya, məhsul/məqalə, əlaqə, landing). Sonra hər tipdən bir nümunə səhifəni ölç.

Səbəb sadədir: eyni şablonu işlədən yüzlərlə səhifə eyni problemi daşıyır. Bir şablonu düzəldəndə yüzlərlə səhifə birdən yaxşılaşır. Səhifə-səhifə optimallaşdırma isə həm yavaşdır, həm də nəticəsi az olur.

Bir də bunu unutmamaq lazımdır: sürət düzəlişi funksionallığı pozmamalıdır. Skript silərkən hansı ölçmənin və ya funksiyanın itdiyini yoxlamaq şərtdir — analitika kodunu təsadüfən silmək sürət qazancından qat-qat baha başa gəlir.

Sürət düzəlişinin nəticəsi biznesə nə verir?

Sıralamadakı təsir mübahisəlidir, amma davranışdakı təsir birmənalıdır və ölçülə bilir. Səhifə yükləmə müddəti azalanda üç şey dəyişir: səhifəni gözləmədən tərk edənlərin payı düşür, orta baxılan səhifə sayı artır və ödəniş mərhələsinə çatanların faizi qalxır.

Bunu öz saytında yoxlamağın sadə üsulu var: düzəlişdən əvvəl və sonra eyni səhifə üçün dönüşüm faizini müqayisə et. Fərq kiçik görünə bilər, amma reklam trafiki alan səhifədə 0,2 faizlik dönüşüm artımı aylıq büdcədə real qazanca çevrilir — çünki eyni pula daha çox müştəri alınır.

Ona görə sürət işini yalnız SEO tapşırığı kimi deyil, dönüşüm optimallaşdırmasının bir hissəsi kimi planlaşdırmaq daha doğrudur.

Tez-tez verilən suallar

PageSpeed balı 100 olmalıdırmı?

Xeyr. Bal laboratoriya ölçməsidir və sıralamada birbaşa işlədilmir. Əhəmiyyətli olan sahə məlumatındakı üç göstəricinin "yaxşı" zonada olmasıdır. 100 bal uğrunda funksionallıqdan imtina etmək çox vaxt zərərlidir.

Düzəlişdən sonra nəticə nə vaxt görünür?

Laboratoriya ölçməsində dərhal. Sahə məlumatında isə 28 günlük pəncərə səbəbindən tam təsir bir aya yaxın müddətdə formalaşır. Search Console hesabatında dəyişiklik adətən 2–4 həftədən sonra görünməyə başlayır.

Mobil və masaüstü göstəriciləri fərqlidirsə hansı vacibdir?

Mobil. Google saytı əsasən mobil versiya üzərindən qiymətləndirir və trafikin böyük hissəsi də adətən mobildən gəlir. Masaüstündə yaxşı, mobildə zəif göstərici problem sayılır.

Şəkilləri gec yükləmək (lazy loading) həmişə faydalıdırmı?

Ekranın altındakı şəkillər üçün bəli. Amma ilk ekranda görünən əsas şəkli gec yükləmək LCP-ni pisləşdirir — o şəkil əksinə, prioritetlə yüklənməlidir. Bu, geniş yayılmış səhvdir.

Sürət üçün CDN lazımdırmı?

Auditoriya bir ölkədədirsə və server də orada yerləşirsə, CDN-in faydası məhduddur. Ziyarətçilər müxtəlif ölkələrdən gəlirsə və ya server uzaqdadırsa, CDN server cavab müddətini nəzərəçarpacaq dərəcədə azaldır. Yəni cavab auditoriyanın coğrafiyasından asılıdır.

Şəkilləri hansı ölçüdə hazırlamaq lazımdır?

Ekranda göstəriləcəyi ölçüdən iki dəfə böyük kifayətdir (yüksək piksel sıxlıqlı ekranlar üçün). Yəni 600 piksel enində göstərilən şəkil üçün 1200 piksellik fayl. Bundan böyüyü faydasızdır və yalnız yükü artırır.

Əlaqəli mövzular

• Texniki SEO — indeksləmə, sitemap və saytın texniki sağlamlığı.
• SEO nədir və necə işləyir — ümumi çərçivə.
• SEO bölməsi — bu mövzudakı bütün yazılar.
• Rəqəmsal marketinq və e-ticarət — sürətin dönüşümə təsiri.