Uzun Animasyon Çerçeveleri API'si

Barry Pollard
Noam Rosenthal

Long Animation Frames API (LoAF olarak telaffuz edilen Lo-Af), yavaş kullanıcı arayüzü güncellemelerinin daha iyi anlaşılması için Long Tasks API'ye yapılan bir güncellemedir. Bu, duyarlılığı ölçen Sonraki Boyamayla Etkileşim (INP) Core Web Vitals metriğini etkileme olasılığı yüksek olan yavaş animasyon karelerini veya düzgünlüğü etkileyen diğer kullanıcı arayüzü lekelerini belirlemek için yararlı olabilir.

API'nin durumu

Tarayıcı Desteği

  • Chrome: 123..
  • Kenar: 123..
  • Firefox: Desteklenmez..
  • Safari: desteklenmez..

Kaynak

Chrome 116'dan Chrome 122'ye kadar olan kaynak denemesinin ardından LoAF API'si Chrome 123'ten gönderildi.

Arka plan: Long Tasks API

Tarayıcı Desteği

  • Chrome: 58..
  • Kenar: 79..
  • Firefox: Desteklenmez..
  • Safari: desteklenmez..

Kaynak

Long Animation Frames API'si, Chrome'da bir süredir (Chrome 58'den itibaren) kullanımda olan Long Tasks API'nin bir alternatifidir. Adından da anlaşılacağı gibi Long Task API, ana iş parçacığını 50 milisaniye veya daha uzun süre kaplayan uzun görevleri izlemenize olanak tanır. Uzun görevler, PeformanceObserver ile PerformanceLongTaskTiming arayüzü kullanılarak izlenebilir:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'longtask', buffered: true });

Uzun görevler, yanıt verme hızıyla ilgili sorunlara neden olabilir. Kullanıcı bir sayfayla etkileşim kurmaya çalışırsa (örneğin, bir düğmeyi tıklar veya bir menüyü açarsa) ancak ana iş parçacığı zaten uzun bir görevle ilgileniyorsa kullanıcının etkileşimi gecikir ve söz konusu görevin tamamlanmasını bekler.

Yanıt verme hızını iyileştirmek için genellikle uzun görevleri bölmeniz önerilir. Her uzun görev daha küçük görevlerden oluşan bir seriye bölünürse etkileşimlere verilen yanıtlarda önemli gecikmelerin önüne geçmek için bunlar arasında daha önemli görevlerin yürütülmesine izin verebilir.

Bu nedenle, yanıt verme hızını iyileştirmeye çalışırken ilk yapmanız gereken genellikle performans takibini gerçekleştirmek ve uzun görevlere bakmaktır. Bunun için Lighthouse gibi (Uzun ana iş parçacığı görevlerinden kaçınma denetimine sahip olan) laboratuvar tabanlı bir denetleme aracı veya Chrome Geliştirici Araçları'nda uzun görevlere göz atma yoluyla izin verilebilir.

Laboratuvar tabanlı testler, yanıt verme sorunlarını tanımlamak için genellikle kötü bir başlangıç noktasıdır. Bu araçlar etkileşimleri içermeyebilir. Ancak bu araçlar olası etkileşimlerin küçük bir alt kümesidir. İdeal olarak, alandaki yavaş etkileşimlerin nedenlerini ölçmeniz gerekir.

Long Tasks API'nin Eksiklikleri

Performans Gözlemcisi kullanarak sahadaki uzun görevleri ölçmek yalnızca bir miktar fayda sağlar. Aslına bakarsanız, uzun bir görevin ne kadar sürdüğünün ötesinde, o kadar fazla bilgi vermez.

Gerçek Kullanıcı İzleme (RUM) araçları genellikle uzun görevlerin sayısını veya süresini belirlemek ya da bu görevlerin hangi sayfalarda gerçekleştiğini belirlemek için bu metriği kullanır. Ancak bu uzun görevin nedenine dair temel bilgiler olmadan yalnızca sınırlı bir şekilde kullanılabilir. Long Tasks API yalnızca temel ilişkilendirme modeline sahiptir. Bu model, yalnızca uzun görevin içinde gerçekleştiğini (üst düzey doküman veya <iframe>) size bildirir. Tipik bir girişte gösterildiği gibi, bu modeli çağıran komut dosyası veya işlevi göstermez:

{
  "name": "unknown",
  "entryType": "longtask",
  "startTime": 31.799999997019768,
  "duration": 136,
  "attribution": [
    {
      "name": "unknown",
      "entryType": "taskattribution",
      "startTime": 0,
      "duration": 0,
      "containerType": "window",
      "containerSrc": "",
      "containerId": "",
      "containerName": ""
    }
  ]
}

Uzun Görevler API'si de bazı önemli görevleri hariç tutabileceği için tamamlanmamış bir görünümdür. Oluşturma gibi bazı güncellemeler, ideal olarak bir önceki yürütmeye dahil edilmesi gereken ayrı görevlerde gerçekleşir. Bu, güncellemenin "toplam işi" doğru şekilde ölçmesine neden olur. seçmeniz gerekir. Görevlere güvenmenin sınırlamaları hakkında daha ayrıntılı bilgi için "Uzun görevlerin yetersiz kaldığı yerler" bölümüne bakın.

Son sorun ise uzun görevlerin ölçülmesi sonucunda yalnızca 50 milisaniyelik sınırı aşan tek tek görevlerin raporlanmasıdır. Bir animasyon karesi, bu 50 milisaniyelik sınırdan daha küçük olan çeşitli görevlerden oluşabilir ancak yine de tarayıcının oluşturma yeteneğini toplu olarak engelleyebilir.

Long Animation Frames API'si

Tarayıcı Desteği

  • Chrome: 123..
  • Kenar: 123..
  • Firefox: Desteklenmez..
  • Safari: desteklenmez..

Kaynak

Long Animation Frames API (LoAF), Long Tasks API'nin bazı eksikliklerini gidermeyi amaçlayan yeni bir API'dir. Bu API, geliştiricilerin yanıt verme sorunlarını ele alma ve INP'yi iyileştirmeye yardımcı olacak daha uygulanabilir analizler elde etmesini sağlar.

İyi yanıt verme, sayfanın kendisiyle yapılan etkileşimlere hızlı yanıt verdiği anlamına gelir. Bunun için kullanıcının ihtiyaç duyduğu güncellemeleri zamanında yapmak ve bu güncellemelerin gerçekleşmesini engellemekten kaçınmak gerekir. INP için 200 milisaniye veya daha kısa sürede yanıt verilmesi önerilir ancak diğer güncellemeler (ör. animasyonlar) için çok uzun olsa bile bu süre geçilebilir.

Long Animation Frames API'si, engelleme çalışmasını ölçmeye alternatif bir yaklaşımdır. Long Animation Frames API, adından da anlaşılacağı gibi, bağımsız görevleri ölçmek yerine uzun animasyon karelerini ölçer. Uzun animasyon çerçevesi, oluşturma güncellemesinin 50 milisaniyeden fazla geciktiğinde ortaya çıkar (Long Tasks API eşiğiyle aynıdır).

Uzun animasyon kareleri, PerformanceObserver içeren uzun görevlere benzer şekilde gözlemlenebilir, ancak bunun yerine long-animation-frame türüne bakılır:

const observer = new PerformanceObserver((list) => {
  console.log(list.getEntries());
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Önceki uzun animasyon kareleri, aşağıdaki şekilde Performans Zaman Çizelgesi'nden de sorgulanabilir:

const loafs = performance.getEntriesByType('long-animation-frame');

Ancak daha yeni girişler atlanan performans girişleri için bir maxBufferSize mevcuttur. Bu nedenle, PerformanceObserver yaklaşımı önerilir. long-animation-frame arabellek boyutu, long-tasks ile aynı şekilde 200 olarak ayarlandı.

Görevler yerine çerçevelere bakmanın avantajları

Buna görevler açısından değil kare perspektifinden bakmanın temel avantajı, uzun bir animasyonun kümülatif olarak uzun bir animasyon karesi ile sonuçlanan herhangi bir sayıda görevden oluşabilmesidir. Bu, daha önce bahsedilen son noktayı ele alır. Bu bağlamda, bir animasyon karesinden önceki çok sayıda küçük, oluşturmayı engelleyen görevin toplamı Long Tasks API tarafından görünmeyebilir.

Uzun görevlerle ilgili bu alternatif görünümün bir başka avantajı da tüm karenin zamanlama dökümlerini sağlayabilmesidir. LoAF, Long Tasks API gibi yalnızca bir startTime ve duration eklemek yerine kare süresinin çeşitli bölümlerinin çok daha ayrıntılı bir dökümünü içerir:

  • startTime: Gezinme başlangıç zamanına göre uzun animasyon karesinin başlangıç zamanı.
  • duration: Uzun animasyon karesinin süresi (sunum süresi hariç).
  • renderStart: Oluşturma döngüsünün başlangıç zamanıdır. Bu süre içinde requestAnimationFrame geri çağırma, stil ve düzen hesaplaması, yeniden boyutlandırma gözlemleyicisi ve kesişim gözlemleyici geri çağırmaları bulunur.
  • styleAndLayoutStart: Stil ve düzen hesaplamalarında harcanan dönemin başlangıcı.
  • firstUIEventTimestamp: Bu çerçeve boyunca işlenecek ilk kullanıcı arayüzü etkinliğinin (fare/klavye vb.) zamanı.
  • blockingDuration: Animasyon karesinin engellendiği milisaniye cinsinden süre.

Bu zaman damgaları, uzun animasyon karesinin zamanlamalara bölünmesini sağlar:

Zamanlama Hesaplama
Başlangıç Zamanı startTime
Bitiş Zamanı startTime + duration
Çalışma süresi renderStart ? renderStart - startTime : duration
Oluşturma süresi renderStart ? (startTime + duration) - renderStart: 0
Oluşturma: Ön düzen süresi styleAndLayoutStart ? styleAndLayoutStart - renderStart : 0
Oluşturma: Stil ve Düzen süresi styleAndLayoutStart ? (startTime + duration) - styleAndLayoutStart : 0

Bu zamanlamalar hakkında daha fazla bilgi için açıklayıcıya bakın. Açıklamada, uzun bir animasyon karesine hangi etkinliğin katkıda bulunduğuyla ilgili ayrıntılı bilgi verilir.

Daha iyi ilişkilendirme

long-animation-frame giriş türü, uzun bir animasyon karesine katkıda bulunan her komut dosyasının daha iyi ilişkilendirme verilerini içerir.

Long Tasks API'ye benzer şekilde bu da bir dizi ilişkilendirme girişinde sağlanır. Bu girişlerin her birinde aşağıdaki ayrıntılar bulunur:

  • Hem name hem de EntryType, script sonucunu döndürür.
  • Komut dosyasının nasıl çağrıldığını gösteren anlamlı bir invoker (örneğin, 'IMG#id.onload', 'Window.requestAnimationFrame' veya 'Response.json.then').
  • Komut dosyası giriş noktasının invokerType:
    • user-callback: Bir web platformu API'sinden kaydedilen bilinen bir geri çağırma (örneğin, setTimeout, requestAnimationFrame).
    • event-listener: Platform etkinliğini dinleyici (örneğin, click, load, keyup).
    • resolve-promise: Belirli bir platformun işleyici (örneğin, fetch()). Taahhütlerde, aynı vaatlerin işleyicilerin tek bir "script" olarak toplandığına dikkat edin..
    • reject-promise: resolve-promise uyarınca, ancak ret geçerlidir.
    • classic-script: Komut dosyası değerlendirmesi (örneğin, <script> veya import())
    • module-script: classic-script ile aynıdır ancak modül komut dosyaları içindir.
  • Komut dosyası için zamanlama verilerini ayırın:
    • startTime: Giriş işlevinin çağrıldığı zaman.
    • duration: startTime ile sonraki mikro görev sırasının işlenmesinin tamamlandığı zaman arasındaki süre.
    • executionStart: Derlemeden sonraki zaman.
    • forcedStyleAndLayoutDuration: Bu işlevdeki zorunlu düzeni ve stili işlemek için harcanan toplam süre (ödünleştirme bölümüne bakın).
    • pauseDuration: "Duraklatma" işleminde harcanan toplam süre eşzamanlı işlemler (uyarı, eşzamanlı XHR).
  • Komut dosyası kaynağı ayrıntıları:
    • sourceURL: Varsa komut dosyası kaynağının adı (veya bulunamadıysa boş).
    • sourceFunctionName: Varsa komut dosyası işlevinin adı (veya bulunamazsa boştur).
    • sourceCharPosition: Kullanılabilir olduğunda komut dosyası karakter konumu (veya bulunamazsa -1).
  • windowAttribution: Uzun animasyon çerçevesinin bulunduğu kapsayıcı (üst düzey doküman veya <iframe>).
  • window: Aynı kaynak pencereye referans.
ziyaret edin.

Kaynak girişleri, geliştiricilerin uzun animasyon karesindeki her bir komut dosyasının çağrı komut dosyasındaki karakter konumuna kadar tam olarak nasıl çağrıldığını bilmesine olanak tanır. Bu, JavaScript kaynağında, uzun animasyon çerçevesiyle sonuçlanan tam konumu verir.

long-animation-frame performans girişi örneği

Tek bir komut dosyası içeren eksiksiz bir long-animation-frame performans girişi örneği:

{
  "blockingDuration": 0,
  "duration": 60,
  "entryType": "long-animation-frame",
  "firstUIEventTimestamp": 11801.099999999627,
  "name": "long-animation-frame",
  "renderStart": 11858.800000000745,
  "scripts": [
    {
      "duration": 45,
      "entryType": "script",
      "executionStart": 11803.199999999255,
      "forcedStyleAndLayoutDuration": 0,
      "invoker": "DOMWindow.onclick",
      "invokerType": "event-listener",
      "name": "script",
      "pauseDuration": 0,
      "sourceURL": "https://web.dev/js/index-ffde4443.js",
      "sourceFunctionName": "myClickHandler",
      "sourceCharPosition": 17796,
      "startTime": 11803.199999999255,
      "window": [Window object],
      "windowAttribution": "self"
    }
  ],
  "startTime": 11802.400000000373,
  "styleAndLayoutStart": 11858.800000000745
}

Görebileceğiniz üzere bu, web sitelerinin oluşturma güncellemelerinde yaşanan gecikmenin nedenini anlayabilmesi için her zamankinden daha fazla veri sağlıyor.

Alanda Long Animation Frames API'sini kullanın

Chrome Geliştirici Araçları ve Lighthouse gibi araçlar, sorunların keşfedilmesi ve yeniden oluşturulması için kullanışlı olsa da kullanıcı deneyiminin yalnızca alan verilerinin sağlayabileceği önemli yönlerini kaçırabilecek laboratuvar araçlarıdır.

Long Animation Frames API'si, Long Tasks API'nin ulaşamadığı kullanıcı etkileşimleri için önemli içerik verilerini toplamak üzere alanda kullanılmak üzere tasarlanmıştır. Bu, etkileşimle ilgili başka şekilde keşfedemeyeceğiniz sorunları tanımlamanıza ve yeniden oluşturmanıza yardımcı olabilir.

Uzun Animasyon Çerçeveleri API desteği algılama özelliği

API'nin desteklenip desteklenmediğini test etmek için aşağıdaki kodu kullanabilirsiniz:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  // Monitor LoAFs
}

Long Animation Frames API'nin en belirgin kullanım alanı, Next Paint ile Etkileşim (INP) sorunlarının teşhis edilmesine ve düzeltilmesine yardımcı olmaktır. Bu, Chrome ekibinin bu API'yi geliştirmesinin temel nedenlerinden biriydi. İyi INP, tüm etkileşimlerin etkileşimden çerçevenin boyanmasına kadar 200 milisaniye veya daha kısa bir sürede yanıtlandığı yerdir. Long Animation Frames API, 50 ms veya daha uzun süren tüm kareleri ölçtüğünden, en sorunlu INP'ler bu etkileşimleri teşhis etmenize yardımcı olmak için LoAF verilerini içermelidir.

"INP LoAF" aşağıdaki şemada gösterildiği gibi, INP etkileşimini içeren LoAF'dir:

INP LoAF&#39;nin vurgulandığı, bir sayfadaki uzun animasyon kareleri örnekleri.
Bir sayfada çok sayıda LoAF olabilir. Bunlardan biri INP etkileşimiyle ilgilidir.

Bazı durumlarda, bir INP etkinliğinin iki LoAF'yi kapsaması mümkündür. Genellikle etkileşim, karenin bir önceki karenin oluşturma kısmını başlattıktan sonra gerçekleşirse ve etkinlik işleyici de sonraki karede işleme koyduğu etkinlik işleyiciden sonra gerçekleşir:

INP LoAF&#39;nin vurgulandığı, bir sayfadaki uzun animasyon kareleri örnekleri.
Bir sayfada çok sayıda LoAF olabilir. Bunlardan biri INP etkileşimiyle ilgilidir.

Bazı nadir durumlarda ikiden fazla LoAF'yi kapsayabilir.

INP etkileşimiyle ilişkili LoAF verilerini kaydetmek, INP etkileşimi hakkında çok daha fazla bilgi edinerek bunu teşhis etmenize yardımcı olabilir. Bu, özellikle giriş gecikmesini anlamanız açısından faydalıdır, çünkü söz konusu çerçevede hangi komut dosyalarının çalıştırıldığını görebilirsiniz.

Kullanıcılarınız için başka komut dosyaları çalışıyor olabileceğinden, etkinlik işleyicileriniz bu komut dosyaları için görülen değerleri yeniden oluşturmuyorsa açıklanmayan işleme süresi ve sunum gecikmesini anlamanız da yararlı olabilir.

Bir INP girişini ilgili LoAF girişine veya girişlerine bağlamak için doğrudan API yoktur ancak bunu, kodda her birinin başlangıç ve bitiş zamanlarını karşılaştırarak yapmak mümkündür (WhyNp örnek komut dosyasına bakın).

web-vitals kitaplığı, 4. sürümdeki INP ilişkilendirme arayüzünün longAnimationFramesEntries özelliğinde kesişen tüm LoAF'leri içerir.

LoAF girişini veya girişlerini bağladıktan sonra, INP ilişkilendirmesiyle bilgiler ekleyebilirsiniz. scripts nesnesi, bu çerçevelerde başka nelerin çalıştığını gösterebildiği için en değerli bilgilerden bazılarını içerir. Bu nedenle bu verileri analiz hizmetinize geri çekmek, etkileşimlerin neden yavaş olduğuyla ilgili daha fazla bilgi edinmenize olanak tanır.

INP etkileşimi için LoAF'leri raporlamak, sayfanızdaki en acil etkileşim sorunlarını bulmanın iyi bir yoludur. Her kullanıcı sayfanızla farklı şekilde etkileşim kurabilir ve yeterli miktarda INP ilişkilendirme verisi olduğunda INP ilişkilendirme verilerine bir dizi olası sorun dahil edilir. Bu, hangi komut dosyalarının yavaş INP ile ilişkili olduğunu görmek için komut dosyalarını hacme göre sıralamanıza olanak tanır.

Daha fazla uzun animasyon verisini bir analiz uç noktasına geri bildirme

Yalnızca INP LoAF'lerine bakmanın dezavantajı, gelecekte INP sorunlarına yol açabilecek, iyileştirme yapılabilecek diğer alanları gözden kaçırma ihtimalinizdir. Bu durum, INP sorununu büyük bir iyileşme umarak düzelttiğinizde kuyruğunuzu takip etme hissine yol açabilir. Bir sonraki en yavaş etkileşim, bundan yalnızca küçük bir miktar daha iyidir. Bu nedenle de INP'niz pek iyileşmez.

Bu nedenle, dikkatinizi yalnızca INP LoAF'ye bakmak yerine, sayfanın ömründeki tüm LoAF'leri hesaba katmayı düşünebilirsiniz:

INP etkileşimi olmasa bile etkileşimler sırasında bir kısmı gerçekleşen çok sayıda LoAF içeren bir sayfa.
Tüm LoAF'leri incelemek, ileride ortaya çıkabilecek INP sorunlarını tespit etmenize yardımcı olabilir.

Bununla birlikte, her LoAF girişi kayda değer veri içerdiğinden, muhtemelen tümünü geri işaretlemek istemeyebilirsiniz. Bunun yerine, analizinizi bazı LoAF'lerle veya bazı verilerle sınırlandırmayı tercih edebilirsiniz.

Önerilen kalıplardan bazıları şunlardır:

Bu kalıplardan hangisinin size en uygun olduğu, optimizasyon yolculuğunuzun ne kadar ilerlediğine ve animasyon karelerinin yaygın olarak ne kadar uzun olduğuna bağlıdır. Daha önce yanıt verme için hiç optimize edilmemiş bir sitede, çok sayıda LoAF'yi (etkileşimli LoAF) sınırlandırmak, yüksek bir eşik belirlemek veya yalnızca en kötülerine bakmak isteyebilirsiniz. Sık karşılaşılan yanıt verme sorunlarını çözerken bunu yalnızca etkileşimlerle sınırlamayarak ve eşikleri düşürerek genişletebilir ya da belirli kalıplar aratabilirsiniz.

Etkileşimlerle birlikte uzun animasyon karelerini gözlemleyin

INP uzun animasyon çerçevesinin ötesinde analizler elde etmek için etkileşim içeren tüm LoAF'lere bakabilirsiniz (firstUIEventTimestamp değeri olduğunda algılanabilir).

Bu ayrıca, INP LoAF'lerini izlemek için ikisi arasında ilişki kurmaya çalışmak yerine daha kolay bir yöntem olabilir ve bu yöntem daha karmaşık olabilir. Çoğu durumda bu, belirli bir ziyaretle ilgili INP LoAF'yi içerir. Nadiren de olsa, düzeltmesi gereken uzun etkileşimler diğer kullanıcılar için INP etkileşimi olabileceğinden, sorunun yine de gösterilmesi söz konusu olur.

Aşağıdaki kod, kare sırasında etkileşimin gerçekleştiği 150 milisaniyeden uzun süren tüm LoAF girişlerini günlüğe kaydeder. 150 değeri, 200 milisaniyelik "iyi" değerden biraz daha az olduğu için seçilmiştir INP eşiği. İhtiyaçlarınıza bağlı olarak daha yüksek veya daha düşük bir değer seçebilirsiniz.

const REPORTING_THRESHOLD_MS = 150;

const observer = new PerformanceObserver(list => {
    for (const entry of list.getEntries()) {
      if (entry.duration > REPORTING_THRESHOLD_MS &&
        entry.firstUIEventTimestamp > 0
      ) {
        // Example here logs to console, but could also report back to analytics
        console.log(entry);
      }
    }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Belirli bir eşikten uzun animasyon karelerini gözlemleme

Diğer bir strateji, tüm LoAF'leri izlemek ve belirli bir eşikten büyük olanları daha sonra analiz edilmek üzere bir analiz uç noktasına geri yönlendirmektir.

const REPORTING_THRESHOLD_MS = 150;

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.duration > REPORTING_THRESHOLD_MS) {
      // Example here logs to console, but could also report back to analytics
      console.log(entry);
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Uzun animasyon çerçevesi girişleri oldukça büyük olabileceğinden, geliştiriciler girişten hangi verilerin Analytics'e gönderileceğine karar vermelidir. Örneğin, girişin özet saatleri ve komut dosyası adları veya gerekli olduğu düşünülebilecek diğer minimum içerik verileri kümesi olabilir.

En kötü uzun animasyon karelerini gözlemleme

Siteler, belirli bir eşiğe sahip olmak yerine, işaretlenmesi gereken veri hacmini azaltmak için verileri en uzun animasyon karesinde (veya karelerinde) toplamak isteyebilir. Bu nedenle, bir sayfa deneyimini ne kadar uzun animasyon çerçevesine alırsa taşısın, yalnızca en kötü olan, beş veya her ne kadar kesinlikle gerekli olan uzun animasyon karesi için veriler gösterilir.

MAX_LOAFS_TO_CONSIDER = 10;
let longestBlockingLoAFs = [];

const observer = new PerformanceObserver(list => {
  longestBlockingLoAFs = longestBlockingLoAFs.concat(list.getEntries()).sort(
    (a, b) => b.blockingDuration - a.blockingDuration
  ).slice(0, MAX_LOAFS_TO_CONSIDER);
});
observer.observe({ type: 'long-animation-frame', buffered: true });

Bu stratejiler de birleştirilebilir. Yalnızca etkileşimi 150 milisaniyeden uzun olan en kötü 10 LoAF'ye bakın.

Uygun zamanda (ideal olarak visibilitychange etkinliğinde) analize geri dönün. Yerel test için düzenli olarak console.table kullanabilirsiniz:

console.table(longestBlockingLoAFs);

Uzun animasyon karelerinde sık karşılaşılan kalıpları tanımlama

Alternatif bir strateji, uzun animasyon karesi girişlerinde en çok görünen yaygın komut dosyalarına bakmaktır. Tekrarlanan suçluların belirlenmesi için veriler senaryo ve karakter konumu düzeyinde bildirilebiliyordu.

Bu, özellikle performans sorunlarına neden olan temaların veya eklentilerin bir dizi sitede belirlenebildiği özelleştirilebilir platformlarda işe yarayabilir.

Uzun animasyon karelerinde yaygın olarak kullanılan komut dosyalarının (veya üçüncü taraf kaynaklarının) yürütme süreleri toplanabilir ve bir site veya site koleksiyonundaki uzun animasyon karelerine en çok katkıda bulunanların belirlenmesi için tekrar raporlanabilir. Örneğin, URL'lere bakmak için:

const observer = new PerformanceObserver(list => {
  const allScripts = list.getEntries().flatMap(entry => entry.scripts);
  const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
  const scriptsBySource= scriptSource.map(sourceURL => ([sourceURL,
      allScripts.filter(script => script.sourceURL === sourceURL)
  ]));
  const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
    sourceURL,
    count: scripts.length,
    totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
  }));
  processedScripts.sort((a, b) => b.totalDuration - a.totalDuration);
  // Example here logs to console, but could also report back to analytics
  console.table(processedScripts);
});

observer.observe({type: 'long-animation-frame', buffered: true});

Bu çıkışın bir örneği şu şekildedir:

(index) sourceURL count totalDuration
0 'https://example.consent.com/consent.js' 1 840
1 'https://example.com/js/analytics.js' 7 628
2 'https://example.chatapp.com/web-chat.js' 1 5

Araçta Long Animation Frames API'sini kullanma

API, yerel hata ayıklama için ek geliştirici araçlarına da olanak tanır. Lighthouse ve Chrome Geliştirici Araçları gibi bazı araçlar, bu verilerin çoğunu daha alt düzey izleme ayrıntılarını kullanarak toplayabilse de bu üst düzey API'ye sahip olmak diğer araçların bu verilere erişmesine olanak tanıyabilir.

Geliştirici Araçları'nda uzun animasyon karesi verilerini gösterme

performance.measure() API kullanarak Geliştirici Araçları'nda uzun animasyon kareleri gösterebilirsiniz. Daha sonra bu kareler, performans iyileştirmeleri için çalışmalarınızı nereye odaklayacağınızı göstermek amacıyla performans izlemelerinde Geliştirici Araçları kullanıcı zamanlamaları kanalında gösterilir:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    performance.measure('LoAF', {
      start: entry.startTime,
      end: entry.startTime + entry.duration,
    });
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Daha uzun vadede, muhtemelen Geliştirici Araçları'nın kendisine dahil edilecektir ancak önceki kod snippet'i bu süre içinde burada gösterilmesine olanak tanır.

Diğer geliştirici araçlarında uzun animasyon karesi verilerini kullanma

Web Vitals uzantısı, performans sorunlarını teşhis etmek için günlüğe kaydedilen hata ayıklama bilgilerini günlüğe kaydetme değerini gösterdi.

Ayrıca, artık her INP geri çağırması ve her etkileşim için uzun animasyon karesi verilerini de gösterir:

Web Vitals Uzantısı konsolu günlük kaydı.
Web Vitals Uzantı konsolu günlük kaydı, LoAF verilerini gösterir.

Otomatik test araçlarında uzun animasyon çerçevesi verilerini kullanma

CI/CD ardışık düzenlerindeki otomatikleştirilmiş test araçları, çeşitli test paketlerini çalıştırırken uzun animasyon karelerini ölçerek olası performans sorunlarıyla ilgili ayrıntıları ortaya çıkarabilir.

SSS

Bu API hakkında sık sorulan sorulardan bazıları şunlardır:

Neden Long Tasks API'yi genişletip tekrar yapmıyorsunuz?

Bu, olası yanıt verme sorunları için benzer ancak nihayetinde farklı olan bir ölçüm bildirmeye alternatif bir bakıştır. Mevcut Uzun Görevler API'sini kullanan sitelerin, mevcut kullanım alanlarını kesintiye uğratmaması için çalışmaya devam etmesini sağlamak önemlidir.

Long Tasks API, LoAF'nin bazı özelliklerinden (ör. daha iyi bir ilişkilendirme modeli) yararlanabilir. Ancak biz görevler yerine çerçevelere odaklanmanın, bu API'yi mevcut Long Tasks API'den temelde farklı bir API haline getiren pek çok avantaj sunduğunu düşünüyoruz.

Neden komut dosyası girişlerim yok?

Bu, uzun animasyon çerçevesinin JavaScript'ten değil, bunun yerine büyük oluşturma çalışmasından kaynaklandığını gösterebilir.

Bu durum, uzun animasyon çerçevesinin JavaScript'ten kaynaklandığı ancak komut dosyası ilişkilendirmesinin, daha önce belirtildiği gibi çeşitli gizlilik nedeniyle (esasen JavaScript'in sayfaya ait olmadığı) sunulamadığı durumlarda da gerçekleşebilir.

Neden komut dosyası girişlerim var ancak kaynak bilgileri hiç yok veya sınırlı?

Bu durum, dikkate alınacak iyi bir kaynak olmaması da dahil olmak üzere çeşitli nedenlerden kaynaklanabilir.

Komut dosyası bilgileri de no-cors cross-origin komut dosyaları için sınırlandırılacaktır; ancak bu sorun, <script> çağrısına crossOrigin = "anonymous" eklenerek CORS kullanılarak bu komut dosyaları getirilerek çözülebilir.

Örneğin, sayfaya eklenecek varsayılan Google Etiket Yöneticisi komut dosyası:

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->

GTM için tüm ilişkilendirme ayrıntılarının sağlanmasına olanak tanımak amacıyla j.crossOrigin = "anonymous" eklenecek şekilde iyileştirilebilir

Bu özellik Long Tasks API'nin yerini alacak mı?

Long Animation Frames API'nin uzun görevleri ölçmek için daha iyi ve eksiksiz bir API olduğuna inansak da şu anda Long Tasks API'yi kullanımdan kaldırma planımız yoktur.

Geri bildirim istendi

Geri bildirimlerinizi GitHub Sorunlar listesinde, Chrome'un API uygulamasındaki hataları ise Chrome'un sorun izleyicisinde bildirebilirsiniz.

Sonuç

Long Animation Frames API'si, önceki Long Tasks API'ye göre birçok potansiyel avantajı olan heyecan verici yeni bir API'dir.

INP tarafından ölçülen yanıt verme sorunlarını çözmede kilit bir araç olduğu kanıtlandı. INP, optimize edilmesi zor bir metriktir. Bu API, Chrome ekibinin geliştiriciler için sorunların tanımlanmasını ve ele alınmasını kolaylaştırmak için bu API'den biridir.

Long Animation Frames API'sinin kapsamı INP'nin ötesinde uzanır ve yavaş güncellemelerin web sitesinin kullanıcı deneyiminin genel sorunsuzluğunu etkileyebilecek diğer nedenlerini belirlemeye yardımcı olabilir.

Teşekkür

Henry Be tarafından Unsplash'teki küçük resim.