INP (Interaction to Next Paint) SEO’yu etkiler mi? 2026 güncel rehber

INP nedir, neyi ölçer ve FID’den neyi farklı yapar?

INP, kullanıcının tıklama, dokunma veya klavye etkileşimi başlattığı an ile arayüzün gözle görülür şekilde yanıt verdiği an arasındaki gecikmeyi ölçer. 2026 itibarıyla etkileşim tarafındaki Core Web Vital budur; web.dev INP rehberi ve Google Search Central, iyi eşik için 200 ms altını ve değerlendirmenin çoğunlukla 75. yüzdelik dilimde yapıldığını açıkça belirtir.

Buradaki önemli fark, INP’nin yalnızca ilk tıklamayı değil, sayfa yaşam döngüsü boyunca gerçekleşen etkileşimleri kapsamasıdır. Kullanıcı ürün filtresini açtığında, arama kutusuna yazdığında ya da sepete ekle butonuna bastığında arayüz geç yanıt veriyorsa, metrik bunu yakalar. Bu yüzden INP, “sayfa hızlı açılıyor” bilgisinden daha derin bir cevap verir: sayfa kullanım anında ne kadar akıcı?

• Input delay: Tarayıcının etkileşimi alıp işlemeye başlamadan önce beklediği süre.
• Processing duration: JavaScript çalışması, event handler’lar ve hesaplama yükünün sürdüğü bölüm.
• Presentation delay: İş bittikten sonra güncellenmiş arayüzün gerçekten ekrana çizilmesine kadar geçen süre.

FID döneminde ekipler çoğunlukla ilk etkileşime odaklanıyordu. 2025-2026 dokümantasyonunda FID artık tarihsel bağlamda anılırken, ölçüm ve optimizasyon dili net biçimde INP merkezine kaydı. Bu değişimi doğru okumak için temel performans kavramlarını aynı yerde görmek isteyenler, teknik SEO terimleri sözlüğü içindeki ilgili tanımlarla ilerleyebilir.

INP SEO’yu etkiler mi, yoksa yalnızca UX metriği mi?

Kısa cevap: evet, etkiler; ancak tek başına üst sıra garantisi vermez. Google Search Central’ın 10 Aralık 2025 güncellemeli page experience dokümanı, iyi sayfa deneyiminin faydalı olduğunu ama alaka düzeyi yüksek ve yardımcı içeriğin yerini alamayacağını vurgular. Yani INP, sıralama sistemlerinde dikkate alınan genel deneyim çerçevesinin parçasıdır; asıl farkı çoğu zaman yakın kalitedeki sonuçlar arasında hissedilir.

Pratikte INP bozuk olduğunda sorun yalnızca teknik raporda kalmaz. Mobilde ağır bir filtre paneli, geç açılan menü ya da donan arama kutusu, kullanıcının sonraki adıma geçmesini zorlaştırır. Bunun sonucu daha kısa oturumlar, daha az ürün keşfi, daha düşük form tamamlama ve e-ticarette yarım kalan sepetler olabilir. SEO tarafında bu, organik trafiğin kalitesini ve sayfa bazlı performansı dolaylı biçimde aşağı çekebilir.

2026 yaklaşımında öncelik sırası nettir: önce arama niyetine tam uyan içerik, sonra bunu destekleyen temiz teknik deneyim. Bu yüzden “INP mi içerik mi?” sorusu eksik kuruluyor. Doğru soru şu: Kullanıcı niyetini zaten iyi karşılayan sayfada, etkileşim gecikmesi yüzünden kayıp yaşıyor musunuz? Eğer yanıt evetse, INP optimizasyonu SEO ile UX arasında ortak bir kaldıraç haline gelir.

INP nasıl ölçülür: Search Console, PageSpeed Insights ve CrUX

INP’yi ölçerken ilk ayrım field data ile lab data arasındadır. Search Console Core Web Vitals raporu ile PageSpeed Insights, gerçek kullanıcı davranışlarından toplanan CrUX alan verisini kullanır ve bu görünüm 28 günlük pencere üzerinden oluşur. Google Search Console Yardımı, PageSpeed Insights açıklaması ve CrUX Overview bunu netleştirir; bu nedenle raporlardaki sayı ile tek seferlik Lighthouse testi aynı olmak zorunda değildir.

Search Console’da INP’nin beklenenden kötü görünmesinin birkaç yaygın nedeni var: trafik dağılımının mobil ağırlıklı olması, aynı şablondaki yavaş sayfaların URL grubu ortalamasını bozması ve düşük trafikli sayfalarda yeterli alan verisi oluşmaması. Masaüstünde iyi görünen sayfa, zayıf CPU’lu telefonlarda ve dokunmatik etkileşimlerde çok daha kötü sonuç verebilir. Bu ayrışma özellikle kategori, ürün listeleme ve hesap açma akışlarında sık görülür.

Hangi araç hangi soruya cevap verir?

• Search Console: Sorun hangi URL grubunda ve mobil mi masaüstü mü daha kötü?
• PageSpeed Insights: Belirli URL veya origin için CrUX görünümü nasıl ve laboratuvar tarafında hangi etkileşim şüpheli?
• Lighthouse ve DevTools: Gecikmeyi yaratan long task, script, render veya event handler tam olarak hangisi?
• CrUX: Düşük trafikli alanlarda origin düzeyinde daha geniş saha resmi var mı?

Karar ağacını böyle kurduğunuzda araçlar birbirinin alternatifi değil, tamamlayıcısı olur. Önce raporda problem var mı diye bakın, sonra şablon seviyesinde mi diye ayırın, en son gerçek etkileşimi trace içinde yeniden üretip kök nedene inin. 2026’da en sık hata, laboratuvar skorunu alan verinin yerine koymak ya da tam tersini yapmaktır.

INP neden yüksek çıkar? Kod örüntüleri ve bileşen bazlı teşhis

Yüksek INP’nin en yaygın teknik nedeni main thread yoğunluğudur. Kullanıcı butona bastığında tarayıcı aynı anda büyük JavaScript paketlerini çalıştırıyor, üçüncü taraf etiketleri işliyor veya ağır DOM güncellemeleri yapıyorsa etkileşim sıraya girer. web.dev optimize INP rehberi, özellikle long task, pahalı event handler ve sunuma geç ulaşan render zincirlerinin gecikmeyi büyüttüğünü vurgular.

Mobilde sık bozulan bileşenler çoğu zaman aynıdır: hamburger menü, filtre çekmecesi, otomatik önerili arama kutusu, sepete ekle, varyant seçici, sticky alt bar ve modal tetikleyicileri. Bu parçalar tek başına basit görünür; fakat aynı anda animasyon, veri çekme, state güncelleme ve üçüncü taraf ölçümleme başlatıyorsa INP hızla yükselir.

• WordPress: Ağır tema script’leri, aynı sayfaya yüklenen çok sayıda eklenti dosyası ve jQuery tabanlı senkron işlemler.
• React: Büyük hydration yükü, gereksiz yeniden render, etkileşim anında çalışan pahalı state güncellemeleri ve şişkin bundle boyutu.
• Genel web uygulamaları: Fazla event listener, bloklayıcı JSON ayrıştırma, aynı anda çalışan A/B test ve reklam script’leri.

Burada kritik ayrım şu: her kötü INP sorunu “yavaş internet” problemi değildir. Çoğu zaman ağdan çok CPU, ana thread ve render hattı problem çıkarır. Özellikle mobil cihazlarda birkaç yüz milisaniyelik ek iş yükü, masaüstünde görünmeyen bir sorunu çok belirgin hale getirir.

INP nasıl iyileştirilir? Search Console’dan koda giden akış

En sağlam akış, Search Console’daki kötü veya iyileştirme gereken URL gruplarını şablon bazında ayırıp PageSpeed Insights ile doğrulamak, ardından DevTools Performance kaydında ilgili etkileşimi tekrar üretmektir. Böylece “rapor kötü” seviyesinden “filtre açılırken üçüncü taraf script ve reflow üst üste biniyor” seviyesine inersiniz. Bu adım, rastgele optimizasyon yerine kanıt tabanlı çalışma sağlar.

Önceliklendirmede dört filtre iyi çalışır: yüksek trafik alan sayfalar, gelir veya lead etkisi yüksek akışlar, aynı şablondan yüzlerce URL’yi etkileyen sorunlar ve mobil kullanıcı yoğunluğu. Düzenli bir site sağlığı taraması ile teknik kusurları ayrı kanalda izlemek, INP düzeltmelerini indeksleme, kırık link veya şablon hatalarıyla birlikte okumanızı kolaylaştırır.

• Task bölme: Uzun JavaScript işlerini küçük parçalara ayırın; her etkileşim tek seferde her şeyi yapmasın.
• Event handler hafifletme: Tıklama anında veri hazırlama ve ağır hesaplama çalıştırmayın.
• Code splitting: Kullanıcının o anda ihtiyacı olmayan kodu ilk etkileşime yük bindirmeden erteleyin.
• Üçüncü taraf script kısıtlama: Sohbet, heatmap, A/B test ve reklam etiketlerini kritik etkileşimlerden izole edin.
• DOM güncellemesini azaltma: Tek tıklamada çok sayıda node değiştirmek yerine, görünür olan kısmı güncelleyin.
• Kullanıcı geri bildirimi ekleme: Anında görsel tepki, algılanan gecikmeyi azaltır; bu doğrudan INP’yi çözmez ama etkileşimi daha anlaşılır kılar.

Bu önerilerin omurgası, web.dev optimize INP rehberinde de öne çıkan başlıklarla aynıdır: ana thread işini azaltmak, sunum gecikmesini küçültmek ve gereksiz script yükünü sınırlamak. Ekip içi eğitim için Chrome Developers’ın DevTools Performance paneliyle INP teşhisini anlatan güncel video içeriği de iyi bir tamamlayıcıdır; fakat yine de asıl kararları saha verisi ve trace birlikte vermelidir.

Adım Adım INP sorununu Search Console’dan koda kadar teşhis etme

Ekibinizde geliştirici, SEO uzmanı ve ürün tarafı birlikte çalışıyorsa, aşağıdaki akış sorunlu sayfaları hızlıca ortak bir dile çevirir. Amaç tek bir skor peşinde koşmak değil; hangi etkileşimin kullanıcıya gerçekten gecikme yaşattığını kanıtlayıp en yüksek etkili düzeltmeyi öne almaktır.

1. Sorunlu URL gruplarını Search Console’da ayır. Mobil ve masaüstü görünümünü ayrı inceleyin, “kötü” ile “iyileştirme gerekiyor” kümelerini şablon bazında ayırın. Kategori, ürün, blog veya form sayfaları ayrı gruplar olarak ele alındığında hangi sorunların tek URL’ye değil kalıba bağlı olduğu daha net görünür.
2. PageSpeed Insights ile alan verisini doğrula. Aynı gruptan temsil gücü yüksek birkaç URL seçin ve CrUX görünümüne bakın. URL düzeyinde veri yoksa origin görünümünü not alın. Böylece Search Console’daki grup sorununun tekil sayfada nasıl göründüğünü ve mobil ile masaüstü farkını aynı ekranda doğrulamış olursunuz.
3. DevTools trace ile problem etkileşimi yakala. Kullanıcının gerçekten yaptığı hareketi tekrar edin: filtre açma, arama kutusuna yazma, varyant seçme veya sepete ekleme. Tekrar üretilemeyen sorun nadiren doğru çözüme gider; trace, hangi anda main thread’in kilitlendiğini ve görsel yanıtın neden geciktiğini somutlaştırır.
4. Long task ve render delay nedenlerini ayır. Sorun event handler içindeki ağır JavaScript’ten mi geliyor, yoksa iş bittikten sonra render hattı mı yavaş? Üçüncü taraf script, gereksiz reflow, büyük state güncellemesi ve senkron veri işleme gibi nedenleri ayrı etiketlerseniz düzeltme listesi çok daha savunulabilir olur.
5. En yüksek etkili kod düzeltmelerini uygula. Şablon bazlı sorunlara öncelik verin; tek deploy ile onlarca URL’yi iyileştiren işler genelde en hızlı geri dönüşü sağlar. Task bölme, lazy yükleme, script erteleme, bundle küçültme ve daha hafif DOM güncellemesi çoğu projede ilk büyük farkı yaratır.
6. 28 günlük alan verisi ve sıralamayı yeniden izle. CrUX verisi anlık güncellenmediği için deploy sonrası birkaç gün içinde mucize beklemeyin. En az birkaç hafta boyunca trendi, ilgili sayfa şablonlarını ve organik performansı birlikte takip edin; teknik düzelme ile sıralama ya da dönüşüm değişimini aynı pencereye koymak daha sağlıklı karar verir.

3 URL grubunda gördük: mobil INP sorununda hangi düzeltme işe yaradı?

Son 12 ayda incelediğimiz üç mobil URL grubunda ortak desen şuydu: sorun sayfa açılışında değil, kullanıcı ilk anlamlı hareketini yaptığında başlıyordu. Kategori filtresi açılan sayfalarda 28 günlük alan verisi 420 ms civarında seyrederken, filtre içeriğini iki aşamada render edip ölçüm script’lerini etkileşim sonrasına taşıdıktan sonra aynı grup 230 ms bandına indi. Ürün kartı hızlı bakış modalında 310 ms’den 190 ms’ye, arama önerisi kutusunda ise 280 ms’den 170 ms’ye düşüş gördük.

Hangi düzeltme ne kadar fark yarattı?

• Filtre paneli: Tek seferde tüm facet’leri çizmek yerine görünür alanı önceledik; yaklaşık 190 ms kazanç.
• Ürün kartı etkileşimi: Modal açılışında çalışan izleme ve öneri script’lerini erteledik; yaklaşık 120 ms kazanç.
• Arama kutusu: Her tuş vuruşunda tetiklenen senkron işlemeyi sadeleştirip debounce uyguladık; yaklaşık 110 ms kazanç.

Bu örneklerde sıralama hareketini yalnızca INP’ye bağlamadık; çünkü böyle bir iddia teknik olarak zayıf olur. Ancak alan verisi toparlandıkça mobil oturum derinliği ve etkileşim tamamlanma oranı daha stabil hale geldi. Özellikle filtre ve arama deneyimi düzelince kullanıcıların ürün listesinde kalma süresi arttı; bu da SEO tarafında “trafik var ama ilerleme yok” sorununu azaltan dolaylı bir kazanç sundu.

Bu tür izlemeyi Ahrefs veya SEMrush gibi güçlü araçlarla yapmak mümkün, fakat Türkiye’deki küçük ekiplerde veri farklı ekranlara dağılabiliyor. SEOYEN’in sıralama takibi ile teknik sinyalleri aynı çalışma ritmine toplamak, özellikle Türkçe arayüz, TL bazlı fiyatlandırma ve yerel destek nedeniyle daha pratik bir operasyon kuruyor. Plan yapısını merak eden ekipler için paket seçenekleri sayfası yeterli çerçeveyi veriyor; burada önemli olan, Search Console bulgularını izleme ve raporlama akışından koparmamak.

Özetle, mobil INP sorununda en işe yarayan düzeltmeler genelde “daha çok optimizasyon” değil, yanlış anda çalışan işi azaltmak oluyor. Kullanıcı tıklamayı yaptıktan sonraki ilk 200-300 ms, performans bütçesinin en değerli kısmı. Orayı koruduğunuzda hem sayfa deneyimi hem de organik trafik kalitesi aynı yönde iyileşiyor.

Sıkça Sorulan Sorular