INP Skoru Kötü Sayfalarda İlk Bakılması Gereken Etkileşim Darboğazları

INP’nin Üç Evresi ve Teşhis Önceliği: Nereden Başlamalısınız?

INP (Interaction to Next Paint), kullanıcının sayfayla etkileşime girdiği andan tarayıcının ekranı güncellediği ana kadar geçen toplam süreyi ölçer. Google’ın resmi INP metodolojisine göre bu süre üç ayrı evreden oluşur: giriş gecikmesi (input delay), işlem süresi (processing duration) ve sunum gecikmesi (presentation delay). Bu üç evrenin toplamı tek bir etkileşimin INP skorunu belirler.

Google’ın belirlediği eşik değerleri 2024’ten bu yana değişmemiştir: 200 ms altı iyi, 200–500 ms arası geliştirilmeli, 500 ms üzeri ise kötü olarak sınıflandırılır. INP, Mart 2024’te FID’in (First Input Delay) yerini alarak resmi Core Web Vitals metriği oldu; 2025–2026 döneminde Google’ın sıralama sinyalleri arasındaki ağırlığı netleşti. FID yalnızca ilk etkileşimi ölçerken INP, sayfa ömrü boyunca tüm etkileşimleri izleyerek en yavaş olanı raporlar — bu, INP’yi çok daha kapsamlı bir ölçüt yapar.

Teşhise nereden başlamalısınız? Alan verisi incelemelerinde kötü INP skorlarının büyük çoğunluğunda birincil darboğazın giriş gecikmesi olduğu gözlemlenmektedir — özellikle sayfa yüklenirken tetiklenen etkileşimlerde. Önerilen teşhis sırası: önce giriş gecikmesi, ardından işlem süresi, son olarak sunum gecikmesi. web-vitals attribution build kullanarak inputDelay, processingDuration ve presentationDelay değerlerini sourceURL ve invokerType bilgileriyle birlikte okuyabilirsiniz. Bu API düzeyinde terimleri teknik terimler sözlüğünden inceleyebilirsiniz.

Giriş Gecikmesi (Input Delay): Ana Thread’i Kilitleyen Başlıca Darboğazlar

Giriş gecikmesi, kullanıcının tıklaması ile tarayıcının bu girdiyi işlemeye başlaması arasındaki süreyi kapsar. Ana thread başka bir görevle meşgulse kullanıcı girdisi kuyruğa alınır ve bekletilir. 50 ms’yi aşan JavaScript görevleri — long task olarak adlandırılır — giriş gecikmesinin birincil kaynağıdır. Bir kullanıcı sayfa yüklenirken tıklarsa, o ana kadar birikmiş long task kuyruğu gecikmesi doğrudan etkileşim süresine yansır.

2025 Web Almanac verilerine göre mobil cihazlarda medyan JavaScript yükü yaklaşık 615 KB‘a ulaşmıştır. Bu büyüklükteki JS paketleri sayfa yükleme sürecinde ana thread’i uzun süre meşgul ederek özellikle ilk etkileşimlerde yüksek giriş gecikmelerine neden olur. Onload aşamasında tetiklenen kullanıcı etkileşimleri bu açıdan özellikle risklidir: tarayıcı aynı anda hem kaynakları değerlendirmek hem de girdiyi işlemek durumundadır.

Üçüncü taraf scriptler — analytics, chat widget ve reklam ağı kodları — sessiz fakat etkili giriş gecikmesi kaynaklarıdır. İzole test yöntemi şöyledir: şüpheli scripti geçici olarak devre dışı bırakın ve INP değerindeki değişimi ölçün; belirgin bir düşüş gözlemlenirse o script birincil şüphelidir. Gerçek kullanıcı giriş gecikmesi verisini toplamak için PerformanceObserver API veya web-vitals JS kütüphanesi attribution modu kullanılabilir; bu yöntem, lab ortamında yakalanması güç olan alan verisi darboğazlarını açığa çıkarır.

İşlem Süresi (Processing Duration): Event Listener ve Uzun JavaScript Görevleri

Giriş gecikmesi kısa olsa bile ağır event listener’lar işlem süresini uzatabilir. Bir kullanıcı tıklaması tetiklendiğinde bu olayla ilişkili tüm callback’ler sırayla çalışır; callback’ler ne kadar yoğunsa işlem süresi o kadar uzar. Dinamik bileşenlere ayrı ayrı listener eklenmesi zamanla birikir ve INP’yi olumsuz etkiler. Bu sorunu azaltmanın en doğrudan yolu event delegation kullanmaktır: olayları tek bir üst elemana dinletmek bireysel listener sayısını ve işlem yükünü önemli ölçüde azaltır.

Senkron XHR çağrıları ve yoğun DOM manipülasyonu da işlem süresini uzatan etkenlerdir; asenkron alternatifler ve toplu DOM yazma işlemleri bunu giderir. Uzun görevleri bölmek için Google’ın resmi optimizasyon rehberinin 2025 itibarıyla standart yöntem olarak önerdiği araç scheduler.yield() API‘sidir. Bu API, uzun bir görevi ana thread’i boşaltarak parçalara böler ve aradaki kullanıcı girdilerinin işlenmesine olanak tanır. setTimeout(0) ile kıyaslandığında scheduler.yield(), öncelik yönetimini tarayıcıya bırakarak daha öngörülebilir sonuçlar üretir.

Chrome DevTools Performance panelinde 50 ms’yi aşan görevler sarı üçgen işaretiyle long task olarak görünür. Hedef etkileşimi tetikleyerek kayıt alın; Bottom-Up veya Call Tree sekmesinden sorumlu fonksiyonu ve invokerType bilgisini okuyarak darboğaza neden olan event listener’ı kesin biçimde saptayabilirsiniz.

Sunum Gecikmesi (Presentation Delay): Layout Thrashing ve DOM Boyutunun Etkisi

JavaScript işlemi tamamlandıktan sonra tarayıcının ekranı güncellemesi de süre alır. Bu sunum gecikmesi büyük ve derin DOM yapılarında, zorla tetiklenen senkron layout hesaplamalarında ve render-blocking kaynaklarda belirgin biçimde artar. Google, 1.500’den fazla düğüm veya 32 seviyeden derin DOM yapısını performans sorunu olarak tanımlar; bu eşiklerin üzerinde her render döngüsü daha pahalı hâle gelir.

Layout thrashing, okuma-yazma döngülerinin tarayıcıyı zorla senkron layout’a itmesiyle oluşur. Bir döngü içinde stil okunur — layout hesaplanır — stil yazılır — layout geçersizleşir — tekrar okunur: her iterasyonda layout yeniden hesaplanır ve sunum gecikmesi katlanır. requestAnimationFrame kullanarak okuma ve yazma işlemlerini ayrı render çerçevelerine dağıtmak bu kısır döngüyü kırar ve sunum gecikmesini belirgin biçimde azaltır.

Render-blocking kaynaklar, iframe elementleri ve cross-origin scriptler de sunum gecikmesine katkıda bulunur. Cross-origin iframe’ler ana sayfa render döngüsüyle bağımsız olarak yüklenerek sunum zamanlamasını bozabilir. Bu kaynakları Chrome DevTools Performance panelinin Layers ve Rendering sekmeleriyle izleyebilir; gereksiz iframe’leri kaldırarak veya gecikmeli yükleyerek sunum süresini kısaltabilirsiniz.

Lab Verisi mi, RUM mu? Aynı Sayfada Farklı Darboğazlar Çıkabiliyor

INP teşhisindeki en yanıltıcı durumlardan biri şudur: Chrome DevTools’ta temiz görünen bir sayfa, CrUX ve PageSpeed Insights alan verilerinde yüksek INP skoruyla görünür. Bu tutarsızlığın temel nedeni, yarış koşullarının (race condition) lab ortamında tetiklenememesidir. Lab ortamı tek kullanıcı, temiz tarayıcı önbelleği ve yüksek donanım gücüyle çalışır. Gerçek dünyada aynı sayfa, 3G bağlantıyla, orta sınıf Android cihazda, onlarca sekmeyle birlikte açılır — bu koşullar, lab’da sessiz kalan uzun görevleri tetikler.

Sahadan somut bir örnek: DevTools’ta 150 ms çıkan bir e-ticaret ürün sayfası, gerçek kullanıcı RUM verisinde 600 ms’yi aşıyordu. Nedeni, yük altında bir üçüncü taraf chat widget’ının uzun göreviyle sayfa yükleme döngüsünün çakışmasıydı; bu çakışma yalnızca belirli cihaz-bağlantı kombinasyonlarında gerçekleştiğinden lab ortamında hiç görünmüyordu. Bu tür durumlar, lab verisine körü körüne güvenmenin optimizasyon kararlarını nasıl yanlış yönlendirebileceğini somut biçimde göstermektedir.

web-vitals JS attribution modu ve RUM araçları bu açığı kapatır: gerçek kullanıcı cihazlarından toplanan en yavaş etkileşimleri önceliklendirerek hangi sayfanın hangi kullanıcı segmentinde sorunlu olduğunu gösterir. PageSpeed Insights alan verisi ve CrUX 75. yüzdelik dilim skoru her zaman lab verisinden önce kontrol edilmelidir. İki veri türünü birlikte kullanmak idealdir: lab verisi hangi kodu düzelteceğinizi, alan verisi hangi sayfayı önceliklendireceğinizi söyler.

Adım Adım INP Darboğazı Teşhis Kılavuzu

1. PageSpeed Insights ile alan verisini kontrol edin: Sayfanın CrUX INP değerini ve 75. yüzdelik dilim skorunu inceleyin; lab verisiyle arasındaki farkı not edin. Büyük fark, sorunun düşük güçlü cihazlara veya yük altı koşullara özgü olduğuna işaret eder.
2. web-vitals attribution build ile evresel breakdown alın: inputDelay, processingDuration ve presentationDelay değerlerini sourceURL ve invokerType ile birlikte okuyun; baskın evreyi belirleyerek teşhis odağınızı daraltın.
3. Üçüncü taraf scriptleri izole edin: Analytics, reklam ve chat scriptlerini geçici olarak kaldırıp INP değerini karşılaştırın; belirgin düşüş yaşanırsa o script birincil şüphelidir ve erteleyerek yüklemeyi değerlendirin.
4. Chrome DevTools’ta long task’leri tespit edin: Hedef etkileşimi tetiklerken Performance panelinde kayıt alın; 50 ms üzeri sarı üçgen işaretli şeritler long task’tir ve alt panelden hangi fonksiyona ait olduğu okunabilir.
5. Event listener’ları denetleyin ve işlem süresini kısaltın: Ağır callback’leri event delegation ile sadeleştirin; scheduler.yield() ile uzun görevleri bölün ve işlem süresinin 50 ms altına düşüp düşmediğini doğrulayın.
6. DOM boyutunu ve layout thrashing’i kontrol edin: Toplam düğüm sayısı 1.500’ü veya derinlik 32 seviyeyi aşıyorsa DOM’u budayın; requestAnimationFrame ile okuma-yazma işlemlerini ayırarak zorla senkron layout’u ortadan kaldırın.
7. Optimizasyonu RUM verisiyle doğrulayın: web-vitals JS ile gerçek kullanıcı INP verisi toplayın; CrUX’a yansıması için 28 günlük yuvarlayan pencereyi takip edin ve alan verisi iyileşmesini onaylayın.

SEOYEN ile INP Sorunlarını Site Genelinde Sistematik Olarak Takip Etme

Tek bir sayfanın INP sorununu manuel teşhis etmek mümkündür; ancak onlarca veya yüzlerce sayfadan oluşan bir sitede sistematik bir yaklaşım zorunludur. SEOYEN’in site sağlığı denetimi ile tüm sayfalardaki hız sorunlarını proaktif olarak tespit edebilir, önem sırasına göre iyileştirme planı oluşturabilirsiniz.

Sıralama takibi bu sürecin kritik tamamlayıcısıdır: INP skoru kötü sayfaların organik trafik kaybıyla ilişkisini doğrudan görmek hangi sayfaya önce odaklanacağınızı netleştirir. INP’nin 2024–2026 döneminde Google sıralama sinyali olarak ağırlık kazanmasıyla hız sorunları ve sıralama kayıpları arasındaki korelasyon daha ölçülebilir hâle gelmiştir.

Ahrefs ve SEMrush kapsamlı SEO platformları olmakla birlikte Türkçe arayüz ve TL bazlı fiyatlandırma sunmaz. SEOYEN; site sağlığı denetimi, sıralama takibi ve teknik SEO araçlarını tek platformda Türk geliştirici ve SEO uzmanlarına yerelleştirilmiş biçimde sunar. Güncel fiyatlandırma bilgisi için fiyatlar sayfasını ziyaret edebilirsiniz.

Sıkça Sorulan Sorular