INP (Interaction to Next Paint) Nedir ve Nasıl İyileştirilir?

Bir e-ticaret sitesinde ürün rengini değiştirmek için bir kare tıklıyorsunuz ama ekran bir buçuk saniye boyunca hiçbir şey yapmıyor gibi görünüyor. Tekrar tıklıyorsunuz, belki üçüncü kez daha. Sonunda sayfa tepki veriyor ama artık sinirlisiniz ve büyük ihtimalle sepete hiçbir şey eklemeden sekmeyi kapatıyorsunuz. Bu gecikmenin arkasındaki teknik neden, Core Web Vitals'ın en yeni üyesi olan INP (Interaction to Next Paint) ile doğrudan ilgili.

Bu yazıda INP nedir sorusunu, neden FID'in yerini aldığını, sitenizde hangi kod ve yapıların INP'yi kötüleştirdiğini ve bunu nasıl düzelteceğinizi anlatıyoruz. Özellikle çok sayıda filtre, form veya etkileşimli bileşen barındıran sitelerde bu metriği anlamak, kullanıcı kaybının gerçek nedenini bulmanıza yardımcı olacak.

Kısa tanım: INP (Interaction to Next Paint), kullanıcının bir sayfayla yaptığı etkileşimlerden (tıklama, dokunma, tuşa basma) ekranda görsel bir tepki oluşana kadar geçen süreyi ölçen bir Core Web Vitals metriğidir. Sayfanın ömrü boyunca gerçekleşen tüm etkileşimler arasından en yavaş olanlara yakın bir değer alınarak hesaplanır.

INP Nedir? FID'in Yerine Neden Geçti?

Mart 2024'te Google, yıllardır kullanılan FID (First Input Delay) metriğini resmi Core Web Vitals listesinden çıkarıp yerine INP'yi koydu. Bu değişikliğin nedeni oldukça mantıklıydı: FID yalnızca sayfadaki ilk etkileşimin, tarayıcının o etkileşimi işlemeye başlamasına kadar geçen gecikmeyi ölçüyordu. Yani hem çok dar bir pencereye bakıyordu hem de işlemin tamamlanma süresini değil, sadece başlama gecikmesini hesaba katıyordu.

INP çok daha kapsamlı: sayfanın tüm yaşam döngüsü boyunca yapılan her etkileşimi izler ve her biri için üç aşamayı birden ölçer:

1. 1Giriş gecikmesi: Tıklama gerçekleştiği an ile tarayıcının bu tıklamayı işlemeye başlaması arasındaki süre.
2. 2İşlem süresi: Tıklamaya bağlı kodun (event handler) çalışma süresi.
3. 3Sunum gecikmesi: İşlem bitip ekranın yeni kareyi gerçekten çizmesine kadar geçen süre.

Bu üç aşamanın toplamı, o etkileşimin gecikmesini oluşturur. Sitenizde onlarca hatta yüzlerce etkileşim olabilir (menü açma, filtre seçme, sekme değiştirme); INP bunların içinden en kötü senaryoyu temsil eden değeri raporlar. Bu yüzden INP, Core Web Vitals içinde sitenin gerçekten ne kadar tepkisel olduğunu en dürüst yansıtan metrik kabul edilir.

INP Eşik Değerleri

Bu değerleri sitenizde görmek için Search Console'daki "Önemli Web Verileri" raporuna ya da PageSpeed Insights sonuçlarındaki saha verisi bölümüne bakabilirsiniz. Laboratuvar testlerinde (Lighthouse) INP yerine genellikle "Toplam Engelleme Süresi" benzer bir sinyal olarak kullanılır, çünkü INP'nin gerçek anlamda ölçülebilmesi için gerçek kullanıcı etkileşimine ihtiyaç vardır.

INP'yi Kendi Sitenizde Nasıl Test Edersiniz?

Gerçek kullanıcı verisine ek olarak, sorunu geliştirme aşamasında yakalamak isterseniz Chrome DevTools'un Performance panelini kullanabilirsiniz. Bir kayıt başlatın, sitenizde birkaç tipik etkileşimi (menü açma, filtre seçme, form doldurma) gerçekleştirin ve kaydı durdurun. Zaman çizelgesinde kırmızı üçgenle işaretlenen bloklar uzun görevleri gösterir; bu bloklara tıkladığınızda hangi fonksiyonun veya hangi üçüncü taraf script'in ana iş parçacığını meşgul ettiğini adım adım görebilirsiniz. Tarayıcı uzantısı olarak sunulan performans ölçüm araçları da sayfa üzerinde anlık INP değerini küçük bir rozet olarak göstererek hızlı bir ön kontrol imkânı sunar.

INP'yi Kötüleştiren Başlıca Nedenler

Uzun JavaScript Görevleri ve Ana İş Parçacığı Tıkanıklığı

Tarayıcılar JavaScript'i genellikle tek bir ana iş parçacığında (main thread) çalıştırır. Bu iş parçacığı 50 milisaniyeden uzun süren bir görevle (long task) meşgulken kullanıcının tıklaması kuyrukta bekler. Ne kadar çok ve ne kadar uzun görev varsa, kullanıcı etkileşimleri o kadar gecikir. Bu, INP'yi kötüleştiren tek ve en büyük nedendir.

Örneğin Ankara merkezli bir yemek sipariş sitesinde, kullanıcı menüde bir ürünü sepete eklediğinde hem sepet toplamını yeniden hesaplayan hem de önerilen ürünler listesini güncelleyen ağır bir işlem aynı anda çalışıyorsa, düğmeye basıldıktan sonra ekranın tepki vermesi gözle görülür şekilde gecikir. Kullanıcı bunu "site takıldı" olarak yorumlar ve genellikle işlemi yarıda bırakır.

Üçüncü Taraf Scriptler

Canlı destek widget'ları, reklam ağları, A/B test araçları, ısı haritası yazılımları — bunların her biri kendi JavaScript'ini indirir ve çalıştırır. Genellikle sizin kontrolünüz dışında oldukları için ana iş parçacığını ne kadar meşgul ettiklerini fark etmek zordur, ama etkileri çoğu zaman kendi kodunuzdan daha büyüktür.

Gereksiz veya Aşırı Büyük Yeniden Render

Özellikle React, Vue gibi çerçevelerle kurulmuş sitelerde, bir durum (state) değişikliği gereğinden fazla bileşenin yeniden render edilmesine yol açabilir. Örneğin İzmir merkezli bir emlak sitesinde kullanıcı fiyat aralığı filtresini her sürüklediğinde yüzlerce ilan kartının anında yeniden hesaplanması, tipik bir INP sorunu örneğidir.

Büyük ve Karmaşık DOM Yapısı

Sayfada binlerce HTML öğesi varsa, tarayıcının stil hesaplama ve düzen işlemleri de o kadar uzar. Bu, özellikle sonsuz kaydırmalı listelerde veya filtrelenebilir büyük tablolarda sık görülür.

INP Nasıl İyileştirilir?

1. Uzun Görevleri Küçük Parçalara Bölün

Tek seferde çalışan büyük bir işlemi (örneğin bir listeyi sıralama veya büyük veri işleme), tarayıcının etkileşimlere ara sıra nefes alma fırsatı bulacağı küçük parçalara bölmek, algılanan tepki süresini büyük ölçüde iyileştirir.

2. Gereksiz JavaScript'i Azaltın

Kullanılmayan kütüphaneleri kaldırın, büyük paketleri sadece ihtiyaç duyulduğunda yükleyin (code splitting) ve sayfa ilk açıldığında gerekmeyen scriptleri erteleyin. Bir sayfanın ilk yüklemesinde ihtiyaç duymadığı her kilobayt JavaScript, potansiyel bir INP maliyetidir.

3. Üçüncü Taraf Scriptleri Denetleyin ve Erteleyin

Hangi üçüncü taraf scriptin ne kadar süre tükettiğini Chrome DevTools'daki Performance panelinden görebilirsiniz. Kritik olmayan scriptleri (canlı destek, bazı analiz araçları) defer niteliğiyle veya kullanıcı bir etkileşim başlattıktan sonra yükleyin.

4. Etkileşime Bağlı İşlemleri Sadeleştirin

Bir tıklama olayında hemen çalışması gereken kodu minimumda tutun; görsel olmayan, arka planda yapılabilecek işleri (loglama, analitik gönderimi) etkileşimin hemen sonrasına değil, tarayıcı boştayken çalışacak şekilde erteleyin.

5. DOM Boyutunu ve Karmaşıklığını Azaltın

Uzun listelerde sanal listeleme (virtualization) kullanarak yalnızca görünen öğeleri DOM'da tutun, geri kalanını render etmeyin. Bu hem INP'yi hem de genel sayfa performansını iyileştirir.

6. Sık Tetiklenen Olayları Sınırlayın

Arama kutusuna her harf yazıldığında, pencere yeniden boyutlandırıldığında veya sayfa kaydırıldığında tetiklenen olaylar (arama önerisi getirme, konum hesaplama gibi) çok sık çalışırsa ana iş parçacığını gereksiz yere meşgul eder. Bu tür olayları belirli bir bekleme süresinden sonra tek seferde çalıştıracak şekilde sınırlamak (debounce ve throttle teknikleri), hem sunucunuza giden gereksiz istekleri azaltır hem de tarayıcının etkileşimlere daha çabuk yanıt vermesini sağlar.

Üçüncü taraf scriptleri yönetirken dikkat etmeniz gereken temel yaklaşım şöyle görünür:

<!-- Sayfa çizimini ve ana iş parçacığını bloklayan yaklaşım -->
<script src="https://ornek-chat-widget.com/embed.js"></script>

<!-- Daha iyi: tarayıcıya bu script'in kritik olmadığını söyler -->
<script src="https://ornek-chat-widget.com/embed.js" defer></script>

<!-- Bağlantıyı önceden ısıtarak gecikmeyi azaltır -->
<link rel="preconnect" href="https://ornek-chat-widget.com">

INP Sorunları ve Çözümleri Özeti

Sık Yapılan Hatalar

• Sadece masaüstünde test etmek: Mobil işlemciler daha yavaş olduğundan INP sorunları mobilde çok daha belirgin ortaya çıkar.
• Üçüncü taraf script sayısını hiç denetlememek: Zamanla eklenen her yeni araç, bir kampanya için eklenen geçici bir widget dahil, birikerek INP'yi kötüleştirir.
• INP'yi yalnızca ilk yüklemede ölçmek: INP, sayfanın tüm kullanım süresi boyunca gerçekleşen etkileşimleri kapsar; kullanıcı sayfada uzun süre kalıp çok etkileşimde bulunduysa bu daha da önem kazanır.
• Sorunu sadece kod tarafında aramak: Bazen sorun sizin kodunuzda değil, entegre ettiğiniz bir reklam ağı ya da eklentidedir; her üçüncü taraf aracı ayrı ayrı test edin.
• Düşük seviye cihazlarda hiç test etmemek: Geliştirme sırasında kullandığınız güçlü bilgisayar, orta seviye bir telefonun yaşadığı gecikmeyi gizler; mümkünse gerçek bir orta segment telefonda da test edin.

INP dahil tüm Core Web Vitals metriklerinin birbiriyle nasıl ilişkili olduğunu görmek için CLS düzeltme ve LCP iyileştirme yazılarımıza da göz atmanızı öneririz; genellikle aynı kök neden (ağır ve kontrolsüz JavaScript) üçünü birden etkiler.

Sıkça Sorulan Sorular

INP ile FID arasındaki en büyük fark nedir?

FID yalnızca sayfadaki ilk etkileşimin başlama gecikmesini ölçüyordu; INP ise sayfanın tüm ömrü boyunca yapılan her etkileşimin işlenme ve ekrana yansıma süresini birlikte ölçer. Bu yüzden INP, gerçek kullanıcı deneyimini çok daha kapsamlı yansıtır.

INP skorumu nasıl ölçebilirim?

Gerçek kullanıcı (saha) verisi için Google Search Console'daki Önemli Web Verileri raporunu veya PageSpeed Insights'ın Chrome Kullanıcı Deneyimi Raporu bölümünü kullanabilirsiniz. Laboratuvar ortamında Chrome DevTools'un Performance panelinden manuel etkileşim testleri de yapabilirsiniz. Sitenizin genelinde hangi sayfa gruplarının en kötü INP değerlerine sahip olduğunu görmek için Search Console raporunu düzenli aralıklarla kontrol etmenizi öneririz.

Ağırlıklı olarak metin ve görselden oluşan statik bir sitede INP sorun olur mu?

Genellikle daha az sorun olur, çünkü az JavaScript daha az ana iş parçacığı yükü demektir. Ancak yoğun reklam, analiz scripti veya karmaşık menü/arama bileşenleri olan statik görünümlü sitelerde bile INP kötüleşebilir.

Kod bölme her sitede uygulanabilir mi?

Modern derleme araçlarının (Vite, Webpack, Next.js gibi) çoğu kod bölmeyi otomatik veya kolay yapılandırılabilir şekilde destekler. Basit statik sitelerde ise gereksiz scriptleri sayfa bazında yüklemek genellikle yeterlidir.

INP kötü olduğunda kullanıcılar bunu gerçekten fark eder mi?

Evet. 200 milisaniyenin üzerindeki gecikmeler insan algısında anlık hissini kaybettirmeye başlar; 500 milisaniye üzeri gecikmeler çoğu kullanıcı tarafından bilinçli olarak fark edilir ve genellikle tekrar tıklama, sekmeyi terk etme gibi davranışlara yol açar.

Sonuç

INP, sitenizin kullanıcıya canlı ve tepkisel hissettirip hissettirmediğinin en net göstergesidir. Uzun JavaScript görevlerini bölmek, gereksiz scriptleri temizlemek ve üçüncü taraf araçları sıkı denetlemek, çoğu sitede INP skorunu kısa sürede iyi seviyeye taşır. Bu iyileştirmeler genellikle tek seferlik bir proje değil, yeni özellik ve entegrasyon eklendikçe tekrar gözden geçirilmesi gereken sürekli bir bakım alışkanlığıdır.

Bu tür teknik iyileştirmeleri kendiniz uygulamak yerine uzmanlara bırakmak isterseniz, SeoPulse çözüm ekibiyle iletişime geçerek sitenizin INP dahil tüm performans sorunlarını sizin yerinize giderebiliriz.