Core/Dash Boyutu: LOAF

Boyut: Uzun Animasyon Kareleri (lurl)

LOAF boyutu, kullanıcılarınızın oturumları sırasında Uzun Animasyon Karelerine neden olan betiklerin URL'lerini gün yüzüne çıkarır. Her bir değer bir betik URL'sidir: birinci taraf bir paket, üçüncü taraf bir analiz etiketi, bir sohbet aracı, bir izin yöneticisi veya oluşturmayı engelleyecek kadar uzun süre çalışan herhangi bir şey. Bu, yalnızca DevTools'ta yeniden oluşturmanız gereken bir yığın izlemesi değil, kaynak düzeyinde bir ilişkilendirmedir.

CoreDash bu verileri, Chrome'un eski Long Tasks API'sinin yerine sunduğu Long Animation Frames API (LoAF)'yi kullanarak toplar. Long Tasks size bir karenin çok uzun sürdüğünü söylerken, LoAF o kare içinde hangi betiklerin çalıştığını ve URL'lerinin ne olduğunu söyler. Bu boyutu üretimde faydalı kılan ayrım budur.

Long Tasks Neden Yeterli Değildi?

Long Tasks API (2017'den beri mevcuttur), 50 ms'yi aşan herhangi bir ana iş parçacığı görevini işaretliyordu, ancak size neredeyse hiçbir ilişkilendirme vermiyordu. Engellemenin gerçekleştiğini görebiliyordunuz; ancak buna neyin sebep olduğunu göremiyordunuz. Geliştiriciler, görev zaman damgalarını ağ şelaleleriyle ilişkilendirmek ve hangi betiğin sorumlu olduğunu tahmin etmek için saatler harcıyorlardı.

LoAF API bunu değiştiriyor. Her biri bir scripts dizisi içeren PerformanceLongAnimationFrameEntry nesnelerini raporlar. Bu dizideki her girdinin bir invokerType, bir sourceURL ve bir duration değeri vardır. CoreDash, uzun bir kare sırasında çalışan her betik için sourceURL değerini okur ve bunu LOAF boyut değeri olarak saklar. Sonuç, kullanıcılarınızın uzun karelerinde ne kadar sıklıkla göründüklerine göre sıralanmış betik URL'lerinin derecelendirilmiş bir listesidir.

CoreDash LoAF Verilerini Nasıl Kullanır?

Kullanıcı etkileşimi her uzun animasyon karesini tetiklediğinde, CoreDash buna katkıda bulunan betik URL'lerini INP gözleminin yanında kaydeder. Bu, INP verilerinizi LOAF URL'sine göre filtreleyebileceğiniz ve en kötü etkileşimlerinizden hangi betiğin sorumlu olduğunu görebileceğiniz anlamına gelir. Boyut, URL'ye göre gruplandırılır, böylece o betiğin uzun bir kareye neden olduğu kaç oturum olduğunu gösteren bir sayı görürsünüz.

LOAF boyutunda göreceğiniz tipik girdiler:

• https://www.googletagmanager.com/gtm.js (Google Tag Manager kapsayıcısı)
• https://cdn.cookielaw.org/consent/... (OneTrust veya benzeri izin platformu)
• https://js.intercomcdn.com/... (sohbet aracı)
• /static/js/app.bundle.js (kendi uygulama kodunuz)
• https://connect.facebook.net/en_US/fbevents.js (Meta Pikseli)

CoreDash verilerinde, üçüncü taraf betikler sitelerin yaklaşık %60-70'inde uzun animasyon karelerinden sorumludur. Yalnızca etiket yöneticileri, izlenen mülklerin yaklaşık %45'inde uzun karelere katkıda bulunur. Geri kalan kısma genellikle React yeniden oluşturmaları veya optimize edilmemiş olay işleyicileri nedeniyle birinci taraf paketler hakimdir.

LoAF Üzerinden INP İlişkilendirmesi

INP, kullanıcı etkileşiminden bir sonraki kare boyamasına kadar geçen süreyi ölçer. Bu boşluk 200 ms'yi aşarsa, Google bu deneyimi "geliştirilmesi gerekiyor" olarak sınıflandırır. LoAF verileri size bu boşluk sırasında hangi betiğin çalıştığını söyler. 210 ms'si bir izin yöneticisi betiğine kadar uzanan 280 ms'lik bir INP, 190 ms'si kendi ödeme işleyicinize uzanan 280 ms'lik bir INP'den tamamen farklı bir sorundur. Çözüm farklıdır. Sorumlu ekip farklıdır. Aciliyet farklıdır.

LoAF ilişkilendirmesi olmadan, INP histogramınızda her ikisi de aynı görünür. LoAF ile sorunu derhal doğru kişiye yönlendirebilirsiniz.

Hata Ayıklama İş Akışı

1. CoreDash'te LOAF boyutunu açın: Sıklığa göre sıralayın (bu URL'yi uzun bir karede kaç oturumun gördüğüne göre). En üstteki girdi en yüksek öncelikli hedefinizdir.
2. INP ile çapraz filtreleme yapın: LOAF filtresini INP metrik görünümünüze uygulayın. O betiğin çalıştığı oturumları izole ettiğinizde INP p75 değerinin değişip değişmediğini kontrol edin. 30 ms+ bir artış, betiğin üretimdeki INP düşüşüne katkıda bulunduğunu doğrular.
3. Birinci taraf veya üçüncü taraf olarak sınıflandırın: URL'de kendi alan adınızın olması, düzeltmeyi sizin kontrol ettiğiniz anlamına gelir. Üçüncü taraf bir CDN URL'si, satıcı betiğini kaldırmanız, geciktirmeniz veya değiştirmeniz gerektiği anlamına gelir.
4. Düzeltmeyi uygulayın ve doğrulayın: Üçüncü taraf betikler için, bir cephe (facade) veya gecikmeli başlatma (delayed init) kullanarak yüklemeyi ilk kullanıcı etkileşiminden sonrasına erteleyin. Birinci taraf kod için, Chrome DevTools'ta CPU yavaşlatmayı (CPU throttling) 4x olarak ayarlayıp ilgili işlevin profilini çıkarın. Değişikliği dağıtın ve gerçek kullanıcı trafiğinin 24-48 saati içinde LOAF boyutunun güncellenmesini izleyin.

Mühendislik Temel Kuralı

• Oturumların %5'inden fazlasında uzun karelerde görünen herhangi bir tekil betik URL'si incelenmeye değerdir. Bu oranda, ay boyunca gerçek kullanıcıların ölçülebilir bir bölümünü etkiliyordur.
• Üçüncü taraf betikler etkileşim işleyicileri sırasında çalışmamalıdır. Bir etiket yöneticisi bir tıklama olayında senkronize olarak tetikleniyorsa, bu bir tarayıcı sınırlaması değil, bir yapılandırma sorunudur.
• Tek bir betik için 200 ms'nin üzerindeki uzun kare süresi açık bir sinyaldir. LoAF API, kare içindeki betik başına süreyi raporlar. Bir karenin 200 ms veya daha fazlasını tüketen herhangi bir betik, sonrasında gelen INP değerinin birincil nedenidir.
• LOAF listesindeki birinci taraf betikler genellikle framework yüküne işaret eder. React, Vue ve Angular, durum güncellemeleri sırasında uzun kareler üretebilir. LoAF URL'si kendi paketiniz olacaktır. Yalnızca ağın değil, bileşen ağacının da profilini çıkarın.

LOAF boyutu size hiçbir sentetik testin veremeyeceği bir şey verir: üretim ortamında gerçek kullanıcıları hangi betiklerin engellediğinin gerçek dünya sıklığına göre sıralanmış kanıtı. Buna göre filtreleyin, INP verilerinizle çapraz referanslayın ve tam olarak neyi, hangi sırayla düzelteceğinize dair önceliklendirilmiş bir listeye sahip olun.