هدف گزارش تجربه کاربر Chrome کمک به جامعه وب در درک توزیع و تکامل عملکرد واقعی کاربر است. تا به امروز، تمرکز ما بر روی معیارهای رنگ و بارگذاری صفحه مانند First Contentful Paint (FCP) و Onload (OL) بوده است، که به ما کمک کرده است تا بفهمیم وب‌سایت‌ها چگونه عملکرد بصری برای کاربران دارند. با شروع انتشار ژوئن 2018، ما در حال آزمایش یک معیار کاربر محور جدید هستیم که بر تعامل صفحات وب تمرکز دارد: اولین تاخیر ورودی (FID). این معیار جدید ما را قادر می سازد تا درک بهتری از نحوه پاسخگویی وب سایت ها به ورودی کاربر داشته باشیم.
FID اخیراً به‌عنوان نسخه آزمایشی اصلی در Chrome در دسترس قرار گرفت، به این معنی که وب‌سایت‌ها می‌توانند این ویژگی جدید پلتفرم وب را آزمایش کنند. به طور مشابه، FID در گزارش Chrome UX به عنوان یک معیار آزمایشی در دسترس خواهد بود، به این معنی که برای مدت زمان آزمایشی مبدا در یک فضای نام "تجربی" جداگانه در دسترس خواهد بود.
چگونه FID اندازه گیری می شود
بنابراین دقیقاً FID چیست؟ در اینجا نحوه تعریف آن در اولین پست وبلاگ اعلام تاخیر ورودی آمده است:
تأخیر ورودی اول (FID) زمان از زمانی که کاربر برای اولین بار با سایت شما ارتباط برقرار می کند (یعنی زمانی که روی یک پیوند کلیک می کند، روی دکمه ای ضربه می زند یا از کنترل سفارشی مبتنی بر جاوا اسکریپت استفاده می کند) تا زمانی که مرورگر واقعاً قادر به انجام آن باشد، اندازه گیری می کند. برای پاسخ به آن تعامل.
این مثل اندازه گیری زمان از زنگ درب کسی تا پاسخ دادن به در است. اگر زمان زیادی طول بکشد، ممکن است دلایل زیادی وجود داشته باشد. به عنوان مثال، ممکن است فرد از در دور باشد یا شاید نتواند به سرعت حرکت کند. به طور مشابه، صفحات وب ممکن است مشغول انجام کارهای دیگر باشند یا ممکن است دستگاه کاربر کند باشد.
کاوش FID در گزارش Chrome UX
با یک ماه داده های FID از میلیون ها منبع، در حال حاضر انبوهی از بینش های جالب برای کشف وجود دارد. بیایید به چند پرس و جو نگاه کنیم که نشان می دهد چگونه می توان این اطلاعات بینش را از گزارش Chrome UX در BigQuery استخراج کرد.
بیایید با پرس و جو برای درصد تجربیات سریع FID برای developers.google.com شروع کنیم. ما می توانیم یک تجربه سریع را به عنوان تجربه ای تعریف کنیم که در آن FID کمتر از 100 میلی ثانیه است. طبق توصیه‌های RAIL ، اگر تأخیر 100 میلی‌ثانیه یا بهتر باشد، باید فوراً به کاربر احساس شود.
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
origin = 'https://developers.google.com'
نتایج نشان می دهد که 95 درصد از تجربیات FID در این مبدا به صورت آنی درک می شوند. این واقعاً خوب به نظر می رسد، اما چگونه با همه ریشه های مجموعه داده مقایسه می شود؟
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
نتایج این پرس و جو نشان می دهد که 84 درصد از تجربیات FID کمتر از 100 میلی ثانیه است. بنابراین developers.google.com بالاتر از حد متوسط است.
در مرحله بعد، بیایید سعی کنیم این داده ها را برش دهیم تا ببینیم آیا تفاوتی بین درصد FID سریع روی دسکتاپ و موبایل وجود دارد یا خیر. یک فرضیه این است که دستگاه های تلفن همراه مقادیر FID کندتری دارند، احتمالاً به دلیل سخت افزار کندتر در مقایسه با رایانه های رومیزی. اگر CPU قدرت کمتری داشته باشد، ممکن است برای مدت طولانی‌تری شلوغ‌تر باشد و منجر به تجربه‌های FID کندتر شود.
SELECT
form_factor.name AS form_factor,
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
form_factor
| فرم_فاکتور | fast_fid |
|---|---|
| دسکتاپ | 96.02٪ |
| تلفن | 79.90٪ |
| تبلت | 76.48٪ |
نتایج فرضیه ما را تایید می کند. دسکتاپ دارای تراکم تجمعی تجربیات سریع FID نسبت به عوامل تلفن و تبلت است. درک اینکه چرا این تفاوت ها وجود دارد، به عنوان مثال عملکرد CPU، به آزمایش A/B خارج از محدوده گزارش Chrome UX نیاز دارد.
اکنون که دیدیم چگونه می توان تشخیص داد که آیا یک منبع دارای تجربیات سریع FID است یا خیر، بیایید نگاهی به چند مبدا بیندازیم که عملکرد بسیار خوبی دارند.
مثال 1: http://secretlycanadian.com
این مبدا 98 درصد از تجربیات FID زیر 100 میلی ثانیه را دارد. چگونه این کار را انجام می دهند؟ با تجزیه و تحلیل نحوه ساخت آن در WebPageTest ، می‌توانیم ببینیم که این صفحه یک صفحه وردپرس پر تصویر است، اما دارای 168 کیلوبایت جاوا اسکریپت است که در حدود 500 میلی‌ثانیه بر روی دستگاه آزمایشگاهی ما اجرا می‌شود. طبق بایگانی HTTP که این صفحه را در صدک 28 قرار می دهد، جاوا اسکریپت چندانی ندارد.
نوار صورتی که بین 2.7 تا 3.0 ثانیه است، فاز تجزیه HTML است. در این مدت صفحه تعاملی نیست و از نظر بصری ناقص به نظر می رسد (به «3.0s» در نوار فیلم بالا مراجعه کنید). پس از آن، هر کار طولانی که نیاز به پردازش دارد، شکسته می شود تا اطمینان حاصل شود که موضوع اصلی ساکن می ماند. خطوط صورتی در ردیف 11 نشان می‌دهد که چگونه کار جاوا اسکریپت به‌طور ناگهانی پخش می‌شود.
مثال 2: https://www.wtfast.com
این مبدا دارای 96٪ تجربه FID فوری است. 267 کیلوبایت جاوا اسکریپت (صدک 38 در بایگانی HTTP) را بارگیری می کند و آن را به مدت 900 میلی ثانیه در دستگاه آزمایشگاه پردازش می کند. نوار فیلم نشان می دهد که صفحه حدود 5 ثانیه برای رنگ آمیزی پس زمینه و حدود 2 ثانیه دیگر برای رنگ کردن محتوا طول می کشد.
جالب‌ترین چیز در مورد نتایج این است که هیچ چیز تعاملی حتی قابل مشاهده نیست در حالی که موضوع اصلی بین 3 تا 5 ثانیه مشغول است. در واقع کندی FCP این صفحه است که FID را بهبود می بخشد . این مثال خوبی از اهمیت استفاده از معیارهای بسیاری برای نمایش تجربه کاربر است.
شروع به کاوش کنید
می توانید در قسمت این هفته وضعیت وب درباره FID بیشتر بدانید:
وجود FID در گزارش Chrome UX ما را قادر می‌سازد تا یک خط پایه از تجربیات تعاملی ایجاد کنیم. با استفاده از این خط پایه، می‌توانیم تغییر آن را در نسخه‌های آینده مشاهده کنیم یا منشاء فردی را معیار قرار دهیم. اگر می‌خواهید شروع به جمع‌آوری FID در اندازه‌گیری‌های میدانی سایت خود کنید، با رفتن به bit.ly/event-timing-ot و انتخاب ویژگی رویداد زمان‌بندی، برای آزمایش اولیه ثبت‌نام کنید. و البته، کاوش مجموعه داده را برای بینش جالب در مورد وضعیت تعامل در وب شروع کنید . این هنوز یک معیار آزمایشی است، بنابراین لطفاً بازخورد خود را با ما در میان بگذارید و تجزیه و تحلیل خود را در گروه بحث گزارش Chrome UX یا @ChromeUXReport در Twitter به اشتراک بگذارید.
،
هدف گزارش تجربه کاربر Chrome کمک به جامعه وب در درک توزیع و تکامل عملکرد واقعی کاربر است. تا به امروز، تمرکز ما بر روی معیارهای رنگ و بارگذاری صفحه مانند First Contentful Paint (FCP) و Onload (OL) بوده است، که به ما کمک کرده است تا بفهمیم وب‌سایت‌ها چگونه عملکرد بصری برای کاربران دارند. با شروع انتشار ژوئن 2018، ما در حال آزمایش یک معیار کاربر محور جدید هستیم که بر تعامل صفحات وب تمرکز دارد: اولین تاخیر ورودی (FID). این معیار جدید ما را قادر می سازد تا درک بهتری از نحوه پاسخگویی وب سایت ها به ورودی کاربر داشته باشیم.
FID اخیراً به‌عنوان نسخه آزمایشی اصلی در Chrome در دسترس قرار گرفت، به این معنی که وب‌سایت‌ها می‌توانند این ویژگی جدید پلتفرم وب را آزمایش کنند. به طور مشابه، FID در گزارش Chrome UX به عنوان یک معیار آزمایشی در دسترس خواهد بود، به این معنی که برای مدت زمان آزمایشی مبدا در یک فضای نام "تجربی" جداگانه در دسترس خواهد بود.
چگونه FID اندازه گیری می شود
بنابراین دقیقاً FID چیست؟ در اینجا نحوه تعریف آن در اولین پست وبلاگ اعلام تاخیر ورودی آمده است:
تأخیر ورودی اول (FID) زمان از زمانی که کاربر برای اولین بار با سایت شما ارتباط برقرار می کند (یعنی زمانی که روی یک پیوند کلیک می کند، روی دکمه ای ضربه می زند یا از کنترل سفارشی مبتنی بر جاوا اسکریپت استفاده می کند) تا زمانی که مرورگر واقعاً قادر به انجام آن باشد، اندازه گیری می کند. برای پاسخ به آن تعامل.
این مثل اندازه گیری زمان از زنگ درب کسی تا پاسخ دادن به در است. اگر زمان زیادی طول بکشد، ممکن است دلایل زیادی وجود داشته باشد. به عنوان مثال، ممکن است فرد از در دور باشد یا شاید نتواند به سرعت حرکت کند. به طور مشابه، صفحات وب ممکن است مشغول انجام کارهای دیگر باشند یا ممکن است دستگاه کاربر کند باشد.
کاوش FID در گزارش Chrome UX
با یک ماه داده های FID از میلیون ها منبع، در حال حاضر انبوهی از بینش های جالب برای کشف وجود دارد. بیایید به چند پرس و جو نگاه کنیم که نشان می دهد چگونه می توان این اطلاعات بینش را از گزارش Chrome UX در BigQuery استخراج کرد.
بیایید با پرس و جو برای درصد تجربیات سریع FID برای developers.google.com شروع کنیم. ما می توانیم یک تجربه سریع را به عنوان تجربه ای تعریف کنیم که در آن FID کمتر از 100 میلی ثانیه است. طبق توصیه‌های RAIL ، اگر تأخیر 100 میلی‌ثانیه یا بهتر باشد، باید فوراً به کاربر احساس شود.
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
origin = 'https://developers.google.com'
نتایج نشان می دهد که 95 درصد از تجربیات FID در این مبدا به صورت آنی درک می شوند. این واقعاً خوب به نظر می رسد، اما چگونه با همه ریشه های مجموعه داده مقایسه می شود؟
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
نتایج این پرس و جو نشان می دهد که 84 درصد از تجربیات FID کمتر از 100 میلی ثانیه است. بنابراین developers.google.com بالاتر از حد متوسط است.
در مرحله بعد، بیایید سعی کنیم این داده ها را برش دهیم تا ببینیم آیا تفاوتی بین درصد FID سریع روی دسکتاپ و موبایل وجود دارد یا خیر. یک فرضیه این است که دستگاه های تلفن همراه مقادیر FID کندتری دارند، احتمالاً به دلیل سخت افزار کندتر در مقایسه با رایانه های رومیزی. اگر CPU قدرت کمتری داشته باشد، ممکن است برای مدت طولانی‌تری شلوغ‌تر باشد و منجر به تجربه‌های FID کندتر شود.
SELECT
form_factor.name AS form_factor,
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
form_factor
| فرم_فاکتور | fast_fid |
|---|---|
| دسکتاپ | 96.02٪ |
| تلفن | 79.90٪ |
| تبلت | 76.48٪ |
نتایج فرضیه ما را تایید می کند. دسکتاپ دارای تراکم تجمعی تجربیات سریع FID نسبت به عوامل تلفن و تبلت است. درک اینکه چرا این تفاوت ها وجود دارد، به عنوان مثال عملکرد CPU، به آزمایش A/B خارج از محدوده گزارش Chrome UX نیاز دارد.
اکنون که دیدیم چگونه می توان تشخیص داد که آیا یک منبع دارای تجربیات سریع FID است یا خیر، بیایید نگاهی به چند مبدا بیندازیم که عملکرد بسیار خوبی دارند.
مثال 1: http://secretlycanadian.com
این مبدا 98 درصد از تجربیات FID زیر 100 میلی ثانیه را دارد. چگونه این کار را انجام می دهند؟ با تجزیه و تحلیل نحوه ساخت آن در WebPageTest ، می‌توانیم ببینیم که این صفحه یک صفحه وردپرس پر تصویر است، اما دارای 168 کیلوبایت جاوا اسکریپت است که در حدود 500 میلی‌ثانیه بر روی دستگاه آزمایشگاهی ما اجرا می‌شود. طبق بایگانی HTTP که این صفحه را در صدک 28 قرار می دهد، جاوا اسکریپت چندانی ندارد.
نوار صورتی که بین 2.7 تا 3.0 ثانیه است، فاز تجزیه HTML است. در این مدت صفحه تعاملی نیست و از نظر بصری ناقص به نظر می رسد (به «3.0s» در نوار فیلم بالا مراجعه کنید). پس از آن، هر کار طولانی که نیاز به پردازش دارد، شکسته می شود تا اطمینان حاصل شود که موضوع اصلی ساکن می ماند. خطوط صورتی در ردیف 11 نشان می‌دهد که چگونه کار جاوا اسکریپت به‌طور ناگهانی پخش می‌شود.
مثال 2: https://www.wtfast.com
این مبدا دارای 96٪ تجربه FID فوری است. 267 کیلوبایت جاوا اسکریپت (صدک 38 در بایگانی HTTP) را بارگیری می کند و آن را به مدت 900 میلی ثانیه در دستگاه آزمایشگاه پردازش می کند. نوار فیلم نشان می دهد که صفحه حدود 5 ثانیه برای رنگ آمیزی پس زمینه و حدود 2 ثانیه دیگر برای رنگ کردن محتوا طول می کشد.
جالب‌ترین چیز در مورد نتایج این است که هیچ چیز تعاملی حتی قابل مشاهده نیست در حالی که موضوع اصلی بین 3 تا 5 ثانیه مشغول است. در واقع کندی FCP این صفحه است که FID را بهبود می بخشد . این مثال خوبی از اهمیت استفاده از معیارهای بسیاری برای نمایش تجربه کاربر است.
شروع به کاوش کنید
می توانید در قسمت این هفته وضعیت وب درباره FID بیشتر بدانید:
وجود FID در گزارش Chrome UX ما را قادر می‌سازد تا یک خط پایه از تجربیات تعاملی ایجاد کنیم. با استفاده از این خط پایه، می‌توانیم تغییر آن را در نسخه‌های آینده مشاهده کنیم یا منشاء فردی را معیار قرار دهیم. اگر می‌خواهید شروع به جمع‌آوری FID در اندازه‌گیری‌های میدانی سایت خود کنید، با رفتن به bit.ly/event-timing-ot و انتخاب ویژگی رویداد زمان‌بندی، برای آزمایش اولیه ثبت‌نام کنید. و البته، کاوش مجموعه داده را برای بینش جالب در مورد وضعیت تعامل در وب شروع کنید . این هنوز یک معیار آزمایشی است، بنابراین لطفاً بازخورد خود را با ما در میان بگذارید و تجزیه و تحلیل خود را در گروه بحث گزارش Chrome UX یا @ChromeUXReport در Twitter به اشتراک بگذارید.
،
هدف گزارش تجربه کاربر Chrome کمک به جامعه وب در درک توزیع و تکامل عملکرد واقعی کاربر است. تا به امروز، تمرکز ما بر روی معیارهای رنگ و بارگذاری صفحه مانند First Contentful Paint (FCP) و Onload (OL) بوده است، که به ما کمک کرده است تا بفهمیم وب‌سایت‌ها چگونه عملکرد بصری برای کاربران دارند. با شروع انتشار ژوئن 2018، ما در حال آزمایش یک معیار کاربر محور جدید هستیم که بر تعامل صفحات وب تمرکز دارد: اولین تاخیر ورودی (FID). این معیار جدید ما را قادر می سازد تا درک بهتری از نحوه پاسخگویی وب سایت ها به ورودی کاربر داشته باشیم.
FID اخیراً به‌عنوان نسخه آزمایشی اصلی در Chrome در دسترس قرار گرفت، به این معنی که وب‌سایت‌ها می‌توانند این ویژگی جدید پلتفرم وب را آزمایش کنند. به طور مشابه، FID در گزارش Chrome UX به عنوان یک معیار آزمایشی در دسترس خواهد بود، به این معنی که برای مدت زمان آزمایشی مبدا در یک فضای نام "تجربی" جداگانه در دسترس خواهد بود.
چگونه FID اندازه گیری می شود
بنابراین دقیقاً FID چیست؟ در اینجا نحوه تعریف آن در اولین پست وبلاگ اعلام تاخیر ورودی آمده است:
تأخیر ورودی اول (FID) زمان از زمانی که کاربر برای اولین بار با سایت شما ارتباط برقرار می کند (یعنی زمانی که روی یک پیوند کلیک می کند، روی دکمه ای ضربه می زند یا از کنترل سفارشی مبتنی بر جاوا اسکریپت استفاده می کند) تا زمانی که مرورگر واقعاً قادر به انجام آن باشد، اندازه گیری می کند. برای پاسخ به آن تعامل.
این مثل اندازه گیری زمان از زنگ درب کسی تا پاسخ دادن به در است. اگر زمان زیادی طول بکشد، ممکن است دلایل زیادی وجود داشته باشد. به عنوان مثال، ممکن است فرد از در دور باشد یا شاید نتواند به سرعت حرکت کند. به طور مشابه، صفحات وب ممکن است مشغول انجام کارهای دیگر باشند یا ممکن است دستگاه کاربر کند باشد.
کاوش FID در گزارش Chrome UX
با یک ماه داده های FID از میلیون ها منبع، در حال حاضر انبوهی از بینش های جالب برای کشف وجود دارد. بیایید به چند پرس و جو نگاه کنیم که نشان می دهد چگونه می توان این اطلاعات بینش را از گزارش Chrome UX در BigQuery استخراج کرد.
بیایید با پرس و جو برای درصد تجربیات سریع FID برای developers.google.com شروع کنیم. ما می توانیم یک تجربه سریع را به عنوان تجربه ای تعریف کنیم که در آن FID کمتر از 100 میلی ثانیه است. طبق توصیه‌های RAIL ، اگر تأخیر 100 میلی‌ثانیه یا بهتر باشد، باید فوراً به کاربر احساس شود.
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
origin = 'https://developers.google.com'
نتایج نشان می دهد که 95 درصد از تجربیات FID در این مبدا به صورت آنی درک می شوند. این واقعاً خوب به نظر می رسد، اما چگونه با همه ریشه های مجموعه داده مقایسه می شود؟
SELECT
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
نتایج این پرس و جو نشان می دهد که 84 درصد از تجربیات FID کمتر از 100 میلی ثانیه است. بنابراین developers.google.com بالاتر از حد متوسط است.
در مرحله بعد، بیایید سعی کنیم این داده ها را برش دهیم تا ببینیم آیا تفاوتی بین درصد FID سریع روی دسکتاپ و موبایل وجود دارد یا خیر. یک فرضیه این است که دستگاه های تلفن همراه مقادیر FID کندتری دارند، احتمالاً به دلیل سخت افزار کندتر در مقایسه با رایانه های رومیزی. اگر CPU قدرت کمتری داشته باشد، ممکن است برای مدت طولانی‌تری شلوغ‌تر باشد و منجر به تجربه‌های FID کندتر شود.
SELECT
form_factor.name AS form_factor,
ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
`chrome-ux-report.all.201806`,
UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
form_factor
| فرم_فاکتور | fast_fid |
|---|---|
| دسکتاپ | 96.02٪ |
| تلفن | 79.90٪ |
| تبلت | 76.48٪ |
نتایج فرضیه ما را تایید می کند. دسکتاپ دارای تراکم تجمعی تجربیات سریع FID نسبت به عوامل تلفن و تبلت است. درک اینکه چرا این تفاوت ها وجود دارد، به عنوان مثال عملکرد CPU، به آزمایش A/B خارج از محدوده گزارش Chrome UX نیاز دارد.
اکنون که دیدیم چگونه می توان تشخیص داد که آیا یک منبع دارای تجربیات سریع FID است یا خیر، بیایید نگاهی به چند مبدا بیندازیم که عملکرد بسیار خوبی دارند.
مثال 1: http://secretlycanadian.com
این مبدا 98 درصد از تجربیات FID زیر 100 میلی ثانیه را دارد. چگونه این کار را انجام می دهند؟ با تجزیه و تحلیل نحوه ساخت آن در WebPageTest ، می‌توانیم ببینیم که این صفحه یک صفحه وردپرس پر تصویر است، اما دارای 168 کیلوبایت جاوا اسکریپت است که در حدود 500 میلی‌ثانیه بر روی دستگاه آزمایشگاهی ما اجرا می‌شود. طبق بایگانی HTTP که این صفحه را در صدک 28 قرار می دهد، جاوا اسکریپت چندانی ندارد.
نوار صورتی که بین 2.7 تا 3.0 ثانیه است، فاز تجزیه HTML است. در این مدت صفحه تعاملی نیست و از نظر بصری ناقص به نظر می رسد (به «3.0s» در نوار فیلم بالا مراجعه کنید). پس از آن، هر کار طولانی که نیاز به پردازش دارد، شکسته می شود تا اطمینان حاصل شود که موضوع اصلی ساکن می ماند. خطوط صورتی در ردیف 11 نشان می‌دهد که چگونه کار جاوا اسکریپت به‌طور ناگهانی پخش می‌شود.
مثال 2: https://www.wtfast.com
این مبدا دارای 96٪ تجربه FID فوری است. 267 کیلوبایت جاوا اسکریپت (صدک 38 در بایگانی HTTP) را بارگیری می کند و آن را به مدت 900 میلی ثانیه در دستگاه آزمایشگاه پردازش می کند. نوار فیلم نشان می دهد که صفحه حدود 5 ثانیه برای رنگ آمیزی پس زمینه و حدود 2 ثانیه دیگر برای رنگ کردن محتوا طول می کشد.
جالب‌ترین چیز در مورد نتایج این است که هیچ چیز تعاملی حتی قابل مشاهده نیست در حالی که موضوع اصلی بین 3 تا 5 ثانیه مشغول است. در واقع کندی FCP این صفحه است که FID را بهبود می بخشد . این مثال خوبی از اهمیت استفاده از معیارهای بسیاری برای نمایش تجربه کاربر است.
شروع به کاوش کنید
می توانید در قسمت این هفته وضعیت وب درباره FID بیشتر بدانید:
وجود FID در گزارش Chrome UX ما را قادر می‌سازد تا یک خط پایه از تجربیات تعاملی ایجاد کنیم. با استفاده از این خط پایه، می‌توانیم تغییر آن را در نسخه‌های آینده مشاهده کنیم یا منشاء فردی را معیار قرار دهیم. اگر می‌خواهید شروع به جمع‌آوری FID در اندازه‌گیری‌های میدانی سایت خود کنید، با رفتن به bit.ly/event-timing-ot و انتخاب ویژگی رویداد زمان‌بندی، برای آزمایش اولیه ثبت‌نام کنید. و البته، کاوش مجموعه داده را برای بینش جالب در مورد وضعیت تعامل در وب شروع کنید . این هنوز یک معیار آزمایشی است، بنابراین لطفاً بازخورد خود را با ما در میان بگذارید و تجزیه و تحلیل خود را در گروه بحث گزارش Chrome UX یا @ChromeUXReport در Twitter به اشتراک بگذارید.