--- title: "INP nedir?" author: Androverse author_url: https://androverse.com.tr/yazar/androverse publisher: Androverse updated_at: 2026-10-15 url: https://androverse.com.tr/sozluk/inp language: tr --- # INP nedir? INP, bir sayfanın kullanıcı etkileşimlerine görsel yanıt verme gecikmesini değerlendiren etkileşim metriğidir. Diğer adlar: Interaction to Next Paint. ## Nerede işine yarar? Girdi gecikmesi, olay işleme ve sonraki çizime kadar bekleme birlikte rol oynar. Uzun görevler, yoğun hesaplama veya büyük render işi yanıtı geciktirebilir. Yalnız açılış hızına bakmak etkileşim sırasında yaşanan sorunu göstermeyebilir. ## Bir cümlede uygulaması Arama alanına yazıldığında yüzlerce kaydı gereksiz yeniden hesaplayan davranışı incelemek. ## Neyle karıştırılmamalı? INP ile laboratuvarda ölçülen Total Blocking Time ilişkili olabilir; aynı metrik değildir. ## Dokundun. Ekran seni duydu mu? Bir ürün listesindeki filtreye basıyorsun. Düğme uzun süre değişmiyor, liste de aynı görünüyor. İşlemin başlayıp başlamadığını anlayamadığın için yeniden basıyorsun. INP, sayfanın kullanıcı etkileşimlerine ne kadar hızlı görsel yanıt verdiğini değerlendiren bir ölçüdür. Yalnız ilk tıklamayı değil, ziyaret boyunca oluşan uygun etkileşimleri ele alır. Hızlı açılan bir sayfanın sonradan ağırlaşması bu yüzden ayrı bir performans konusudur. Gecikme düğmenin olay işleyicisinden önce başlayabilir. Tarayıcının ana iş parçacığı başka bir uzun işi bitiriyorsa kullanıcının girdisi bekler. Ardından olayla ilgili kod çalışır; son olarak yeni görüntünün çizilebilmesi gerekir. Bu üç bölüm farklı nedenlerle uzayabilir. Büyük bir veri listesini aynı anda hesaplamak, fazla bileşen güncellemek veya gereksiz yerleşim hesapları yapmak benzer hissi üretse de çözüm aynı olmayabilir. Bir sözlük aramasını düşün. Kullanıcı her harfi yazdığında bütün uzun açıklamaları tarayıcıya taşıyıp yeniden işlemek yerine arama için gereken sınırlı veriler kullanılabilir. Sonuçlar anlaşılır bir boyutta gösterilebilir. Ağ üzerinden sorgu gerekiyorsa bekleme durumu açıkça belirtilir. Böylece hem hesaplama maliyeti hem belirsizlik yönetilir. Kullanıcıya bir yükleniyor işareti göstermek, ağır işi sınırsızca büyütmenin gerekçesi değildir; ikisi birlikte ele alınır. INP, uzaktaki sunucuda bütün işlemin tamamlanma süresiyle aynı şey değildir. Kullanıcı kaydet dediğinde düğmenin hemen yanıt vermesi ile dosyanın gerçekten saklanması iki ayrı andır. Arayüz bu farkı dürüstçe anlatmalıdır: başladı, sürüyor, tamamlandı veya başarısız oldu. Henüz sonuç gelmeden başarı göstermek hızlı hissettirebilir ama yanlış beklenti yaratır. Etkileşim performansı, teknik süre kadar doğru geri bildirimin zamanlamasını da gerektirir. Klavye kullanıcısının etkileşimi de aynı tasarım sorumluluğuna dahildir. Bir filtre fareyle hızlı çalışırken klavye odağı sonuç güncellemesinden sonra kayboluyorsa deneyim tamamlanmış değildir. Yeni sonuçları anlaşılır biçimde duyurmak ve odağı kullanıcının görevini sürdürdüğü yerde tutmak gerekir. Bir seçim yalnız küçük bir listeyi değiştirdiğinde tüm sayfayı yeniden kurmak hem gereksiz iş hem yön kaybı yaratabilir. Performans ile erişilebilirlik burada aynı yönde ilerler: değişen alanın kapsamını küçük ve anlamlı tutmak. Hızlı görsel tepkinin yanında hangi bilginin değiştiğini de açıkça göstermek, kullanıcının tekrar tekrar denemesini azaltır. ### Bekleme Kullanıcının girdisinden önce ana iş parçacığını meşgul eden başka işler var mı? Otomatik başlayan animasyonlar, üçüncü taraf betikler veya büyük hesaplamalar etkileşim anıyla çakışabilir. Sorun yalnız tıklanan bileşenin içinde olmayabilir. ### İşleme Etkileşim hangi veriyi ve kaç parçayı güncelliyor? Küçük bir seçim bütün sayfanın hesaplarını tetikliyorsa kapsamı daraltmayı düşün. İşin gerçekten gerekli olan kısmıyla daha sonra yapılabilecek kısmını ayır. ### Çizim Hesaplama bitince ekranda hangi geri bildirim oluşuyor? Gereksiz yerleşim okumaları ve yazmaları, büyük DOM değişimleri veya pahalı görsel işlemler yeni karenin çizilmesini geciktirebilir. Sonuç yalnız JavaScript süresinden ibaret değildir. ## İşlem başladı ile işlem bitti aynı söz değil. ### Hızlı geri bildirim Kaydet düğmesi basıldığında işlem durumunu gösterir ve tekrar gönderimi uygun biçimde yönetir. Kullanıcı girdisinin alındığını anlar. Bu ilk görsel yanıt etkileşimin akıcılığına katkı sağlar. Ancak sistemin henüz tamamlamadığı bir işi tamamlandı diye sunmamak gerekir; geri bildirim gerçek durumu taşımalıdır. ### Gerçek tamamlanma Sunucunun dosyayı işlemesi veya bir dış hizmetin yanıt vermesi daha uzun sürebilir. Bu sürede ilerleme, bekleme, iptal veya yeniden deneme seçenekleri göreve göre tasarlanır. INP bu uçtan uca iş süresinin yerine geçmez. Ürün deneyimi hem hızlı tepkiyi hem doğru sonuç yönetimini kapsar. ## Etkileşimin neden geciktiğini bulmak INP incelenirken yalnız tıklama işleyicisinin süresine bakılmaz. Ana iş parçacığının önceden meşgul olması ve sonraki görüntünün hazırlanması da gecikmeyi etkileyebilir. Yoğun filtreleme, uzun hesaplama veya büyük DOM güncellemesi gerçek görev sırasında ölçülmelidir. - Yavaş hissedilen kontrolü gerçek içerik miktarıyla dene. - Uzun işleri böl veya uygun iş parçacığına taşı. - İşlem sürerken durum bilgisini geciktirmeden göster. ## Hızlı açılan sayfa hızlı etkileşir mi? Her zaman değil. Yükleme ve etkileşim farklı aşamalardır. İlk görüntü hızlı gelirken filtre veya menü pahalı işlem yapabilir. Bu yüzden yükleme ölçümlerinin yanında kullanıcı eylemleri de değerlendirilir. ## Bu karar, işinin neresinde? INP kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) ## Karar masası ### İyi INP değeri nasıl okunur? Core Web Vitals için iyi INP eşiği 200 milisaniye ve altıdır; gerçek ziyaretlerin yüzde 75'lik diliminde değerlendirilir. Tek bir hızlı düğme denemesi bütün sayfanın etkileşim sağlığını açıklamaz. Uzun ziyaretler, farklı cihazlar ve ağır işlemler de tabloya girer. Sonucu yorumlarken hangi etkileşimlerin geciktiğini ve hangi kullanıcı koşullarında sorunun belirginleştiğini araştırmak gerekir. ### Her animasyonu kaldırmak gerekir mi? Hayır. Hafif ve amaca hizmet eden bir hareket, durum değişimini anlaşılır kılabilir. Sorun etkileşimle yarışan ağır iş veya gereksiz çizim maliyetidir. Bir düğmenin renk tepkisiyle tüm ekranı yeniden hesaplatan görsel etki aynı maliyette değildir. Hareketin nasıl üretildiğini, ne zaman başladığını ve hangi alanı etkilediğini incele. Tasarımın kimliğini koruyarak işi küçültmek çoğu zaman mümkündür. ### Arama kutusunda debounce her sorunu çözer mi? Debounce peş peşe gelen girdilerde işi belli bir bekleme sonrasına bırakabilir; özellikle ağ isteği sayısını yönetmekte yararlı olabilir. Fakat büyük bir hesaplamayı yalnız geciktirmek onu hafifletmez. Kullanıcının yazdığı harflerin görünmesi de gecikmemelidir. Girdi geri bildirimiyle sonuç hesaplamasını ayır, veri kapsamını küçült ve bekleme davranışının kullanıcıya nasıl hissettirdiğini düşün. Teknik araç, görevin ihtiyacına hizmet etmelidir. ### Sadece güçlü bilgisayarda incelemek yeterli mi? Güçlü işlemciler pahalı işleri görünmez hâle getirebilir. Daha sınırlı cihazlarda aynı kod belirgin gecikme üretir. Bu nedenle hedef kitlenin cihazları ve gerçek ziyaret verisi önemlidir. Bir animasyon geliştirici bilgisayarında akıcıyken mobilde filtrelemeyi zorlaştırabilir. Tasarım kararı yalnız üretildiği makinenin konforuna göre verilirse kullanıcıların önemli bir bölümü farklı bir ürün deneyimler. ## Bir filtreye üç açıdan bak. Kategori değiştiren bir liste seç. Kullanıcının dokunuşundan yeni sonucun görünmesine kadar olan akışı bekleme, işlem ve çizim diye ayır. Her bölüm için gereksiz işi bulmaya çalış. - [ ] Filtreye basıldığı anda görünen geri bildirimi tarif et. Seçili durum, sonuç sayısı ve yüklenme mesajı hangi sırayla değişiyor? Kullanıcının ikinci kez basmasına neden olan belirsiz bir aralık varsa bunu ayrı bir tasarım sorunu olarak yaz. - [ ] Filtreleme için gereken alanları belirle. Başlık ve kategori yeterliyken bütün uzun makaleleri istemciye taşımak zorunlu değildir. Veriyi görevine göre küçült; içeriğin tamamını okuma sayfasında sunmaya devam et. - [ ] Etkileşim anında çalışan başka işleri listele. Otomatik medya, üçüncü taraf betik veya pahalı arka plan hesabı aynı kaynağı kullanıyor olabilir. Önce gerçekten gerekli olmayan başlangıç işlerini ertelemeyi ya da kaldırmayı değerlendir. - [ ] Sonucun gecikmesi ve işlemin başarısız olması için ayrı durumlar çiz. Hızlı geri bildirim, doğru tamamlanma mesajı ve erişilebilir odak birlikte çalışsın. İşlem süresini gizlemek yerine kullanıcıya ne olduğunu açıkça göster. Etkileşim, kullanıcının sözüne verilen cevaptır. Önce onu duyduğunu göster; sonra gerekli işi küçük, anlaşılır ve doğru adımlarla tamamla. ## Bağlantılı kavramlar - [LCP](https://androverse.com.tr/sozluk/lcp) — LCP, sayfanın görünür alanındaki en büyük uygun içerik öğesinin gösterilme zamanını ölçen bir yükleme metriğidir. - [CLS](https://androverse.com.tr/sozluk/cls) — CLS, beklenmeyen yerleşim kaymalarının sayfa deneyimi boyunca oluşturduğu görsel kararsızlığı ölçer. - [Hydration](https://androverse.com.tr/sozluk/hydration) — Hydration, önceden oluşturulmuş HTML üzerine tarayıcıda uygulamanın etkileşimli davranışlarının bağlanması sürecidir. ## Konuyu uygulamaya taşı - [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) — INP kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. - [“Biraz daha wow” kaç piksel?](https://androverse.com.tr/blog/biraz-daha-wow-kac-piksel) — INP ile ilgili tasarım kararını Androverse’nin uygulama örnekleri ve değerlendirme sorularıyla birlikte düşün. ## Kaynaklar - [web.dev — Web Vitals](https://web.dev/articles/vitals) - [web.dev — Interaction to Next Paint](https://web.dev/articles/inp) [Androverse profili](https://androverse.com.tr/yazar/androverse) · [Yayın ilkeleri](https://androverse.com.tr/yayin-ilkeleri)