INP: FID'nin Yerine Gelen Yeni Kritik Metrik
Google, 12 Mart 2024'te Önemli Web Verileri'nin geçişini tamamladı: FID (İlk Giriş Gecikmesi) ve çıkıldı, INP (Sonraki Boyayla Etkileşim) ve girildi. Panellerde sessiz bir değişiklik Ancak milyonlarca sitenin SEO sıralaması üzerinde gerçek etkileri olan Google Arama Konsolu. bana göre Chrome Kullanıcı Deneyimi Raporu'ndan (CrUX) elde edilen veriler, Web sitelerinin %43'ü hâlâ başarısız oluyor INP "İyi" eşiği (200 ms'nin altında)göre çok daha yüksek bir sayı FID'de başarısız olan sitelerin %30'u.
FID yalnızca ilk girişe olan gecikmeyi ölçtü: kullanıcıdan bu yana ne kadar zaman geçti tarayıcı bu olayı işlemeye başladığında ilk kez tıklandı. Geçilmesi kolay bir ölçümdü çünkü yalnızca ilk etkileşimi ölçüyordu ve geçerli değildi bir sonraki boyanın hesabı. INP tamamen farklıdır: duyarlılık genel seansın tamamı boyunca, final puanı olarak seçim yaparak etkileşimlerin en kötü yüzdelik dilimi.
Ne Öğreneceksiniz
- INP'nin FID'den farkı nedir ve neden gerçek yanıt verebilirliği ölçer?
- INP İyi/İyileştirme Gerekiyor/Kötü eşikler (200 ms / 500 ms)
- Chrome DevTools, web-vitals.js ve PageSpeed Insights ile INP nasıl ölçülür?
- INP'yi patlatan en yaygın beş JavaScript modeli
- CrUX saha verileri ve Lighthouse sentetik verileri nasıl yorumlanır?
- Yavaş etkileşimleri bulup düzeltmek için hata ayıklama iş akışı
Hangi INP Önlemleri: Teknik Tanım
INP, ziyaret sırasında sayfayla olan tüm kullanıcı etkileşimlerini gözlemler: tıklamalar, dokunmalar ve tuşa basar. Her etkileşim için girişten bu yana geçen süreyi ölçün tarayıcının kullanıldığı sırada kullanıcının bir sonraki kareyi boyar bu yansıtır bu girdiye verilen görsel yanıt. Bu aralığa denir etkileşim gecikmesi ve üç bölümden oluşur:
- Giriş gecikmesi: tarayıcı olayı işlemeye başlamadan önce geçen süre (ana iş parçacığı meşguldü)
- İşlem süresi: JavaScript olay işleyicilerinin yürütme süresi
- Sunum gecikmesi: tarayıcının yeni çerçeveyi düzenlemesi, boyaması ve birleştirmesi için gereken süre
INP alır 98. yüzdelik dilim oturumdaki tüm etkileşimlerin (veya en kötüsünün) 50'den az etkileşim varsa değer). Ortalama değil, tipik değer değil: neredeyse en kötüsü. Bu, INP'yi gecikme artışlarına karşı FID'den çok daha duyarlı hale getirir.
INP Eşikleri
| Derecelendirme | INP değeri | SEO etkisi |
|---|---|---|
| İyi | < 200ms | Sıralamaya olumlu katkı sağlar |
| İyileştirme Gerekiyor | 200ms - 500ms | Nötr, iyileştirme alanı |
| Fakir | > 500ms | Google sıralama cezası |
FID ve INP: Önemli Fark
FID'den INP'ye geçişin neden önemli bir değişiklik olduğunu anlamak için şu senaryoyu göz önünde bulundurun: Bir e-ticaret sayfanız var. İlk yükleme sonrasında kullanıcı "Sepete Ekle"yi tıklar ve olay 50 ms'de işlenir (mükemmel FID). Daha sonra sayfada gezinin, ürünleri filtreleyin, bir kategori açılır menüsü açılır. Bu ikinci etkileşim ağır bir hesaplama olduğundan 800 ms sürüyor ana iş parçacığı üzerinde çalışıyor.
İle FID: skor 50ms idi - İyi.
İle INP: puan 800ms - Fakir.
INP, yalnızca ilk tıklamayı değil, oturum boyunca gerçek kullanıcı deneyimini yansıtır. Mükemmel FID'ye sahip birçok sitenin artık sorunlu INP'ye sahip olmasının nedeni budur.
INP Nasıl Ölçülür?
1. Chrome Geliştirici Araçları - Performans Paneli
INP'yi teşhis etmenin en doğru yolu Chrome DevTools'un Performans panelidir. Şu şekilde ilerleyin:
- DevTools'u (F12) açın ve sekmeye gidin Performans
- Kaydı başlatmak için kırmızı daireye tıklayın
- Ölçmek istediğiniz etkileşimleri çalıştırın (tıklamalar, yazma vb.)
- Kaydı durdur
- Ortaya çıkan panelde bölümdeki kırmızı çubukları arayın. Etkileşimler
- Dökümü görmek için bir etkileşime tıklayın: giriş gecikmesi, işlem süresi, sunum gecikmesi
2. Web Vitals JS Kütüphanesi (Alan Verileri)
Kütüphane web-vitals Google'ın üretimdeki kullanıcıların gerçek INP'sini ölçmenize olanak tanır.
Bunu projenize ekleyin ve verileri bir analiz uç noktasına gönderin:
import { onINP } from 'web-vitals';
onINP((metric) => {
// metric.value: il valore INP in millisecondi
// metric.rating: 'good' | 'needs-improvement' | 'poor'
// metric.entries: le PerformanceEventTiming entries
console.log('INP:', metric.value, metric.rating);
// Invia a analytics
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
metric: 'INP',
value: metric.value,
rating: metric.rating,
url: window.location.href,
}),
});
});3. PageSpeed Insights ve CrUX
PageSpeed Insights, "Alan Verileri" bölümünde alan adınız için gerçek CrUX verilerini gösterir. CrUX verilerinin senkronizasyonu etkinleştirmiş Chrome kullanıcılarına dayandığını lütfen unutmayın. bu nedenle sentetik Lighthouse sonuçlarını değil, gerçek cihazlardaki gerçek deneyimi yansıtırlar donanım kontrollü olarak çalışır.
Laboratuvar Verileri ve Saha Verileri
"Lab" modundaki Lighthouse ve PageSpeed Insights, orta sınıf bir mobil cihazı simüle eder yavaş bir 4G bağlantısında. CrUX verileri (Alan Verileri) sitenizin gerçek kullanıcılarını yansıtır. İki ölçüm arasında %30-50 fark olması normaldir. Saha verilerini gösterge olarak kullanın SEO kararları için birincil ve teknik hata ayıklama için laboratuvar verileri.
Yüksek INP'ye Neden Olan En Yaygın Kalıplar
1. Ana Konudaki Uzun Görevler
Yüksek INP'nin ana suçlusu, Uzun Görevler: JavaScript görevleri
50 ms'den fazla süren. Her Uzun Görev tarayıcının ana ileti dizisini bloke ederek yanıt vermesini engeller
kullanıcı girişine. Bunları tanımlamanın en kolay yolu DevTools Performans panelidir
veya API PerformanceObserver:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
console.warn('Long Task rilevato:', {
duration: entry.duration,
startTime: entry.startTime,
});
}
}
});
observer.observe({ type: 'longtask', buffered: true });2. Ağır Olay İşleyicileri
Eşzamanlı olarak yoğun hesaplama gerçekleştiren tıklama işleyicileri, yüksek INP'nin sık görülen bir nedenidir. Tipik kalıp şu özelliklere sahip bir işleyicidir:
- Bellekteki büyük dizileri filtreleyin veya dönüştürün
- DOM'u büyük ölçüde oluşturun (yüzlerce öğe ekleyin)
- Karmaşık düzenleri hesaplayın veya tarayıcıyı yeniden düzenlemeye zorlayın
- Büyük JSON'u ayrıştırır
3. Tepki/Açısal Değişim Tespiti Optimize Edilmemiş
React veya Angular gibi çerçevelerde tek bir olay, değişiklik tespit döngüsünü tetikleyebilir tüm bileşen ağacını yeniden hesaplar. Karmaşık bileşenlerde veya not almanın yokluğunda uygunsa bu 100-400ms sürebilir.
Angular'da çözüm şudur: ChangeDetectionStrategy.OnPush ve sinyallerin kullanımı
granüler reaktivite. React'ta, React.memo, useMemo e useCallback
bunlar anahtar araçlardır.
4. Üçüncü Taraf Komut Dosyaları
Analizler, sohbet widget'ları, reklam komut dosyaları ve diğer üçüncü taraf komut dosyaları genellikle ana ileti dizisinde çalışır ve girişlere verilen yanıtı engelleyebilir. Bunları tanımlamak için DevTools Performans panelinde üçüncü taraf etki alanlarından kaynaklanan Uzun Görevleri arayın.
5. SSR Çerçevelerinde Hidrasyon
SSR (Next.js, Angular Universal, Nuxt) içeren uygulamalarda hidrasyon aşaması şu şekilde olabilir: pahalı. Hidrasyon sırasında çerçeve, olay işleyicilerini oluşturulan DOM'a yeniden bağlar sunucu tarafı. Bu aşama bir kullanıcı etkileşimiyle çakışırsa INP zarar görür.
INP Hata Ayıklama İş Akışı
Yüksek NPI'yi teşhis etmek ve düzeltmek için önerilen iş akışı:
- Sorunlu etkileşimleri tanımlayın Performans panelini kullanma DevTools tarafından. Etkileşimler bölümünde gecikme süresi > 200 ms olan etkileşimleri arayın.
- Dökümü analiz edin: üç bileşenden hangisi (giriş gecikmesi, işleme, sunum) en büyüğü mü?
- If ve giriş gecikmesi: O sırada ana iş parçacığında başka bir şey çalışıyordu tıklamanın. Zaman çizelgesinde etkileşimden önceki Uzun Görevleri arayın.
-
Eğer ve işlem süresi: Olay işleyicileriniz çok yavaş.
Amerika
scheduler.yield()onları kırmak için (sonraki makaleye bakın). - Eğer ve sunum gecikmesi: Çerçeve oluşturma yavaş. Çarpıcı düzenlere, pahalı CSS animasyonlarına veya aşırı birleştirme katmanlarına bakın.
INP ve SEO: Gerçek Etki
Google, INP dahil Önemli Web Verilerinin sıralama faktörleri olduğunu doğrulamıştır. Ağırlık Tam olarak kamuya açık değil, ancak ampirik kanıtlar INP'de "Kötü"den "İyi"ye geçişin olduğunu gösteriyor Rekabetçi sayfalar için %2-5 sıralama iyileştirmesi sağlayabilir. Trafiği olan siteler için önemli organik, bu ölçülebilir trafik artışı anlamına gelir.
En büyük öncelik tüm ana sayfaları (ana sayfa, kategori sayfaları, ürün sayfaları) "İyi" derecesine (< 200 ms) yükseltir. Statik içerik sayfaları nadiren INP sorunları; sorunlar karmaşık etkileşimli arayüzlere sahip sayfalara odaklanıyor.
Sonraki Adımlar
Artık INP sorunlarını nasıl ölçeceğinizi ve tanımlayacağınızı bildiğinize göre, bir sonraki adım nasıl yapılacağını öğrenmektir.
bunları düzeltin: bu serideki bir sonraki makale nasıl kullanılacağını açıklıyor scheduler.yield()
Uzun Görevleri bölmek ve bir etkileşim ile diğeri arasındaki ana konuyu serbest bırakmak için.
İşleme tarafı için, LCP Optimizasyonu makalesi, Sunumu geciktirir ve ilk önemli karenin boyanmasını hızlandırır.
Sonuçlar
INP, web performansı ölçümünde bir paradigma değişikliğini temsil ediyor: bu yeterli değil sayfanın hızlı yüklenmesi için aynı zamanda cevap hızlı bir şekilde seansın süresi. INP'nin İyi eşiğini geçemeyen sitelerin %43'ünün fırsatı var hem kullanıcı deneyimini hem de SEO sıralamasını iyileştirmenin somut yolu.
Başlangıç noktası her zaman ölçümdür: kurulum web-vitals.js seninkinde
sitenizi ziyaret edin, gerçek kullanıcı verilerini toplayın ve etkileşimleri teşhis etmek için Chrome DevTools'u kullanın
sorunlar. Yalnızca somut verilerle bilinçli optimizasyon kararları verebilirsiniz.