Core Web Vitals ve INP Optimizasyonu: Alan Verisiyle Mühendislik

Metrikleri doğru tanımlamak: üç sayı, on bileşen

Core Web Vitals üç metrikten oluşur ancak her metrik tek bir olayı değil, bir zincirin toplamını ölçer. Optimizasyonun ilk kuralı, iyileştirilecek bileşeni izole etmektir; aksi hâlde ekipler rastgele eklenti kapatıp açan bir döngüye girer.

LCP (Largest Contentful Paint), görünür alandaki en büyük metin bloğu veya görselin boyandığı andır ve dört bileşene ayrılır: sunucunun ilk baytı göndermesi (TTFB), kaynağın keşfedilmesine kadar geçen yükleme gecikmesi, kaynağın indirilme süresi ve indirme bittikten sonra öğenin ekrana çizilmesine kadar geçen render gecikmesi. Saha verisinde LCP kötü olan sitelerin büyük kısmında suçlu görsel boyutu değil, TTFB ile keşif gecikmesidir.

CLS (Cumulative Layout Shift), beklenmedik düzen kaymalarının etki payı ile mesafe payının çarpımlarının en kötü oturum penceresindeki toplamıdır. Kullanıcı girdisinden sonraki 500 ms içinde gerçekleşen kaymalar sayılmaz; bu istisna, akordeon ve filtre gibi bilinçli etkileşimleri korur.

INP (Interaction to Next Paint), sayfadaki tüm tıklama, dokunma ve tuş etkileşimleri arasından en kötüye yakın olanın süresidir. Üç bileşeni vardır: girdi gecikmesi (ana iş parçacığı meşgul olduğu için olayın işlenmeye başlayamaması), işleme süresi (olay işleyicilerinin çalışması) ve sunum gecikmesi (stil, düzen ve boyama işlemleri). Hedef eşikler sırasıyla LCP için 2,5 saniye, CLS için 0,1 ve INP için 200 milisaniyedir; değerlendirme 28 günlük alan verisinin 75. yüzdeliğine göre yapılır.

Ölçüm mimarisi: CrUX, RUM ve laboratuvar

Üç veri kaynağının rolü birbirinden farklıdır ve karıştırıldığında yanlış kararlar üretir.

• CrUX (Chrome User Experience Report): Google'ın değerlendirmede kullandığı kaynaktır. Kaba taneli, 28 günlük hareketli pencereyle çalışır ve düşük trafikli URL'lerde veri sağlamaz. Karar verilecek metrik budur ancak teşhis için yavaştır.
• RUM (kendi gerçek kullanıcı ölçümünüz): web-vitals kütüphanesiyle toplanan olay verisidir. Şablon, cihaz sınıfı, ülke, bağlantı tipi ve hatta hangi DOM öğesinin sorumlu olduğu düzeyinde kırılım verir. Teşhisin bel kemiğidir ve etkiyi saatler içinde görmenizi sağlar.
• Laboratuvar (Lighthouse, WebPageTest): Tekrarlanabilir koşullarda hata ayıklama aracıdır. Skor bir hedef değil, bir termometre okumasıdır.

Doğru kurulum, RUM verisinin şablon etiketiyle (ürün detay, kategori, blog, hizmet, ana sayfa) birlikte toplanmasıdır. Bir e-ticarette LCP sorunu genellikle tüm sitede değil, tek bir şablonda yoğunlaşır; şablon kırılımı olmadan bu görülemez ve kaynak yanlış yere harcanır. INP tarafında ek olarak etkileşim hedefinin seçicisi (event.target) kaydedilmelidir; bu alan, "hangi buton yavaş" sorusunu tahminden çıkarır.

LCP: keşif gecikmesini yok etmek

Saha vakalarımızda LCP bütçesinin çoğu, tarayıcının LCP öğesini geç keşfetmesinden kaybedilir. Uygulanan kaldıraçlar sırasıyla:

Sunucu yanıt süresi

TTFB, LCP'nin tabanıdır; 800 ms'lik bir TTFB ile 2,5 saniyelik hedefe ulaşmak neredeyse imkânsızdır. Kenar önbelleği, nesne önbelleği ve veritabanı indeksleri bu kalemi çözer. Dinamik sayfalarda erken ipucu (103 Early Hints) veya HTML akışının parça parça gönderilmesi, sunucu düşünürken tarayıcının kritik kaynakları indirmeye başlamasını sağlar.

Kaynak önceliklendirme

Hero görselinin fetchpriority="high" ile işaretlenmesi ve <link rel="preload"> ile erken bildirilmesi, keşif gecikmesini tipik olarak birkaç yüz milisaniye kısaltır. Aynı ölçüde önemli olan ters yöndeki karardır: görünür alanın altındaki tüm görseller loading="lazy" almalı, hero görseli ise asla lazy olmamalıdır. CSS arka planı olarak tanımlanan hero görselleri en kötü senaryodur; çünkü tarayıcı bunları ancak CSS ayrıştırıldıktan sonra keşfeder.

Kritik render yolu

Render'ı bloke eden CSS ve senkron script'ler, LCP öğesi indirilmiş olsa bile boyamayı geciktirir. Kritik CSS'in satır içine alınması, kalanının asenkron yüklenmesi; script'lerin defer ile ertelenmesi standart uygulamadır. Web fontlarında font-display: swap ve alt kümeleme (subsetting), metin tabanlı LCP öğelerinde belirgin kazanç sağlar.

Görsel teslimi

Modern formatlar (AVIF, WebP), doğru srcset ve sizes tanımı, gereksiz büyük çözünürlüklerin engellenmesi. Bir mobil ekrana 2.400 piksel genişliğinde görsel göndermek, en iyi altyapıyı bile kullanışsız kılar.

INP: ana iş parçacığını boşaltmak

INP problemi neredeyse her zaman aynı cümleyle özetlenir: kullanıcı tıkladığında ana iş parçacığı başka bir işle meşguldür. Bu nedenle çözüm, JavaScript'i hızlandırmaktan çok, işi bölmek ve ertelemektir.

Uzun görevleri parçalamak

50 milisaniyeyi aşan her görev, o pencerede gelen etkileşimleri geciktirir. Ağır döngüler ve büyük liste render'ları scheduler.yield(), setTimeout(0) veya requestIdleCallback ile parçalanır. Kullanıcının görsel geri bildirim beklediği işlemlerde önce arayüz güncellenir, ağır hesaplama sonraki kareye bırakılır.

Olay işleyicilerini hafifletmek

Bir tıklama işleyicisinin içinde analitik gönderimi, düzen ölçümü ve durum güncellemesi arka arkaya yapıldığında işleme süresi kolayca 300 ms'yi aşar. Analitik çağrıları navigator.sendBeacon ile ayrıştırılır; düzen okuma ve yazma işlemleri gruplanarak zorunlu yeniden düzen (layout thrashing) engellenir.

Hidrasyon maliyeti

Bileşen tabanlı arayüzlerde ilk etkileşimin gecikmesinin başlıca nedeni, tüm sayfanın tek seferde hidrate edilmesidir. Aşamalı veya seçici hidrasyon, ada mimarisi (islands) ve etkileşimi olmayan bölümlerin tamamen statik bırakılması, INP'yi yapısal olarak düzeltir. Sunucu tarafında render edilen HTML'in erken gönderilmesi de girdi gecikmesini azaltır.

Üçüncü taraf yükü

Sohbet widget'ları, ısı haritaları, A/B test script'leri ve reklam etiketleri, ana iş parçacığında ölçülmeyen bir vergi yaratır. Etkin yöntem, etiket envanterinin çıkarılıp her etiket için "hangi karar bu veriye dayanıyor" sorusunun sorulmasıdır. Kalanlar kullanıcı etkileşimine kadar geciktirilir; ağır olanlar iframe içine alınarak ayrı bir iş parçacığına taşınır.

CLS: rezervasyon disiplini

CLS çözümü tek bir ilkeye indirgenebilir: her öğe, içeriği gelmeden önce yerini ayırtmalıdır.

• Tüm <img> ve <video> etiketlerinde width ve height öznitelikleri veya CSS aspect-ratio tanımı bulunmalıdır.
• Reklam ve gömülü içerik alanlarına minimum yükseklik verilir; boşsa alan çökmemelidir.
• Çerez bildirimi, duyuru çubuğu ve bildirim şeritleri içerik akışını itmeyecek şekilde konumlandırılır veya yer ayırtılarak sunulur.
• Web fontu geçişlerinde size-adjust ve yedek font metrik eşlemesi kullanılarak metin sıçraması engellenir.
• Animasyonlar top, height gibi düzen tetikleyen özelliklerle değil, transform ve opacity ile yapılır.

Tek başına görsel boyut özniteliklerinin eklenmesi, denetimini yaptığımız sitelerin çoğunda CLS'i eşik altına indirmeye yetmiştir; buna rağmen en sık atlanan maddedir.

Vaka analizi: B2B kurumsal sitede INP

Aşağıdaki veriler, ürün konfigüratörü bulunan bir üretim firması sitesinde yürütülen sekiz haftalık çalışmanın saha ölçümleridir.

Yapılan işler sırasıyla: kenar önbelleği ve nesne önbelleği kurulumu; hero görselinin CSS arka planından <img> etiketine taşınması ve yüksek öncelikle işaretlenmesi; konfigüratörün tek seferlik hidrasyondan etkileşim anında yüklenen ada bileşenine dönüştürülmesi; dört adet üçüncü taraf etiketinin kaldırılması, ikisinin etkileşime kadar geciktirilmesi; tüm görsellere boyut öznitelikleri eklenmesi; font alt kümeleme.

Dikkat çekici nokta, en büyük INP kazancının kod optimizasyonundan değil, etiket envanterinin temizlenmesinden gelmesidir. Ölçüm yapılmadan bu karar verilemezdi; ekip başlangıçta sorunun konfigüratör kodunda olduğunu varsayıyordu.

Regresyonu önlemek: performans bütçesi

Performans kazanımı, korunmadığı takdirde iki üç sürümde erir. Kalıcılık için üç mekanizma kurulur.

Performans bütçesi: Şablon başına maksimum JavaScript boyutu, maksimum istek sayısı ve hedef TTFB tanımlanır. Bütçe aşımı, sürümü otomatik uyarıya düşürür.

Sürekli entegrasyonda ölçüm: Her önemli şablon için otomatik laboratuvar testi çalıştırılır; eşik altına düşen değişiklikler incelemeye alınır. Laboratuvar burada karar değil, erken uyarı görevi görür.

Saha izleme ve uyarı: RUM verisinde şablon bazlı 75. yüzdelik değerler günlük izlenir; belirlenen eşiğin üzerine çıkıldığında uyarı üretilir. Böylece bir üçüncü taraf script'inin sürüm çıkarması gibi dışsal bozulmalar da yakalanır.

Bu üç mekanizma birlikte çalıştığında performans, dönemsel bir kampanya olmaktan çıkıp ürün kalitesinin ölçülen bir boyutuna dönüşür.

Öncelik sıralaması ve iş etkisi

Sınırlı geliştirme kaynağıyla çalışan ekipler için etki/maliyet sıralaması genellikle şu şekildedir: önce TTFB (tüm metrikleri aynı anda iyileştirir), sonra üçüncü taraf envanteri (kod değişikliği gerektirmez), ardından görsel teslimi ve boyut öznitelikleri, en son mimari hidrasyon değişiklikleri. Bu sıra izlendiğinde ilk dört haftada saha verisinde görünür iyileşme elde edilir ve proje içeride destek bulmaya devam eder.

Son olarak, Core Web Vitals çalışmasını yalnızca sıralama kaygısıyla gerekçelendirmek stratejik bir hatadır. Etkileşim gecikmesinin 500 ms'den 150 ms'ye inmesi, kullanıcının form doldurma ve sepete ekleme davranışını doğrudan değiştirir; bu, arama motoru etkisinden bağımsız ve genellikle daha büyük bir kazançtır. Teknik altyapının tarama tarafındaki karşılığı için crawl bütçesi ve log analizi rehberimizi, kapsamlı denetim süreci için teknik SEO hizmeti sayfamızı inceleyebilirsiniz.

Şablon bazlı teşhis şablonu

Bir sitede performans çalışmasına başlarken en verimli ilk çıktı, aşağıdaki gibi doldurulan bir teşhis tablosudur. Tablo, hangi şablonun kaç oturum ürettiğini ve bu oturumların metrik dağılımını yan yana koyduğu için önceliklendirmeyi tartışmadan çıkarır.

Bu tabloda görülen tipik desen şudur: en kötü INP değeri en çok trafik alan şablonda değil, dönüşümün gerçekleştiği şablondadır. Trafik ağırlıklı önceliklendirme yapan ekipler bu nedenle en değerli iyileştirmeyi en sona bırakır. Doğru yaklaşım, oturum payını gelir payıyla birlikte ağırlıklandırmaktır.

Mobil cihaz sınıfı gerçeği

Saha verisinin en çok göz ardı edilen kırılımı cihaz sınıfıdır. Türkiye'deki organik mobil trafiğin önemli bir bölümü, orta ve alt segment Android cihazlardan gelir; bu cihazların tek çekirdek performansı, geliştirici masasındaki dizüstü bilgisayarın üçte biri ile beşte biri arasındadır. Aynı JavaScript paketi, geliştirici cihazında 90 ms'de çalışırken sahada 400 ms sürebilir.

Bu farkı görünür kılmanın iki pratik yolu vardır. Birincisi, laboratuvar testlerinin dört kat CPU kısıtlaması ve yavaş 4G profiliyle çalıştırılmasıdır; bu, orta segment cihaz davranışına makul bir yaklaşım verir. İkincisi, RUM verisinde navigator.hardwareConcurrency ve bellek bilgisine göre cihaz sınıfı etiketi tutmak ve metrikleri bu kırılımda raporlamaktır. Bir projede genel INP değeri eşiğe yakınken, alt segment cihaz kırılımında değerin iki katı çıkmış ve gerçek sorun ancak bu kırılımda görünür olmuştu.

Pratik sonuç: JavaScript bütçesi masaüstü deneyimine göre değil, sahadaki medyan cihaza göre belirlenmelidir. Aynı işlevi yarı boyutlu bir paketle sunmak, çoğu zaman kod optimizasyonundan daha büyük kazanç sağlar.

Ölçüm kurulumu: pratik uygulama notları

RUM kurulumunda sık yapılan hatalar sonuçları kullanılamaz hâle getirir. Aşağıdaki notlar, üretimde doğrulanmış bir kurulumun asgari gereklerini içerir.

• Olayları sayfa kapanışında gönderin. INP değeri oturum boyunca güncellenir; erken gönderilen ölçüm gerçek en kötü değeri kaçırır. visibilitychange olayında sendBeacon ile gönderim standarttır.
• Şablon etiketini sunucu tarafında basın. İstemci tarafında URL desenine bakarak tahmin etmek, çok dilli ve parametreli yapılarda hatalı sınıflandırma üretir.
• Öğe bilgisini saklayın. LCP için element, INP için etkileşim hedefi ve olay tipi kaydedilmezse teşhis aşamasında yeniden ölçüm yapmak gerekir.
• Örnekleme oranını dikkatli seçin. Düşük trafikli şablonlarda tam örnekleme, yüksek trafikli şablonlarda oransal örnekleme maliyeti dengeler.
• Bot trafiğini ayıklayın. Otomatik test ve tarayıcı botları p75 değerlerini gerçek dışı biçimde iyileştirebilir.

Kurulum tamamlandıktan sonra ilk iki hafta yalnızca veri toplanır ve hiçbir değişiklik yapılmaz. Bu sabır, sonraki tüm iyileştirmelerin etkisini kanıtlanabilir kılan ölçüm temelini üretir.

Karar çerçevesi: neyi ne zaman yapmalı

Aşağıdaki karar kuralları, sahadaki teşhise göre doğrudan uygulanabilir.

• TTFB > 600 ms ise: önce altyapı. Görsel ve script optimizasyonu bu durumda ölçülebilir kazanç üretmez.
• LCP kötü ama TTFB iyi ise: keşif gecikmesine bakın; hero kaynağının HTML içinde erken görünür olduğundan emin olun.
• INP kötü ve etkileşim hedefi filtre/menü ise: olay işleyicisini bölün, ağır DOM güncellemelerini sanallaştırın.
• INP kötü ve hedef form alanı ise: her tuş vuruşunda çalışan doğrulama ve analitik çağrılarını geciktirin.
• CLS kötü ve kayma üstte ise: duyuru çubuğu, çerez bildirimi veya font geçişi; alt bölgede ise lazy yüklenen görseller ve gömülü içerik.
• Metrikler iyi ama dönüşüm düşük ise: sorun performans değil; arayüz ve içerik akışına geçin.

Bu çerçeve, performans çalışmasını deneme yanılma döngüsünden çıkarıp öngörülebilir bir mühendislik sürecine dönüştürür. Her adımın etkisi ayrı ayrı ölçüldüğü için hangi yatırımın karşılığını verdiği de netleşir; bu, bir sonraki dönemin bütçe görüşmesinde en güçlü argümanınız olur.

Sık sorulan üç itiraz ve teknik yanıtları

"Sitemiz zaten hızlı, kullanıcı şikâyeti yok." Şikâyet, performans sorunlarının en geç gelen göstergesidir; kullanıcı yavaş sayfayı bildirmez, terk eder. Alan verisinde 75. yüzdelik değere bakıldığında, geliştirici deneyimiyle gerçek kullanıcı deneyimi arasında çoğu projede iki-üç kat fark bulunur.

"Skorumuz yeşil, iş bitti." Laboratuvar skoru tek bir koşulun fotoğrafıdır. Aynı sitenin CrUX verisi, cihaz ve şebeke dağılımı nedeniyle kırmızıda olabilir. Karar daima 28 günlük saha verisiyle verilir.

"Bu iş pazarlamanın değil, yazılımın işi." Performans bir kesişim alanıdır: etiket envanteri pazarlamanın, hidrasyon mimarisi yazılımın, görsel bütçesi tasarımın sorumluluğundadır. Tek bir ekibe devredildiğinde çalışma ya başlamaz ya da sürdürülemez. Berpel projelerinde bu nedenle performans bütçesi, sürüm sürecinin ortak kontrol maddesi olarak tanımlanır ve her sürümde birlikte gözden geçirilir.

Özet: ölçülmeyen performans yönetilemez

Core Web Vitals çalışmasının tamamı üç cümleye indirgenebilir. Kararı laboratuvar skoru değil, şablon ve cihaz kırılımıyla toplanmış saha verisi verir. İyileştirme sırası altyapıdan (TTFB) başlar, üçüncü taraf envanteriyle devam eder, mimari değişikliklerle biter. Kazanım performans bütçesi, sürekli entegrasyon kontrolü ve saha uyarılarıyla korunmadığı sürece birkaç sürüm içinde geri alınır. Bu üç ilkeyi işleten ekipler, aynı geliştirme bütçesiyle rakiplerinden belirgin biçimde daha hızlı bir ürün çıkarır ve bu farkı dönüşüm oranlarında somut olarak görür.