تعاملات آهسته را در میدان پیدا کنید

بیاموزید که چگونه تعاملات آهسته را در داده های میدانی وب سایت خود پیدا کنید تا بتوانید فرصت هایی برای بهبود تعامل آن در Next Paint پیدا کنید.

Jeremy Wagner

داده‌های میدانی داده‌هایی هستند که به شما می‌گویند کاربران واقعی وب‌سایت شما را چگونه تجربه می‌کنند. مشکلاتی را که نمی توانید به تنهایی در داده های آزمایشگاهی پیدا کنید، حل می کند. در مورد Interaction to Next Paint (INP) ، داده‌های میدانی برای شناسایی تعاملات آهسته ضروری است و سرنخ‌های حیاتی برای کمک به رفع آن‌ها ارائه می‌دهد.

در این راهنما، یاد خواهید گرفت که چگونه به سرعت INP وب سایت خود را با استفاده از داده های میدانی گزارش تجربه کاربر Chrome (CrUX) ارزیابی کنید تا ببینید آیا وب سایت شما با INP مشکل دارد یا خیر. متعاقباً، یاد خواهید گرفت که چگونه از ساخت اسناد کتابخانه جاوا اسکریپت web-vitals - و بینش‌های جدیدی که از Long Animation Frames API (LoAF) ارائه می‌کند - برای جمع‌آوری و تفسیر داده‌های میدانی برای تعاملات آهسته در وب‌سایت خود استفاده کنید.

برای ارزیابی INP وب سایت خود با CrUX شروع کنید

اگر اطلاعات میدانی را از کاربران وب سایت خود جمع آوری نمی کنید، CrUX ممکن است نقطه شروع خوبی باشد. CrUX داده های میدانی را از کاربران واقعی Chrome که ارسال داده های تله متری را انتخاب کرده اند جمع آوری می کند.

داده‌های CrUX در تعدادی از مناطق مختلف ظاهر می‌شوند و این بستگی به دامنه اطلاعاتی دارد که به دنبال آن هستید. CrUX می تواند داده هایی را در مورد INP و دیگر Core Web Vitals برای موارد زیر ارائه دهد:

• صفحات منفرد و کل مبدا با استفاده از PageSpeed ​​Insights .
• انواع صفحات. برای مثال، بسیاری از وب‌سایت‌های تجارت الکترونیک دارای انواع صفحه جزئیات محصول و صفحه فهرست محصول هستند. می‌توانید داده‌های CrUX را برای انواع صفحات منحصربه‌فرد در کنسول جستجو دریافت کنید.

به عنوان نقطه شروع، می توانید URL وب سایت خود را در PageSpeed ​​Insights وارد کنید. هنگامی که URL را وارد کردید، داده های فیلد مربوط به آن - در صورت وجود - برای چندین معیار از جمله INP نمایش داده می شود. همچنین می توانید از ضامن ها برای بررسی مقادیر INP خود برای ابعاد موبایل و دسکتاپ استفاده کنید.

این داده مفید است زیرا به شما می گوید که آیا مشکلی دارید. با این حال، کاری که CrUX نمی تواند انجام دهد این است که به شما بگوید چه چیزی باعث مشکلات می شود. راه حل های بسیاری برای نظارت بر کاربر واقعی (RUM) موجود است که به شما کمک می کند داده های میدانی خود را از کاربران وب سایت خود جمع آوری کنید تا به شما در پاسخ به آن کمک کند، و یک گزینه این است که خودتان آن داده های میدانی را با استفاده از کتابخانه JavaScript web-vitals جمع آوری کنید.

داده های میدانی را با کتابخانه جاوا اسکریپت web-vitals جمع آوری کنید

کتابخانه جاوا اسکریپت web-vitals یک اسکریپت است که می توانید برای جمع آوری داده های میدانی از کاربران وب سایت خود در وب سایت خود بارگذاری کنید. می توانید از آن برای ثبت تعدادی معیار از جمله INP در مرورگرهایی که از آن پشتیبانی می کنند استفاده کنید.

ساخت استاندارد کتابخانه web-vitals می تواند برای دریافت داده های اولیه INP از کاربران در این زمینه استفاده شود:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  console.log(name);    // 'INP'
  console.log(value);   // 512
  console.log(rating);  // 'poor'
});

به منظور تجزیه و تحلیل داده های میدانی خود از کاربران خود، می خواهید این داده ها را به جایی ارسال کنید:

import {onINP} from 'web-vitals';

onINP(({name, value, rating}) => {
  // Prepare JSON to be sent for collection. Note that
  // you can add anything else you'd want to collect here:
  const body = JSON.stringify({name, value, rating});

  // Use `sendBeacon` to send data to an analytics endpoint.
  // For Google Analytics, see https://github.com/GoogleChrome/web-vitals#send-the-results-to-google-analytics.
  navigator.sendBeacon('/analytics', body);
});

با این حال، این داده ها به خودی خود چیز بیشتری از CrUX به شما نمی گوید. اینجاست که ساختار اسناد کتابخانه web-vitals وارد می‌شود.

با ساخت اسناد کتابخانه web-vitals بیشتر بروید

ساختار اسناد کتابخانه web-vitals داده‌های بیشتری را نشان می‌دهد که می‌توانید از کاربران در این زمینه دریافت کنید تا به شما در عیب‌یابی بهتر تعاملات مشکل‌ساز که بر INP وب‌سایت شما تأثیر می‌گذارند کمک کند. این داده ها از طریق شی attribution ظاهر شده در روش onINP() کتابخانه قابل دسترسی است:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, rating, attribution}) => {
  console.log(name);         // 'INP'
  console.log(value);        // 56
  console.log(rating);       // 'good'
  console.log(attribution);  // Attribution data object
});

علاوه بر خود INP صفحه، ساخت انتساب داده‌های زیادی را ارائه می‌کند که می‌توانید از آنها برای درک دلایل کندی تعامل استفاده کنید، از جمله اینکه باید روی کدام بخش از تعامل تمرکز کنید. می تواند به شما کمک کند به سوالات مهمی مانند:

• "آیا کاربر هنگام بارگیری صفحه با آن ارتباط برقرار کرده است؟"
• "آیا کنترل کننده های رویداد تعامل برای مدت طولانی اجرا می شدند؟"
• "آیا کد کنترل کننده رویداد تعامل با تاخیر شروع شده بود؟ اگر چنین است، در آن زمان چه چیز دیگری در رشته اصلی اتفاق می افتاد؟"
• "آیا این تعامل باعث رندر کار زیادی شد که نقاشی فریم بعدی را به تاخیر انداخت؟"

جدول زیر برخی از داده‌های انتساب اولیه را که می‌توانید از کتابخانه دریافت کنید نشان می‌دهد که می‌تواند به شما کمک کند برخی از دلایل سطح بالا تعاملات کند در وب‌سایت خود را کشف کنید:

با شروع نسخه 4 کتابخانه web-vitals، می‌توانید از طریق داده‌هایی که با تفکیک‌های فاز INP (تأخیر ورودی، مدت زمان پردازش و تأخیر ارائه) و Long Animation Frames API (LoAF) ارائه می‌کند، بینش عمیق‌تری در مورد تعاملات مشکل‌ساز دریافت کنید.

The Long Animation Frames API (LoAF)

اشکال زدایی تعاملات با استفاده از داده های میدانی یک کار چالش برانگیز است. با این حال، با داده‌های LoAF، اکنون می‌توان بینش‌های بهتری در مورد دلایل پشت تعاملات آهسته به دست آورد، زیرا LoAF تعدادی زمان‌بندی دقیق و داده‌های دیگری را نشان می‌دهد که می‌توانید برای مشخص کردن دلایل دقیق و مهم‌تر از آن، کجا منبع مشکل استفاده کنید. در کد وب سایت شما قرار دارد.

ساخت اسناد کتابخانه web-vitals آرایه‌ای از ورودی‌های LoAF را در زیر کلید longAnimationFrameEntries شی attribution نشان می‌دهد. جدول زیر چند بیت کلیدی از داده‌هایی را که می‌توانید در هر ورودی LoAF پیدا کنید فهرست می‌کند:

همه این اطلاعات می توانند چیزهای زیادی را در مورد اینکه چه چیزی باعث کندی تعامل می شود به شما بگوید - اما آرایه scripts که LoAF ورودی های سطح آن را نشان می دهد باید از جذابیت خاصی برخوردار باشد:

هر ورودی در این آرایه حاوی داده‌های نشان‌داده‌شده در این جدول است، که اطلاعاتی درباره اسکریپتی که مسئول تعامل آهسته بوده است - و نحوه انجام آن به شما می‌دهد.

اندازه گیری و شناسایی علل مشترک در پشت تعاملات کند

برای اینکه ایده‌ای در مورد نحوه استفاده از این اطلاعات به شما ارائه دهد، این راهنما اکنون نحوه استفاده از داده‌های LoAF را که در کتابخانه web-vitals ظاهر می‌شود برای تعیین برخی از دلایل پشت تعاملات آهسته توضیح می‌دهد.

مدت زمان پردازش طولانی

مدت زمان پردازش یک تعامل، زمانی است که طول می کشد تا فراخوان های کنترل کننده رویداد ثبت شده تعامل تا تکمیل شوند و هر چیز دیگری که ممکن است بین آنها اتفاق بیفتد. مدت زمان پردازش بالا توسط کتابخانه web-vitals ظاهر می شود:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5
});

طبیعی است که فکر کنیم دلیل اصلی یک تعامل کند این است که اجرای کد مدیریت رویداد شما بیش از حد طول کشیده است، اما همیشه اینطور نیست! هنگامی که تأیید کردید که این مشکل است، می‌توانید با داده‌های LoAF عمیق‌تر کاوش کنید:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {processingDuration} = attribution; // 512.5

  // Get the longest script from LoAF covering `processingDuration`:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Get attribution for the long-running event handler:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

همانطور که در قطعه کد قبلی مشاهده می‌کنید، می‌توانید با داده‌های LoAF کار کنید تا علت دقیق تعامل را با مقادیر طولانی مدت پردازش بالا ردیابی کنید، از جمله:

• عنصر و شنونده رویداد ثبت شده آن.
• فایل اسکریپت - و موقعیت کاراکتر درون آن - حاوی کد مدیریت رویداد طولانی مدت است.
• نام تابع.

این نوع داده ها بسیار ارزشمند است. دیگر نیازی نیست که کار اصلی را انجام دهید تا بفهمید دقیقاً کدام تعامل - یا کدام یک از گردانندگان رویداد آن - مسئول مقادیر طولانی مدت پردازش هستند. همچنین، از آنجا که اسکریپت های شخص ثالث اغلب می توانند کنترل کننده رویداد خود را ثبت کنند، می توانید تعیین کنید که آیا این کد شما مسئول بوده است یا خیر! برای کدی که روی آن کنترل دارید، باید به دنبال بهینه سازی کارهای طولانی باشید.

تاخیرهای ورودی طولانی

در حالی که کنترل‌کننده‌های رویداد طولانی‌مدت رایج هستند، بخش‌های دیگری از تعامل وجود دارد که باید در نظر گرفت. یک بخش قبل از مدت زمان پردازش رخ می دهد که به عنوان تاخیر ورودی شناخته می شود. این زمانی است که کاربر تعامل را آغاز می‌کند، تا لحظه‌ای که فراخوان‌های کنترل‌کننده رویداد آن شروع به اجرا می‌کنند و زمانی اتفاق می‌افتد که رشته اصلی در حال پردازش کار دیگری است. ساخت اسناد کتابخانه web-vitals می تواند طول تاخیر ورودی برای یک تعامل را به شما بگوید:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536
});

اگر متوجه شدید که برخی از فعل و انفعالات دارای تأخیرهای ورودی بالایی هستند، باید بفهمید که در زمان تعامل در صفحه چه اتفاقی افتاده است که باعث تأخیر ورودی طولانی شده است - و این اغلب به این ختم می شود که آیا تعامل به عنوان صفحه در حال بارگیری بود یا بعد از آن.

آیا در حین بارگذاری صفحه بود؟

موضوع اصلی اغلب با بارگیری صفحه شلوغ ترین است. در این مدت، انواع کارها در صف و پردازش قرار می گیرند و اگر کاربر سعی کند در حالی که همه این کارها در حال انجام است با صفحه تعامل داشته باشد، می تواند تعامل را به تاخیر بیاندازد. صفحاتی که جاوا اسکریپت زیادی بارگیری می‌کنند می‌توانند کار را برای کامپایل و ارزیابی اسکریپت‌ها و همچنین اجرای توابعی که صفحه را برای تعامل با کاربر آماده می‌کنند، آغاز کنند. اگر کاربر هنگام انجام این فعالیت تعامل داشته باشد، این کار می‌تواند مانع شود، و می‌توانید بفهمید که آیا این موضوع برای کاربران وب‌سایت شما صادق است یا خیر:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  if (script) {
    // Invoker types can describe if script eval blocked the main thread:
    const {invokerType} = script;    // 'classic-script' | 'module-script'
    const {sourceLocation} = script; // 'https://example.com/app.js'
  }
});

اگر این داده‌ها را در فیلد ثبت می‌کنید و تأخیرهای ورودی بالا و انواع فراخوان 'classic-script' یا 'module-script' را مشاهده می‌کنید، پس منصفانه است که بگوییم اسکریپت‌های سایت شما زمان زیادی برای ارزیابی می‌برند . مسدود کردن رشته اصلی به اندازه کافی برای به تاخیر انداختن تعاملات. می‌توانید این زمان مسدود شدن را با تقسیم کردن اسکریپت‌های خود به بسته‌های کوچک‌تر کاهش دهید، کدهای استفاده نشده اولیه را به تعویق بیندازید تا در زمان بعدی بارگذاری شوند، و سایت خود را برای کدهای استفاده نشده که می‌توانید به طور کلی حذف کنید، بررسی کنید.

بعد از بارگذاری صفحه بود؟

در حالی که تاخیرهای ورودی اغلب در حین بارگیری صفحه رخ می دهند، به همان اندازه ممکن است که پس از بارگیری صفحه رخ دهند، به دلیل یک دلیل کاملاً متفاوت. دلایل رایج تاخیرهای ورودی پس از بارگیری صفحه می‌تواند کدهایی باشد که به‌دلیل تماس‌های قبلی setInterval به‌طور دوره‌ای اجرا می‌شوند، یا حتی تماس‌های رویدادی که برای اجرای زودتر در صف قرار گرفته‌اند و هنوز در حال پردازش هستند.

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {inputDelay} = attribution; // 125.59439536

  // Get the longest script from the first LoAF entry:
  const loaf = attribution.longAnimationFrameEntries[0];
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  if (script) {
    const {invokerType} = script;        // 'user-callback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

همانطور که در مورد عیب یابی مقادیر بالای مدت زمان پردازش وجود دارد، تاخیرهای ورودی بالا به دلیل دلایلی که قبلا ذکر شد، داده های مربوط به انتساب اسکریپت را به شما ارائه می دهد. با این حال، چیزی که متفاوت است این است که نوع فراخوان بر اساس ماهیت کاری که تعامل را به تاخیر انداخته تغییر می کند:

• 'user-callback' نشان می‌دهد که وظیفه مسدود کردن از setInterval ، setTimeout یا حتی requestAnimationFrame بوده است.
• 'event-listener' نشان می دهد که وظیفه مسدود کردن از ورودی قبلی است که در صف قرار گرفته و هنوز در حال پردازش است.
• 'resolve-promise' و 'reject-promise' به این معنی است که کار مسدود کردن از برخی کارهای ناهمزمان است که قبلاً شروع شده بود، و در زمانی که کاربر تلاش کرد با صفحه تعامل داشته باشد و تعامل را به تأخیر انداخت، حل یا رد شد.

در هر صورت، داده‌های انتساب اسکریپت به شما این حس را می‌دهد که از کجا شروع به جستجو کنید، و اینکه آیا تاخیر ورودی به دلیل کد خودتان بوده است یا یک اسکریپت شخص ثالث.

تاخیرهای طولانی ارائه

تأخیرهای ارائه آخرین مایل یک تعامل هستند و زمانی شروع می‌شوند که کنترل‌کننده‌های رویداد تعامل به پایان می‌رسند، تا جایی که فریم بعدی نقاشی شده است. آنها زمانی رخ می دهند که کار در یک کنترل کننده رویداد به دلیل یک تعامل، وضعیت بصری رابط کاربر را تغییر دهد. مانند مدت زمان پردازش و تاخیرهای ورودی، کتابخانه web-vitals می تواند به شما بگوید که تاخیر ارائه برای تعامل چقدر بوده است:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691
});

اگر این داده ها را ثبت کنید و تاخیرهای زیادی در ارائه برای تعاملاتی که به INP وب سایت شما کمک می کند مشاهده کنید، مقصران می توانند متفاوت باشند، اما در اینجا چند دلیل وجود دارد که باید مراقب آنها باشید.

کار سبک و چیدمان گران قیمت

تأخیرهای طولانی ارائه ممکن است برای محاسبه مجدد سبک و کار چیدمان گران قیمت باشد که به دلایل مختلفی از جمله انتخابگرهای پیچیده CSS و اندازه های بزرگ DOM ناشی می شود. می توانید مدت زمان این کار را با زمان بندی های LoAF که در کتابخانه web-vitals ظاهر می شود اندازه گیری کنید:

import {onINP} from 'web-vitals/attribution';

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 113.32307691

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  // Get necessary timings:
  const {startTime} = loaf; // 2120.5
  const {duration} = loaf;  // 1002

  // Figure out the ending timestamp of the frame (approximate):
  const endTime = startTime + duration; // 3122.5

  // Get the start timestamp of the frame's style/layout work:
  const {styleAndLayoutStart} = loaf; // 3011.17692309

  // Calculate the total style/layout duration:
  const styleLayoutDuration = endTime - styleAndLayoutStart; // 111.32307691

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running style and layout operation:
    const {invokerType} = script;        // 'event-listener'
    const {invoker} = script;            // 'BUTTON#update.onclick'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

LoAF به شما نمی گوید که مدت زمان سبک و چیدمان برای یک فریم است، اما به شما می گوید که چه زمانی شروع شده است. با این مهر زمانی شروع، می‌توانید از سایر داده‌های LoAF برای محاسبه مدت زمان دقیق آن کار با تعیین زمان پایان فریم، و کم کردن مهر زمانی شروع کار سبک و طرح‌بندی از آن استفاده کنید.

تماس های طولانی requestAnimationFrame

یکی از دلایل بالقوه تاخیرهای طولانی ارائه، کار بیش از حد انجام شده در پاسخ به requestAnimationFrame است. محتویات این فراخوان پس از پایان اجرای کنترل کننده رویداد، اما درست قبل از محاسبه مجدد سبک و کار طرح بندی اجرا می شود.

در صورتی که کار انجام شده در آنها پیچیده باشد، ممکن است تکمیل این تماس ها زمان قابل توجهی طول بکشد. اگر فکر می‌کنید که مقادیر بالای تاخیر ارائه به دلیل کاری است که با requestAnimationFrame انجام می‌دهید، می‌توانید از داده‌های LoAF که توسط کتابخانه web-vitals ظاهر می‌شود برای شناسایی این سناریوها استفاده کنید:

onINP(({name, value, attribution}) => {
  const {presentationDelay} = attribution; // 543.1999999880791

  // Get the longest script from the last LoAF entry:
  const loaf = attribution.longAnimationFrameEntries.at(-1);
  const script = loaf?.scripts.sort((a, b) => b.duration - a.duration)[0];

  // Get the render start time and when style and layout began:
  const {renderStart} = loaf;         // 2489
  const {styleAndLayoutStart} = loaf; // 2989.5999999940395

  // Calculate the `requestAnimationFrame` callback's duration:
  const rafDuration = styleAndLayoutStart - renderStart; // 500.59999999403954

  if (script) {
    // Get attribution for the event handler that triggered
    // the long-running requestAnimationFrame callback:
    const {invokerType} = script;        // 'user-callback'
    const {invoker} = script;            // 'FrameRequestCallback'
    const {sourceURL} = script;          // 'https://example.com/app.js'
    const {sourceCharPosition} = script; // 83
    const {sourceFunctionName} = script; // 'update'
  }
});

اگر می بینید که بخش قابل توجهی از زمان تأخیر ارائه در پاسخ به تماس requestAnimationFrame سپری می شود، مطمئن شوید که کاری که در این تماس ها انجام می دهید محدود به انجام کاری است که منجر به به روز رسانی واقعی رابط کاربری می شود. هر اثر دیگری که به DOM یا سبک‌های به‌روزرسانی دست نزند، نقاشی فریم بعدی را بی جهت به تأخیر می‌اندازد، پس مراقب باشید!

نتیجه گیری

داده‌های میدانی بهترین منبع اطلاعاتی است که می‌توانید هنگام درک اینکه کدام تعامل برای کاربران واقعی در این زمینه مشکل‌ساز است، از آن استفاده کنید. با تکیه بر ابزارهای گردآوری داده‌های میدانی مانند کتابخانه جاوا اسکریپت web-vitals (یا ارائه‌دهنده RUM)، می‌توانید در مورد اینکه کدام تعامل مشکل‌سازتر است، اطمینان بیشتری داشته باشید و سپس به تولید مجدد تعاملات مشکل‌دار در آزمایشگاه بروید و سپس به رفع مشکل بپردازید. آنها را

تصویر قهرمان از Unsplash , توسط فدریکو رسپینی .