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

FID

خانه / صفحه وبلاگ / FID
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/

ادامه مطلب
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/

ادامه مطلب