API Frame Animasi Panjang

Barry Pollard

Noam Rosenthal

Long Animation Frames API (LoAF diucapkan Lo-Af) adalah update pada Long Tasks API untuk memberikan pemahaman yang lebih baik tentang update antarmuka pengguna (UI) yang lambat. Parameter ini dapat berguna untuk mengidentifikasi frame animasi lambat yang mungkin memengaruhi metrik Core Web Vital Interaction to Next Paint (INP) yang mengukur responsivitas, atau untuk mengidentifikasi jank UI lain yang memengaruhi kelancaran.

Status API

Setelah uji coba origin dari Chrome 116 hingga Chrome 122, LoAF API telah dikirim dari Chrome 123.

Latar belakang: Long Tasks API

Long Animation Frames API adalah alternatif untuk Long Tasks API yang telah tersedia di Chrome selama beberapa waktu sekarang (sejak Chrome 58). Seperti namanya, Long Task API memungkinkan Anda memantau tugas yang berjalan lama, yaitu tugas yang menempati thread utama selama 50 milidetik atau lebih. Tugas yang berjalan lama dapat dipantau menggunakan antarmuka PerformanceLongTaskTiming, dengan PeformanceObserver:

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

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

Tugas yang lama cenderung menyebabkan masalah responsivitas. Jika pengguna mencoba berinteraksi dengan halaman—misalnya, mengklik tombol, atau membuka menu—tetapi thread utama sudah menangani tugas yang panjang, maka interaksi pengguna tertunda menunggu hingga tugas tersebut selesai.

Untuk meningkatkan responsivitas, sering kali disarankan untuk memisahkan tugas yang berjalan lama. Jika setiap tugas yang panjang dipecah menjadi serangkaian tugas yang lebih kecil, tugas yang lebih penting dapat dijalankan di antaranya untuk menghindari penundaan yang signifikan dalam menanggapi interaksi.

Jadi, saat mencoba meningkatkan responsivitas, upaya pertama sering kali adalah menjalankan pelacakan performa dan melihat tugas yang berjalan lama. Hal ini dapat dilakukan melalui alat audit berbasis lab seperti Lighthouse (yang memiliki audit Hindari tugas thread utama yang panjang), atau dengan melihat tugas yang berjalan lama di Chrome DevTools.

Pengujian berbasis lab sering kali merupakan titik awal yang buruk untuk mengidentifikasi masalah responsivitas, karena alat ini mungkin tidak menyertakan interaksi—jika digunakan, hanya sebagian kecil dari kemungkinan interaksi. Idealnya, Anda akan mengukur penyebab lambatnya interaksi di lapangan.

Kekurangan Long Tasks API

Mengukur tugas yang berjalan lama di lapangan menggunakan Performance Observer hanya sedikit berguna. Pada kenyataannya, model ini tidak memberikan banyak informasi selain fakta bahwa tugas yang lama terjadi, dan berapa lama waktu yang dibutuhkan.

Alat Pemantauan Pengguna Nyata (RUM) sering menggunakan ini untuk tren jumlah atau durasi tugas yang lama atau mengidentifikasi halaman mana yang terjadi—tetapi tanpa detail dasar tentang penyebab tugas yang lama, hal ini hanyalah penggunaan terbatas. Long Tasks API hanya memiliki model atribusi dasar, yang hanya memberi tahu Anda container tempat tugas panjang terjadi (dokumen tingkat atas atau <iframe>), tetapi bukan skrip atau fungsi yang memanggilnya, seperti yang ditunjukkan oleh entri standar:

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

Long Tasks API juga merupakan tampilan yang tidak lengkap karena mungkin juga mengecualikan beberapa tugas penting. Beberapa update—seperti rendering—terjadi dalam tugas terpisah yang idealnya harus disertakan bersama dengan eksekusi sebelumnya yang menyebabkan update tersebut mengukur "total pekerjaan" secara akurat atas interaksi tersebut. Untuk detail selengkapnya tentang batasan mengandalkan tugas, lihat bagian "Di mana tugas yang berjalan lama gagal" dalam penjelasan.

Masalah terakhir adalah pengukuran tugas yang berjalan lama hanya melaporkan tugas individual yang memakan waktu lebih dari batas 50 milidetik. Bingkai animasi dapat terdiri dari beberapa tugas yang lebih kecil dari batas 50 milidetik ini, namun secara kolektif masih memblokir kemampuan browser untuk merender.

Long Animation Frames API

Long Animation Frames API (LoAF) adalah API baru yang berupaya mengatasi beberapa kekurangan Long Tasks API agar developer mendapatkan lebih banyak hasil analisis yang bisa ditindaklanjuti untuk membantu mengatasi masalah responsivitas dan meningkatkan INP.

Responsivitas yang baik berarti halaman merespons interaksi yang dilakukan dengan cepat. Hal ini berarti mampu melukiskan pembaruan apa pun yang diperlukan oleh pengguna secara tepat waktu, dan menghindari pemblokiran pembaruan ini agar tidak terjadi. Untuk INP, sebaiknya respons dalam waktu 200 milidetik atau kurang, tetapi untuk update lainnya (misalnya, animasi) meskipun durasinya mungkin terlalu panjang.

Long Animation Frames API adalah pendekatan alternatif untuk mengukur pekerjaan pemblokiran. Daripada mengukur tugas satu per satu, Long Animation Frames API—seperti namanya—mengukur frame animasi yang panjang. Frame animasi yang panjang adalah saat update rendering tertunda di atas 50 milidetik (sama dengan batas untuk Long Tasks API).

Frame animasi yang panjang dapat diamati dengan cara yang sama seperti tugas panjang dengan PerformanceObserver, tetapi dengan melihat jenis long-animation-frame:

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

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

Frame animasi panjang sebelumnya juga dapat dikueri dari Linimasa Performa seperti berikut:

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

Namun, ada maxBufferSize untuk entri performa setelah entri baru dihapus, sehingga pendekatan PerformanceObserver adalah pendekatan yang direkomendasikan. Ukuran buffer long-animation-frame disetel ke 200, sama seperti untuk long-tasks.

Keuntungan melihat {i>frame<i} daripada tugas

Keuntungan utama melihat hal ini dari perspektif frame dan bukan perspektif tugas, adalah animasi yang panjang dapat terdiri dari sejumlah tugas yang secara kumulatif menghasilkan frame animasi yang panjang. Hal ini akan mengatasi poin terakhir yang disebutkan sebelumnya, di mana jumlah banyak tugas yang lebih kecil dan memblokir render sebelum frame animasi mungkin tidak dimunculkan oleh Long Tasks API.

Keuntungan lebih lanjut dari tampilan alternatif ini pada tugas yang berjalan lama adalah kemampuan untuk memberikan perincian waktu pada seluruh frame. Daripada hanya menyertakan startTime dan duration, seperti Long Tasks API, LoAF menyertakan perincian yang jauh lebih mendetail tentang berbagai bagian durasi frame termasuk:

• startTime: waktu mulai frame animasi panjang relatif terhadap waktu mulai navigasi.
• duration: durasi frame animasi yang panjang (tidak termasuk waktu presentasi).
• renderStart: waktu mulai siklus rendering, yang mencakup callback requestAnimationFrame, penghitungan gaya dan tata letak, serta mengubah ukuran callback observer dan observer persimpangan.
• styleAndLayoutStart: awal jangka waktu yang dihabiskan dalam penghitungan gaya dan tata letak.
• firstUIEventTimestamp: waktu peristiwa UI pertama (mouse/keyboard dan sebagainya) yang harus ditangani selama frame ini.
• blockingDuration: durasi dalam milidetik saat frame animasi diblokir.

Stempel waktu ini memungkinkan frame animasi yang panjang dibagi menjadi beberapa pengaturan waktu:

Untuk mengetahui detail selengkapnya tentang pengaturan waktu masing-masing, lihat penjelasan, yang memberikan detail lebih mendetail tentang aktivitas mana yang berkontribusi pada frame animasi panjang.

Atribusi yang lebih baik

Jenis entri long-animation-frame menyertakan data atribusi yang lebih baik dari setiap skrip yang berkontribusi pada frame animasi panjang.

Serupa dengan Long Tasks API, API ini akan disediakan dalam array entri atribusi, yang masing-masing detailnya:

• name dan EntryType keduanya akan menampilkan script.
• invoker yang bermakna, yang menunjukkan cara skrip dipanggil (misalnya, 'IMG#id.onload', 'Window.requestAnimationFrame', atau 'Response.json.then').
• invokerType titik entri skrip:
  • user-callback: Callback yang diketahui dan terdaftar dari API platform web (misalnya, setTimeout, requestAnimationFrame).
  • event-listener: Pemroses peristiwa platform (misalnya, click, load, keyup).
  • resolve-promise: Pengendali promise platform (misalnya, fetch(). Perlu diketahui bahwa untuk promise, semua pengendali promise yang sama akan digabungkan menjadi satu "skrip").
  • reject-promise: Sesuai dengan resolve-promise, tetapi untuk penolakan.
  • classic-script: Evaluasi skrip (misalnya, <script> atau import())
  • module-script: Sama seperti classic-script, tetapi untuk skrip modul.
• Pisahkan data waktu untuk skrip tersebut:
  • startTime: Waktu saat fungsi entri dipanggil.
  • duration: Durasi antara startTime dan saat antrean tugas mikro berikutnya selesai diproses.
  • executionStart: Waktu setelah kompilasi.
  • forcedStyleAndLayoutDuration: Total waktu yang dihabiskan untuk memproses gaya dan tata letak paksa di dalam fungsi ini (lihat thrashing).
  • pauseDuration: Total waktu yang dihabiskan dalam "menjeda" operasi sinkron (peringatan, XHR sinkron).
• Detail sumber skrip:
  • sourceURL: Nama resource skrip jika tersedia (atau kosong jika tidak ditemukan).
  • sourceFunctionName: Nama fungsi skrip jika tersedia (atau kosong jika tidak ditemukan).
  • sourceCharPosition: Posisi karakter skrip jika tersedia (atau -1 jika tidak ditemukan).
• windowAttribution: Container (dokumen tingkat teratas, atau <iframe>) tempat frame animasi panjang terjadi.
• window: Referensi ke periode origin yang sama.

Jika disediakan, entri sumber memungkinkan developer mengetahui secara persis cara setiap skrip dalam frame animasi yang panjang dipanggil, hingga ke posisi karakter dalam skrip panggilan. Ini memberikan lokasi yang tepat dalam resource JavaScript yang menghasilkan frame animasi yang panjang.

Contoh entri performa long-animation-frame

Contoh entri performa long-animation-frame lengkap, yang berisi satu skrip, adalah:

{
  "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
}

Seperti yang dapat dilihat, hal ini memberikan jumlah data yang belum pernah ada sebelumnya agar situs dapat memahami penyebab update rendering yang lambat.

Menggunakan Long Animation Frames API di kolom

Alat seperti Chrome DevTools dan Lighthouse—meskipun berguna untuk menemukan dan mereproduksi masalah—merupakan alat lab yang mungkin melewatkan aspek penting pengalaman pengguna yang hanya dapat diberikan oleh data lapangan.

Long Animation Frames API dirancang untuk digunakan dalam kolom guna mengumpulkan data kontekstual penting bagi interaksi pengguna yang tidak dapat dilakukan oleh Long Tasks API. Fitur ini dapat membantu Anda mengidentifikasi dan mereproduksi masalah dengan interaktivitas yang mungkin tidak Anda temukan.

Fitur yang mendeteksi dukungan Long Animation Frames API

Anda dapat menggunakan kode berikut untuk menguji apakah API didukung:

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

Link ke interaksi INP terpanjang

Kasus penggunaan yang paling jelas untuk Long Animation Frames API adalah untuk membantu mendiagnosis dan memperbaiki masalah Interaction to Next Paint (INP), dan itulah salah satu alasan utama tim Chrome mengembangkan API ini. INP yang baik adalah tempat semua interaksi direspons dalam waktu 200 milidetik atau kurang dari interaksi sampai frame di-lukis, dan karena Long Animation Frames API mengukur semua frame yang memerlukan waktu 50 md atau lebih, INP yang paling bermasalah harus menyertakan data LoAF untuk membantu Anda mendiagnosis interaksi tersebut.

"INP LoAF" adalah LoAF yang mencakup interaksi INP, seperti yang ditunjukkan dalam diagram berikut:

Dalam beberapa kasus, peristiwa INP dapat menjangkau dua LoAF—biasanya jika interaksi terjadi setelah frame memulai bagian rendering frame sebelumnya, sehingga pengendali peristiwa yang diprosesnya dalam frame berikutnya:

Bahkan mungkin saja mencakup lebih dari dua LoAF pada beberapa situasi yang jarang terjadi.

Perekaman data LoAF yang terkait dengan interaksi INP memungkinkan Anda mendapatkan lebih banyak informasi tentang interaksi INP untuk membantu mendiagnosisnya. Hal ini sangat membantu untuk memahami penundaan input: karena Anda dapat melihat skrip lain yang berjalan di frame tersebut.

Sebaiknya Anda juga memahami durasi pemrosesan dan penundaan presentasi yang tidak dijelaskan jika pengendali peristiwa Anda tidak mereproduksi nilai yang terlihat untuk nilai tersebut, karena skrip lain mungkin berjalan untuk pengguna Anda yang mungkin tidak disertakan dalam pengujian Anda sendiri.

Tidak ada API langsung untuk menautkan entri INP dengan entri atau entri LoAF terkait, meskipun hal ini dapat dilakukan dalam kode dengan membandingkan waktu mulai dan waktu berakhir masing-masing (lihat skrip contoh WhyNp).

Library web-vitals menyertakan semua LoAF yang berpotongan di properti longAnimationFramesEntries antarmuka atribusi INP dari v4.

Setelah menautkan entri atau entri LoAF, Anda dapat menyertakan informasi dengan atribusi INP. Objek scripts berisi beberapa informasi yang paling berharga karena dapat menunjukkan apa lagi yang berjalan dalam frame tersebut. Jadi, dengan menemukan kembali data tersebut ke layanan analisis, Anda akan dapat memahami lebih lanjut mengapa interaksi berjalan lambat.

Pelaporan LoAF untuk interaksi INP adalah cara tepat untuk menemukan masalah interaktivitas yang paling mendesak di halaman Anda. Setiap pengguna dapat berinteraksi secara berbeda dengan halaman Anda, dan dengan volume data atribusi INP yang cukup, sejumlah potensi masalah akan disertakan dalam data atribusi INP. Hal ini memungkinkan Anda mengurutkan skrip berdasarkan volume untuk melihat skrip mana yang berkorelasi dengan INP yang lambat.

Melaporkan lebih banyak data animasi panjang kembali ke endpoint analisis

Satu kelemahan jika hanya melihat INP LoAF, adalah Anda mungkin melewatkan area potensial lain untuk peningkatan yang dapat menyebabkan masalah INP di masa mendatang. Hal ini dapat menimbulkan perasaan mencari arah di mana Anda memperbaiki masalah INP dengan harapan akan melihat peningkatan besar, hanya untuk menemukan interaksi paling lambat berikutnya hanya sedikit lebih baik dari itu sehingga INP Anda tidak meningkat jauh.

Jadi, daripada sekadar melihat INP LoAF, Anda sebaiknya mempertimbangkan semua LoAF di sepanjang masa aktif halaman:

Namun, setiap entri LoAF berisi data yang cukup besar, jadi Anda mungkin tidak ingin menunjukkan semuanya kembali. Sebagai gantinya, Anda ingin membatasi analisis Anda ke beberapa LoAF atau beberapa data.

Beberapa pola yang disarankan meliputi:

• Mengamati frame animasi panjang dengan interaksi
• Mengamati frame animasi yang lebih panjang dari batas tertentu
• Mengamati frame animasi panjang terburuk
• Mengidentifikasi pola umum dalam frame animasi panjang

Manakah dari pola berikut yang paling cocok untuk Anda, bergantung pada seberapa jauh perjalanan pengoptimalan Anda, dan seberapa panjang frame animasi yang umum. Untuk situs yang belum pernah mengoptimalkan responsivitas sebelumnya, mungkin ada banyak LoAF yang mungkin ingin Anda batasi hanya pada LoAF dengan interaksi, atau menetapkan batas tinggi, atau hanya melihat yang terburuk. Saat Anda menyelesaikan masalah responsivitas umum, Anda dapat memperluas ini dengan tidak membatasi hanya pada interaksi dan dengan menurunkan nilai minimum, atau mencari pola tertentu.

Amati frame animasi panjang dengan interaksi

Untuk mendapatkan insight selain frame animasi panjang INP, Anda dapat melihat semua LoAF dengan interaksi (yang dapat dideteksi dengan adanya nilai firstUIEventTimestamp).

Ini juga dapat menjadi metode yang lebih mudah untuk memantau INP LoAF daripada mencoba mengkorelasikan keduanya, yang bisa jadi lebih kompleks. Umumnya, hal ini akan mencakup INP LoAF untuk kunjungan tertentu, dan dalam kasus yang jarang terjadi jika kolom tersebut tidak masih menampilkan interaksi lama yang penting untuk diperbaiki, karena mungkin ini adalah interaksi INP untuk pengguna lain.

Kode berikut mencatat semua entri LoAF yang lebih besar dari 150 milidetik saat interaksi terjadi selama frame. Angka 150 dipilih di sini karena angkanya sedikit di bawah 200 milidetik jika “bagus” Nilai minimum INP. Anda dapat memilih nilai yang lebih tinggi atau lebih rendah bergantung pada kebutuhan.

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 });

Mengamati frame animasi yang lebih panjang dari batas tertentu

Strategi lain adalah memantau semua LoAF dan beacon yang lebih besar dari ambang batas tertentu kembali ke titik akhir analisis untuk analisis nanti:

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 });

Karena entri frame animasi yang panjang bisa sangat besar, developer harus memutuskan data apa dari entri yang harus dikirim ke analisis. Misalnya, waktu ringkasan entri dan mungkin nama skrip, atau beberapa set minimum data kontekstual lainnya yang mungkin dianggap perlu.

Amati frame animasi panjang terburuk

Daripada memiliki nilai minimum yang ditetapkan, situs sebaiknya mengumpulkan data pada frame (atau beberapa frame) animasi terpanjang, untuk mengurangi volume data yang perlu disuar. Jadi, tidak peduli berapa banyak {i>frame<i} animasi panjang yang dialami halaman, hanya data untuk yang terburuk, lima, atau berapa pun {i>frame<i} animasi panjang yang benar-benar diperlukan yang akan ditampilkan kembali.

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 });

Strategi ini juga dapat digabungkan—cukup lihat 10 LoAF terburuk, dengan interaksi, yang berdurasi lebih dari 150 milidetik.

Pada waktu yang tepat (idealnya pada peristiwa visibilitychange) beacon kembali ke analisis. Untuk pengujian lokal, Anda dapat menggunakan console.table secara berkala:

console.table(longestBlockingLoAFs);

Mengidentifikasi pola umum dalam frame animasi yang panjang

Strategi alternatifnya adalah dengan melihat skrip umum yang paling sering muncul dalam entri frame animasi yang panjang. Data dapat dilaporkan kembali pada tingkat posisi skrip dan karakter untuk mengidentifikasi pelanggar berulang.

Ini mungkin bekerja dengan sangat baik untuk platform yang dapat disesuaikan di mana tema atau plugin yang menyebabkan masalah kinerja dapat diidentifikasi di sejumlah situs.

Waktu eksekusi skrip umum—atau asal pihak ketiga—dalam frame animasi yang panjang dapat diringkas dan dilaporkan kembali untuk mengidentifikasi kontributor umum pada frame animasi panjang di seluruh situs atau kumpulan situs. Misalnya untuk melihat URL:

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});

Dan contoh dari output ini adalah:

Menggunakan Long Animation Frames API di alat

API ini juga memungkinkan alat developer tambahan untuk proses debug lokal. Meskipun beberapa alat seperti Lighthouse dan Chrome DevTools dapat mengumpulkan banyak data ini menggunakan detail pelacakan tingkat yang lebih rendah, memiliki API tingkat lebih tinggi ini dapat memungkinkan alat lain mengakses data ini.

Menampilkan data frame animasi panjang di DevTools

Anda dapat menampilkan frame animasi panjang di DevTools menggunakan performance.measure() API, yang kemudian ditampilkan di jalur waktu pengguna DevTools di rekaman aktivitas performa guna menunjukkan area untuk memfokuskan upaya Anda dalam peningkatan performa:

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 });

Dalam jangka panjang, ini mungkin akan dimasukkan ke dalam DevTools itu sendiri, tetapi cuplikan kode sebelumnya memungkinkannya untuk ditampilkan di sana sementara itu.

Menggunakan data frame animasi panjang di alat developer lainnya

Ekstensi Data Web telah menunjukkan nilai dalam informasi debug ringkasan logging untuk mendiagnosis masalah performa.

Sekarang, contoh ini juga menampilkan data frame animasi panjang untuk setiap callback INP dan setiap interaksi:

Menggunakan data frame animasi panjang di alat pengujian otomatis

Demikian pula, alat pengujian otomatis dalam pipeline CI/CD dapat menampilkan detail tentang potensi masalah performa dengan mengukur frame animasi yang panjang saat menjalankan berbagai rangkaian pengujian.

FAQ

Beberapa pertanyaan umum (FAQ) terkait API ini mencakup:

Mengapa tidak memperpanjang atau melakukan iterasi di Long Tasks API?

Hal ini merupakan alternatif dalam melaporkan pengukuran yang serupa—tetapi pada akhirnya berbeda—tentang potensi masalah responsivitas. Penting untuk memastikan situs yang mengandalkan Long Tasks API yang ada terus berfungsi agar tidak mengganggu kasus penggunaan yang ada.

Meskipun Long Tasks API dapat memanfaatkan beberapa fitur LoAF (seperti model atribusi yang lebih baik), kami percaya bahwa berfokus pada frame daripada tugas memberikan banyak manfaat, yang menjadikannya API yang pada dasarnya berbeda dengan Long Tasks API yang sudah ada.

Mengapa saya tidak memiliki entri skrip?

Ini mungkin menunjukkan bahwa bingkai animasi yang panjang bukan karena JavaScipt, melainkan karena pekerjaan render yang besar.

Hal ini juga dapat terjadi jika frame animasi panjang disebabkan karena JavaScript, tetapi atribusi skrip tidak dapat diberikan karena berbagai alasan privasi seperti yang disebutkan sebelumnya (terutama JavaScript tidak dimiliki oleh halaman).

Mengapa saya memiliki entri skrip tetapi tidak ada, atau terbatas, informasi sumber?

Hal ini dapat terjadi karena beberapa alasan, termasuk tidak adanya sumber yang bagus untuk ditunjuk.

Informasi skrip juga akan dibatasi untuk skrip no-cors cross-origin, meskipun hal ini dapat diatasi dengan mengambil skrip tersebut menggunakan CORS dengan menambahkan crossOrigin = "anonymous" ke panggilan <script>.

Misalnya, skrip default Google Tag Manager yang akan ditambahkan ke halaman:

<!-- 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 -->

Dapat ditingkatkan untuk menambahkan j.crossOrigin = "anonymous" guna memungkinkan detail atribusi lengkap diberikan untuk GTM

Apakah ini akan menggantikan Long Tasks API?

Meskipun kami yakin bahwa Long Animation Frames API adalah API yang lebih baik dan lebih lengkap untuk mengukur tugas yang berjalan lama, saat ini, tidak ada rencana untuk menghentikan Long Tasks API.

Masukan diinginkan

Masukan dapat diberikan di daftar Masalah GitHub, atau bug dalam implementasi API Chrome dapat dilaporkan di Issue Tracker Chrome.

Kesimpulan

Long Animation Frames API adalah API baru yang menarik dengan banyak potensi keunggulan dibandingkan Long Tasks API sebelumnya.

Hal ini terbukti menjadi alat utama untuk mengatasi masalah responsivitas yang diukur oleh INP. INP adalah metrik yang menantang untuk dioptimalkan dan API ini adalah salah satu cara yang coba dilakukan tim Chrome untuk mempermudah mengidentifikasi dan mengatasi masalah bagi developer.

Cakupan Long Animation Frames API lebih dari sekadar INP, dan dapat membantu mengidentifikasi penyebab lain yang lambat update yang dapat memengaruhi kelancaran pengalaman pengguna situs secara keseluruhan.

Ucapan terima kasih

Gambar thumbnail oleh Henry Be di Unsplash.