Core Web Vitals — Google o'lchaydigan uchta ko'rsatkich: LCP (asosiy kontent qachon ko'rindi), INP (bosishga javob qancha kechikdi), CLS (sahifa yuklanayotganda element qancha siljidi). Ularni tuzatish uchun laboratoriya testi emas, real foydalanuvchi ma'lumoti (CrUX) kerak: Google reytingda aynan shu maydon ma'lumotini ishlatadi. Quyida har bir ko'rsatkich uchun sabab va yechim.
Chegara qiymatlar va qayerdan qaraladi
Google uchala ko'rsatkich uchun "yaxshi" va "yomon" chegarasini rasman e'lon qilgan. Baholash o'rtacha qiymat bo'yicha emas, 28 kunlik foydalanuvchilarning 75-protsentili bo'yicha oladi — ya'ni foydalanuvchilarning to'rtdan uchi shu qiymatdan yaxshiroq tajriba olishi kerak.
| Ko'rsatkich | Yaxshi | Tuzatish kerak | Yomon |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Ma'lumot manbalari ikki xil. Maydon ma'lumoti (field) — Search Console'dagi "Core Web Vitals" hisoboti va PageSpeed Insights sahifasining yuqori qismi; reyting uchun ahamiyatli aynan shu. Laboratoriya ma'lumoti (lab) — Lighthouse va PageSpeed'ning pastki qismi; u sabab qidirishga qulay, lekin ballari maydon ma'lumotidan sezilarli farq qilishi normal. Search Console hisobotlarini o'qishni alohida maqolada ko'rib chiqqanmiz.
LCP: eng katta element nima va nega kech chiqadi
LCP — ekranning ko'rinadigan qismidagi eng katta element (odatda hero rasm, banner yoki katta sarlavha bloki) chizilgan payt. Uni tuzatishdan oldin qaysi element LCP ekanini aniqlang: Chrome DevTools → Performance → Timings qatorida "LCP" belgisi shu elementni ko'rsatadi.
Amaliyotda sabablar kamdan-kam kod optimizatsiyasida bo'ladi. Ko'p uchraydigani:
- Server javobi sekin (TTFB). Sahifa PHP/Node tomondan 1,5 sekundda chiqsa, LCP hech qachon 2,5 dan past bo'lmaydi. Avval keshni yoqing (sahifa keshi, so'ng CDN), keyin rasm bilan shug'ullaning.
- LCP rasmi kech topiladi. Agar rasm CSS
background-imageorqali yoki JavaScript bilan qo'yilsa, brauzer uni HTML o'qish paytida ko'rmaydi. Yechim:<img>tegi vafetchpriority="high". - LCP rasmiga
loading="lazy"qo'yilgan. Bu keng tarqalgan xato — lazy-loading faqat ekrandan pastdagi rasmlarga qo'yiladi. - Rasm o'lchami haddan tashqari katta. 3000 px kenglikdagi fayl 800 px joyga qo'yilsa, foydalanuvchi ortiqcha megabaytni yuklaydi.
<!-- Ekranning yuqori qismidagi asosiy rasm -->
<img src="/uploads/mini/1200x630/hero.webp"
width="1200" height="630"
fetchpriority="high" decoding="async" alt="...">
<!-- Ekrandan pastdagi rasmlar -->
<img src="/uploads/mini/600x400/card.webp"
width="600" height="400"
loading="lazy" decoding="async" alt="...">
INP: bosishdan keyingi kechikish
INP 2024-yil mart oyida FID o'rniga rasmiy ko'rsatkich bo'ldi va o'lchash usuli qattiqroq: FID faqat birinchi ta'sirning kutish vaqtini olardi, INP esa sahifadagi barcha bosish va klaviatura ta'sirlarining eng yomonlaridan birini oladi — kutish, qayta ishlash va keyingi kadr chizilishi bilan birga.
Sekin INP deyarli har doim bitta sababdan: asosiy oqim (main thread) band. Foydalanuvchi tugmani bosadi, lekin brauzer o'sha paytda uzun JavaScript vazifasini bajarayotgan bo'ladi va javob kechikadi. Tekshirish uchun DevTools → Performance da uzun vazifalarni (50 ms dan uzun bloklar) qidiring.
Amaliy yechimlar: kerak bo'lmagan uchinchi tomon skriptlarini olib tashlash (chat vidjet, ikki xil analitika, A/B test skripti — har biri asosiy oqimni bloklaydi); og'ir hisob-kitobni requestIdleCallback yoki Web Worker'ga ko'chirish; ro'yxatlarda hodisa tinglovchilarini har elementga emas, ota-elementga bir marta qo'yish. Reaktiv freymvorklarda esa ko'pincha muammo bitta bosishdan keyin butun daraxtning qayta chizilishida bo'ladi.
CLS: siljish qayerdan keladi
CLS — yuklanish davomida elementlarning kutilmagan siljishi. Odam uchun bu "tugmani bosmoqchi edim, reklama chiqib ketdi" tajribasi. Sabablari qisqa ro'yxatda:
- Rasm va videoga o'lcham berilmagan.
widthvaheightatributlari bo'lmasa, brauzer joy ajratmaydi va rasm kelganda matn pastga suriladi. Bu CLS'ning eng ko'p uchraydigan sababi. - Reklama va embed bloklari. Ularga oldindan minimal balandlik (
min-height) bering, hatto bo'sh turgan holatda ham. - Web-shrift almashuvi. Fallback shriftdan asosiy shriftga o'tishda matn balandligi o'zgaradi.
font-display: swapvasize-adjustbilan farqni kamaytiring. - DOM'ga yuqoridan element qo'shish. Cookie banneri, "yangi xabar" chizig'i — ular kontent ustiga qo'shilsa emas, ustidan (
position: fixed) chiqsa siljish bo'lmaydi.
CLS ni tuzatish odatda eng arzon ish: ko'p hollarda shablonga width/height qo'shish yetadi va ko'rsatkich bir deploy'da yaxshilanadi.
Qaysi sahifadan boshlash kerak
Barcha sahifani birdan tuzatish shart emas — Search Console CVW hisoboti sahifalarni guruhlarga (URL patterns) birlashtiradi va bitta shablonni tuzatsangiz, o'sha guruhdagi minglab sahifa birdan yaxshilanadi.
Tartib oddiy: eng ko'p trafik keladigan shablonni oling (odatda maqola sahifasi yoki mahsulot kartochkasi), uni tuzating, deploy qiling, keyin keyingisiga o'ting. Katalog va filtr sahifalari ko'pincha eng og'ir bo'ladi, lekin ularning bir qismi umuman indeksda kerak emas — bu haqda filtr sahifalari va index bloat maqolasida yozganmiz.
Natijani qachon ko'rasiz
Bu yerda ko'p odam adashadi. Deploy qilingandan keyin PageSpeed'ning laboratoriya bali darhol o'zgaradi, lekin Search Console'dagi hisobot 28 kunlik oynani ishlatadi. Ya'ni tuzatish real foydalanuvchilarga yetib borishi va oynaga to'lishi kerak.
Amaliy jadval: laboratoriya bali — darhol; PageSpeed'dagi maydon ma'lumoti — bir necha kundan keyin siljiy boshlaydi; Search Console'da guruh "yaxshi" holatga o'tishi — odatda bir necha hafta. Shu sababli har kuni qayta o'lchash foydasiz. Tuzatgandan keyin hisobotda "Validate fix" tugmasini bosing va kuting.
Nimani o'lchamaslik kerak
Bir nechta chalkashlik tez-tez uchraydi. Lighthouse'ning 100 balli umumiy bali reyting omili emas — u laboratoriya bali va Core Web Vitals'dan boshqa narsalarni ham o'z ichiga oladi. Mobil va desktop alohida o'lchanadi, va Google mobil ma'lumotni asos qiladi.
Yana bir jihat: Core Web Vitals — reyting omillari orasida kuchsizlaridan biri. Bir xil sifatdagi ikki sahifa orasida tanlovda ta'sir qiladi, lekin yomon kontentni yuqoriga chiqarmaydi. Shuning uchun tezlik ustida ishlashni umumiy texnik audit doirasida, indeksatsiya va kontent muammolari hal bo'lgandan keyin qilish to'g'riroq. Agar ishni tashqaridan qildirmoqchi bo'lsangiz, xizmatlar sahifasida qamrov ko'rsatilgan.
Ko'p so'raladigan savollar
Core Web Vitals ni yaxshilash reytingni ko'taradimi?
To'g'ridan-to'g'ri va kafolatlangan ko'tarish yo'q. Google buni sahifa tajribasi signali sifatida ishlatadi va o'zi hujjatlarda "yaxshi kontentning o'rnini bosmaydi" deb yozadi. Real foyda ko'proq konversiyada ko'rinadi: sekin sahifadan foydalanuvchi chiqib ketadi.
PageSpeed Insights nega har safar boshqa ball ko'rsatadi?
Chunki pastki qismdagi ball — laboratoriya testi, u har chaqirilganda serverning o'sha paytdagi holati va tarmoq shartlariga bog'liq. Qaror qabul qilish uchun yuqoridagi maydon ma'lumotiga (CrUX) qarang — u 28 kunlik real foydalanuvchi statistikasi va barqaror.
Yangi sayt uchun maydon ma'lumoti yo'q bo'lsa nima qilish kerak?
CrUX ma'lumoti chiqishi uchun sahifada yetarli trafik bo'lishi kerak. Trafik oz bo'lsa PageSpeed "ma'lumot yetarli emas" deydi — bu holda laboratoriya testiga va butun sayt bo'yicha ma'lumotga (origin-level) tayaning.
Bu ishlarni dasturchisiz o'zim qila olamanmi?
CLS bilan bog'liq qismini ko'pincha ha — rasm o'lchamlarini shablonga qo'shish va ortiqcha bannerlarni olib tashlash CMS ichida bajariladi. LCP'ning server tomoni va INP'dagi JavaScript optimizatsiyasi esa odatda dasturchi ishtirokini talab qiladi.
Tezlik ustida ishlashni bitta shablondan boshlang, o'zgarishni deploy qiling va bir necha hafta kuting. Uchala ko'rsatkichni birdan quvish o'rniga, eng yomon bo'lgan bittasini tanlash amalda tezroq natija beradi.