INP ve JavaScript Yükü: Core Web Vitals Eşik Değerleri

Hızlı Özet (TL;DR)

Core Web Vitals, Google’ın bir web sayfasının gerçek kullanıcı deneyimini (Real User Monitoring - CrUX %75 yüzdelik dilim) ölçmek için kullandığı üç temel performans metriğidir: LCP (Yükleme Hızı), INP (Etkileşim Tepki Süresi) ve CLS (Görsel Kararlılık). Özellikle eski FID metriğinin yerini alan INP (Interaction to Next Paint), kullanıcının sayfadaki tüm tıklama, dokunma ve klavye etkileşimlerine tarayıcının 200 milisaniye altında görsel yanıt verip veremediğini denetler. Ağır JavaScript paketlerinin ana iş parçacığını (Main Thread) kilitlemesini önlemek için; Uzun Görevlerin (Long Tasks) parçalanması, hesaplama yükünün Web Worker arka plan iş parçacıklarına taşınması, DOM düğüm sayısının azaltılması ve Astro Statik Site Üretimi (SSG) ile gereksiz çerçeve kodlarının temizlenmesi zorunludur.

Core Web Vitals Eşik Değerleri ve %75 Persentil (CrUX) Ölçüm Standardı

Google Search Console ve PageSpeed Insights raporlarında bir sayfanın “İyi” (Yeşil) kabul edilmesi için, sayfayı ziyaret eden gerçek kullanıcıların en az %75’inin (75th Percentile) aşağıdaki hedef eşik değerlerini hem mobil hem de masaüstü cihazlarda karşılaması gerekir:

Core Web Vitals Metriği	Ölçtüğü Teknik Deneyim	İyi (Yeşil Hedef)	Geliştirilmeli (Turuncu)	Zayıf (Kırmızı)
LCP (Largest Contentful Paint)	Görüş alanındaki en büyük görsel veya başlık bloğunun çizilme süresi	≤ 2.5 saniye	2.5 sn – 4.0 sn	> 4.0 saniye
INP (Interaction to Next Paint)	Tıklama, dokunma ve tuş vuruşlarından sonraki kare çizimine kadar geçen süre	≤ 200 ms	200 ms – 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Sayfa yaşam döngüsü boyunca beklenmedik düzen kaymalarının toplam skoru	≤ 0.10 puan	0.10 – 0.25 puan	> 0.25 puan
TBT (Total Blocking Time - Lab)	Laboratuvar testlerinde (Lighthouse) INP’nin en yakın öncül göstergesi	< 200 ms	200 ms – 600 ms	> 600 ms

FID Neden Kaldırıldı ve INP (Interaction to Next Paint) Neden Çok Daha Zorlu?

Geçmişte kullanılan FID (First Input Delay - İlk Giriş Gecikmesi) metriği yalnızca kullanıcının sayfaya yaptığı ilk tıklamayı ölçüyor ve sadece olay işleyicinin (Event Handler) çalışmaya başlayana kadarki bekleme süresini hesaba katıyordu. Oysa modern web uygulamalarında asıl donmalar ilk tıklamadan sonra ve olay işleyicinin kendi kodunu çalıştırıp ekranı yeniden boyaması (Repaint) sırasında yaşanır.

INP (Sonraki Boyamayla Etkileşim) metriği ise kullanıcının sayfada geçirdiği tüm süre boyunca yaptığı her bir fare tıklamasını, mobil dokunuşu ve klavye girişini izler ve en yavaş gerçekleşen etkileşimi (veya çok sayıda etkileşim varsa 98. yüzdelik dilimdeki değeri) sayfanın INP skoru olarak kaydeder. Bir INP etkileşimi teknik olarak üç ardışık fazın toplamıdır:

1. Giriş Gecikmesi (Input Delay): Kullanıcı bir menü düğmesine tıkladığı anda tarayıcının Ana İş Parçacığı (Main Thread) başka bir JavaScript dosyasını ayrıştırmakla veya çalıştırmakla meşgulse, tıklama olayı kuyrukta bekler.
2. İşleme Süresi (Processing Time): Tıklamaya bağlı olan JavaScript olay dinleyicilerinin (click, pointerdown, keydown callback fonksiyonlarının) çalışması için geçen süredir.
3. Sunum Gecikmesi (Presentation Delay): JavaScript kodu DOM üzerinde bir değişiklik yaptıktan sonra tarayıcının yeni stilleri hesaplaması (Style Recalculation), yerleşimi kurması (Layout / Reflow), boyaması (Paint) ve pikselleri ekrana basması (Composite) için geçen süredir.

Bu üç fazın toplamı 200 milisaniyeyi aştığında kullanıcı arayüzün “takıldığını” hisseder ve sayfa Core Web Vitals denetiminden kalır.

JavaScript Ana İş Parçacığı (Main Thread) Blokajı ve Uzun Görevler (Long Tasks)

Tarayıcı mimarisinde HTML ayrıştırma, CSS stil hesaplama, sayfa çizimi (Rendering) ve JavaScript kodlarının yürütülmesi tek bir ana iş parçacığı (Single-Threaded Main Thread) üzerinde sırayla gerçekleşir. Ana iş parçacığını kesintisiz olarak 50 milisaniyeden uzun süre meşgul eden her JavaScript işlemine Uzun Görev (Long Task) adı verilir.

[ Ana İş Parçacığı ]: |--- 280ms Ağır JS Bundle Yürütme (Long Task) ---| -> [Tıklama İşleme] -> [Boyama]
                               ^
                   (Kullanıcı burada tıkladı: 220ms Giriş Gecikmesi!)

Yukarıdaki şemada görüldüğü üzere, 280 milisaniyelik tek bir blok JavaScript görevi çalışırken kullanıcı açılır menüye tıklarsa, tarayıcı o görev bitene kadar tıklamaya tepki veremez.

Uzun Görevleri Parçalama: scheduler.yield() ve Zaman Dilimleme

Ana iş parçacığını kilitleyen ağır döngüleri veya veri işleme fonksiyonlarını 50 milisaniyenin altındaki küçük parçalara bölmek (Yielding to the Main Thread), tarayıcıya arada bekleyen kullanıcı tıklamalarını işleme ve ekranı boyama fırsatı verir. Modern tarayıcılarda scheduler.yield() (veya geriye dönük uyumlulukla setTimeout / requestAnimationFrame) kullanılarak uzun görevler şu şekilde bölünür:

async function islemKuyrugunuCalistir(gorevListesi) {
  for (const gorev of gorevListesi) {
    gorev(); // Tekil adımı çalıştır

    // Ana iş parçacığına nefes aldır: Kullanıcı etkileşimi varsa önce onu çiz!
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise((resolve) => setTimeout(resolve, 0));
    }
  }
}

Ağır Hesaplamaları Web Worker Arka Plan İş Parçacığına Taşıma

Kurumsal B2B portallarda, ürün filtreleme ekranlarında, teknik maliyet hesaplayıcılarda veya Özel ERP & CRM ve İmalat Çözümleri arayüzlerinde büyük JSON veri setlerinin sıralanması, filtrelenmesi veya kriptografik doğrulama işlemleri ana iş parçacığında yapılmamalıdır. Web Workers API, JavaScript kodlarını ekran çiziminden tamamen bağımsız, işletim sistemi seviyesinde ayrı bir arka plan iş parçacığında (Background Thread) çalıştırır:

// main.js — Ana İş Parçacığı (Arayüz %100 akıcı kalır, INP < 30ms)
const filtreWorker = new Worker('/js/urun-filtre-worker.js');

document.querySelector('#kategori-secim').addEventListener('change', (e) => {
  // 1. Kullanıcıya anında görsel geri bildirim ver (Sonraki Boyama hemen gerçekleşir)
  durumGostergesiniGuncelle('Filtreleniyor...');

  // 2. Ağır veri işleme yükünü Web Worker'a devret
  filtreWorker.postMessage({ kategori: e.target.value });
});

filtreWorker.addEventListener('message', (e) => {
  sonuclariEkranaBas(e.data.filtrelenmisUrunler);
});

Bu mimari sayesinde arka planda 50.000 satırlık endüstriyel stok verisi filtrelenirken bile kullanıcı sayfadaki butonlara tıkladığında 0 ms giriş gecikmesi yaşar.

Sunum Gecikmesini (Presentation Delay) Azaltma ve DOM Boyutu Optimizasyonu

Bazen JavaScript kodunuz 10 milisaniyede biter ancak tarayıcının değişikliği ekrana boyaması 300 milisaniye sürer. Bu durumun temel nedeni aşırı şişkin DOM ağacı ve Layout Thrashing (Zoraki Senkron Yerleşim) hatalarıdır:

1. DOM Düğüm Sayısını 1.500 Altında Tutma: Hazır sayfa oluşturucu eklentiler (Page Builders) basit bir metin kutusu için bile 15 kat iç içe <div> üretir ve sayfadaki toplam HTML eleman sayısı 5.000’i aşar. Bir düğmeye tıklandığında tarayıcı 5.000 düğümün tamamında CSS kurallarını yeniden hesaplamak zorunda kalır. Yalın ve semantik HTML mimarisiyle DOM derinliği minimumda tutulmalıdır.
2. CSS content-visibility: auto Kullanımı: Uzun teknik makalelerde ve katalog sayfalarında ekranın alt kısmında kalan bölümlere content-visibility: auto; contain-intrinsic-size: auto 600px; uygulanarak tarayıcının görünmeyen alanlar için yerleşim ve boyama maliyeti harcaması engellenir.
3. Layout Thrashing Önleme: JavaScript içinde döngü kurarak bir elemanın önce offsetHeight değerini okuyup hemen ardından sınıfını/stilini değiştirmek tarayıcıyı saniyede onlarca kez zoraki yeniden çizime (Reflow) zorlar. Okuma ve yazma işlemleri mutlaka ayrıştırılmalıdır.

Üçüncü Parti Scriptler (Analytics, Tag Manager, Chat) ve Astro SSG Avantajı

Gerçek saha verilerinde (CrUX) INP puanını çökerten en yaygın suçlu, siteye kontrolsüzce eklenen üçüncü parti izleme kodları (Google Tag Manager, Facebook Pixel, ısı haritası araçları ve ağır canlı destek widget’ları) ile monolitik çerçevelerin hidrasyon (Hydration) yüküdür.

• Astro SSG ve Zero-JS Mimarisi: Geleneksel React/Vue/Next.js SPA sitelerinde tarayıcı önce tüm sayfanın JavaScript kopyasını indirip çalıştırana (Hydration) kadar sayfa tıklamalara geç yanıt verir. Maysa Yazılım’ın uyguladığı Astro Statik Site Üretimi (SSG) mimarisinde ise sayfalar varsayılan olarak 0 KB çerçeve JavaScript’i ile sunulur; menüler, akordeonlar (<details>/<summary>) ve geçişler donanım hızlandırmalı saf HTML/CSS ile çalıştığı için INP değeri 16–40 ms aralığında kalır.
• LCP ve CLS ile Bütüncül Uyum: Sayfanın LCP görselinde fetchpriority="high" kullanılması ve tüm görsellere açık width/height verilerek CLS’nin sıfırlanması, tarayıcı ana iş parçacığının ilk açılışta gereksiz yeniden yerleşim (Reflow) hesaplamalarıyla yorulmasını önleyerek INP performansını da doğrudan destekler.

Yüksek performanslı kurumsal portallardan Özel Yazılım Geliştirme projelerine ve güvenli sunucu altyapılarına (Ortak Dosya Sunucusu ve Yedekleme) kadar tüm dijital yatırımlarınızda kusursuz PageSpeed ve yeşil Core Web Vitals garantisi için Kurumsal Web Tasarım ve SEO Çözümleri sayfamızdan mühendislik desteği alabilirsiniz.

Sıkça Sorulan Sorular

Lighthouse testinde 95+ puan aldığımız halde Search Console’da INP neden “Geliştirilmeli” görünüyor?

Lighthouse (PageSpeed Insights üst kısmı) sayfanın sadece ilk açılış anını simüle eden bir laboratuvar testidir ve sayfada gerçek bir kullanıcı gibi menülere tıklamaz, formları doldurmaz veya sayfayı aşağı kaydırıp filtreleri çalıştırmaz. Search Console’daki Core Web Vitals raporu ise gerçek Chrome kullanıcılarının (CrUX) sayfa içindeki gerçek tıklama deneyimlerini ölçer. Eğer açılır menünüzde, filtre butonlarınızda veya üçüncü parti canlı destek aracınızda ağır bir JavaScript çalışıyorsa bu sorun yalnızca gerçek kullanıcıların tıklamasıyla (INP) ortaya çıkar.

Canlı destek (Chat) ve Google Tag Manager scriptlerinin INP’yi bozması nasıl engellenir?

Üçüncü parti analiz ve canlı destek scriptleri sayfa ilk yüklenirken ana iş parçacığını bloke etmemelidir. Canlı destek widget’ları sayfa açılışında gerçek kütüphaneyi yüklemek yerine hafif bir statik buton (Facade / Kukla Buton) göstermeli ve asıl script yalnızca kullanıcı o butona tıkladığında veya üzerine geldiğinde indirilmelidir. Analitik scriptleri ise defer niteliğiyle veya requestIdleCallback / Partytown (Web Worker izolasyonu) kullanılarak ana iş parçacığından uzaklaştırılmalıdır.

Mobil cihazlarda INP değerinin masaüstüne göre çok daha yüksek (kötü) çıkmasının sebebi nedir?

Masaüstü bilgisayarların çok çekirdekli güçlü işlemcileri 150 milisaniyelik bir JavaScript görevini 30 milisaniyede eritebilirken; orta ve giriş seviyesi mobil telefonların işlemci saat hızları (CPU) ve bellek bant genişlikleri masaüstüne göre 4 ila 6 kat daha yavaştır. Bu nedenle masaüstünde fark edilmeyen bir JavaScript paketi veya büyük DOM ağacı, mobil cihazlarda ana iş parçacığını 400–500 milisaniye boyunca kilitleyerek INP eşiğinin aşılmasına yol açar.

Kaynaklar

• web.dev — Core Web Vitals