SEO uchun saytni qanday tezlashtirish: Core Web Vitals cheklisti
Core Web Vitals — Google page experience reyting signali qismi sifatida rasmiy ishlatadigan uchta metrika: LCP yuklanish tezligi uchun, CLS vizual barqarorlik uchun, INP harakatlarga javobgarlik uchun javobgar. Uchalasi ham PageSpeed Insights va Search Console'dagi Core Web Vitals hisobotida o'lchanadi.
LCP: nega asosiy ekran tez paydo bo'lishi kerak
LCP (Largest Contentful Paint) — ko'rinadigan eng katta blokning chizilish vaqti: odatda bu hero-rasm, video-preview yoki katta sarlavha. «Yaxshi» chegara — 2,5 soniyagacha, «yaxshilash kerak» — 4 soniyagacha, 4 soniyadan yuqorisi — «yomon», va aynan shu toifa reytingga to'g'ridan-to'g'ri zarar yetkazadi.
Sekin LCP'ning asosiy sabablari: sarlavhadagi og'ir siqilmagan rasm, matn renderlanishini bloklovchi shrift (FOIT) va asosiy kontentdan oldin sinxron yuklanadigan tashqi skriptlar — chat vidjetlari, analitika hisoblagichlari, retargeting piksellari.
Amaliy qadamlar: hero-rasmni fetchpriority="high" atributi bilan WebP yoki AVIF'ga o'girish, shriftlarni font-display: swap orqali ulash, tashqi skriptlarni async yoki defer orqali asinxron yuklashga o'tkazish, statik fayllar uchun CDN'dan foydalanish — O'zbekiston uchun bu mintaqadan tashqaridagi hostingga nisbatan kechikishni sezilarli kamaytiradi.
CLS: nega sayt yuklanishda «sakramasligi» kerak
CLS (Cumulative Layout Shift) sahifa yuklanishi davomida elementlarning umumiy vizual siljishini o'lchaydi. «Yaxshi» chegara — 0,1 gacha, «yomon» — 0,25 dan yuqori. Foydalanuvchi matnni o'qishni boshlaydi, bir soniyadan keyin yuklangan rasm yoki reklama tufayli blok suriladi — bu CLS, va Google bunday siljishlarni dasturiy tarzda qayd etadi.
Asosiy manbalar: width va height atributlari yoki CSS aspect-ratio aniq belgilanmagan rasm va videolar, natijada brauzer joy oldindan zaxiralamaydi; keyinroq yuklanib matn kengligini o'zgartiradigan shriftlar; joy zaxiralanmagan dinamik kontent — bannerlar, cookie roziligi popaplari.
Amaliy qadamlar: media uchun har doim o'lchamlarni ko'rsatish yoki CSS'da aspect-ratio ishlatish, banner va popaplar uchun ular yuklanishidan oldin min-height orqali joy zaxiralash, foydalanuvchi harakatiga javob bo'lmasa, allaqachon chizilgan kontent ustiga yangi kontent qo'shmaslik.
INP: FID o'rniga javobgarlikning yangi metrikasi
INP (Interaction to Next Paint) 2024-yil martida FID o'rnini bosdi va faqat birinchi o'zaro ta'sirni emas, butun tashrif davomida foydalanuvchi harakati — teginish, bosish, matn kiritish — bilan interfeysning vizual javobi orasidagi kechikishni o'lchaydi. «Yaxshi» chegara — 200 ms gacha, «yomon» — 500 ms dan yuqori.
Yomon INP'ning asosiy sababi — JavaScript asosiy oqimidagi uzun vazifalar: og'ir analitika, mahsulot kartochkalaridagi murakkab hodisa handlerlari, katalog filtrlashdagi sinxron hisob-kitoblar. Asosiy oqim band bo'lgan vaqtda brauzer foydalanuvchi teginishiga javob bera olmaydi.
Amaliy qadamlar: uzun vazifalarni requestIdleCallback yordamida rejalashtirish yoki bo'laklarga bo'lish orqali qismlarga ajratish, filtr va qidiruvdagi kiritish handlerlarida debounce ishlatish, interfeysni bloklamasdan mumkin bo'lgan joyda og'ir hisob-kitoblarni Web Worker'ga o'tkazish.
Qanday o'lchash kerak: dala ma'lumotlari laboratoriyadan muhimroq
PageSpeed Insights ikki turdagi ma'lumotni ko'rsatadi: laboratoriya (Lighthouse, bitta simulyatsiya qilingan ishga tushirish) va dala (Chrome UX Report, so'nggi 28 kunlik real foydalanuvchi ma'lumotlari). Google reyting uchun aynan dala ma'lumotlarini ishlatadi — laboratoriya natijasi diagnostika uchun foydali, lekin algoritm ko'radigan narsani aks ettirmaydi.
Agar saytda CrUX'ga tushish uchun yetarli trafik bo'lmasa (odatda sezilarli tashrif hajmi kerak), Search Console dala ma'lumotlarini umuman ko'rsatmaydi va PageSpeed Insights'ning laboratoriya ko'rsatkichlariga hamda web-vitals.js orqali o'z RUM (real user monitoring)'ga tayanishga to'g'ri keladi.
Ishlar tartibi: optimallashtirishni nimadan boshlash kerak
Avval LCP — bu eng ko'zga tashlanadigan metrika va nisbatan oddiy tuzatishlardan eng katta o'sish beradi: rasmlarni siqish, critical CSS, heroni ustuvorlashtirish. Keyin CLS — odatda kodni jiddiy qayta ishlashsiz media o'lchamlarini aniq belgilash orqali tuzatiladi. INP eng uzoq tuzatiladi, chunki sahifaning JS-arxitekturasini tahlil qilishni talab qiladi va uni dasturchi bilan alohida iteratsiya sifatida rejalashtirish kerak.
Har bir tuzatishdan keyin nafaqat laboratoriya testidagi o'zgarishni tekshiring, balki CrUX dala ma'lumotlari yangilanishini kuting — bu 28 kungacha davom etadi, shuning uchun oraliq laboratoriya metrikasi haqiqiy reyting signalida xuddi shunday siljishni kafolatlamaydi.