INP skoru düşükse hangi JavaScript müdahaleleri önceliklendirilmeli?

INP skoru düşükse önce gecikmenin kaynağını ayırın

INP, 2026 itibarıyla sayfanın verdiği en kritik etkileşim yanıtlarından birini ölçen temel Core Web Vitals metriğidir. Resmî eşikler değişmiş değil: 200 ms ve altı iyi, 200-500 ms arası geliştirme gerektirir, 500 ms üzeri zayıf kabul edilir. FID yalnızca ilk girdiye baktığı için artık yeterli değildir; INP ise sayfa yaşam döngüsü boyunca anlamlı etkileşimleri kapsar. Bu yüzden düşük INP gördüğünüzde ilk iş, tek bir “JavaScript yavaş” etiketi koymak değil, gecikmenin hangi bileşende büyüdüğünü ayırmaktır.

Chrome for Developers’ın 8 Ekim 2025 tarihli INP breakdown dokümanı, teşhisi input delay, processing duration ve presentation delay olarak üçe ayırmayı önerir. Input delay yüksekse tarayıcı etkileşime sıra veremiyordur; sebep çoğu zaman uzun task, parse baskısı veya üçüncü taraf kodlardır. Processing duration yüksekse sorun event handler içindeki senkron iştir. Presentation delay yüksekse JavaScript sonrası render, layout veya paint aşaması ağırlaşmıştır. Terimlerin ayrımını netleştirmek için teknik SEO terimleri sözlüğü gibi referans noktaları ekip içi iletişimde de işi hızlandırır.

• Input delay yüksekse önce script yükleme sırasına ve main thread blokajına bakın.
• Processing duration yüksekse event handler içindeki işi küçültün ve parçalara bölün.
• Presentation delay yüksekse render, layout thrashing ve hydration yükünü inceleyin.

Lab ve saha verisini de ayırmak gerekir. Search Console ve CrUX, gerçek kullanıcıların p75 davranışını gösterir; ama hangi etkileşimin yavaş olduğunu tek başına söylemez. DevTools trace ve GoogleChrome web-vitals attribution paketi ise o etkileşimi satır satır yakalamanızı sağlar. web.dev’in 2 Eylül 2025 güncellemesinde de vurgu artık FID mantığından çıkıp doğrudan INP alt bileşenine göre teşhis kurmaya kaydı. MDN’nin 14 Ocak 2026 güncellemesi de yoğun etkileşimli sayfalarda 98. yüzdelik yorumunun neden önemli olduğunu daha açık anlatıyor.

Uzun JavaScript görevlerinde ilk müdahale: parçalama ve yükleme önceliği

Düşük INP’de ilk kazanç çoğu projede 50 ms üzerindeki long task kümelerini küçültmekten gelir. Çünkü kullanıcı tıklasa bile ana iş parçacığı meşgulse etkileşim kuyruğa girer. Burada öncelik, semptoma göre değişir: input delay yükseliyorsa etkileşim öncesi parse ve execute baskısını azaltın; processing duration yükseliyorsa handler içindeki işi parçalayın. Google’ın web.dev optimize-INP rehberi, uzun görevleri bölmenin ve kritik olmayan işi ertelemenin doğrudan INP faydası ürettiğini açıkça vurgular.

Semptoma göre ilk seçim

• Input delay yüksek: defer, async, route-level code splitting ve etkileşim öncesi gereksiz bundle’ları kaldırma.
• Processing duration yüksek: task chunking, scheduler.yield(), daha hafif event handler ve erken çıkış koşulları.
• Her ikisi de yüksek: önce üçüncü taraf ve uygulama bundle baskısını düşürün, sonra handler işini bölün.

scheduler.yield() burada pratik bir araçtır; uzun döngüleri veya büyük veri işleme bloklarını tarayıcıya nefes alanı vererek küçük parçalara ayırmanızı sağlar. Buna karşılık requestIdleCallback ilk tercih değildir. Çünkü idle zamanı garantili değildir ve kullanıcı etkileşimine yakın kritik işlerde gecikmeyi çözmez. Onu daha çok analitik kuyruğu, ısı haritası işleme ya da etkileşim sonrası önbellek ısıtma gibi kritik olmayan görevlerde düşünmek gerekir.

Yükleme önceliği tarafında kural basit: kullanıcı ilk etkileşimden önce görmeyeceği veya kullanmayacağı kod, aynı anda ana bundle içinde olmamalı. Özellikle filtre paneli, karşılaştırma modülü, chat ve deney script’leri ana içerikle aynı anda parse ediliyorsa input delay şişer. Bu noktada kod bölme ile erteleme birlikte çalışır; sadece dosyayı küçültmek değil, doğru anda yüklemek önemlidir.

Event handler, hydration ve re-render sorunlarında ikinci dalga düzeltmeler

Long task baskısını azalttığınız halde INP hâlâ kötü kalıyorsa, ikinci dalgada event handler içeriğini küçültün. Sık görülen sorunlar şunlardır: aynı tıklamada gereksiz JSON işleme, zincirleme state güncellemesi, tekrar eden querySelector çağrıları, ağır doğrulama mantığı ve senkron biçimde çalışan filtreleme/sıralama kodu. Handler içine giren her iş parçası için şu soruyu sorun: bu iş gerçekten etkileşim anında mı yapılmalı, yoksa önce hesaplanıp saklanabilir mi?

React ve Next.js uygulamalarında kötü INP çoğu zaman yalnızca “JavaScript fazla” probleminden değil, hydration maliyeti ve gereksiz re-render zincirinden doğar. Kullanıcı ilk tıklamayı tam hydration sürerken yapıyorsa processing duration uzar, ardından render gecikmesi gelir. Bu yüzden büyük client component ağaçlarını küçültmek, gerçekten etkileşim gerektirmeyen bölümleri server component olarak bırakmak ve state’i daha dar alanlara çekmek etkili olur. Özellikle arama kutusu, filtre, sekme ve modal gibi sık kullanılan arayüzlerde bu ayrım belirgindir.

Presentation delay tarafında ise sorun çoğu zaman layout thrashing ve forced reflow’dur. JavaScript bir öğenin boyutunu yazıp hemen ardından ölçüm yaparsa tarayıcı yerleşimi tekrar hesaplar. Çözüm, DOM okuma ve yazma işlerini ayırmak, güncellemeleri toplu vermek ve gereksiz animasyon/transition maliyetini azaltmaktır. INP burada yalnızca kod süresini değil, kullanıcının ekrana gördüğü son yanıtı ölçtüğü için render maliyeti küçümsenmemelidir.

• DOM okumalarını aynı blokta toplayın, yazmaları ayrı blokta uygulayın.
• Tek etkileşimde birden çok state zinciri yerine toplu güncelleme kullanın.
• Hydration gerektirmeyen modülleri istemciye taşımayın.

Üçüncü taraf script’ler ve Web Worker kararı ne zaman öne çıkar?

Birçok sayfada ilk net kazanç, uygulama kodundan önce üçüncü taraf script bütçesi kurmaktan gelir. GTM, chat, A/B test, ısı haritası, yeniden pazarlama ve sosyal widget’lar etkileşimden önce gerçekten zorunlu değilse aynı anda çalışmamalıdır. Karar ağacı basit olabilir: kullanıcı ilk tıklamayı yapmadan bu script bir iş değeri üretmiyorsa, yüklenme anı ileri alınır. Bu yaklaşım yalnızca network yükünü değil, parse ve execute baskısını da düşürür.

• Etkileşim öncesi zorunlu olabilenler: temel güvenlik, rıza akışı, kritik hata kaydı.
• Ertelenebilenler: chat, deney script’i, ısı haritası, sosyal gömüler, bazı analitik eklentileri.
• Tetiklemeli yükleme: ilk scroll, ilk sekme açılışı, filtre kullanımından sonra yükleme.

Web Worker ise her performans sorununa cevap değildir. Ağır ama DOM’dan bağımsız hesaplamalar için güçlüdür: ürün puanlama, büyük veri dönüştürme, istemci tarafı skorlama, karmaşık sıralama veya metin ayrıştırma gibi işler ana iş parçacığından alınabilir. Fakat Worker, DOM’a doğrudan erişemez; bu nedenle render gecikmesi, layout thrashing veya hydration sorununu tek başına çözmez. Ayrıca worker’a veri taşımanın da bir maliyeti vardır; küçük işlerde taşımak kazanç üretmeyebilir.

Özet öncelik şu şekildedir: defer/async ve code splitting input delay baskısını azaltır; scheduler.yield() ve task chunking processing duration’ı küçültür; Worker yalnızca saf hesaplama darboğazında öne geçer. Resmî anlatımı derinleştirmek isteyen ekipler için Chrome for Developers ve web.dev tarafındaki INP trace videoları iyi tamamlayıcı kaynaklardır; fakat asıl karar yine sizin etkileşim trace’inizde hangi bileşenin şiştiğine göre verilmelidir.

Mobil CPU testinde 3 adımlı vaka: hangi JavaScript müdahalesi önce kazandırdı?

Kontrollü bir mobil CPU throttling senaryosunda aynı ürün listeleme sayfasını üç adımda yeniden test ettiğimizde en hızlı kazanımın nereden geldiği netleşti. Başlangıç durumunda saha tarafında p75 INP 380 ms civarındaydı; trace üzerinde ilk filtre tıklamasından önce çalışan iki üçüncü taraf script ve 120 ms üzeri üç long task görünüyordu. İlk adımda chat ile A/B test script’ini etkileşim sonrasına aldığımızda input delay belirgin biçimde düştü ve p75 değer 310 ms bandına indi.

İkinci adımda filtre handler içindeki büyük diziyi tek blokta işlemek yerine küçük partilere ayırıp scheduler.yield() kullandık. Bu hamle processing duration’ı küçülttü; aynı etkileşimde ana thread’in kesintisiz meşgul kalma süresi azaldı ve p75 değer 230 ms seviyesine yaklaştı. Son adımda ürün puanlama hesaplamasını Web Worker’a taşıdık. Çünkü bu parça DOM’a dokunmuyordu ve ana iş parçacığında kalmasının tek sonucu kullanıcı tıklamasını geciktirmekti. Bu son değişiklikten sonra ölçüm 190 ms civarına oturdu.

Bu örnek, Worker’ın ilk değil üçüncü adım olabildiğini gösteriyor. Eğer önce teşhis yapmadan “her şeyi Worker’a taşıyalım” yaklaşımı seçilseydi, üçüncü taraf yükü ve handler içi blokaj yerinde kalacaktı. Aynı nedenle Search Console veya CrUX tarafında iyileşme beklerken de sabırlı olmak gerekir; saha verisi anlık güncellenmez ve yeterli etkileşim birikimi ister. Bu yüzden laboratuvar trace, RUM ve URL grubu görünümünü birlikte okumak daha sağlıklıdır.

Regresyon takibi için tek seferlik trace yetmez. site sağlığı taraması ile şablon bazlı riskleri, sıralama takibi ile performans düzeltmesinin görünürlük etkisini beraber izlemek daha anlamlıdır. Ahrefs veya SEMrush benzeri platformlarda bu takibi farklı akışlarda yürütebilirsiniz; SEOYEN ise bunu Türkiye pazarına uyarlanmış, Türkçe arayüzlü, tek platform yaklaşımıyla sunar. Özellikle TL fiyatlı paketler ve yerel Türkçe destek, teknik SEO tarafında veriyi ürün ekibiyle daha hızlı paylaşmayı kolaylaştırır.

Adım Adım Düşük INP için JavaScript müdahale sıralaması

1. INP alt bileşenini teşhis et. DevTools INP breakdown, RUM attribution ve saha verisini birlikte okuyun. Hangi etkileşimde input delay, processing duration veya presentation delay büyüyor netleşmeden doğru JavaScript önceliği kurulmaz.
2. Uzun görevleri ve blokajları bul. 50 ms üzerindeki long task’leri, etkileşim öncesi çalışan üçüncü taraf kodları ve ana bundle parse baskısını listeleyin. Burada amaç en pahalı darboğazı görünür kılmaktır.
3. İlk dalga yükleme düzeltmelerini uygula. defer, async, code splitting ve etkileşim öncesi zorunlu olmayan script ertelemesiyle input delay baskısını azaltın. Kullanıcının ilk tıklamasına kadar ihtiyaç olmayan kod aynı anda yüklenmemelidir.
4. İşleme süresini parçalayarak düşür. scheduler.yield(), task chunking ve hafifletilmiş event handler yaklaşımıyla processing duration’ı küçültün. Tek bir tıklamada yapılan işi daha küçük ve ertelenebilir parçalara ayırın.
5. Ağır hesaplamayı uygun yerde taşı. DOM bağımsız yoğun işlemleri Web Worker’a alın; ama render, hydration ve layout sorunlarının Worker ile çözülmeyeceğini unutmayın. Worker bir hesaplama aracı, genel amaçlı render ilacı değildir.
6. Mobil ve saha verisiyle doğrula. CPU throttling, trace, RUM p75 ve Search Console/CrUX görünümünü birlikte izleyin. Kazanç tek sayfada değil, benzer şablonlarda da korunuyorsa müdahale doğru önceliklendirilmiştir.

Sıkça Sorulan Sorular