Google Core Web Vitals 2.0 ve INP (Interaction to Next Paint) Optimizasyonu

Google’ın hız kriterlerinde yeni standart INP (Interaction to Next Paint) oldu. Sayfanızın yalnızca hızlı yüklenmesi artık yetmiyor; kullanıcının tıkladığı butona, açtığı menüye ya da doldurduğu forma milisaniyeler içinde görsel yanıt vermesi gerekiyor. Bu yazıda INP’nin ne olduğunu, nasıl ölçüldüğünü ve INP optimizasyonu için uyguladığımız teknikleri kod örnekleriyle anlatıyoruz.

tufiworks olarak gereksiz script yüklerini temizleyerek ve asenkron veri akışları kurgulayarak web sitelerini performans zirvesine taşıyoruz. Aşağıda bu sürecin arkasındaki yöntemleri adım adım bulabilirsiniz.

INP (Interaction to Next Paint) Nedir?

Interaction to Next Paint, bir kullanıcının sayfayla etkileşime geçmesi (tıklama, dokunma veya klavye tuşuna basma) ile tarayıcının bu etkileşimin sonucunu ekrana çizmesi arasında geçen süreyi ölçen bir metriktir. INP, sayfa ziyareti boyunca gerçekleşen etkileşimleri gözlemler ve en yavaş etkileşimlerden birini (çok sayıda etkileşim olan sayfalarda aşırı uç değerler göz ardı edilerek) sayfanın genel yanıt verme skoru olarak raporlar.

Google, Mart 2024’te INP’yi Core Web Vitals setine dahil etti ve yalnızca ilk etkileşimin gecikmesini ölçen First Input Delay (FID) metriğinin yerine koydu. Sektörde bu değişim sıklıkla Core Web Vitals 2.0 olarak anılıyor; bu resmî bir Google adı olmasa da ölçüm yaklaşımındaki köklü değişikliği iyi özetliyor: Artık sadece “ilk izlenim” değil, ziyaretin tamamındaki etkileşim deneyimi değerlendiriliyor.

INP Hangi Aşamalardan Oluşur?

Her etkileşimin süresi üç parçanın toplamıdır. INP nasıl iyileştirilir sorusunun cevabı da bu üç aşamayı ayrı ayrı ele almaktan geçer:

• Girdi gecikmesi (Input Delay): Kullanıcı etkileşime geçtiğinde ana iş parçacığı (main thread) başka bir işle meşgulse, olay işleyicisinin çalışmaya başlaması beklenir.
• İşleme süresi (Processing Duration): Olay işleyicilerinizdeki JavaScript kodunun çalışması için geçen süre.
• Sunum gecikmesi (Presentation Delay): Kod tamamlandıktan sonra tarayıcının stil hesaplama, yerleşim (layout) ve boyama (paint) işlemlerini yapıp bir sonraki kareyi göstermesi için geçen süre.

İyi Bir INP Değeri Kaç ms?

Google’ın belirlediği eşik değerleri şöyledir:

• İyi: 200 milisaniye veya altı
• İyileştirilmesi gerekiyor: 200 ms ile 500 ms arası
• Zayıf: 500 milisaniyenin üzeri

Bu değerlendirme, gerçek kullanıcı verilerinin 75. yüzdelik dilimine göre yapılır. Yani “iyi” sınıfına girebilmek için sayfa ziyaretlerinin en az yüzde 75’inde INP değerinin 200 ms veya altında olması gerekir. Mobil ve masaüstü verileri ayrı ayrı değerlendirildiği için özellikle daha zayıf işlemcili mobil cihazlarda ölçüm yapmak önemlidir.

INP Neden Önemli? Google Sayfa Deneyimi ve Kullanıcı Algısı

Core Web Vitals, Google sayfa deneyimi sinyallerinin bir parçasıdır. Google, sıralamada içerik alaka düzeyinin hâlâ belirleyici olduğunu belirtse de sayfa deneyimi benzer kalitedeki sayfalar arasında fark yaratabilir. Daha da önemlisi, INP doğrudan kullanıcının hissettiği deneyimi yansıtır:

• Butona tıklayıp bir şey olmadığını düşünen kullanıcı tekrar tekrar tıklar ya da siteyi terk eder.
• Sepete ekle, filtreleme ve form gönderimi gibi kritik adımlardaki gecikmeler dönüşümleri olumsuz etkileyebilir.
• Hızlı yüklenen ama etkileşimde takılan bir site, kullanıcıda “yavaş site” algısı oluşturur.

Bu nedenle INP’yi bir SEO kalemi olmanın ötesinde, site hızı optimizasyonu ve kullanıcı deneyimi stratejisinin merkezine yerleştiriyoruz.

INP Nasıl Ölçülür?

INP bir etkileşim metriği olduğu için en güvenilir veri, gerçek kullanıcılardan toplanan saha verisidir (field data). Laboratuvar araçları ise sorunun kaynağını bulmak için kullanılır.

Saha Verisi (Gerçek Kullanıcı Verisi)

• PageSpeed Insights: Sayfanızın URL’sini girdiğinizde üst bölümde yer alan “Gerçek kullanıcılarınızın deneyimini öğrenin” alanı, Chrome User Experience Report (CrUX) üzerinden son 28 günün INP değerini gösterir.
• Google Search Console: Core Web Vitals raporu, INP sorunu yaşayan URL gruplarını mobil ve masaüstü olarak ayrı listeler.
• web-vitals kütüphanesi: Kendi analitik altyapınıza gerçek kullanıcı INP verisi göndermenizi sağlar.

web-vitals kütüphanesiyle temel bir ölçüm kurulumu:

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {

// metric.value: INP süresi (ms)

// metric.attribution: yavaş etkileşimin hangi öğede ve hangi aşamada yaşandığı

navigator.sendBeacon('/analytics', JSON.stringify({

value: metric.value,

target: metric.attribution.interactionTarget

}));

});

attribution sürümü, yavaşlığın hangi öğeden kaynaklandığını ve süreyi girdi gecikmesi, işleme süresi ve sunum gecikmesi olarak ayrıştırarak raporlar. Bu bilgi, optimizasyona nereden başlanacağını belirlemek için çok değerlidir.

Laboratuvar Verisi (Hata Ayıklama)

• Chrome DevTools Performance paneli: Sayfayla etkileşime geçerken kayıt alarak uzun görevleri (long tasks) ve etkileşim sürelerini detaylı inceleyebilirsiniz. CPU yavaşlatma (throttling) seçeneğiyle mobil cihaz koşullarını simüle etmenizi öneririz.
• Lighthouse: Standart sayfa yükleme analizi etkileşim içermediği için INP’yi doğrudan ölçmez; bunun yerine Total Blocking Time (TBT) metriği, ana iş parçacığının ne kadar meşgul olduğuna dair güçlü bir gösterge sunar. Lighthouse’un “timespan” modu ise kayıt sırasında yaptığınız etkileşimleri analiz edebilir.

INP Nasıl İyileştirilir? Uygulanabilir Teknikler ve Kod Örnekleri

INP sorunlarının büyük çoğunluğu ana iş parçacığını uzun süre meşgul eden JavaScript kodundan kaynaklanır. Bu yüzden JavaScript performans optimizasyonu, INP iyileştirmenin temelidir. Projelerimizde en sık uyguladığımız teknikleri aşağıda paylaşıyoruz.

1. Gereksiz Script Yüklerini Temizleyin

Her ek script, ana iş parçacığında yer kaplar. İlk adımımız her zaman mevcut yükü sadeleştirmektir:

• Kullanılmayan eklentileri, eski takip kodlarını ve tekrar eden kütüphaneleri kaldırın.
• Üçüncü taraf scriptleri (sohbet widget’ları, reklam ve analitik araçları) defer veya async ile yükleyin ya da kullanıcı etkileşimine kadar erteleyin.
• Kod bölme (code splitting) ile her sayfada yalnızca ihtiyaç duyulan JavaScript’i yükleyin.

2. Uzun Görevleri (Long Tasks) Bölün

50 ms’den uzun süren her JavaScript görevi “uzun görev” olarak kabul edilir ve bu süre boyunca tarayıcı kullanıcı etkileşimlerine yanıt veremez. Büyük işleri küçük parçalara bölüp aralarda ana iş parçacığına kontrolü geri vermek girdi gecikmesini belirgin şekilde azaltabilir:

function yieldToMain() {

if ('scheduler' in window && 'yield' in scheduler) {

return scheduler.yield();

}

return new Promise((resolve) => setTimeout(resolve, 0));

}

async function processItems(items) {

let lastYield = performance.now();

for (const item of items) {

processItem(item);

// Yaklaşık her 50 ms'de bir ana iş parçacığına nefes aldır

if (performance.now() - lastYield > 50) {

await yieldToMain();

lastYield = performance.now();

}

}

}

scheduler.yield() henüz tüm tarayıcılarda desteklenmediği için örnekte setTimeout tabanlı bir yedek çözüm kullanıyoruz.

3. Önce Görsel Geri Bildirim, Sonra Ağır İş

Kullanıcıya etkileşimin algılandığını hemen göstermek, INP için kritik önemdedir. Kritik olmayan işleri bir sonraki kare çizildikten sonra çalıştırabilirsiniz:

button.addEventListener('click', () => {

// 1. Anında görsel geri bildirim

button.classList.add('is-loading');

// 2. Ağır işi bir sonraki boyamadan sonraya ertele

requestAnimationFrame(() => {

setTimeout(() => {

updateCart();

sendAnalyticsEvent('add_to_cart');

}, 0);

});

});

4. Sık Tetiklenen Olaylarda Debounce Kullanın

Arama kutusu, filtreleme veya pencere yeniden boyutlandırma gibi saniyede onlarca kez tetiklenebilen olaylarda her tetiklemede ağır işlem çalıştırmak ana iş parçacığını kilitler. Debounce, işlemi kullanıcı yazmayı bıraktıktan sonra bir kez çalıştırır:

function debounce(fn, delay = 300) {

let timer;

return (...args) => {

clearTimeout(timer);

timer = setTimeout(() => fn(...args), delay);

};

}

const searchInput = document.querySelector('#search');

searchInput.addEventListener('input', debounce((event) => {

fetchResults(event.target.value);

}, 300));

5. Ağır Hesaplamaları Web Worker’a Taşıyın

Büyük veri setlerini filtrelemek, sıralamak veya işlemek gibi DOM’a erişim gerektirmeyen işler, ayrı bir iş parçacığında çalışan Web Worker’lara devredilebilir. Böylece ana iş parçacığı kullanıcı etkileşimlerine yanıt vermek için serbest kalır.

main.js

const worker = new Worker('/js/filter-worker.js');

filterInput.addEventListener('input', (event) => {

worker.postMessage({ products, query: event.target.value });

});

worker.onmessage = (event) => {

renderProductList(event.data);

};

filter-worker.js

self.onmessage = (event) => {

const { products, query } = event.data;

const q = query.toLowerCase();

const result = products.filter((p) => p.name.toLowerCase().includes(q));

self.postMessage(result);

};

6. Asenkron Veri Akışları Kurgulayın

Etkileşim sırasında senkron çalışan ağ istekleri veya büyük veri işleme adımları kullanıcıyı bekletir. Veri çağrılarını async/await ile asenkron hâle getiriyor, arayüzü önce iskelet (skeleton) görünümlerle güncelliyor, veriyi ise hazır olduğunda yerleştiriyoruz. Bu yaklaşım, etkileşim ile ilk görsel yanıt arasındaki süreyi kısaltır.

7. DOM Boyutunu ve Render Maliyetini Azaltın

Sunum gecikmesinin başlıca nedenlerinden biri, büyük ve karmaşık DOM yapılarıdır. Her etkileşimde tarayıcının yeniden hesaplaması gereken öğe sayısı arttıkça boyama süresi uzar:

• Gereksiz iç içe geçmiş öğeleri sadeleştirin.
• Uzun listelerde sanallaştırma (virtualization) kullanarak yalnızca görünen öğeleri render edin.
• Ekran dışındaki bölümler için CSS content-visibility: auto özelliğinden yararlanın.
• Döngü içinde ardışık okuma ve yazma yaparak zorunlu senkron yerleşime (layout thrashing) yol açmaktan kaçının.

Önce/Sonra: INP İyileştirmesini Nasıl Belgeliyoruz?

Bir optimizasyonun gerçekten işe yarayıp yaramadığını görmek için ölçülebilir bir karşılaştırma şarttır. Projelerimizde şu süreci izliyoruz:

1. Başlangıç kaydı: PageSpeed Insights’ta mobil ve masaüstü saha verisinin (INP, LCP, CLS) ekran görüntüsünü alıyor, Search Console’daki Core Web Vitals raporunu kaydediyoruz.
2. Sorunlu etkileşimleri tespit: web-vitals attribution verisi ve DevTools kayıtlarıyla en yavaş etkileşimleri ve bunlara neden olan scriptleri belirliyoruz.
3. Optimizasyon: Yukarıdaki teknikleri önceliklendirilmiş bir sırayla uyguluyoruz.
4. Sonuç kaydı: CrUX verisi 28 günlük kayan bir pencereyle hesaplandığı için değişikliklerin PageSpeed Insights saha verisine tam yansıması birkaç haftayı bulabilir. Bu sürenin sonunda aynı ekranların görüntülerini yeniden alarak karşılaştırma raporu hazırlıyoruz.

Kendi sitenizde de bu yöntemi uygulamanızı öneririz: Değişiklik öncesi ve sonrası PageSpeed Insights ekran görüntülerini saklamak, hem ekibinize hem de paydaşlarınıza ilerlemeyi somut olarak göstermenin en pratik yoludur.

INP Optimizasyonu Kontrol Listesi

• Saha verisini PageSpeed Insights ve Search Console üzerinden kontrol edin.
• Gerçek kullanıcı verisi için web-vitals kütüphanesini kurun.
• Kullanılmayan ve gereksiz üçüncü taraf scriptleri kaldırın veya erteleyin.
• 50 ms’yi aşan uzun görevleri bölün.
• Etkileşimlerde önce görsel geri bildirim verin.
• Sık tetiklenen olaylarda debounce uygulayın.
• Ağır hesaplamaları Web Worker’a taşıyın.
• DOM boyutunu küçültün ve render maliyetini azaltın.
• Sonuçları önce/sonra ekran görüntüleriyle belgeleyin.

Sonuç: Hızlı Yüklenmek Yetmez, Hızlı Yanıt Vermek Gerekir

Core Web Vitals’taki bu dönüşüm, performansı yalnızca “sayfa ne kadar hızlı açılıyor?” sorusundan çıkarıp “sayfa kullanıcıya ne kadar hızlı yanıt veriyor?” sorusuna taşıdı. INP optimizasyonu; doğru ölçüm, gereksiz script yükünün temizlenmesi ve akıllı JavaScript mimarisiyle ulaşılabilir bir hedeftir.

tufiworks olarak gereksiz script yüklerini temizleyerek ve asenkron veri akışları kurgulayarak web sitenizi performans zirvesine taşıyoruz. Sitenizin INP değerini analiz etmek ve somut bir iyileştirme planı oluşturmak isterseniz ekibimizle iletişime geçebilirsiniz.