Veb sayt sürəti optimallaşdırılması – Core Web Vitals bələdçisi

Sayt sürəti niyə ziyarətçinin qalıb-qalmayacağına qərar verir?

Veb sayt sürəti artıq yalnız proqramçıların müzakirə etdiyi texniki mövzu deyil - bu, birbaşa biznes göstəricisidir. Google-un öz araşdırmaları göstərir ki, səhifə üç saniyədən çox yüklənərsə, mobil istifadəçilərin yarıdan çoxu geri qayıdıb rəqibə keçir. Bakı və Azərbaycan bazarında, istifadəçilərin bir neçə saniyə ərzində xidmət təminatçısı seçdiyi bir mühitdə, yavaş sayt Google Ads-də pul ödədiyiniz lidi itirməyin ən sürətli yoludur. Axtarış motorları bu səbirsizliyi sıralamaya da tərcümə edir: Core Web Vitals rəsmi ranqlama siqnalıdır, yəni məzmun eyni keyfiyyətdə olsa belə, yavaş səhifə daha sürətli rəqibin arxasında qalır.

ONE Studio-da bu təsiri dəfələrlə ölçmüşük. one.az saytının özündə mobil Largest Contentful Paint göstəricisi bir vaxtlar 8-13 saniyə arasında idi - çünki iki font provayderi paralel yüklənirdi və birinci paint zamanı ağır hero video oynayırdı. Dublikat font provayderini sildikdən, hero-nu poster şəkil ilə əvəz etdikdən və kritik CSS-i inline etdikdən sonra LCP üç saniyədən aşağı düşdü, bir ay ərzində üzvi konversiyalar üçdə birdən çox artdı. Bu bələdçi məhz həmin nümunəni öz saytınız üçün təkrarlamağınıza kömək edir.

Core Web Vitals nədir?

Core Web Vitals - Google-un real istifadəçi təcrübəsini qiymətləndirmək üçün istifadə etdiyi üç sahə-göstəricisidir. Bu göstəricilər Chrome istifadəçilərindən Chrome User Experience Report (CrUX) vasitəsilə toplanır və Google Search Console-un "Core Web Vitals" bölməsində raport verilir. Üç metrik üç sadə suala cavab verir: səhifə nə qədər sürətlə yüklənmiş görünür, girişə nə qədər tez reaksiya verir və yüklənərkən layout nə qədər sabitdir.

Metrik	Hədəf (Yaxşı)	Tipik uğursuzluq səbəbləri	Həlli yolu
LCP (Largest Contentful Paint)	< 2.5 san	Sıxılmamış hero şəkil, render-blok CSS, yavaş TTFB, ağır font-lar	LCP şəklini preload et, AVIF/WebP servis et, CDN istifadə et, kritik CSS-i inline et
INP (Interaction to Next Paint)	< 200 ms	Uzun JavaScript tapşırıqları, ağır üçüncü tərəf skriptləri, hydration xərci	Uzun tapşırıqları bölün, kritik olmayan JS-i defer edin, istifadə olunmayan kitabxanaları silin
CLS (Cumulative Layout Shift)	< 0.1	Ölçüsü olmayan şəkillər, sonradan enən banner-lər, gec yüklənən font-lar	width/height ilə yer saxlayın, font-display: optional istifadə edin, gec reklamları yuxarıda buraxmayın

Köhnə First Input Delay (FID) metriki 2024-cü ilin martında ləğv edildi və INP ilə əvəz olundu. INP yalnız ilk deyil, səhifənin bütün ömrü boyu hər qarşılıqlı əlaqənin gecikməsini ölçür. Komandanız hələ də FID izləyirsə, göstəriş panellərinizi indi köçürün.

Core Web Vitals-ı necə düzgün ölçürsən?

Ölçmənin iki növü var və onları qarışdırmaq ən çox rastlaşdığımız səhvdir. Lab data - saytın nəzarətli mühitdə, sabit şəbəkə və CPU sürətində yüklənməsi zamanı yaradılır. Field data - real istifadəçilərin faktiki təcrübəsidir. Google səhifələri sahə göstəriciləri əsasında sıralayır, ona görə də CrUX hələ pis performans göstərirsə, lab-da 100 balı heç bir məna daşımır.

• PageSpeed Insights (pagespeed.web.dev) - həm Lighthouse lab, həm də 28 günlük CrUX field data-nı yan-yana göstərir. Buradan başlayın.
• Chrome User Experience Report (CrUX) - əsas verilənlər bazası. BigQuery və ya CrUX API vasitəsilə tarixi trendlərə baxa bilərsiniz.
• Google Search Console Core Web Vitals hesabatı - URL-ləri şablon üzrə qruplaşdırır və hansı şablonların işə ehtiyacı olduğunu göstərir.
• WebPageTest.org - diaqnostik mikroskop. Waterfall görünüşü, filmstrip, bağlantı throttling, sorğu səviyyəsində detallar.
• Chrome DevTools Performance paneli - öz cihazınızda real qarşılıqlı əlaqəni profil edin. Web Vitals genişlənməsi brauzerdə canlı LCP, INP və CLS göstərir.

Yalnız Lighthouse-un yaşıl balının arxasınca qaçmayın. Lighthouse-da 98 alan, lakin orta səviyyəli Android-də real LCP-si zəif olan səhifə hələ də Google gözündə uğursuz səhifədir.

LCP-ni necə yaxşılaşdırırsan?

Largest Contentful Paint demək olar ki, həmişə şəkil, hero video poster və ya səhifənin yuxarısındakı böyük mətn blokudur. Bu ardıcıllıqla düzəldin:

1. Elementi tapın. DevTools Performance paneli və Web Vitals genişlənməsi bunu adlandırır. Təxmin etməyin.
2. Müasir formatda servis edin. AVIF JPEG-dən 40-50 faiz kiçikdir, WebP təxminən 25-30 faiz. next/image, Laravel Media Library konversiyalarını və ya build addımını istifadə edin.
3. Preload edin. <link rel="preload" as="image" fetchpriority="high" href="/hero.avif"> əlavə edin ki, brauzer CSS-i parse etməzdən əvvəl yükləməyə başlasın.
4. CDN + Brotli ilə çatdırın. Cloudflare, Bunny və ya Fastly regiondan kənar istifadəçilər üçün gedib-gəlmə vaxtını azaldır. Brotli mətn asset-lərində Gzip-ə nisbətən 15-20 faiz üstündür.
5. TTFB-ni düzəldin. TTFB 800 ms-dən yuxarıdırsa, heç bir şəkil hiyləsi sizi xilas edə bilməz. Full-page cache aktiv edin, PHP-FPM işçilərini artırın və ya müasir VPS-ə keçin.

INP-ni necə azaldırsan?

INP - JavaScript-ağır steklarda ən çox problem yaradan metrikdir. Yüklənmə zamanı bütün səhifəni hydrate edən React və ya Vue proqramı orta səviyyəli Android-də tez-tez 300 ms-dən yuxarı INP göstərir - Lighthouse 95 versə də. Praktiki həllər:

• Uzun JavaScript tapşırıqlarını scheduler.yield() və ya setTimeout(fn, 0) ilə bölün. 50 ms-dən uzun hər tapşırıq Long Task-dır.
• İstifadə olunmayan kitabxanaları silin. Bundle-ı next build --analyze və ya webpack-bundle-analyzer ilə audit edin. Moment.js-i date-fns və ya Intl API ilə əvəz edin. Lodash-ı fərdi importlarla əvəz edin.
• Kritik olmayan üçüncü tərəf skriptlərini defer edin. Google Tag Manager, chat widget-lər və reklam pixel-ləri birinci paint-də işə düşməyə ehtiyac duymur.
• Island və ya qismən hydration istifadə edin. Astro, Qwik və Server Components ilə Next.js App Router köhnə SPA-nın istifadə etdiyi JS-in bir hissəsini göndərir.

Şəkillərin WebP, AVIF və next/image ilə optimallaşdırılması

Şəkillər əksər saytlarda ən böyük asset sinfidir. Audit etdiyimiz saytların doxsan faizi hələ də 360 piksellik telefon ekranına 1920 piksellik JPEG və ya PNG göndərir. 2026-cı ildə müasir şəkil idarəçiliyi seçim deyil, məcburiyyətdir.

• AVIF-i əsas format, WebP-ni yedək, JPEG-i son çıxış yolu kimi istifadə edin. Hər üçü brauzer bazarının 99 faizini örtür.
• Cavabdeh mənbələri srcset və sizes ilə servis edin ki, telefon 480 piksellik faylı yükləsin, desktop orijinalını yox.
• Explicit width və height ilə ölçüləri qeyd edin - CLS-in qarşısını alır.
• Aşağıdakı şəkilləri loading="lazy" ilə lazy-load edin. LCP şəklini heç vaxt lazy-load etməyin, əvəzinə fetchpriority="high" istifadə edin.
• Next.js-də daxili next/image komponentini istifadə edin. Laravel-də Intervention Image və ya spatie/laravel-medialibrary konversiyalarından istifadə edin.

Font strategiyası: görünməz flaş olmadan sürətli mətn

Fontlar iki problem yaradır: yuxarıda mətn render edərlərsə LCP-ni bloklayırlar və fallback artıq paint edildikdən sonra çatdıqlarında CLS-ə səbəb olurlar. Həll xüsusi fontlardan imtina etmək deyil, onları proqnozlaşdırıla bilən şəkildə yükləməkdir.

• Fontlarınızı özünüz hostinq edin. Üçüncü tərəf provayderlər əlavə DNS lookup və TCP handshake tələb edir. WOFF2 fayllarını yükləyin, CDN-ə yerləşdirin və birbaşa @font-face istifadə edin.
• Faktiki dəstəklədiyiniz dillərə görə fontları subset edin. Latın plus Azərbaycan plus Kiril tam multi-script fayldan qat-qat kiçikdir.
• Body mətn üçün font-display: swap, yuxarıdakı sabit qalması istənilən mətn üçün font-display: optional istifadə edin.
• Əsas çəkini preload edin: <link rel="preload" as="font" type="font/woff2" crossorigin href="/fonts/inter-variable.woff2">.
• Eyni fontu iki provayderdən heç vaxt yükləməyin. Bu, one.az-ı LCP-nin səkkiz saniyəni keçməsinə səbəb olan konkret səhv idi.

CDN, HTTP/3 və Brotli

CDN bytelərinizi istifadəçiyə yaxınlaşdırır. Azərbaycan boyunca müştəri xidmət edən Bakı-əsaslı origin üçün düzgün istiləşdirilmiş Cloudflare cache adətən TTFB-ni yarıya endirir. CDN-i bunlarla birləşdirin:

• HTTP/3 (QUIC) - itkili mobil şəbəkələrdə daha az gedib-gəlmə. Cloudflare-də və ya müasir nginx-də aktiv edin.
• Brotli sıxılma - HTML, CSS, JS və SVG-də Gzip-dən 15-20 faiz kiçik. nginx-də brotli on; qoyun və ya Cloudflare Speed parametrlərində aktiv edin.
• Hash-lənmiş asset-lərdə uzun cache header-lər: Cache-Control: public, max-age=31536000, immutable.
• Stale-while-revalidate ilə CDN köhnəlmiş HTML-i servis edərkən fon-da təzəsini gətirir.

JavaScript bundle-nin azaldılması

300 KB gzipped-dən çox JavaScript bundle - xəbərdarlıq işarəsi, 500 KB-dan çox - böhrandır. Konkret addımlar:

• Bundle-nı analiz edin. Hər stekdə analiz aləti var: next build, Vite-in rollup-plugin-visualizer və ya Webpack Bundle Analyzer.
• Route-a görə code-split edin ki, istifadəçi yalnız açdığı səhifənin JS-ni yükləsin.
• İstifadə olunmayan export-ları tree-shake edin. ES modul və adlandırılmış import istifadə edin, heç vaxt import _ from 'lodash' deyil.
• Ağır asılılıqları əvəz edin. Nativ brauzer API-lərinə üstünlük verin: sadə hallarda axios yerinə fetch, query-string yerinə URLSearchParams.
• Müasir brauzerlərə module/nomodule pattern ilə müasir JavaScript göndərin.

Üçüncü tərəf skriptlərinin idarə edilməsi

Analitika, reklam pixel-ləri, chat widget-ləri, cookie banner-ləri, A/B test skriptləri, error tracker-lər - hər biri INP-də millisaniyələr və bundle-də kilobaytlar dəyər. Onları rəhmsizcə audit edin.

• Chrome DevTools > Network > Domain-də hər üçüncü tərəfi siyahılayın və hər birinə çağırış edin. Data-ya baxmayan varsa, tag-i silin.
• Analitikanı load hadisəsindən sonra yükləyin və ya server-side tagging istifadə edin.
• Chat widget-lərini istifadəçi scroll etdikdə və ya hover etdikdə açın. Intercom, Tawk və Crisp gecikdirilmiş inicializasiyanı dəstəkləyir.
• DOM-a toxunan hər şey üçün async-dan çox defer-ə üstünlük verin və eyni hadisələri raport edən çoxsaylı analitika kitabxanalarını qarışdırmayın.

Nümunə: one.az-ın LCP-si 8-13 saniyədən 3 saniyədən aşağıya

one.az əsas səhifəsi bizim öz ən pis nümunəmiz idi. Auditdə dörd üst-üstə düşən problem tapıldı: iki font provayderi paralel yüklənir, mobil-də 4.2 MB hero video avtoplay olunur, 340 KB render-blok CSS bundle və HTML üçün CDN cache yox. Düzəlişlər dörd iş gününə tamamlandı və Bakıda 4G-də orta səviyyəli Android cihazda bu əvvəl/sonra göstəriciləri verdi:

Metrik	Əvvəl	Sonra
LCP	8.4 - 13.1 san	2.6 - 2.9 san
INP	410 ms	160 ms
CLS	0.28	0.04
Bounce rate (mobil)	62 faiz	44 faiz

Ən böyük tək qazanc dublikat font provayderinin silinməsindən gəldi - o dəyişiklik təkbaşına LCP-ni dörd saniyədən çox azaltdı.

Daha dərinə getmək üçün

Rəsmi sənədlər üçün Google-un özünün saxladığı mənbələrə baxın: web.dev/vitals, PageSpeed Insights və Chrome DevTools Performance sənədləri. Xam sahə data-sı istəyirsinizsə, CrUX BigQuery data-seti publikdir.

Sürət optimallaşdırılması ONE Studio ilə

ONE Studio Azərbaycan və beynəlxalq müştərilər üçün Core Web Vitals auditləri və tam optimallaşdırma proqramları həyata keçirir. Auditimiz prioritetlənmiş düzəliş planı, CDN və hostinq baxışı, şəkil və font ötürməsi və mühəndislik komandanızın saxlaya biləcəyi JavaScript büdcəsi hazırlayır. Yayımladığımız müştəri saytları adətən 90+ mobil Core Web Vitals balları alır və bu balı real trafik altında saxlayır.

Saytınızı 3-5 dəfə sürətli etməyə hazırsınız? Sürətli əsas üzərində qurmaq üçün veb sayt hazırlanması xidmətini araşdırın, mövcud saytı düzəltmək üçün performans dəstəyi və texniki müşayiət ilə başlayın. Bu gün Bakıda ONE Studio ilə əlaqə saxlayın və Core Web Vitals-ı qırmızı xəbərdarlıqdan rəqabət üstünlüyünə çevirin.