آوین آویسا – خدمات سئو | فروشگاه اختصاصی | بلاک چین و رمزارزها
  • صفحه اصلی
  • خدمات ما
    • خدمات فروشگاه اختصاصی
    • خدمات سئو
    • خدمات بلاک‌چین و رمزارزها
    • خدمات ربات معامله‌گر
  • آخرین پروژه‌ها
  • وبلاگ
  • تازه های تکنولوژی
  • درباره ما
  • تماس با ما
  • English
آوین آویسا – خدمات سئو | فروشگاه اختصاصی | بلاک چین و رمزارزها

Core Web Vitals

خانه / صفحه وبلاگ / Core Web Vitals
07تیر

معیار بزرگترین عنصر (LCP) چیست؟

تیر 7, 1400 نویسنده آوین آویسا سئو

از نظر تاریخی، اندازه‌گیری سرعت بارگیری و مشاهده محتوای اصلی یک صفحه وب برای کاربران یک چالش مهم برای توسعه‌دهندگان بوده است. معیار بزرگترین عنصر (LCP) کلید ماجراست!

معیارهای قدیمی مانند load یا DOMContentLoaded خوب نیستند، زیرا لزوماً با آنچه کاربر در صفحه خود می‌بیند مطابقت ندارند. معیارهای جدیدتر عملکرد کاربر محور مانند First Contentful Paint (FCP) نیز فقط ابتدای تجربه بارگیری را اندازه‌گیری می‌کنند. اگر صفحه‌ای نشانگر بارگیری را نشان می‌دهد‌، این لحظه برای کاربر چندان مناسب نیست.

معیارهای عملکردی مانند First Meaningful Paint (FMP) و Speed Speed (SI) (هر دو موجود در Lighthouse) نیز موجود هستند، اما توضیح این معیارها پیچیده است، و اغلب اشتباه است – به این معنی که آن‌ها هنوز هم بارگذاری محتوای اصلی صفحه را تشخیص نمی‌دهند.

بعضی اوقات نگاه ساده‌تر، بهتر است. بر اساس بحث در کارگروه عملکرد وب W3C و تحقیقاتی که در Google انجام شده است، متوجه شده‌ایم که یک روش دقیق‌تر برای اندازه‌گیری زمان بارگیری محتوای اصلی یک صفحه، بررسی زمان ارائه بزرگترین عنصر است.

معیار بزرگترین عنصر (LCP) چیست؟

معیار Largest Contentful Paint (LCP) زمان رندر بزرگترین تصویر یا بلوک متنی را که در قسمت viewport قابل مشاهده است، نسبت به زمان بارگیری صفحه برای اولین بار، را گزارش می‌کند.

امتیاز خوب برای معیار بزرگترین عنصر (LCP) چیست؟

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

چه عناصری در این معیار در نظر گرفته می‌شوند؟

انواع عناصر در نظر گرفته شده برای بزرگترین محتوا عبارتند از:

  • عناصر <img>.
  • عناصر <image> داخل عنصر <svg>.
  • عناصر <video> (از تصویر پوستر استفاده می‌شود).
  • عنصری با تصویر پس‌زمینه که از طریق تابع url () بارگیری می‌شود (در مقابل گرادیان CSS).
  • عناصر سطح بلوک حاوی گره‌های متنی یا سایر عناصر متن درون خطی فرزندان(children).

توجه داشته باشید، محدود کردن عناصر به این مجموعه محدود به منظور ساده نگه داشتن موارد در ابتدا بوده است. با انجام تحقیقات بیشتر ممکن است در آینده عناصر اضافی (به عنوان مثال <svg> و <video>) اضافه شوند.

اندازه یک عنصر چگونه تعیین می‌شود؟

اندازه عنصر گزارش شده برای بزرگترین محتوا معمولاً اندازه‌ای است که برای کاربر در داخل ویوپورت قابل‌مشاهده است. اگر عنصر خارج از ویوپورت گسترش یابد، یا اگر هر یک از عناصر قطع شده یا دارای سرریز غیرقابل مشاهده(non-visible overflow) باشد‌، آن قسمت‌ها در اندازه عنصر محاسبه نمی‌شوند.

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

برای عناصر متن، فقط اندازه گره‌های متنی آن‌ها در نظر گرفته شده است (کوچکترین مستطیلی که همه گره‌های متنی را در بر می‌گیرد).

برای همه عناصر، هیچ حاشیه، padding یا حاشیه اعمال شده از طریق CSS در نظر گرفته نشده است.

چه زمانی بزرگترین محتوا گزارش می‌شود؟

صفحات وب معمولاً به صورت مرحله‌ای بارگیری می‌شوند و در نتیجه ممکن است بزرگترین عنصر صفحه تغییر کند.

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

به عنوان مثال، در صفحه‌ای با متن و یک تصویر، مرورگر ممکن است در ابتدا متن را رندر کند – در آن زمان مرورگر یک ورودی با بزرگترین محتوا را ارسال می‌کند که ویژگی عنصر آن احتمالاً به یک <p> یا <h1> اشاره دارد. بعداً، پس از اتمام بارگذاری تصویر، دومین ورودی با محتوای بزرگ‌تر ارسال می‌شود و ویژگی عنصر آن به <img> اشاره می‌کند.

توجه به این نکته مهم است که فقط می‌توان یک عنصر را بزرگترین عنصر محتوایی در نظر گرفت که برای کاربر قابل‌مشاهده است. تصاویری که هنوز بارگیری نشده‌اند “ارائه” محسوب نمی‌شوند. در چنین مواردی ممکن است عنصر کوچکتر به عنوان بزرگترین عنصر محتوا گزارش شود، اما به محض اتمام رندر، عنصر بزرگتر از طریق یک شی دیگر PerformanceEntry گزارش می‌شود.

علاوه بر تصاویر و قلم‌هایی که دیرهنگام بارگذاری می‌شوند، یک صفحه ممکن است با دسترسی به محتوای جدید عناصر جدیدی را به DOM اضافه کند. اگر هر یک از این عناصر جدید از بزرگترین عنصر محتوای قبلی بزرگتر باشند، عملکرد جدیدی نیز گزارش می‌شود.

اگر عنصری که در حال حاضر بزرگترین عنصر محتوایی است از قسمت view حذف شود (یا حتی از DOM حذف شود)، همچنان بزرگترین عنصر محتوایی در نظر گرفته خواهد شد مگر این‌که یک عنصر بزرگ‌تر ارائه شود.

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

برای تجزیه و تحلیل، شما فقط باید آخرین PerformanceEntry ارسال‌شده شده را به سرویس تجزیه و تحلیل خود گزارش دهید.

زمان بارگذاری در مقابل زمان ارائه

به دلایل امنیتی، مهر زمانی تصاویر cross-origin که فاقد هدر Timing-Allow-Origin هستند، قرار نمی‌گیرد. در عوض، فقط زمان بارگذاری آن‌ها در معرض دید قرار دارد (زیرا این مورد از قبل از طریق بسیاری از API‌های وب دیگر نشان داده شده است).

نحوه تغییر عناصر و چیدمان عناصر چگونه انجام می شود؟

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

مثال‌ها

در اینجا چند نمونه در چند وب سایت معروف مرور شده ا‌ند:

در هر دو جدول زمانی بالا، بزرگترین عنصر با بارگذاری محتوا تغییر می‌کند. در مثال اول، محتوای جدید به DOM اضافه می‌شود و این بزرگترین عنصر را تغییر می‌دهد. در مثال دوم، چیدمان تغییر می‌کند و محتوایی که قبلاً بیشترین مقدار را داشت، از ویوپورت حذف می‌شود.

گرچه غالباً چنین اتفاقی می‌افتد که محتوای بارگذاری دیررس نسبت به محتوای موجود در صفحه بزرگتر است، اما لزوماً اینگونه نیست. دو مثال بعدی بزرگترین محتوا را قبل از بارگیری کامل صفحه نشان می‌دهد.

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

بزرگترین عنصر (LCP) چگونه اندازه‌گیری می‌شود؟

LCP را می‌توان در آزمایشگاه یا به طور عملیاتی اندازه‌گیری کرد. ابزارهای زیر در دسترس هستند:

ابزار عملیاتی:

  • Chrome User Experience Report

  • PageSpeed Insights

  • Search Console (Core Web Vitals report)

  • web-vitals JavaScript library

ابزار آزمایشگاهی:

  • Chrome DevTools

  • Lighthouse

  • WebPageTest

اندازه‌گیری LCP در جاوااسکریپت

برای اندازه‌گیری LCP در JavaScript، می‌توانید از Largest Contentful Paint APIAPI استفاده کنید. مثال زیر نحوه ایجاد PerformanceObserver را نشان می‌دهد که ورودی‌های largest-contentful-paint را زیر نظر می‌گیرد و آن‌ها را به کنسول وارد می‌کند.

1
2
3
4
5
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

 

در مثال بالا، هر ورودی largest-contentful-paintنشان‌دهنده کاندیدای فعلی LCP است. به طور کلی، مقدار startTime آخرین ورودی منتشر شده مقدار LCP است – با این حال، همیشه اینطور نیست. همه ورودی های largest-contentful-paint برای اندازه گیری LCP معتبر نیستند.

تفاوت‌های بین معیار و API
  • API بزرگترین محتوا را برای صفحات بارگیری شده در یک برگه پس زمینه ارسال می کند، اما هنگام محاسبه LCP این صفحات باید نادیده گرفته شوند.
  • API پس از ایجاد پس زمینه در یک صفحه، به largest-contentful-paint بیشتر ادامه می‌دهد، اما هنگام محاسبه LCP، باید این ورودی‌ها را نادیده گرفت (فقط در صورتی که صفحه در تمام زمان در پیش‌زمینه باشد، عناصر در نظر گرفته می‌شوند).
  • هنگام بازگرداندن صفحه از کش بک/ فرانت، API، ورودی‌های largest-contentful-paint را گزارش نمی‌کند، اما LCP باید در این موارد اندازه‌گیری شود زیرا کاربران آنها را به عنوان بازدیدهای صفحه تجربه می‌کنند.
  • API، ورودی‌هایی را که درون iframes رخ می‌دهند گزارش نمی‌کند، اما برای اندازه‌گیری صحیح LCP باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند با استفاده از API ورودی‌های largest-contentful-paint خود را برای تجمیع در فریم والد گزارش دهند.

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

1
2
3
import {getLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
getLCP(console.log);

اگر بزرگترین عنصر مهمترین عنصر نباشد چه می‌شود؟

در بعضی موارد مهمترین عنصر (یا عناصر) صفحه با بزرگترین عنصر یکی نیست و توسعه‌دهندگان ممکن است به جای آن علاقه بیشتری به اندازه‌گیری زمان رندر این عناصر دیگر را داشته باشند. همان‌طور که در مقاله معیارهای سفارشی شرح داده شده است، این مساله با استفاده از Element Timing API امکان‌پذیر است.

نحوه بهینه‌سازی معیار بزرگترین عنصر محتوا (LCP)

درمقاله جداگانه با جزییات تمام نحوه بهینه‌سازی LCP شرح داده شده است.

منبع:

https://web.dev/lcp/

ادامه مطلب
24خرداد

معیار تأخیر ورودی اول (FID) چیست؟

خرداد 24, 1400 نویسنده آوین آویسا سئو

همه ما می‌دانیم که ایجاد یک احساس خوب در برخورد اول چقدر مهم است. همان‌طور که این مساله هنگام ملاقات با افراد جدید بسیار مهم است، در مورد تجربیات در وب نیز اهمیت بالایی دارد. معیار تأخیر ورودی اول (FID) نشان‌دهنده همین تجربه در وب است.

در وب، اولین برداشت خوب می‌تواند تفاوتی را بین تبدیل شدن شخصی به کاربر وفادار یا خروج و عدم بازگشت ایجاد کند. سوال این است که چه چیزی باعث ایجاد تأثیر خوب می‌شود و چگونه می توان نوع برداشتی کاربران را اندازه گیری کرد؟

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

در حالی که اندازه گیری اینکه کاربران چقدر طراحی سایت را دوست دارند سخت است، اما اندازه‌گیری سرعت و پاسخگویی آن چنین نیست!

اولین برداشت کاربران از اینکه سرعت بارگذاری سایت شما با First Contentful Paint (FCP) چقدر سریع است قابل اندازه‌گیری است. اما اینکه سایت شما با چه سرعتی می‌تواند پیکسل‌های صفحه را پر کند، تنها بخشی از داستان است. به همان اندازه میزان توانایی تعامل و پاسخگویی سایت شما با کاربرانی که سعی در استفاده از عناصر صفحه را دارند هم مهم است.

معیار تأخیر ورودی اول (FID) به اندازه‌گیری اولین برداشت کاربر از تعامل و پاسخگویی سایت شما کمک می‌کند.

معیار تأخیر ورودی اول (FID) چیست؟

FID از زمانی که کاربر برای اولین بار با یک صفحه ارتباط برقرار می‌کند (به عنوان مثال هنگامی که روی لینک کلیک می‌کند، روی دکمه‌ای ضربه می‌زند یا از کنترل سفارشی با استفاده از JavaScript استفاده می‌کند) تا زمانی که مرورگر در واقع در پاسخ به آن تعامل قادر به پردازش کنترل کننده‌های رویداد است، اندازه گیری می‌کند.

چه امتیازی برای معیار تأخیر ورودی اول (FID) خوب محسوب می‌شود؟

برای ایجاد یک تجربه کاربری خوب، سایت‌ها باید تلاش کنند تا تأخیر ورودی اول 100 میلی‌ثانیه یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای بیشتر کاربران، یک آستانه خوب برای اندازه‌گیری، رسیدن به این آستانه در ۷۵ درصد بار بارگیری صفحه است که در دستگاه‌های تلفن همراه و دسکتاپ اتفاق می‌افتد.

جزییات معیار تأخیر ورودی اول (FID)

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

به طور کلی، تأخیر ورودی به این دلیل اتفاق می‌افتد که ترد (thread) اصلی مرورگر مشغول انجام کار دیگری است، بنابراین (در آن لحظه) نمی‌تواند به کاربر پاسخ دهد. یک دلیل رایج ممکن است این اتفاق باشد، مرورگر مشغول تجزیه و اجرای یک فایل جاوا اسکریپت بزرگ است که توسط برنامه شما بارگذاری شده است. در حالی که این کار را انجام می‌دهد، نمی‌تواند شنوندگان(listeners) رویداد را اجرا کند زیرا JavaScript که بارگیری می‌کند ممکن است به او بگوید کار دیگری انجام دهد.

جدول زمانی زیر را برای بارگذاری معمول صفحه وب در نظر بگیرید:

تصویر فوق صفحه‌ای را نشان می‌دهد که چندین درخواست شبکه برای منابع (به احتمال زیاد فایل‌های CSS و JS) ایجاد می‌کند و – پس از اتمام بارگیری این منابع – در ترد اصلی پردازش می‌شوند.

این نتیجه در دوره‌هایی است که ترد اصلی لحظه‌ای مشغول است، که توسط بلوک‌های کار بژ رنگ نشان داده می‌شوند.

تأخیرهای ورودی اول طولانی معمولاً بین First Contentful Paint (FCP) و Time to Interactive (TTI) رخ می‌دهد زیرا این صفحه برخی از محتوای خود را ارائه داده است اما هنوز به طور کامل تعاملی نیست. برای نشان دادن چگونگی این اتفاق ، FCP و TTI به جدول زمانی اضافه شده‌اند:

ممکن است متوجه شده باشید که بین FCP و TTI زمان نسبتاً کمی (از جمله سه تسک طولانی) وجود دارد، اگر کاربر در آن مدت سعی کند با صفحه ارتباط برقرار کند (به عنوان مثال روی لینک کلیک کند)، بین زمانی کلیک و هنگامی که ترد اصلی قادر به پاسخگویی است، تاخیری به وجود خواهد آمد.

در نظر بگیرید که اگر یک کاربر سعی کند با صفحه، نزدیک به ابتدای طولانی ترین کار تعامل کند چه اتفاقی می‌افتد:

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

اگر یک تعامل شنونده رویداد (event listener) نداشته باشد، چه اتفاقی می‌افتد؟

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

به عنوان مثال، همه عناصر HTML زیر قبل از پاسخ به تعاملات کاربر باید منتظر بمانند تا کارهای در حال انجام روی ترد اصلی تکمیل شود:

  • زمینه‌های نوشتاری، چک‌باکس‌ها و دکمه‌های رادیویی (<input> ، <textarea>).

  • گزینه‌های کشویی انتخاب (<select>).

  • لینک‌ها (<a>).

چرا فقط ورودی اول را در نظر می‌گیریم؟

در حالی که تأخیر از هر ورودی می‌تواند منجر به تجربه کاربری بدی شود، به چند دلیل توصیه می‌کنیم اولین تاخیر ورودی را اندازه‌گیری کنید:

  • اولین تأخیر ورودی اولین برداشت کاربر از پاسخگویی سایت شما خواهد بود و اولین برداشت‌ها در شکل‌گیری تأثیر کلی ما درباره کیفیت و قابلیت اطمینان سایت بسیار مهم است.

  • بیشترین مشکلات تعاملی که امروزه در وب مشاهده می‌کنیم در هنگام بارگذاری صفحه رخ می‌دهد. بنابراین، ما اعتقاد داریم که در ابتدا تمرکز بر بهبود اولین تعامل کاربر سایت بیشترین تأثیر را در بهبود تعامل کل وب خواهد داشت.

  • راه‌حل‌های پیشنهادی برای اینکه چگونه سایت‌ها تأخیرهای ورودی اول بالا را برطرف کنند (تقسیم کد، بارگیری کمتر جاوا اسکریپت از قبل و غیره) لزوماً راه‌حل‌های یکسانی برای رفع تأخیر ورودی آهسته پس از بارگذاری صفحه نیستند. با تفکیک این معیارها، می‌توانیم دستورالعمل‌های عملکرد ویژه‌تری را به توسعه‌دهندگان وب ارائه دهیم.

چه‌چیزی به عنوان ورودی اول در نظر گرفته می‌شود؟

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

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

به عبارت دیگر، FID بر روی R (پاسخگویی) در مدل عملکرد RAIL تمرکز دارد، در حالی که اسکرول و بزرگنمایی بیشتر مربوط به A (انیمیشن) است و کیفیت عملکرد آنها باید جداگانه ارزیابی شود.

اگر کاربری تعاملی با سایت شما نداشت چه اتفاقی می‌افتد؟

همه کاربران در هر بار بازدید با سایت شما ارتباط برقرار نخواهند کرد، و همه تعاملات مربوط به FID نیستند (همانطور که در بخش قبلی ذکر شد). بعلاوه، اولین تعاملات برخی از کاربران در مواقع بد (زمانی که ترد اصلی برای مدت زمان طولانی مشغول است) انجام خواهند شد و اولین تعاملات برخی دیگر از کاربران در اوقات خوب (زمانی که ترد اصلی کاملاً بیکار است) خواهند بود.

این بدان معناست که برخی از کاربران هیچ مقدار FID ندارند، برخی از کاربران دارای مقادیر FID کم و برخی از کاربران احتمالاً مقادیر FID بالایی دارند.

نحوه ردیابی، گزارش و تجزیه و تحلیل FID احتمالاً کاملاً متفاوت از سایر معیارهایی است که شما تا حالا استفاده کرده‌اید. بخش بعدی چگونگی انجام این کار را توضیح می‌دهد.

چرا فقط تأخیر ورودی را در نظر می‌گیریم؟

همانطور که در بالا ذکر شد، FID فقط “تأخیر” در پردازش رویداد را اندازه‌گیری می‌کند. این معیار نه زمان پردازش رویداد را اندازه می‌گیرد و نه زمانی را که مرورگر برای به روزرسانی UI پس از اجرای برنامه‌های کنترل رویداد نیاز دارد.

اگرچه این زمان برای کاربر مهم است و تجربه را تحت تأثیر قرار می‌دهد، اما در این معیار گنجانده نشده است، زیرا انجام این کار می‌تواند باعث ایجاد انگیزه در برنامه‌نویسان برای افزودن راهکارهایی شود که در واقع باعث بدتر شدن تجربه می‌شوند. یعنی آنها می‌توانند برای جدا کردن از وظیفه مرتبط با رویداد، منطق کنترل‌کننده رویداد خود را در یک کال‌بک ناهمگام قرار دهند (از طریق setTimeout () یا requestAnimationFrame ()). نتیجه می‌تواند بهبود در نمره معیار باشد در حالی که پاسخ کندتری توسط کاربر درک می‌شود.

با این حال، در حالی که FID فقط میزان “تأخیر” تأخیر رویداد را اندازه‌گیری می‌کند، توسعه‌دهندگانی که می‌خواهند بیشتر چرخه عمر رویداد را ردیابی کنند، می‌توانند با استفاده از API زمانبندی رویداد این کار را انجام دهند.

اندازه‌گیری معیار تأخیر ورودی اول (FID)

FID معیاری است که فقط در حالت عملیاتی قابل اندازه‌گیری است، زیرا برای تعامل با صفحه شما به یک کاربر واقعی نیاز دارد. می توانید FID را با ابزار زیر اندازه‌گیری کنید.

  • Chrome User Experience Report

  • PageSpeed Insights

  • Search Console (Core Web Vitals report)

  • web-vitals JavaScript library

اندازه‌گیری معیار تأخیر ورودی اول (FID) در جاوااسکریپت

برای اندازه‌گیری FID در JavaScript، می‌توانید از Event Timing API استفاده کنید. مثال زیر نحوه ایجاد PerformanceObserver را نشان می‌دهد که ورودی‌های ورودی اول را گوش می‌کند و آنها را در کنسول ثبت می‌کند:

1
2
3
4
5
6
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

در مثال فوق، مقدار تأخیر ورودی اول ورودی با در نظر گرفتن دلتا بین زمان شروع ورود و پردازش زمان شروع می‌شود. در اکثر مواقع، این مقدار FID خواهد بود. با این حال، همه ورودی‌های ورودی اول برای اندازه‌گیری FID معتبر نیستند.

در بخش زیر تفاوت بین گزارش‌های API و نحوه محاسبه FID ذکر شده است:

  • API، ورودی‌های ورودی اول را برای صفحات بارگیری شده در یک برگه پس زمینه ارسال می‌کند اما هنگام محاسبه FID نباید از این صفحات چشم پوشی کرد.

  • اگر صفحه قبل از اولین ورودی صفحه پس زمینه داشته باشد، API، ورودی‌های ورودی اول را نیز ارسال می‌کند، اما هنگام محاسبه FID، این صفحات نیز باید نادیده گرفته شوند (ورودی‌ها فقط درصورتی که صفحه در کل زمان در پیش زمینه باشد در نظر گرفته می‌شوند).

  • هنگام بازگرداندن صفحه از کش بک/ فرانت، API، ورودی‌های ورودی اول را گزارش نمی‌کند، اما FID باید در این موارد اندازه‌گیری شود زیرا کاربران آنها را به عنوان بازدیدهای صفحه تجربه می‌کنند.

  • API، ورودی‌هایی را که درون iframes رخ می‌دهند گزارش نمی‌کند، اما برای اندازه‌گیری صحیح FID باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند با استفاده از API ورودی‌های ورودی اول خود را برای تجمیع در فریم والد گزارش دهند.

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

1
2
3
import {getFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
getFID(console.log);

تحلیل و گزارش FID

با توجه به واریانس مورد انتظار در مقادیر FID، بسیار مهم است که هنگام گزارش دادن در FID به توزیع مقادیر توجه کرده و روی درصدهای بالاتر تمرکز کنید.

در حالی که انتخاب درصد برای همه آستانه های (Core Web Vital) ۷۵ درصد است، اما در مورد FID اکیداً توصیه می‌کنیم که درصدهای ۹۵ تا ۹۹ را بخاطر داشته باشید، زیرا این موارد مربوط به اولین برداشت کاربران از سایت شما خواهد بود.

حتی بهتر است گزارشات خود را بر اساس دسته یا نوع دستگاه تقسیم کنید. به عنوان مثال، اگر گزارشات جداگانه‌ای برای دسکتاپ و موبایل اجرا می‌کنید، مقدار FID مورد توجه شما در دسکتاپ باید ۹۵–۹۹ درصد کاربران دسکتاپ باشد و مقدار FID مورد توجه شما در تلفن همراه باید ۹۵–۹۹ کاربران موبایل باشد.

بهبود امتیاز FID

در مقاله‌ای جداگانه به طور کامل در مورد راه‌های بهبود FID صحبت کرده‌ایم که برای مشاهده آن مقاله می‌توانید به آن مراجعه کنید. (لینک)

منبع:

https://web.dev/fid/

ادامه مطلب
17خرداد

معیار تغییر تجمعی چیدمان (CLS) چیست؟

خرداد 17, 1400 نویسنده آوین آویسا سئو

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

بیشتر اوقات این نوع تجربه ها فقط آزاردهنده هستند، اما در بعضی موارد می‌توانند آسیب واقعی ایجاد کنند.

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

آنچه این مسئله را حتی بیشتر مشکل‌ساز می‌کند این است که نحوه عملکرد سایت در حین توسعه اغلب با تجربه کاربران متفاوت است. محتوای شخصی‌سازی‌شده یا محتوای شخص ثالث معمولاً رفتار یکسان در مرحله توسعه و تولید را ندارد، تصاویر آزمایشی اغلب در حافظه پنهان مرورگر توسعه‌دهنده قرار دارند و تما‌س‌های API که به صورت لوکال اجرا می‌شوند اغلب به قدری سریع هستند که تأخیر قابل توجه نیست.

معیار تغییر تجمعی چیدمان (CLS) به شما کمک می‌کند تا با اندازه‌گیری میزان بروز آن برای کاربران واقعی این مشکل را برطرف کنید.

معیار تغییر تجمعی چیدمان (CLS) چیست؟

CLS معیاری برای بزرگترین تغییرات طرح برای هر تغییر طرح غیر منتظره است که در کل طول عمر یک صفحه رخ می‌دهد.

هر زمان که عنصر قابل رویت موقعیت خود را از یک قاب ارائه شده به قاب دیگر تغییر می‌دهد، تغییر طرح‌بندی رخ می‌دهد.

شیفت‌های طرح‌بندی، که به عنوان پنجره جلسه (session window) شناخته می‌شود، زمانی است که یک یا چند تغییر چیدمان منفرد به صورت پی در پی و با کمتر از 1 ثانیه در هر شیفت و حداکثر 5 ثانیه برای کل مدت پنجره اتفاق می‌افتد.

بزرگترین شیفت پنجره جلسه‌ای با حداکثر نمره تجمعی از همه تغییرات طرح‌بندی در آن پنجره است.

امتیاز مناسب برای معیار تغییر تجمعی چیدمان (CLS) چیست؟

برای ارائه یک تجربه کاربری خوب، سایت‌ها باید تلاش کنند که نمره ۰.۱ یا کمتر داشته باشند. برای اطمینان از رسیدن به این هدف برای بیشتر کاربران، یک آستانه خوب برای اندازه‌گیری، رسیدن به این آستانه در ۷۵ درصد بار بارگیری صفحه است که در دستگاه‌های تلفن همراه و دسکتاپ اتفاق می‌افتد.

جزییات تغییرات چیدمان

شیفت‌های چیدمان توسط Layout Instability API تعریف می‌شوند، که گزارشات ورودی layout-shift را گزارش می‌دهد، هرگاه عنصری که در ویوپورت قابل مشاهده است، موقعیت آغازین خود را تغییر دهد. چنین عناصری، عناصر ناپایدار محسوب می‌شوند.

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

امتیاز تغییر چیدمان

برای محاسبه نمره تغییر طرح، مرورگر به اندازه Viewport و حرکت عناصر ناپایدار در Viewport بین دو فریم ارائه شده نگاه می‌کند. نمره تغییر طرح نتیجه ضرب دو اندازه‌گیری از آن حرکت است: نسبت تأثیر و نسبت فاصله (هر دو در زیر تعریف شده اند).

1
<span style="font-family: Liberation Mono, serif; color: #000000;"><span lang="en-US"><code class="western"><span lang="fa-IR">layout shift score = impact fraction * distance fraction</span></code></span></span>

نسبت تاثیر

نسبت تاثیر چگونگی تأثیر عناصر ناپایدار بر فضای نمای بین دو قاب را اندازه می‌گیرد.

اجتماع مناطق قابل مشاهده برای همه عناصر ناپایدار برای قاب قبلی و قاب فعلی – به عنوان کسری از کل مساحت viewport – نسبت ضربه برای قاب فعلی است.

در تصویر بالا عنصری وجود دارد که نیمی از نمای در یک قاب را اشغال می‌کند. سپس، در فریم بعدی، عنصر 25٪ از ارتفاع viewport به سمت پایین حرکت می‌کند. مستطیل قرمز نشانگر اجتماع ناحیه قابل مشاهده عنصر در هر دو قاب است که در این حالت 75٪ کل viewport است، بنابراین نسبت تأثیر آن 0.75 است.

نسبت فاصله

قسمت دیگر معادله نمره تغییر طرح، فاصله‌ای را که عناصر ناپایدار نسبت به viewport حرکت کرده‌اند را اندازه‌گیری می‌کند. نسبت فاصله بزرگترین مسیری است که هر عنصر ناپایداری در قاب حرکت کرده است (به صورت افقی یا عمودی) تقسیم بر بزرگترین بعد viewport (عرض یا ارتفاع، هر کدام که بیشتر باشد).

مثال ۱:

 

در مثال بالا، بزرگترین بعد viewport ارتفاع است و عنصر ناپایدار ۲۵٪ از ارتفاع viewport حرکت کرده است که نسبت فاصله را ۰.۲۵ می‌کند. بنابراین، در این مثال نسبت ضربه ۰.۷۵ و نسبت فاصله ۰.۲۵ است، بنابراین نمره تغییر طرح ۰.۷۵ * ۰.۲۵ = ۰.۱۸۷۵ است.

مثال ۲:

مثال بعدی نشان می‌دهد که چگونه افزودن محتوا به یک عنصر موجود روی امتیاز تغییر طرح تأثیر می‌گذارد:

دکمه “Click Me!” در انتهای جعبه خاکستری با متن سیاه اضافه شده است، که جعبه سبز با متن سفید را به پایین (و تا حدی خارج از نمای نمایشگر) حرکت می‌دهد.

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

دکمه “Click Me!” قبلا در DOM نبود، بنابراین موقعیت آغازین آن نیز تغییر نمی‌کند.

موقعیت آغازین جعبه سبز تغییر می‌کند، اما از آنجایی که قسمتی از قسمت دید خارج شده است، هنگام محاسبه نسبت ضربه، منطقه پنهان‌شده در نظر گرفته نمی‌شود. اجتماع نواحی قابل‌مشاهده برای جعبه سبز در هر دو قاب (با مستطیل قرمز نشان داده شده است) همان مساحت جعبه سبز در قاب اول است – ۵۰٪ viewport. نسبت ضربه ۰.۵ است.

نسبت فاصله با فلش بنفش نشان داده شده است. جعبه سبز حدود ۱۴٪ از viewport به سمت پایین حرکت کرده بنابراین کسر فاصله ۰.۱۴ است.

نمره تغییر طرح ۰.۱۴ *۰.۵ = ۰.۰۷ است.

مثال ۳:

مثال بعدی چندین عنصر ناپایدار را نشان می‌دهد:

در اولین قاب بالا، چهار نتیجه درخواست API برای حیوانات وجود دارد که به ترتیب حروف الفبا مرتب شده‌اند. در فریم دوم، نتایج بیشتری به لیست مرتب‌شده اضافه می‌شوند.

اولین مورد در لیست (“Cat“) موقعیت آغازین خود را بین قاب‌ها تغییر نمی‌دهد، بنابراین پایدار است. به همین ترتیب، موارد جدید اضافه شده به لیست قبلاً در DOM نبودند، بنابراین موقعیت‌های آغازین آن‌ها نیز تغییر نمی‌کند. اما مواردی با برچسب “Dog” ،“Horse” و “Zebra” همه موقعیت‌های آغازین خود را تغییر می‌دهند و آن‌ها را به عناصر ناپایدار تبدیل می‌‌شوند.

مجدداً، مستطیل‌های قرمز نشان‌دهنده اجتماع این سه عنصر ناپایدار در مناطق قبل و بعد از آن است که در این حالت حدود ۳۸٪ viewport (نسبت تأثیر ۰.۳۸) است.

پیکان‌ها فاصله‌هایی را نشان می‌دهند که عناصر ناپایدار از موقعیت آغازین خود حرکت کرده‌اند. عنصر “Zebra” ، که با پیکان آبی نشان داده شده است، با حدود ۳۰٪ حرکت در ارتفاع viewport، بیشترین حرکت را داشته است. در نتیجه، نسبت فاصله در این مثال ۰.۳ است.

نمره تغییر طرح ۰.۳ * ۰.۳۸ = ۰.۱۱۷۲ است.

تغییرات چیدمان قابل‌پیش‌بینی در مقابل غیرقابل‌ پیش‌‌بینی

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

چیدمانی که توسط کاربر تغییر می‌کند

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

به عنوان مثال، اگر کاربر درخواستی دارد که نیاز به ارسال داده در شبکه ایجاد می‌کند و انجام آن ممکن است مدتی طول بکشد، بهتر است فوراً فضای خالی ایجاد کرده و یک نشانگر بارگیری را نشان دهید تا با تکمیل درخواست، از تغییر طرح نامناسب جلوگیری شود. اگر کاربر متوجه نشود که چیزی در حال بارگیری است، یا تصوری از زمان آماده شدن درخواست خود نداشته باشد، ممکن است هنگام انتظار سعی کند روی مورد دیگری کلیک کند – مساله‌ای که می‌تواند چیدمان را تغییر دهد.

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

انیمیشن و انتقال

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

ویژگی transform در CSS به شما امکان می‌دهد تا عناصر را جابجا کنید بدون اینکه تغییراتی در طرح ایجاد کنید:

  • به جای تغییر خصوصیات ارتفاع و عرض، از transform: scale () استفاده کنید.

  • برای جابجایی عناصر به اطراف، از تغییر خصوصیات بالا، راست، پایین یا چپ خودداری کنید و به جای آن از transform: translate () استفاده کنید.

تغییر تجمعی چیدمان (CLS) چگونه اندازه‌گیری می‌شود؟

CLS را می‌توان در آزمایشگاه یا به طور عملیاتی اندازه‌گیری کرد. ابزارهای زیر در دسترس هستند:

ابزار عملیاتی:

  • Chrome User Experience Report

  • PageSpeed Insights

  • Search Console (Core Web Vitals report)

  • web-vitals JavaScript library

ابزار آزمایشگاهی:

  • Chrome DevTools

  • Lighthouse

  • WebPageTest

اندازه‌گیری CLS در جاوااسکریپت

برای اندازه‌گیری CLS در JavaScript، می توانید از Layout Instability API استفاده کنید. مثال زیر نحوه ایجاد یک PerformanceObserver را نشان می‌دهد که ورودی‌های غیر منتظره layout-shift را گوش می‌دهد، آن‌ها را در جلسات گروه‌بندی می‌کند و هر زمان تغییر کند حداکثر مقدار جلسه را ثبت می‌کند.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
let clsValue = 0;
let clsEntries = [];
let sessionValue = 0;
let sessionEntries = [];
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    // Only count layout shifts without recent user input.
    if (!entry.hadRecentInput) {
      const firstSessionEntry = sessionEntries[0];
      const lastSessionEntry = sessionEntries[sessionEntries.length - 1];
      // If the entry occurred less than 1 second after the previous entry and
      // less than 5 seconds after the first entry in the session, include the
      // entry in the current session. Otherwise, start a new session.
      if (sessionValue &&
          entry.startTime - lastSessionEntry.startTime < 1000 &&
          entry.startTime - firstSessionEntry.startTime < 5000) {
        sessionValue += entry.value;
        sessionEntries.push(entry);
      } else {
        sessionValue = entry.value;
        sessionEntries = [entry];
      }
      // If the current session value is larger than the current CLS value,
      // update CLS and the entries contributing to it.
      if (sessionValue > clsValue) {
        clsValue = sessionValue;
        clsEntries = sessionEntries;
        // Log the updated value (and its entries) to the console.
        console.log('CLS:', clsValue, clsEntries)
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

در بیشتر موارد، مقدار فعلی CLS در زمان بارگیری صفحه، مقدار نهایی CLS برای آن صفحه است، اما چند استثنا مهم وجود دارد:

در بخش زیر تفاوت بین گزارش های API و نحوه محاسبه معیار ذکر شده است.

تفاوت‌های بین معیار و API

  • اگر صفحه‌ای در پس‌زمینه بارگیری می شود یا قبل از اینکه مرورگر هر محتوایی را ارائه کند، پس‌زمینه دارد، نباید هیچ مقدار CLS را گزارش کند.

  • هنگام بازگرداندن صفحه از کش بک/ فرانت، مقدار CLS آن باید به صفر برسد زیرا کاربران این کار را به عنوان یک بازدید متمایز از صفحه تجربه می‌کنند.

  • API، ورودی‌هایی را که درون iframes رخ می‌دهند گزارش نمی‌کند، اما برای اندازه‌گیری صحیح CLS باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند با استفاده از API ورودی‌های layout-shift خود را برای تجمیع در فریم والد گزارش دهند.

علاوه بر این موارد استثنایی، CLS به دلیل اینکه کل طول عمر یک صفحه را اندازه‌گیری می‌کند دارای پیچیدگی‌های بیشتری است:

  • کاربران ممکن است یک تب را برای مدت زمان طولانی – روزها، هفته‌ها، ماه‌ها – باز نگه دارند. در واقع، یک کاربر ممکن است هرگز یک تب را نبندد.

  • در سیستم عامل‌های تلفن همراه، مرورگرها معمولاً برگشت بارگیری صفحه را برای تب‌های پس‌زمینه اجرا نمی‌کنند، بنابراین گزارش نمره “نهایی” دشوار است.

برای رسیدگی به چنین مواردی، CLS باید هر زمان که یک صفحه پس‌زمینه است هم گزارش شود – علاوه بر هر زمان بارگیری آن (رویداد visibilitychange هر دو سناریو را پوشش می‌دهد). سپس سیستم‌های تحلیلی دریافت‌کننده این داده‌ها باید مقدار CLS نهایی را در قسمت بک‌اند محاسبه کنند.

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

1
2
3
4
import {getCLS} from 'web-vitals';
// Measure and log CLS in all situations
// where it needs to be reported.
getCLS(console.log);

نحوه بهینه‌سازی CLS

درمقاله جداگانه با جزییات تمام نحوه بهینه‌سازی CLS شرح داده شده است.

منبع:

https://web.dev/cls/

ادامه مطلب
08خرداد

بهینه سازی بزرگترین عنصر محتوا (LCP)

خرداد 8, 1400 نویسنده آوین آویسا سئو

من هیچ محتوای مفیدی نمی توانم ببینم! چرا بارگیری اینقدر طولانی است؟ بیایید با بهینه سازی بزرگترین عنصر محتوا (LCP) این تجربه کاربری ناخوشایند را از بین ببریم.

یکی از عواملی که باعث ایجاد تجربه نامناسب در کاربر می‌شود مدت زمانی است که کاربر باید منتظر بماند تا محتوای ارائه شده روی صفحه را ببیند. First Contentful Paint (FCP) مدت زمان لازم برای ارائه محتوای اولیه DOM را اندازه‌گیری می‌کند، اما مدت زمان طولانی‌تری را که برای بزرگترین (معمولاً با معنی‌ترین) محتوای صفحه صرف می‌شود را محاسبه نمی‌کند.

LCP یک از معیارهای اصلی Core Web Vital است و زمانی را محاسبه می‌کند که بزرگترین عنصر محتوای در viewport قابل مشاهده است.این معیار می‌تواند برای تعیین زمان پایان ارائه محتوای اصلی صفحه بر روی صفحه استفاده شود.

معمول‌ترین دلایل LCP ضعیف عبارتند از:

  • زمان طولانی پاسخ‌دهی سرور.
  • رندر–بلاکینگ جاوا اسکریپت و CSS.
  • زمان طولانی بارگیری منابع.
  • رندرینگ در سمت کاربر.
زمان طولانی پاسخ‌دهی سرور

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

قبل از هر چیز دیگری، نحوه و مکانی که سرور محتوای شما را هندل می‌کند بهبود ببخشید. برای اندازه‌گیری زمان پاسخ سرور از Time to First Byte (TTFB) استفاده کنید. شما می‌توانید TTFB خود را به روش‌های مختلفی بهبود بخشید:

  • سرور خود را بهینه کنید.
  • کاربران را به CDN نزدیک هدایت کنید.
  • کش محتوا.
  • ابتدا صفحات HTML را به صورت کش سرو کنید.
  • ارتباطات شخص ثالث را زودهنگام برقرار کنید.
بهینه‌سازی سرور

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

به جای سرویس دهی فوری یک صفحه ثابت به درخواست مرورگر، بسیاری از فریم‌ورک‌های وب که سمت سرور رندر می‌شوند، نیاز به ایجاد صفحه وب پویا دارند. به عبارت دیگر، فریم‌ورک‌ها به جای ارسال فقط یک فایل HTML کامل که در لحظه درخواست مرورگر از قبل آماده است، زمانی را برای ساخت صفحه با توجه به درخواست و کد صرف کنند. این ممکن است به دلیل جستجو در پایگاه داده باشد یا حتی به این دلیل که HTML باید توسط یک فریم‌ورک UI تولید شوند (مانند React). بسیاری از فریم‌ورک‌های وب که بر روی سرور اجرا می‌شوند دارای راهنمایی عملکردی هستند که می‌توانید برای سرعت بخشیدن به این روند از آنها استفاده کنید.

هدایت کاربران به نزدیک‌ترین CDN

شبکه تحویل محتوا (CDN) شبکه ای از سرورها است که در مکان های مختلف توزیع شده اند. اگر محتوای صفحه وب شما در یک سرور میزبانی شود، وب سایت شما برای کاربرانی که از نظر جغرافیایی دورتر هستند، کندتر بارگیری می شود زیرا درخواست مرورگر آن‌ها به معنای واقعی کلمه باید به سراسر جهان سفر کند. استفاده از CDN را در نظر داشته باشید تا اطمینان حاصل کنید که کاربران شما هرگز منتظر درخواست شبکه به سرورهای دور نخواهند ماند.

کش محتوا

اگر HTML شما ثابت و استاتیک است و نیازی به تغییر در هر درخواست نیست، caching می تواند از ایجاد مجدد غیرضروری آن جلوگیری کند. با ذخیره یک نسخه از HTML تولیدشده در دیسک، ذخیره سمت سرور می تواند TTFB را کاهش داده و استفاده از منابع را به حداقل برساند.

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

  • پروکسی‌های معکوس (Varnish، nginx) را برای ارائه محتوای ذخیره‌شده پیکربندی کنید.
  • کش محتوا ارائه دهنده ابر (Firebase ، AWS ، Azure) خود را پیکربندی و مدیریت کنید.
  • از CDN که سرورهای لبه را فراهم می‌کنند استفاده کنید تا محتوای شما در نزدیکی کاربران ذخیره شود.
سرو صفحات HTML به صورت کش در ابتدا

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

ارتباطات زودهنگام با شخص ثالث

درخواست‌های سرور به مبدا شخص ثالث نیز می‌تواند بر LCP تأثیر بگذارد، مخصوصاً اگر برای نمایش محتوای مهم در صفحه مورد نیاز باشد. با استفاده از rel = “preconnect” به مرورگر اطلاع دهید که صفحه شما قصد دارد در اسرع وقت اتصال برقرار کند.

1
<span style="color: #000000; font-size: 16px;"><link rel="preconnect" href="https://example.com" /></span>

برای حل سریع‌تر جستجوی DNS می توانید از dns-prefetch نیز استفاده کنید.

1
<span style="color: #000000; font-size: 16px;"><link rel="dns-prefetch" href="https://example.com" /></span>

گرچه هر دو متفاوت عمل می کنند، استفاده از dns-prefetch را به عنوان گزینه فال‌بک برای مرورگرهایی که از اتصال مجدد پشتیبانی نمی‌کنند، در نظر بگیرید.

1
2
3
4
5
<span style="color: #000000; font-size: 16px;"><head>
  …
  <link rel="preconnect" href="https://example.com" />
  <link rel="dns-prefetch" href="https://example.com" />
</head></span>

رندر بلاکینگ جاوااسکریپت و CSS

قبل از اینکه یک مرورگر بتواند هر محتوایی را ارائه دهد، باید مارک HTML را در یک درخت DOM تجزیه کند. تجزیه کننده HTML اگر با صفحه‌های خارجی (<link rel = “stylesheet”>) یا برچسب‌های هم‌گام جاوااسکریپت (<script src = “main.js”>) روبرو شود، صبر می‌کند. اسکریپت‌ها و شیوه‌نامه‌ها هر دو منابع مسدود کننده هستند که FCP و در نتیجه LCP را به تأخیر می‌اندازند. برای سرعت بخشیدن به بارگذاری محتوای اصلی صفحه وب خود‌، JavaScript و CSS غیر مهم را به تعویق بیندازید.

کاهش زمان مسدودسازی CSS

با رعایت موارد زیر اطمینان حاصل کنید که حداقل مقدار CSS لازم، رندر را در سایت شما مسدود می‌کند:

  • CSS را کم کنید.

  • CSS غیر مهم را به تعویق بیندازید.

  • درون خطی CSS مهم.

کاهش CSS

برای خوانایی آسان‌تر، فایل‌های CSS می‌توانند شامل نویسه‌هایی مانند فاصله یا کامنت باشند. این کاراکترها برای مرورگر غیرضروری هستند و کوچک کردن این پرونده‌ها باعث می‌شود که حذف شوند. در نهایت‌، کاهش میزان مسدود کردن CSS همیشه باعث بهینه سازی بزرگترین عنصر محتوا (LCP) می‌شود.

تعویق CSS غیرمهم

برای یافتن CSS استفاده نشده در صفحه وب خود از تب Coverage در Chrome DevTools استفاده کنید.

برای بهینه سازی:

  • در صورت استفاده در صفحه جداگانه سایت خود ، CSS بدون استفاده را به طور کامل حذف کنید یا آن را به صفحه سبک دیگری منتقل کنید.

  • برای هر CSS که برای ارائه اولیه نیازی به آن نیست، از loadCSS برای بارگیری همزمان پرونده‌ها استفاده کنید، که از rel = “preload” و onload استفاده می‌شود.

1
<span style="font-size: 16px; color: #000000;">html <link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'"></span>

درون‌خطی CSS

با قرار دادن CSS مهم در سربرگ فایل HTML آن را درون‌خطی کنید:

درون‌خطی استایل‌های مهم، نیاز به درخواست رفت و برگشت برای CSS مهم را از بین می‌برد. همچنین به تعویق انداختن بقیه، زمان مسدودسازی CSS را به حداقل می‌رساند.

کاهش زمان مسدودسازی جاوا اسکریپت

حداقل جاوااسکریپت لازم را بارگیری و به کاربران ارائه دهید. کاهش میزان مسدودسازی JavaScript منجر به رندر سریع‌تر و در نتیجه LCP بهتر می‌شود. با بهینه‌سازی اسکریپت‌ها به چند روش مختلف می‌توانید این کار را انجام دهید:

  • پرونده های جاوا اسکریپت را کوچک و فشرده کنید.

  • جاوا اسکریپت استفاده‌نشده را به تعویق بیندازید.

پلی‌فیلزهای استفاده‌نشده را به حداقل برسانید.

زمان طولانی بارگیری منابع 

اگرچه افزایش زمان انسداد CSS یا JavaScript مستقیماً منجر به عملکرد بدتر می‌شود، اما زمان بارگیری برای بسیاری از انواع دیگر منابع نیز می‌تواند بر LCP تأثیر بگذارد.  

انواع عناصر موثر بر LCP عبارتند از:  

  • <img>. 
  • <image> داخل عنصر <svg>.  
  • <video>. 
  • عنصری با تصویر پس زمینه که از طریق تابع url () بارگیری می‌شود (در مقابل گرادیان CSS).  
  • عناصر سطح بلوک حاوی گره‌های متنی یا سایر عناصر متن سطح درون‌خطی. 

مدت زمان لازم برای بارگیری این عناصر ، تأثیر مستقیمی بر LCP خواهد داشت. چند روش برای اطمینان از بارگیری سریع این پرونده‌ها وجود دارد:  

  • بهینه‌سازی و فشرده‌سازی تصاویر. 
  • منابع مهم را از قبل بارگیری کنید. 
  • فشرده‌سازی فایل‌های متنی. 
  • ارائه دارایی‌های مختلف بر اساس اتصال به شبکه (سرویس انطباقی). 
  • دارایی‌ها را با استفاده از یک سرویس ورکر ذخیره کنید.
بهینه‌سازی و فشرده‌سازی تصاویر 

برای بسیاری از سایت‌ها، تصاویر پس از اتمام بارگیری صفحه، بزرگترین محتوای قابل مشاهده هستند. اسلایدرها و بنرهای بزرگ نمونه‌های متداول این موضوع هستند. 

بهبود مدت زمان بارگیری و ارائه این نوع تصاویر مستقیماً سرعت LCP را افزایش می‌دهد. برای انجام این کار:  

  • در وهله اول استفاده نکردن از تصویر را در نظر بگیرید. اگر مربوط به محتوا نیست، آن را حذف کنید. 
  • فشرده سازی تصاویر (به عنوان مثال با Imagemin). 
  • تبدیل تصاویر به قالب‌های جدیدتر (JPEG 2000 ،JPEG XR یا WebP). 
  • از تصاویر رسپانسیو استفاده کنید. 
  • استفاده از CDN تصویر را در نظر بگیرید. 
منابع مهم را از قبل بارگیری کنید  

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

اگر می‌دانید یک منبع خاص باید اولویت‌بندی شود، از <link rel = “preload”> استفاده کنید تا آن را زودتر بارگیری کنید. بسیاری از منابع می‌توانند از قبل بارگیری شوند، اما ابتدا باید روی بارگیری دارایی های مهم مانند فونت‌ها، تصاویر یا فیلم‌های حجیم و CSS یا JavaScript تمرکز کنید.

1
2
3
4
5
<link rel="preload" as="script" href="script.js" />
<link rel="preload" as="style" href="style.css" />
<link rel="preload" as="image" href="img.png" />
<link rel="preload" as="video" href="vid.webm" type="video/webm" />
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin />

فایل‌های تکست را فشرده‌سازی کنید 

الگوریتم‌های فشرده‌سازی، مانند Gzip و Brotli، می‌توانند اندازه فایل‌های متنی (HTML،CSS، JavaScript) را به میزان قابل‌توجهی کاهش دهند زیرا آن‌ها بین سرور و مرورگر منتقل می‌شوند. Gzip به طور موثر در همه مرورگرها پشتیبانی می‌شود و Brotli ، که حتی نتایج فشرده‌سازی بهتری را نیز فراهم می‌کند، تقریباً در همه مرورگرهای جدیدتر قابل استفاده است. با فشرده‌سازی منابع، زمان تحویل و زمان بارگذاری آن‌ها کاهش می‌یابد و در نتیجه LCP بهبود می‌یابد.  

  1. ابتدا بررسی کنید که آیا سرور شما از قبل فایل‌ها را به طور خودکار فشرده می‌کند یا خیر. بیشتر سیستم عامل‌های هاست، CDN ها و سرورهای معکوس پروکسی یا دارایی‌ها را به صورت پیش‌فرض فشرده‌سازی می‌کنند یا به شما امکان می‌دهند به راحتی آنها را پیکربندی کنید.  
  2. اگر می‌خواهید سرور خود را برای فشرده‌سازی فایل‌ها اصلاح کنید، استفاده از Brotli به جای gzip را در نظر بگیرید زیرا می‌تواند نسبت‌های فشرده‌سازی بهتری را فراهم کند.  
  3. هنگامی که یک الگوریتم فشرده‌سازی برای استفاده انتخاب کردید، دارایی‌ها را در زمان ساخت فشرده‌ کنید نه در هنگام ارسال. با این کار سربار سرور به حداقل می‌رسد و از تأخیر در هنگام درخواست به ویژه هنگام استفاده از نسبت‌های فشرده‌سازی بالا جلوگیری می‌کند. 
سرو کردن متناسب داده 

هنگام بارگیری منابعی که محتوای اصلی یک صفحه را تشکیل می‌دهند، بسته به شرایط و ضوابط کاربر، می‌توان دارایی‌های مختلف را ارسال کرد. این کار را می‌توان با استفاده از APIهای اطلاعات شبکه، حافظه دستگاه و HardwareConcurrency انجام داد. به عنوان مثال، می‌توانید برای سرعت اتصال کمتر از 4G، به جای فیلم، یک تصویر نمایش دهید: 

1
2
3
4
5
6
7
if (navigator.connection && navigator.connection.effectiveType) {
  if (navigator.connection.effectiveType === '4g') {
    // Load video
  } else {
    // Load image
  }
}

لیستی از ویژگی‌های مفیدی که می‌توانید استفاده کنید:

  • navigator.connection.effectiveType

  • navigator.connection.saveData

  • navigator.hardwareConcurrency

  • navigator.deviceMemory

کش کردن دارایی‌ها با سرویس‌ورکر

از سرویس‌ورکر می‌توان برای بسیاری از کارهای مفید استفاده کرد، از جمله ارائه پاسخ‌های HTML کوچکتر که قبلاً در این مقاله ذکر شد. آنها همچنین می‌توانند برای ذخیره هر منبع استاتیک که می‌تواند به جای استفاده از شبکه در درخواست‌های تکراری، به مرورگر ارائه شود، مورد استفاده قرار بگیرند

precaching منابع حیاتی با استفاده از سرویس‌ورکر می‌تواند زمان بارگیری آن‌ها را به میزان قابل‌توجهی کاهش دهد، خصوصاً برای کاربرانی که صفحه وب را با اتصال ضعیف‌تری بارگیری می‌کنند (یا حتی به صورت آفلاین به آن دسترسی دارند). کتابخانه‌هایی مانند Workbox می‌توانند روند به روزرسانی دارایی‌های منسوخ شده را آسان‌تر از نوشتن یک سرویس‌ورکر سفارشی کنند تا خودتان این کار را انجام دهید.

رندر سمت کاربر

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

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

هنگام ساخت یک سایت رندر در سمت کاربر، بهینه‌سازی‌های زیر را در نظر بگیرید:

  • جاوا اسکریپت مهم را به حداقل برسانید.

  • از رندر در سمت سرور استفاده کنید.

  • از پیش رندر استفاده کنید.

استفاده از رندر سمت سرور

به حداقل رساندن مقدار جاوا اسکریپت همیشه باید اولین موضوعی باشد که در سایت‌هایی که در سمت کاربر رندر می شوند تمرکز کرد. با این حال، شما همچنین باید ترکیبی از رندر سمت سرور برای بهبود هرچه بیشتر LCP را در نظر داشته باشید.

این مفهوم با استفاده از سرور برای رندر اپلیکیشن به HTML کار می‌کند، جایی که مشتری سپس تمام JavaScript و داده‌های مورد نیاز را روی همان محتوا “hydrates” می‌کند. این کار می‌تواند با اطمینان از اینکه محتوای اصلی صفحه ابتدا در سرور ارائه می شود نه فقط در کلاینت، LCP را بهبود بخشد، اما چند اشکال وجود دارد:

  • حفظ اپلیکیشن رندر شده توسط JavaScript در سرور و کاربر می‌تواند پیچیدگی را افزایش دهد.

  • اجرای جاوا اسکریپت برای رندر یک فایل HTML در سرور همیشه باعث افزایش زمان پاسخ سرور (TTFB) در مقایسه با رندر فقط صفحات ثابت از سرور می‌شود.

  • یک صفحه رندر شده از سرور ممکن است به نظر برسد که می‌توان با آن تعامل کرد، اما تا زمانی که تمام JavaScript سمت کاربر را اجرا نکند، نمی‌تواند به هیچ ورودی کاربر پاسخ دهد. به طور خلاصه، می‌تواند Time to Interactive (TTI) را بدتر کند.

استفاده از پیش رندر

پیش رندر یک تکنیک جداگانه است که پیچیدگی کمتری نسبت به رندر سمت سرور دارد و همچنین روشی را برای بهبود LCP در برنامه شما ارائه می‌دهد.

پیش رندر، همچنان بر TTI تأثیر منفی می‌گذارد اما بر زمان پاسخگویی سرور تحت تأثیر رندر سمت سرور که هر صفحه را فقط پس از درخواست به صورت پویا ارائه می دهد، تأثیر نمی گذارد.

منبع:

https://web.dev/optimize-lcp/

ادامه مطلب
01خرداد

بهینه‌سازی تاخیر ورودی اول (FID)

خرداد 1, 1400 نویسنده آوین آویسا سئو

کلیک کردم اما اتفاقی نیفتاد! چرا نمی توانم با این صفحه ارتباط برقرار کنم؟ دلیل آن تاخیر ورودی اول (FID) است. می‌باست با بهینه‌سازی تاخیر ورودی اول (FID) تجربه کاربری بهتری را برای کاربران خود به ارمغان آوریم.

First Contentful Paint (FCP) و Largest Contentful Paint (LCP) هر دو معیارهایی هستند که مدت زمان ارائه بصری محتوای صفحه را اندازه‌گیری می‌کنند. اگرچه این معیارها مهم هستند، اما مشخص نمی‌کنند صفحه با چه سرعتی به تعامل کاربر پاسخ می‌دهد.

First Input Delay(FID) یکی از معیارهای اصلی Core Web Vital است که اولین تاثیر کاربر از تعامل و پاسخگویی سایت را به تصویر می‌کشد. این زمان از زمانی که کاربر برای اولین بار با یک صفحه ارتباط برقرار می‌کند تا زمانی که مرورگر در واقع قادر به پاسخگویی به آن تعامل است را اندازه‌گیری می‌کند. FID یک معیار عملیاتی است و نمی‌تواند در محیط آزمایشگاه شبیه‌سازی شود. برای اندازه‌گیری تأخیر پاسخ، به تعامل واقعی کاربر نیاز است.

برای کمک به پیش‌بینی FID در آزمایشگاه، محاسبه زمان مسدود کردن کل (TBT) را توصیه می‌کنیم. اگرچه آن‌ها موارد مختلفی را اندازه‌گیری می‌کنند، اما بهبود TBT معمولاً با ارتقای FID مطابقت دارد.

علت اصلی ضعف FID، اجرای JavaScript سنگین است. بهینه‌سازی نحوه تجزیه، کامپایل و اجرای JavaScript در صفحه وب شما به طور مستقیم باعث بهینه‌سازی تاخیر ورودی اول (FID) می‌شود.

اجرای جاوااسکریپت سنگین

هنگام اجرای جاوا اسکریپت در ترد (thread) اصلی، مرورگر نمی‌تواند به بیشتر ورودی‌های کاربر پاسخ دهد. به عبارت دیگر، در حالی که ترد اصلی مشغول است، مرورگر نمی‌تواند به تعاملات کاربر پاسخ دهد. برای بهبود می‌توان موارد زیر را در نظر گرفت:

  • تسک‌های طولانی را از هم جدا کنید.

  • صفحه خود را برای آمادگی برای تعامل بهینه کنید.

  • از یک وب ورکر استفاده کنید.

  • زمان اجرای جاوا اسکریپت را کاهش دهید.

جداسازی تسک‌های طولانی از هم

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

تسک‌های طولانی، دوره‌های اجرای JavaScript است که در آن کاربران ممکن است UI شما را بی پاسخ ببینند. هر قطعه کد که ترد اصلی را برای 50 میلی‌ثانیه یا بیشتر مسدود کند، می‌تواند به عنوان یک تسک طولانی توصیف شود. تسک‌های طولانی نشانه انسداد بیش از حد احتمالی جاوا اسکریپت است (بارگذاری و اجرا بیشتر از آنچه ممکن است کاربر در حال حاضر به آن نیاز داشته باشد). تقسیم کارهای طولانی می‌تواند تأخیر ورودی را در سایت شما کاهش دهد.

با اتخاذ بهترین روش‌ها مانند تقسیم کد و شکستن کارهای طولانی، بهینه‌سازی تاخیر ورودی اول (FID) بهطور چشمگیری اتفاق می‌افتد. اگرچه TBT یک معیار عملیاتی نیست، اما برای بررسی پیشرفت در جهت بهبود هر دو معیار TTI و FID مفید است.

آمادگی صفحه برای تعامل

تعدادی از دلایل عمده برای ضعف FID و TBT در اپلیکیشن‌های وب وجود دارند که به شدت به دلیل نحوه بارگیری و اجرای JavaScript است:

افزایش سرعت جاوا اسکریپت، زمان اجرای سنگین و تجزیه ناکارآمد می‌تواند سرعت پاسخ یک صفحه به ورودی کاربر و تأثیر برFID ، TBT و TTI را کاهش دهد. بارگذاری تدریجی کد و ویژگی‌ها می‌تواند به بهبود آمادگی تعامل کمک کند. به نظر می‌رسد اپلیکیشن‌های رندر شده از سمت سرور به سرعت در حال نمایش عناصر روی صفحه هستند، اما مراقب باشید که تعاملات کاربر توسط اجرای اسکریپت‌های بزرگ مسدود نشود. در صورت استفاده از تجزیه کد مبتنی بر مسیر (routing)، این کار می تواند چند صد میلی ثانیه، حتی گاهی چند ثانیه طول بکشد. در نظر داشته باشید که بیشتر در سمت سرور جابجا شوید یا به طور ایستا محتوای بیشتری در زمان ساخت ایجاد کنید.

انتظار برای زنجیره دریافت داده از سرور، می‌تواند تأخیر در تعامل را تحت تأثیر قرار دهد. ذخیره داده‌های بزرگ درون‌خطی می‌تواند زمان تجزیه HTML را تحت تاثیر قرار داده و بر روی معیارهای نمایش محتوا و تعامل تأثیر بگذارد.

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

استفاده از وب ورکر

ترد اصلی مسدودشده یکی از دلایل اصلی تأخیر ورودی است. وب ورکرها امکان اجرای جاوا اسکریپت را بر روی یک ترد پس زمینه فراهم می‌کنند. انتقال عملیات غیر UI به تعدادی وب ورکر جداگانه می‌تواند زمان مسدود کردن ترد اصلی را کاهش داده و در نتیجه باعث بهینه‌سازی تاخیر ورودی اول (FID) می‌شود.

کاهش زمان اجرای جاوااسکریپت

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

برای کاهش مقدار جاوا اسکریپت اجرا شده در صفحه خود:

  • جاوا اسکریپت استفاده‌نشده را به تعویق بیندازید.

  • polyfill های استفاده‌نشده را به حداقل برسانید.

به تعویق انداختن جاوااسکریپت‌های استفاده‌نشده

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

تب Coverage در Chrome DevTools می‌تواند به شما بگوید که چه مقدار از JavaScript در صفحه وب شما استفاده نمی‌شود.

برای کاهش جاوا اسکریپت استفاده نشده:

  • باندل کد خود را به چند بخش تقسیم کنید.

  • با استفاده از async یا defer هر JavaScript غیر مهم، از جمله اسکریپت‌های شخص ثالث را به تعویق بیندازید.

Code-splitting مفهوم تقسیم یک بسته بزرگ جاوا اسکریپت به قطعات کوچکتر است که می‌توانند به صورت مشروط بارگیری شوند (همچنین به عنوان lazy-loading شناخته می‌شود). بیشتر مرورگرهای جدید از ایمورت پویا پشتیبانی می‌کنند که به شما امکان می‌دهد ماژول را بر اساس تقاضا فراخوان کنید:

1
2
3
<span style="font-size: 16px;">import('module.js').then((module) => {
  // Do something with the module.
});</span>

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

علاوه بر تقسیم کد، همیشه از async یا defer برای اسکریپت‌های مورد استفاده در محتوای غیرمهم یا محتوایی که در ابتدا در نمایشگر ظاهر نمی‌شوند، استفاده کنید.

1
2
<span style="font-size: 16px;"><script defer src="…"></script>
<script async src="…"></script></span>

در صورت عدم وجود دلیل خاصی، همه اسکریپت‌های شخص ثالث باید به طور پیش‌فرض با defer یا async بارگذاری شوند.

کاهش polyfillهای استفاده‌نشده

اگر کد خود را با استفاده از سینتکس مدرن جاوا اسکریپت و مرجع API های مرورگرهای مدرن کدنویسی کرده‌اید، برای کار در مرورگرهای قدیمی‌تر، باید از polyfillها استفاده کرد.

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

برای بهینه‌سازی استفاده از plyfill در سایت خود:

  • اگر از Babel به عنوان مبدل استفاده می‌کنید، از @ babel / preset-env استفاده کنید تا فقط شامل polyfillهای مورد نیاز برای مرورگرهایی باشد که قصد دارید آنها را هدف قرار دهید.

  • برای ارائه دو بسته جداگانه از الگوی module / nomodule استفاده کنید.

1
2
3
<span style="font-size: 16px;"><script type="module" src="modern.js"></script>
<script nomodule src="legacy.js" defer></script>
</span>

منبع:

https://web.dev/optimize-cls/

ادامه مطلب
25اردیبهشت

بهینه‌سازی معیار تغییر تجمعی چیدمان (CLS)

اردیبهشت 25, 1400 نویسنده آوین آویسا سئو

«قصد داشتم روش کلیک کنم چرا تکون خورد!؟» تغییر چیدمان می تواند توجه کاربران را منحرف کند. تصور کنید خواندن یک مقاله را شروع کرده اید، هنگامی که عناصر در اطراف صفحه به طور ناگهانی تغییر مکان می‌دهند ، حواس شما را پرت می‌کنند و شما مجبور خواهید شد دوباره مکان قبلی در مقاله را پیدا کنید. این مورد در وب بسیار رایج است، از جمله هنگام خواندن اخبار، یا تلاش برای کلیک کردن روی آن دکمه های “جستجو” یا “افزودن به سبد خرید“. چنین تجاربی از نظر بصری گیج‌کننده و ناامیدکننده است. این عوامل اغلب هنگامی ایجاد می شوند که عناصر قابل مشاهده مجبور به حرکت شوند زیرا عنصر دیگری ناگهان به صفحه اضافه شده یا تغییر اندازه داده‌اند. بهینه‌سازی معیار تغییر تجمعی چیدمان (CLS) این مشکل را برطرف خواهد کرد.

Cumulative Layout Shift (CLS)، یک معیار Core Web Vital، بی‌ثباتی بصری محتوا را با جمع کردن تغییرات چیدمان که بعد از 500 میلی ثانیه پس از ورود کاربر رخ می‌دهد را اندازه گیری می کند. این موضوع به بررسی میزان تغییر محتوای قابل مشاهده در ویوپورت و همچنین تغییر فاصله عناصر تأثیرگذار می پردازد.

شایعترین دلایل CLS ضعیف عبارتند از:

  • تصاویر بدون ابعاد
  • تبلیغات، جاسازی‌ها و فریم‌های بدون ابعاد.
  • محتوای ورودی پویا.
  • فونت‌های وب که باعث ایجاد FOIT / FOUT می‌شوند.
  • اقدامات منتظر پاسخ شبکه قبل از به روزرسانی DOM.
تصاویر بدون ابعاد

ویژگی‌های اندازه عرض و ارتفاع را همیشه روی تصاویر و عناصر ویدئویی خود قرار دهید. روش جایگزین این است که می‌توانید فضای مورد نیاز خود را با جعبه های نسبت CSS ذخیره کنید. این روش تضمین می کند که مرورگر می‌تواند مقدار صحیح فضا را هنگام بارگیری تصویر اختصاص دهد.

تاریخچه:

در سال‌های ابتدایی گسترش وب، توسعه‌دهندگان ویژگی‌های عرض و ارتفاع را به برچسب <img> خود اضافه می‌کردند تا اطمینان حاصل کنند که فضای کافی در صفحه قبل از شروع مرورگر برای نمایش تصاویر اختصاص داده شده است. این باعث میشد که جریان و تغییر چیدمان مجدد به حداقل برسد.

1
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons" />

ممکن است متوجه شده باشید که عرض و ارتفاع بالا شامل واحد نمی شوند. این ابعاد “پیکسل” باعث می شوند یک منطقه 640×360 رزرو شود. تصویر متناسب با این فضا صرف نظر از اینکه ابعاد واقعی با هم مطابقت دارند یا نه، کشیده خواهد شد.

با طراحی رسپانسیو وب، توسعه‌دهندگان شروع به حذف عرض و ارتفاع کردند به استفاده از CSS برای تغییر اندازه تصاویر رو آوردند:

1
2
3
img {
  width: 100%; /* or max-width: 100%; */
  height: auto;

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

اینجا بود که نسبت ابعاد وارد شدند. نسبت ابعاد تصویر نسبت عرض به ارتفاع آن است. معمولا این نسبت را به صورت دو عدد که با دو نقطه از هم جدا شده اند مشاهده می‌کنید (به عنوان مثال 16: 9 یا 4: 3). برای نسبت ابعاد x: y، تصویر x واحد عرض و y واحد ارتفاع است.

این بدان معناست که اگر یکی از ابعاد را بدانیم، می‌توان بعد دیگر را نیز تعیین کرد. دانستن نسبت ابعاد به مرورگر این امکان را می‌دهد تا فضای کافی برای ارتفاع و مساحت مربوطه را محاسبه و ذخیره کند.

بهترین و مدرن‌ترین روش

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

1
2
<!-- set a 640:360 i.e a 16:9 - aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons" />

… و همه مرورگرها نسبت ابعادی پیش‌فرض را بر اساس ویژگی‌های عرض و ارتفاع موجود اضافه می‌کنند:

1
2
3
img {
  aspect-ratio: attr(width) / attr(height);
}

این نسبت ابعاد را بر اساس ویژگی‌های عرض و ارتفاع قبل از بارگیری تصویر محاسبه می‌کند. این اطلاعات را در ابتدای محاسبه طرح ارائه می دهد. به محض اینکه گفته می‌شود یک عکس عرض مشخصی دارد (به عنوان مثال عرض: 100٪)، از نسبت ابعاد برای محاسبه ارتفاع استفاده می‌شود.

اگر تصویر شما در یک کانتینر است، می‌توانید با استفاده از CSS اندازه تصویر را به عرض این کانتینر تغییر دهید و ارتفاع به صورت خودکار تنظیم می‌شود، این کار برای جلوگیری از ثابت بودن ارتفاع تصویر (به عنوان مثال 360 پیکسل) اتفاق می‌افتد.

1
2
3
4
img {
  height: auto;
  width: 100%;
}

اما چه اتفاقی برای عکس‌های رسپانسیو می‌افتد؟

هنگام کار با تصاویر رسپانسیو، با ویژگی srcset به مرورگر اجازه می دهید بین عکس‌ها و اندازه‌ آن‌ها انتخاب کند. برای اطمینان از تنظیم ویژگی‌های عرض و ارتفاع، هر تصویر باید از همان نسبت تصویر استفاده کند.

1
2
3
4
5
6
7
<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

تبلیغات، جاسازی‌ها و فریم‌های بدون ابعاد
آگهی‌ها

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

در طول چرخه حیات تبلیغات، بسیاری از عوامل می‌توانند باعث تغییر چیدمان شوند:

  • وقتی سایتی کانتینر تبلیغ را در DOM وارد می‌کند.
  • وقتی سایز تبلیغات را با کد اولیه تغییر اندازه می‌دهد.
  • هنگامی که کتابخانه برچسب تبلیغات بارگیری می شود (و کانتینر تبلیغ را تغییر می‌دهد).
  • هنگامی که آگهی یک کانتینر را پر می کند (و اگر آگهی نهایی دارای اندازه دیگری باشد اندازه آن تغییر می‌کند).

خبر خوب این است که این امکان وجود دارد که سایت‌ها بهترین روش‌ها را برای کاهش تغییرات چیدمانی تبلیغات دنبال کنند. سایت‌ها می‌توانند این تغییرات چیدمان را با استفاده از موارد زیر کاهش دهند:

  • از نظر آماری فضا را برای فضای تبلیغات حفظ کنید.

    • به عبارت دیگر، قبل از بارگذاری کتابخانه برچسب تبلیغ، استایل عنصر را مشخص کنید.

    • اگر تبلیغات را در جریان محتوا قرار می‌دهید، اطمینان حاصل کنید که با ذخیره اندازه فضا، شیفت‌ها از بین می‌روند. در صورت بارگیری در خارج از صفحه، این تبلیغات نباید باعث تغییر طرح شوند.

  • هنگام قرار دادن تبلیغات غیرچسبنده در بالای viewport دقت کنید.

  • اگر در هنگام مشاهده فضای تبلیغات با نمایش یک place holder، هیچ آگهی نمایش داده نشود از حذف فضای ذخیره شده خودداری کنید.

  • با حفظ بیشترین اندازه ممکن برای فضای تبلیغات، شیفت‌ها را حذف کنید.

  • براساس داده‌های تاریخی، محتمل‌ترین اندازه را برای فضای تبلیغات انتخاب کنید.

​Embeds and iframes

ابزارک های قابل‌جاسازی به شما امکان می‌دهند محتوای قابل حمل (portable) وب را در صفحه خود جاسازی کنید (به عنوان مثال فیلم از YouTube، نقشه‌های Google Maps ، پست‌های رسانه‌های اجتماعی و غیره). این جاسازی‌ها می‌توانند انواع مختلفی داشته باشند:

  • فال‌بک HTML و یک برچسب جاوا اسکریپت.

  • قطعه درون خطی HTML.

  • iframe تعبیه شده.

این جاسازی ها اغلب از میزان بزرگ بودن جاسازی اطلاع ندارند (به عنوان مثال، در مورد یک پست در شبکه های اجتماعی – آیا این یک تصویر جاسازی شده دارد؟ فیلم؟ چندین ردیف متن؟). در نتیجه، پلتفرم‌هایی که این جاسازی‌ها را ارائه می‌دهند همیشه فضای کافی را در نظر نمی‌گیرند و همین مساله می‌تواند باعث تغییر چیدمان در هنگام بارگیری شود.

برای حل این مسئله، می توانید CLS را با پیش محاسبه فضای کافی برای جاسازی با یک مکان ذخیره یا جایگزین به حداقل برسانید و باعث بهینه‌سازی معیار تغییر تجمعی چیدمان (CLS) شوید:

  • با ابزار بازرسی (inspecting) از طریق ابزارهای توسعه دهنده مرورگر، ارتفاع جاسازی نهایی خود را بدست آورید.

  • پس از بارگیری جاسازی، iframe موجود تغییر اندازه داده و متناسب می شود.

محتوای پویا

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

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

  • “در خبرنامه ما ثبت نام کنید!”.

  • “مطالب مرتبط“.

  • “برنامه [آی او اس / اندروید] ما را نصب کنید“.

  • “ما هنوز سفارش می‌گیریم“.

  • “اعلامیه GDPR”.

اگر نیاز به نمایش این نوع پیام‌ها در رابط کاربری دارید، از قبل فضای کافی برای نمایش، حفظ کنید تا هنگام بارگیری، باعث تغییر چیدمان در صفحه نشود.

​Web fonts causing FOUT/FOIT

بارگیری و نمایش فونت‌های وب می‌تواند باعث تغییر طرح‌بندی به دو روش شود:

  • فونت جایگزین با یک فونت جدید عوض می‌شود (FOUT).

  • متن “نامرئی” نمایش داده می‌شود تا زمانی که قلم جدید نمایش داده شود (FOIT).

ابزارهای زیر می‌توانند در به حداقل رساندن این مورد و بهینه‌سازی معیار تغییر تجمعی چیدمان (CLS) به شما کمک کنند:

  • font-display به شما امکان می‌دهد رفتار رندر فونت‌های سفارشی را با مقادیری مانند auto، swap، block ، fallback و optional
         تغییر دهید. متأسفانه، همه این مقادیر (به استثنای اختیاری) می توانند به یکی از روش های فوق باعث طرح بندی مجدد شوند.

  • Font Loading API می تواند زمان لازم برای دریافت فونت های لازم را کاهش دهد.

منبع:

https://web.dev/optimize-cls/

ادامه مطلب
18اردیبهشت

معیارهای Core Web Vitals

اردیبهشت 18, 1400 نویسنده آوین آویسا سئو

بهینه سازی برای کیفیت تجربه کاربری رمز موفقیت ماندگار هر وب‌سایتی است. اطلاعات و آمار خواه کارآفرین، بازاریاب یا توسعه‌دهنده باشید معیارهای Core Web Vitals می‌تواند به شما کمک کند تا تجربه کاربری سایت خود را قابل اندازه‌گیری کنید و فرصت‌های بهبود را شناسایی کنید.

بیان مساله

Web Vital ابتکاری از طرف Google برای ارائه راهنمایی واحد برای شاخص‌های کیفی است که برای ارائه یک تجربه کاربری عالی در وب‌سایت ضروری می‌باشند.

گوگل در طی سال های گذشته ابزارهای مختلفی را برای اندازه‌گیری و گزارش عملکرد ارائه کرده است. برخی از توسعه‌دهندگان در استفاده از این ابزارها متخصص هستند، در حالی که برخی دیگر، هم ابزار و هم معیارها را برای ادامه کار چالش‌برانگیز دانسته‌اند.

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

Core Web Vitals

معیارهای Core Web Vitals زیرمجموعه Web Vital است که در همه صفحات وب اعمال می‌شود به طوری که باید توسط همه دارندگان سایت اندازه گیری شود و در تمام ابزارهای Google ظاهر می شود. هر یک از Core Web Vital ها وجه متمایزی از تجربه کاربر را نشان می دهند و منعکس کننده یک خروجی مهم با محوریت کاربر است.

معیارهای تشکیل دهنده Core Web Vital با گذشت زمان تکامل یافته‌اند و در ادامه هم تکامل خواهند یافت. مجموعه فعلی برای سال ۲۰۲۰ بر سه جنبه از تجربه کاربر متمرکز است – بارگذاری، تعامل و ثبات بصری – و شامل معیارهای زیر (و آستانه‌های مربوط به آن‌ها) است:

Largest Contentful Paint (LCP): این شاخص بارگیری را اندازه‌گیری می‌کند. برای ایجاد یک تجربه کاربری مناسب، LCP باید کمتر از ۲.۵ ثانیه از شروع بارگیری صفحه رخ دهد

First Input Delay (FID): این شاخص تعامل را اندازه‌گیری می‌کند. برای ایجاد یک تجربه کاربری مناسب، این شاخص در صفحات باید ۱۰۰ میلی ثانیه یا کمتر باشد.

Cumulative Layout Shift (CLS): ثبات بصری را اندازه‌گیری می‌کند. برای ایجاد یک تجربه کاربری مناسب، این شاخص در صفحات باید ۰.۱ یا کمتر باشد.

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

ابزاری که Core Web Vital را محاسبه می‌کنند، صفحه‌ای را مناسب تشخیص خواهند داد که در ۷۵ درصد بازدیدها، امتیاز لازم در ۳ شاخص مذکور را کسب کند.

ابزار اندازه‌گیری و گزارش‌دهی در مورد Core Web Vital

گوگل معتقد است که معیارهای Core Web Vitals برای تجربه کاربری وب بسیار مهم است. بنابراین ، خود را متعهد می‌داند که ابزارهایی مناسب برای اندازه‌گیری این شاخص‌ها معرفی کند. در ادامه جزئیات ابزارهای پشتیبانی از Core Web Vital را شرح داده می‌شود.

ابزار عملیاتی برای اندازه‌گیری Core Web Vitalها

Chrome User Experience Report داده‌های اندازه‌گیری کاربر واقعی و ناشناس را برای هر Core Web Vital جمع‌آوری می‌کند. این داده‌ها صاحبان سایت را قادر می‌سازند تا به سرعت عملکرد خود را ارزیابی کنند بدون اینکه لازم باشد به صورت دستی تجزیه و تحلیل نمایند و از ابزارهایی مانند PageSpeed Insights و گزارش Core Web Vital Search Console استفاده کنند.

داده های ارائه شده توسط Chrome User Experience Report راهی سریع برای ارزیابی عملکرد سایت‌ها ارائه می‌دهد، اما اندازه‌گیری باجزییات در هر صفحه را که اغلب برای تشخیص دقیق ، نظارت و واکنش سریع ضروری است، ارائه نمی‌دهد. در نتیجه ، اکیداً توصیه می‌شود سایت‌ها نظارت شخصی و انسانی خود را حفظ کنند.

اندازه‌گیری Core Web Vitals با استفاده از جاوااسکریپت

هر یک از معیارهای Core Web Vitals ها با استفاده از API های استاندارد وب در جاوااسکریپت قابل اندازه‌گیری هستند. ساده‌ترین راه برای اندازه‌گیری همه Core Web Vitalها استفاده از کتابخانه جاواسکریپت web-vitals است، یک بسته کوچک و آماده که هر یک از متریک‌ها را به گونه‌ای اندازه‌گیری می‌کند که مطابق با نحوه گزارش‌دهی توسط همه ابزارهای Google که قبلاً به آن‌ها اشاره شد، می‌باشند

با استفاده از کتابخانه web-vitals ، اندازه‌گیری هر معیار به سادگی فراخوانی یک تابع است (برای کسب جزییات بیشتر به اینجا مراجعه کنید):

1
2
3
4
5
6
7
8
9
10
11
12
import {getCLS, getFID, getLCP} from 'web-vitals';
 
function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}
 
getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);

 

هنگامی که از کتابخانه vitals برای اندازه‌گیری و ارسال داده‌های Core Web Vital به اند پوینت(end point) تجزیه و تحلیل استفاده می‌کنید، گام بعدی جمع‌آوری و گزارش در مورد آن داده‌ها است تا ببینید آیا صفحات شما آستانه‌های پیشنهادی را در ۷۵ درصد بازدیدها از صفحات را برآورده می‌کنند.

همچنین می‌توانید بدون نوشتن کدی با استفاده از افزونه Chrome Vension Web Vital در مورد هر یک از Core Web Vitalها گزارش بگیرید. این برنامه افزودنی از کتابخانه web-vitals برای اندازه‌گیری هر یک از این معیارها و نمایش آن‌ها به کاربران هنگام مرور وب استفاده می‌کند. این افزونه برای درک وضعیت سایت شما، سایت‌های رقبای شما و به طور کلی وب بسیار مفید است.

ابزار آزمایشگاهی برای اندازه‌گیری Core Web Vitalها

در حالی که همه Core Web Vitalها، در درجه اول، معیارهای عملیاتی وب هستند، اما بسیاری از آن‌ها در آزمایشگاه نیز قابل اندازه‌گیری هستند. اندازه‌گیری آزمایشگاه بهترین روش برای آزمایش عملکرد ویژگی‌ها در حین توسعه است – قبل از اینکه این ویژگی‌ها برای کاربران منتشر شود. همچنین بهترین روش برای گرفتن رگرسیون عملکرد قبل از وقوع است.

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

عملکرد یک سایت می‌تواند بر اساس قابلیت‌های دستگاه کاربر، شرایط شبکه وی، سایر فرایندهایی که روی دستگاه در حال اجرا هستند و نحوه تعامل آن‌ها با صفحه، تفاوت چشمگیری داشته باشد. در واقع، امتیاز هر یک از معیارهای Core Web Vital می‌توانند تحت تأثیر تعامل کاربر قرار گیرند. فقط اندازه‌گیری عملیاتی می‌تواند تصویر کامل را با دقت ارائه دهد.

بهینه‌سازی Core Web Vitals برای آشنایی با نحوه بهینه‌سازی هر یک از معیارها می‌توانید به مقالات زیر مراجعه نمایید:

بهینه‌سازی معیار تغییر تجمعی چیدمان (CLS)

بهینه‌سازی معیار بزرگترین عنصر محتوا (LCP)

بهینه‌سازی معیار تاخیر ورودی اول (FID)

Web Vitalsهای دیگر

در حالی که Core Web Vital معیارهای اساسی برای درک و ارائه یک تجربه کاربری عالی هستند، معیارهای حیاتی دیگری نیز وجود دارد. این سایر Web Vitalها غالباً به عنوان معیارهای مکمل Core Web Vitalها به شما کمک می‌کنند تا قسمت بیشتری از تجربه را در نظر بگیرید یا به تشخیص مسئله خاصی کمک کنید.

به عنوان مثال ، معیارهای Time to First Byte (TTFB) و First Contentful Paint (FCP) هر دو جنبه حیاتی تجربه بارگیری هستند و هر دو در تشخیص مسائل مرتبط با LCP (به ترتیب، پاسخ‌دهی کند سرور و منابع بلاک‌کننده) مفید هستند.

به طور مشابه ، معیارهایی مانند Total Blocking Time (TBT) و Time to Interactive (TTI) معیارهای آزمایشگاهی هستند که برای تشخیص مسائل تعاملی که بر FID تأثیر می گذارند بسیار مهم هستند. با این حال، آن‌ها بخشی از مجموعه Core Web Vital نیستند زیرا قابل اندازه‌گیری نیستند، و همچنین نتیجه‌ای بر اساس کاربر را نشان نمی دهند.

تکامل Web Vitals

Web Vital و Core Web Vital نشان دهنده بهترین شاخص‌های موجود است که امروزه توسعه‌دهندگان برای سنجش کیفیت تجربه در وب دارند، اما این شاخص‌ها کامل نیستند و باید انتظار بهبود یا اضافه شدن آنها در آینده را داشت.

Core Web Vital مربوط به همه صفحات وب است و در ابزارهای مرتبط Google نمایش داده می شود. تغییر در این معیارها تأثیرات گسترده‌ای خواهد داشت. به همین دلیل، توسعه‌دهندگان انتظار دارند که تعاریف و آستانه های Core Web Vital پایدار باشند، و در زمان مناسبی از به‌روزرسانی‌ها اطلاع پیدا کنند.

سایر Web Vitalها غالباً مختص به زمینه یا ابزار خاص هستند و ممکن است تجربی تر از Core Web Vitalها باشند. به همین دلیل، ممکن است تعاریف و آستانه‌های آن‌ها با فرکانس بیشتری تغییر کند.

برای همه Web Vitalها، تغییرات به طور دقیق در اینجا بیان می‌شوند.

 

منبع:

https://web.dev/vitals/

ادامه مطلب