INP Optimizasyonu: Görev Bölme ve Kod Doğrulama

Bu rehber, ölçümde bulunan bir etkileşim gecikmesini düzeltmek için uygulama adımları sunar. INP eşikleri ve alan/lab ayrımı için ölçüm rehberini okuyun. Kod çalışması, Seobify’ın canlı INP değerinin iyileştiğini tek başına kanıtlamaz.

Önce yavaş etkileşimin izini bulun

Girdi gecikmesi, işleme süresi ve sunum gecikmesi farklı darboğazlara işaret edebilir. Yalnız olay dinleyicisini kısaltmak bütün sorunu çözmeyebilir. Kaynak: web.dev INP optimizasyon rehberi.

İzdeki bulgu	Araştırılacak küçük değişiklik	Tekrar kontrol
Olaydan önce ana iş parçacığı meşgul	Önceki görevin gereksiz işini azaltma	Aynı etkileşim anındaki bekleme
Dinleyicide büyük hesaplama	İşi dilimleme veya uygun hesaplamayı Worker’a taşıma	Sonuç doğruluğu ve diğer etkileşimler
DOM güncellemesinden sonra maliyet	Görünen kayıt sayısı ve stil/layout işlemleri	Sonucun okunabilirliği ve çizim süresi
Üçüncü taraf kod baskın	Gereksiz kodu kaldırma veya yükleme zamanını değiştirme	İlk etkileşimde yeni gecikme oluşmaması

Bütün üçüncü taraf kodları ilk tıklamaya taşımak yeni bir darboğaz oluşturabilir. Sabit bir DOM düğümü sayısını evrensel INP sınırı saymayın; sayfanın gerçek izini inceleyin.

İndirilebilir zaman bütçeli filtreleme örneği

JavaScript örneğini indirin. Modül hem tarayıcıda hem Node ortamında kullanılabilir. Bu eğitim örneği INP ölçmez. Varsayılan 8 ms bütçe, denenecek bir dilimleme tercihidir; performans garantisi değildir.

import { chunkedFilter } from './inp-chunking.mjs';

const products = [
  { id: 1, available: true },
  { id: 2, available: false },
  { id: 3, available: true },
];
const result = await chunkedFilter(
  products,
  product => product.available,
  { budgetMs: 8 },
);
console.log(result.map(product => product.id)); // [1, 3]

Modül, destek varsa scheduler.yield(), yoksa zamanlayıcıyla başka göreve geçiş olanağı kullanır. Bir defa yield edip ardından ağır hesaplamayı tek blokta çalıştırmak, ağır bloğu parçalamış olmaz. Görev bölme yaklaşımı: web.dev uzun görev rehberi.

Kodun sınırları ve hata senaryoları

• Filtre koşulu eşzamanlı olmalıdır; async koşul desteklenmez.
• Tek kaydın hesabı çok ağırsa bu örnek onu kendi içinde bölemez.
• Filtre sonucunu çok büyük bir DOM’a tek seferde basmak ayrı çizim maliyeti oluşturabilir.
• İptal için AbortSignal desteklenir. Yeni filtre seçimi geldiğinde eski sonuçların ekrana basılmasını uygulama tarafında önleyin.
• Boş giriş boş sonuç verir; geçersiz dizi/koşul veya pozitif olmayan zaman bütçesi hata üretir.

Bir yükleniyor etiketi göstermek sunum gecikmesini sıfırlamaz. Tarayıcıya görev geçişi fırsatı verilmesi de her çağrıda yeni kare çizimini garanti etmez. Sonucu gerçek tarayıcı etkileşim kaydıyla doğrulayın.

Agent kabul ve geri alma komutu

“Önce aynı akışın izini kaydet. Sonuç doğruluğunu koruyan küçük bir değişiklik uygula. Normal sonuç, boş giriş, geçersiz giriş ve iptal durumlarını kontrol et. Tarayıcı/sürüm/cihaz koşulunu kaydederek aynı etkileşimi tekrar çalıştır. Lab zamanlamasını alan INP değeri olarak sunma. Yeni hata veya sonuç farkı varsa önceki uygulamaya dön.”

Sıkça sorulan sorular

Kod örneği INP’yi 50 ms altına indirir mi?

Böyle bir garanti vermez. Sonuç cihaz, diğer görevler ve çizim maliyetine bağlıdır.

Worker bütün kodlar için çözüm mü?

Hayır. DOM’a erişen işleri ve veri aktarım maliyetini ayrıca tasarlamak gerekir.

Hangi sonucu raporlamalıyım?

Önce doğruluk ve aynı koşuldaki etkileşim izini; varsa alan metriğini ayrı kapsamla raporlayın.

Daha geniş teknik kapsam için teknik SEO kontrol listesine geçebilirsiniz.