INP nedir ve nasıl ölçülür.
INP, bir kullanıcı etkileşiminden sonra sayfanın görsel yanıt vermesine kadar geçen süredir ve Google 200 milisaniyenin altını iyi sayar.
2024 Mart'ında Core Web Vitals'a giren ve FID'in yerini alan metrik budur. Değişim önemliydi çünkü FID yalnız İLK etkileşimin GECİKMESİNİ ölçüyordu — yani kullanıcı tıkladıktan sonra tarayıcının işlemeye başlamasına kadar geçen süreyi. Tıklamanın sonucunun ekrana yansıması hiç ölçülmüyordu.
Pratik sonucu şuydu: bir sayfa ilk tıklamaya hızlı yanıt verip sonraki her etkileşimde donabilir ve FID yine mükemmel çıkardı. INP tüm oturumdaki etkileşimlere bakıyor ve gecikmeyi değil tam döngüyü ölçüyor. Çok daha zor ve çok daha dürüst bir sınav.
Üç aşama
Bir etkileşimin süresi üç parçaya ayrılır ve tanı için üçünü ayırmak gerekir.
- Giriş gecikmesi — kullanıcı tıkladı, ama ana iş parçacığı başka bir işle meşgul. İşleyici çalışmaya başlayana kadar geçen süre.
- İşleme süresi — olay işleyicilerinin kendisi ne kadar sürdü? Kodunuzun doğrudan sorumluluğu.
- Sunum gecikmesi — işleyici bitti, ama tarayıcı bir sonraki kareyi boyamaya ne zaman geçebildi?
Çoğu ekip yalnız ikinci aşamayı düşünür ve olay işleyicilerini optimize eder. Oysa saha verilerinde en büyük payı genelde birinci ve üçüncü aşamalar alır — yani sorun sizin işleyicinizin yavaş olması değil, ana iş parçacığının başka bir şeyle meşgul olmasıdır.
Bu ayrımın en pratik sonucu şu: INP sorunlarının çoğu, etkileşimden bağımsız bir yerde — sayfa yüklenirken çalışan uzun betiklerde, üçüncü taraf kodlarında ya da ağır bir çerçevenin hidrasyon işinde — yaşıyor.
Ana iş parçacığı
Tarayıcıda JavaScript tek bir iş parçacığında çalışır ve o parçacık aynı zamanda düzen hesabından ve boyamadan da sorumludur. Uzun süren bir JavaScript işi çalışırken tarayıcı hiçbir şey boyayamaz ve hiçbir tıklamaya yanıt veremez — sayfa donmuş görünür.
Bu yüzden INP'nin en etkili tedavisi uzun işleri bölmektir. Elli milisaniyeden uzun süren her görev, o süre boyunca sayfayı tepkisiz bırakır. İşi küçük parçalara ayırıp aralarında tarayıcıya kontrolü geri vermek, toplam süreyi değiştirmez ama sayfayı kullanılabilir tutar.
İkinci tedavi, işi tamamen ana iş parçacığından çıkarmaktır. Ağır hesaplamalar arka plan iş parçacıklarına taşınabilir; orada çalışan kod, kullanıcı arayüzünü hiç engellemez. Bu, her iş için mümkün değildir ama hesaplama yoğun işler için en temiz çözümdür.
Üçüncüsü ve en çok kazandıranı: gereksiz işi hiç yapmamak. Kullanılmayan bir kütüphanenin yüklenip çalıştırılması, en iyi bölme stratejisinden daha pahalıdır. INP çalışmasının ilk adımı optimizasyon değil, envanterdir.
En hızlı JavaScript, hiç çalıştırılmayan JavaScript'tir.
Neden laboratuvarda ölçülemez
INP'nin en can sıkıcı yanı, laboratuvar araçlarında güvenilir biçimde ölçülememesidir. Sebep tanımında: metrik gerçek kullanıcı etkileşimlerine bakar ve bir denetim aracı sayfayla etkileşmez. Araçlar bir tahmin üretebilir ama o tahmin gerçek kullanımı temsil etmez.
Bu yüzden INP için saha verisi bir seçenek değil zorunluluktur. Tarayıcı, gerçek kullanıcıların yaşadığı değerleri toplar ve bu veri hem Google'ın kendi raporlarında hem de kendi sayfanıza ekleyeceğiniz küçük bir ölçüm koduyla erişilebilir hâle gelir.
Kendi ölçümünüzü kurmanın avantajı ayrıntıdır: hangi etkileşimin, hangi sayfada ve hangi öğede yavaş olduğunu görebilirsiniz. Google'ın toplu raporu size bir sayı verir; kendi ölçümünüz o sayının nereden geldiğini söyler.
Bir gizlilik notu: bu ölçüm çerez gerektirmez ve kişisel veri toplamaz — yalnız süre değerleri ve etkileşilen öğenin seçicisi kaydedilir. Bu sitede gizlilik metni çerez kullanılmadığını söylüyor ve süit bunu her koşumda ölçüyor; eklenecek herhangi bir ölçüm o iddiayı bozamaz.
Nereden başlanır
INP çalışması, diğer iki metrikten farklı olarak bir envanterle başlar. Sorunun kaynağı genelde sizin yazdığınız etkileşim kodu değil, sayfada çalışan işin toplamıdır — dolayısıyla önce o toplamı görmek gerekir.
- Yüklenen betikleri listele — kaç dosya, ne kadar bayt, hangisi üçüncü taraf?
- Uzun görevleri bul — performans panelinde elli milisaniyeyi aşan görevler işaretlenir; kaynağı hangi dosya?
- Üçüncü tarafları tart — sohbet balonu, analitik, reklam. Her birinin ana iş parçacığına maliyeti ayrı ölçülebilir.
- Gerçekten gerekeni sor — hangi kütüphane hangi özellik için? Kullanılmayan varsa çıkar.
- Kalanları geciktir — etkileşim gerektirmeyen işler ilk boyamadan sonraya alınabilir.
- Uzun işleri böl — bölünemeyen işi arka plan iş parçacığına taşı.
Bu sıra, en büyük kazancı en üste koyuyor: hiç yüklenmeyen bir betiğin maliyeti sıfırdır ve hiçbir optimizasyon o sonucu veremez. Bu sitede vendor kütüphaneleri gzip sonrası 55,7 kilobayt ve listede yalnız gerçekten kullanılan beş modül var — envanter disiplininin somut karşılığı budur.
Son bir ölçüm notu: INP saha verisinde 75. yüzdelik olarak raporlanır, yani kullanıcıların dörtte üçünün yaşadığı süre. Kendi güçlü cihazınızda ölçtüğünüz değer o dağılımın en iyi ucundadır ve gerçek kullanıcı deneyimini temsil etmez. Düşük güçlü bir cihazda test etmek, INP için diğer iki metrikten daha kritiktir.
Çerçeve seçiminin bedeli
INP üzerinde en büyük etkiyi yapan tek karar, genelde hiç performans kararı olarak alınmayan bir karardır: hangi ön yüz çerçevesinin kullanılacağı. Sunucuda üretilip istemcide yeniden canlandırılan sayfalar, o canlandırma işi boyunca ana iş parçacığını meşgul eder ve o pencerede yapılan her tıklama gecikir.
Bu, çerçeveleri kötü yapmıyor — karmaşık uygulamalar için gerekli olabilirler. Ama bir tanıtım sitesi, bir blog ya da bir vitrin sitesi için o maliyeti ödemenin karşılığı çoğu zaman yoktur. Bu sitede istemci tarafında canlandırma yok; sayfalar dosya olarak geliyor ve JavaScript yalnız hareket katmanını kuruyor.
Ölçülen sonuç: kendi kodun gzip sonrası 28 kilobayt, vendor kütüphaneleri 55,7 kilobayt. Toplam 83,7 kilobayt ve tavanı 150 kilobayt olan bütçenin epey altında. Bu rakam bir optimizasyon başarısı değil, bir mimari kararın doğal sonucu.