توصیه‌های برتر Core Web Vitals ما برای سال 2023

مجموعه‌ای از بهترین روش‌ها که تیم توسعه دهنده کروم معتقد است مؤثرترین راه‌ها برای بهبود عملکرد Core Web Vitals در سال 2023 است.

برندن کنی
Brendan Kenny
X GitHub
جرمی واگنر
فیلیپ والتون
ریک ویسکومی
بری پولارد

در طول سال‌ها، ما در Google توصیه‌های زیادی به توسعه‌دهندگان وب در مورد چگونگی بهبود عملکرد ارائه کرده‌ایم.

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

مگر اینکه عملکرد وب کار روزانه شما باشد، احتمالاً مشخص نیست که کدام توصیه ها بیشترین تأثیر مثبت را روی سایت شما خواهند داشت. به عنوان مثال، ممکن است خوانده باشید که پیاده سازی CSS حیاتی می تواند عملکرد بارگذاری را بهبود بخشد، و همچنین ممکن است شنیده باشید که بهینه سازی تصاویر شما مهم است. اما، اگر وقت ندارید روی هر دو مورد کار کنید، چگونه تصمیم می گیرید کدام یک را انتخاب کنید؟

در تیم Chrome، سال گذشته را صرف پاسخ دادن به این سؤال کرده‌ایم: مهم‌ترین توصیه‌هایی که می‌توانیم به توسعه‌دهندگان بدهیم تا به آنها در بهبود عملکرد کاربرانشان کمک کنیم چیست؟

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

به طور خلاصه، ما می‌خواستیم لیستی از بهترین توصیه‌های عملکرد وب روی آنها تمرکز کند:

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

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

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

بزرگترین رنگ محتوایی (LCP)

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

اطمینان حاصل کنید که منبع LCP از منبع HTML قابل کشف است

طبق بایگانی HTTP Web Almanac 2022 ، 72 درصد از صفحات تلفن همراه دارای یک تصویر به عنوان عنصر LCP خود هستند، به این معنی که برای اکثر سایت ها برای بهینه سازی LCP خود، باید اطمینان حاصل کنند که این تصاویر می توانند به سرعت بارگذاری شوند.

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

در واقع، از صفحاتی که عنصر LCP یک تصویر بود، 39٪ از آن تصاویر دارای URL های منبع بودند که از منبع سند HTML قابل کشف نبودند. به عبارت دیگر، آن URL ها در ویژگی های استاندارد HTML (مانند <img src="..."> یا <link rel="preload" href="..."> یافت نشدند، که به مرورگر اجازه می دهد به سرعت آنها را کشف کنید و بلافاصله شروع به بارگیری آنها کنید.

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

به عنوان یک قاعده کلی، اگر عنصر LCP شما یک تصویر است، URL تصویر همیشه باید از منبع HTML قابل کشف باشد. چند نکته برای امکان پذیر کردن آن عبارتند از:

  • تصویر را با استفاده از عنصر <img> با ویژگی src یا srcset بارگیری کنید. از ویژگی های غیر استاندارد مانند data-src که برای رندر کردن به جاوا اسکریپت نیاز دارند استفاده نکنید، زیرا همیشه کندتر خواهد بود. 9٪ از صفحات تصویر LCP خود را در پشت data-src پنهان می کنند.

  • رندر سمت سرور (SSR) را به رندر سمت سرویس گیرنده (CSR) ترجیح دهید، زیرا SSR نشان می دهد که نشانه گذاری کامل صفحه (از جمله تصویر) در منبع HTML وجود دارد. راه حل های CSR برای اجرا قبل از کشف تصویر به جاوا اسکریپت نیاز دارند.

  • اگر تصویر شما نیاز به ارجاع از یک فایل CSS یا JS خارجی دارد، همچنان می توانید آن را از طریق تگ <link rel="preload"> در منبع HTML قرار دهید. توجه داشته باشید که تصاویر ارجاع شده توسط سبک های درون خطی توسط اسکنر پیش بارگیری مرورگر قابل کشف نیستند، بنابراین حتی اگر در منبع HTML یافت می شوند، ممکن است کشف آنها همچنان در بارگذاری منابع دیگر مسدود شود، بنابراین بارگذاری اولیه می تواند در این موارد کمک کند.

برای کمک به درک اینکه آیا تصویر LCP شما دارای مشکلات قابل کشف است، لایت‌هاوس یک ممیزی جدید در نسخه 10.0 منتشر می‌کند (انتظار می‌شود ژانویه 2023).

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

اطمینان حاصل کنید که منبع LCP اولویت بندی شده است

اطمینان از اینکه منبع LCP را می توان از منبع HTML کشف کرد، اولین گام حیاتی برای اطمینان از اینکه منبع LCP می تواند زود بارگذاری شود، است، اما گام مهم دیگر اطمینان از اینکه بارگذاری آن منبع در اولویت قرار دارد و پشت یک دسته قرار نمی گیرد، است. سایر منابع کم اهمیت تر

به عنوان مثال، حتی اگر تصویر LCP شما در منبع HTML با استفاده از یک تگ استاندارد <img> وجود داشته باشد، اگر صفحه شما قبل از آن تگ <img> دارای دوازده تگ <script> در <head> سند شما باشد، ممکن است مدتی قبل از اینکه منبع تصویر شما بارگیری شود.

ساده ترین راه برای حل این مشکل این است که با تنظیم ویژگی جدید fetchpriority="high" در تگ <img> یا <link> که تصویر LCP شما را بارگیری می کند، به مرورگر اشاره ای در مورد منابعی که بالاترین اولویت را دارند ارائه دهید. این به مرورگر دستور می دهد تا آن را زودتر بارگذاری کند، نه اینکه منتظر تکمیل آن اسکریپت ها باشد.

طبق وب سالنامه، تنها 0.03٪ از صفحات واجد شرایط از این API جدید استفاده می کنند، به این معنی که فرصت زیادی برای اکثر سایت های روی وب وجود دارد تا LCP را با کار بسیار کمی بهبود بخشند. در حالی که ویژگی fetchpriority در حال حاضر فقط در مرورگرهای مبتنی بر Chromium پشتیبانی می‌شود، این API یک پیشرفت پیشرونده است که سایر مرورگرها آن را نادیده می‌گیرند، بنابراین ما قویاً به توسعه‌دهندگان توصیه می‌کنیم هم اکنون از آن استفاده کنند.

برای مرورگرهای غیر Chromium، تنها راه برای اطمینان از اولویت‌بندی منبع LCP بالاتر از سایر منابع، ارجاع به آن در ابتدا در سند است. با استفاده مجدد از مثال سایتی با تعداد زیادی تگ <script> در <head> سند، اگر می‌خواهید مطمئن شوید که منبع LCP شما قبل از آن منابع اسکریپت اولویت دارد، می‌توانید یک <link rel="preload"> اضافه کنید. <link rel="preload"> قبل از هر یک از آن اسکریپت ها تگ کنید، یا می توانید آن اسکریپت ها را به زیر <img> بعداً در <body> منتقل کنید. در حالی که این کار می کند، ارگونومیک کمتری نسبت به استفاده از fetchpriority دارد، بنابراین امیدواریم مرورگرهای دیگر به زودی پشتیبانی اضافه کنند.

یکی دیگر از جنبه‌های مهم اولویت‌بندی منبع LCP این است که اطمینان حاصل کنید که کاری انجام نمی‌دهید که باعث از بین رفتن اولویت شود، مانند افزودن ویژگی loading="lazy" . امروزه، 10٪ از صفحات در واقع loading="lazy" روی تصویر LCP خود تنظیم می کنند. مراقب راه‌حل‌های بهینه‌سازی تصویر باشید که رفتار بارگذاری تنبلی را به‌طور بی‌توجهی روی همه تصاویر اعمال می‌کنند. اگر آنها راهی برای نادیده گرفتن این رفتار ارائه می دهند، حتماً از آن برای تصویر LCP استفاده کنید. اگر مطمئن نیستید که کدام تصویر LCP خواهد بود، سعی کنید از روش های اکتشافی برای انتخاب یک نامزد معقول استفاده کنید.

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

به طور خلاصه، باید این بهترین شیوه‌ها را دنبال کنید تا اطمینان حاصل کنید که منبع LCP زودهنگام و با اولویت بالا بارگیری می‌شود:

  • fetchpriority="high" را به تگ <img> تصویر LCP خود اضافه کنید. اگر منبع LCP از طریق تگ <link rel="preload"> بارگیری می شود، نترسید زیرا می توانید fetchpriority="high" نیز روی آن تنظیم کنید!
  • هرگز loading="lazy" را روی تگ <img> تصویر LCP خود تنظیم نکنید. انجام این کار تصویر شما را از اولویت خارج می کند و زمان بارگذاری آن را به تاخیر می اندازد.
  • منابع غیر حیاتی را در صورت امکان به تعویق بیندازید. یا با انتقال آنها به انتهای سند خود، استفاده از بارگذاری تنبل بومی برای تصاویر یا iframe ، یا بارگیری آنها به صورت ناهمزمان از طریق جاوا اسکریپت.

از CDN برای بهینه سازی TTFB سند و منبع استفاده کنید

دو توصیه قبلی بر این تمرکز داشت که مطمئن شوید منبع LCP شما زودهنگام کشف شده و اولویت بندی شده است تا بتواند بلافاصله بارگیری را شروع کند. قطعه نهایی این پازل این است که مطمئن شوید که پاسخ سند اولیه در سریع ترین زمان ممکن نیز می رسد.

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

این زمان به عنوان Time to First Byte (TTFB) شناخته می شود و بهترین راه برای کاهش TTFB این است:

  • محتوای خود را تا حد امکان از نظر جغرافیایی نزدیک به کاربران خود ارائه دهید
  • محتوایی که اخیراً درخواست شده است را در حافظه پنهان ذخیره کنید، می‌توانید دوباره به سرعت ارائه شود.

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

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

بر اساس وب سالنامه، تنها 29 درصد از درخواست های سند HTML از یک CDN ارائه شده است، که به این معنی است که فرصت قابل توجهی برای سایت ها وجود دارد که صرفه جویی بیشتری را درخواست کنند.

برخی از نکات برای پیکربندی CDN ها عبارتند از:

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

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

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

مجموعه بعدی توصیه ها برای تغییر چیدمان تجمعی (CLS) است که معیاری برای ثبات بصری در صفحات وب است. در حالی که CLS از سال 2020 در وب بسیار بهبود یافته است، حدود یک چهارم وب سایت ها هنوز آستانه توصیه شده را برآورده نمی کنند، بنابراین فرصت بزرگی برای بسیاری از سایت ها وجود دارد تا تجربه کاربری خود را بهبود بخشند.

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

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

ساده‌ترین راه برای رفع تغییرات طرح‌بندی ناشی از تصاویر بدون اندازه، تنظیم صریح ویژگی‌های width و height (یا ویژگی‌های CSS معادل) است. با این حال، طبق بایگانی HTTP، 72٪ از صفحات حداقل یک تصویر بدون اندازه دارند. بدون اندازه صریح، مرورگرها در ابتدا ارتفاع پیش‌فرض 0px را تعیین می‌کنند و ممکن است زمانی که تصویر در نهایت بارگیری می‌شود و ابعاد آن کشف می‌شود، تغییر طرح‌بندی محسوسی ایجاد کند. این یک فرصت بزرگ برای وب جمعی است - و این فرصت به تلاش بسیار کمتری نسبت به سایر توصیه‌های پیشنهاد شده در این مقاله نیاز دارد.

همچنین مهم است که به خاطر داشته باشید که تصاویر تنها مشارکت کنندگان در CLS نیستند. تغییرات طرح‌بندی ممکن است ناشی از محتوای دیگری باشد که معمولاً پس از ارائه اولیه صفحه بارگیری می‌شود، از جمله تبلیغات شخص ثالث یا ویدیوهای جاسازی شده. ویژگی aspect-ratio می تواند به مبارزه با این موضوع کمک کند. این یک ویژگی نسبتاً جدید CSS است که به توسعه دهندگان این امکان را می دهد که صریحاً نسبت ابعاد به تصاویر و همچنین عناصر غیر تصویری را ارائه دهند. این به شما این امکان را می‌دهد که یک width پویا (مثلاً بر اساس اندازه صفحه) تنظیم کنید، و مرورگر به طور خودکار ارتفاع مناسب را محاسبه کند، تقریباً به همان روشی که برای تصاویر با ابعاد انجام می‌دهد.

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

اطمینان حاصل کنید که صفحات برای bfcache واجد شرایط هستند

مرورگرها از مکانیزم ناوبری به نام حافظه پنهان عقب/ جلو - یا به اختصار bfcache - استفاده می کنند تا فوراً یک صفحه از قبل یا بعد در تاریخچه مرورگر را مستقیماً از یک عکس فوری بارگیری کنند.

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

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

صاحبان سایت باید بررسی کنند که صفحات آنها برای bfcache واجد شرایط هستند و به هر دلیلی که این کار را نمی کنند کار کنند. Chrome قبلاً یک آزمایش‌کننده bfcache در DevTools دارد و امسال ما قصد داریم ابزارسازی را در اینجا با ممیزی Lighthouse جدید که آزمایش مشابهی را انجام می‌دهد و یک API برای اندازه‌گیری آن در این زمینه تقویت کنیم.

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

از انیمیشن‌ها/انتقال‌هایی که از ویژگی‌های CSS القاکننده طرح‌بندی استفاده می‌کنند اجتناب کنید

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

در حالی که داده‌های بایگانی HTTP نمی‌توانند به طور قطعی انیمیشن‌ها را به تغییرات طرح‌بندی متصل کنند، داده‌ها نشان می‌دهند که صفحاتی که هر ویژگی CSS را متحرک می‌کنند که می‌تواند روی طرح‌بندی تأثیر بگذارد، 15 درصد کمتر از صفحات کلی CLS «خوب» دارند. برخی از خواص با CLS بدتر از سایرین مرتبط هستند. برای مثال، صفحاتی که پهنای margin یا border متحرک می‌کنند، دارای CLS ضعیف هستند، تقریباً دو برابر نرخی که صفحات در کل ضعیف ارزیابی می‌شوند.

این شاید تعجب آور نباشد، زیرا هر زمان که هر ویژگی CSS القاکننده طرح‌بندی را تغییر دهید یا متحرک کنید، منجر به تغییرات طرح‌بندی می‌شود و اگر این تغییرات طرح‌بندی در 500 میلی‌ثانیه از تعامل کاربر نباشد، بر CLS تأثیر می‌گذارد.

چیزی که ممکن است برای برخی از توسعه دهندگان تعجب آور باشد این است که این موضوع حتی در مواردی که عنصر خارج از جریان عادی سند گرفته می شود نیز صادق است. به عنوان مثال، عناصر کاملاً قرار گرفته که top یا left متحرک می‌شوند، حتی اگر محتوای دیگر را به اطراف منتقل نکنند، باعث تغییر چیدمان می‌شوند. با این حال، اگر به جای متحرک کردن top یا left ، transform:translateX() یا transform:translateY() را متحرک کنید، باعث به‌روزرسانی طرح‌بندی صفحه توسط مرورگر نمی‌شود و بنابراین هیچ تغییری در طرح‌بندی ایجاد نمی‌کند.

ترجیح دادن انیمیشن از ویژگی‌های CSS که می‌توانند در رشته ترکیب‌کننده مرورگر به‌روزرسانی شوند، مدت‌ها بهترین عملکرد بوده است، زیرا این کار را روی GPU و خارج از رشته اصلی منتقل می‌کند. و علاوه بر اینکه بهترین عملکرد عمومی است، می تواند به بهبود CLS نیز کمک کند.

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

ممیزی Lighthouse Avoid non-composited animations هشدار می دهد که صفحه ای ویژگی های بالقوه کند CSS را متحرک کند.

تاخیر ورودی اول (FID)

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

معیار جدید تعامل با رنگ بعدی (INP) جانشین احتمالی FID است و همه توصیه‌های زیر برای FID و INP به خوبی اعمال می‌شوند. با توجه به اینکه سایت‌ها در INP نسبت به FID عملکرد بدتری دارند ، به‌ویژه در تلفن همراه، ما توسعه‌دهندگان را تشویق می‌کنیم تا با وجود داشتن FID «خوب»، این توصیه‌های پاسخ‌گویی را جدی بگیرند.

از کارهای طولانی اجتناب کنید یا آن ها را کنار بگذارید

Tasks هر قطعه ای از کار مجزا است که مرورگر انجام می دهد. وظایف شامل رندر، چیدمان، تجزیه و کامپایل و اجرای اسکریپت ها است. هنگامی که وظایف به وظایف طولانی تبدیل می شوند - یعنی 50 میلی ثانیه یا بیشتر - مانع از پاسخگویی سریع به ورودی های کاربر توسط رشته اصلی می شوند.

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

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

گزینه دیگر استفاده از APIهایی مانند isInputPending و Scheduler API است. isInputPending تابعی است که یک مقدار بولی را برمی‌گرداند که نشان می‌دهد ورودی کاربر در حال تعلیق است یا خیر. اگر true را برگرداند، می توانید به رشته اصلی تسلیم شوید تا بتواند ورودی های معلق کاربر را مدیریت کند.

Scheduler API یک رویکرد پیشرفته‌تر است که به شما امکان می‌دهد کار را بر اساس سیستمی از اولویت‌ها برنامه‌ریزی کنید که این را در نظر می‌گیرد که آیا کار انجام شده برای کاربر قابل مشاهده است یا پس‌زمینه.

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

از جاوا اسکریپت غیر ضروری خودداری کنید

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

با این حال، این یک مشکل غیر قابل حل نیست. شما چند گزینه دارید:

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

از به‌روزرسانی‌های رندر بزرگ خودداری کنید

جاوا اسکریپت تنها چیزی نیست که می تواند بر روی پاسخگویی وب سایت شما تأثیر بگذارد. رندر می تواند به خودی خود یک نوع کار گران قیمت باشد – و هنگامی که به روز رسانی های رندر بزرگ اتفاق می افتد، می توانند در توانایی وب سایت شما برای پاسخ دادن به ورودی های کاربر اختلال ایجاد کنند.

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

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

نتیجه

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

در حالی که توصیه‌های فهرست‌شده در اینجا به هیچ وجه جامع نیستند، ما معتقدیم - بر اساس تجزیه و تحلیل دقیق وضعیت وب - که این توصیه‌ها مؤثرترین راه‌هایی هستند که سایت‌ها می‌توانند عملکرد Core Web Vitals خود را در سال 2023 بهبود بخشند.

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

در اینجا یک سال جدید است، و یک وب سریعتر برای همه! باشد که سایت های شما از همه راه هایی که بیشترین اهمیت را دارد برای کاربران شما سریع باشد.

عکس از Devin Avery