موثرترین راه ها برای بهبود Core Web Vitals,موثرترین راه ها برای بهبود Core Web Vitals

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

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

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

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

روی هم، اینها واقع بینانه ترین و تاثیرگذارترین راه هایی هستند که می توانید معیارهای Core Web Vitals خود را بهبود ببخشید. اگر با عملکرد وب تازه کار هستید - یا اگر هنوز تصمیم می گیرید چه چیزی بیشترین بازده سرمایه را به شما می دهد - این بهترین مکان برای شروع است.

تعامل با رنگ بعدی (INP)

به عنوان جدیدترین معیار Core Web Vital، Interaction to Next Paint (INP) برخی از بزرگترین فرصت‌ها را برای بهبود دارد. با این حال، از آنجایی که تعداد سایت‌های کمتری در مقایسه با نسخه قبلی خود از آستانه تجربه‌های «خوب» عبور می‌کنند، ممکن است شما در میان بسیاری از توسعه‌دهندگان باشید که برای اولین بار نحوه بهینه‌سازی پاسخ‌گویی تعامل را یاد می‌گیرند. برای موثرترین راه‌ها برای بهبود INP، با این تکنیک‌های ضروری شروع کنید.

1. اغلب برای از بین بردن کارهای طولانی تسلیم شوید

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

پشتیبانی مرورگر

  • کروم: 129.
  • لبه: 129.
  • فایرفاکس: پشتیبانی نمی شود.
  • سافاری: پشتیبانی نمی شود.

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

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

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

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

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

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

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

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

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

بهینه سازی کار رندر فرآیند ساده ای نیست و بستگی به هدف شما دارد. با این وجود، در اینجا چند کار وجود دارد که می توانید انجام دهید تا مطمئن شوید که رندر وظایف به کارهای طولانی تبدیل نمی شوند:

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

بزرگترین رنگ محتوایی (LCP) هسته حیاتی وب است که توسعه دهندگان بیشتر با آن مشکل دارند— 40٪ از سایت ها در گزارش Chrome UX آستانه LCP توصیه شده برای تجربه کاربری خوب را برآورده نمی کنند. تیم Chrome تکنیک‌های زیر را به‌عنوان مؤثرترین راه‌ها برای بهبود LCP توصیه می‌کند.

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

تیم Chrome در رابطه با LCP در وب به موارد زیر توجه کرده است:

  • طبق بایگانی HTTP Web Almanac 2022 ، 72٪ از صفحات تلفن همراه دارای یک تصویر به عنوان عنصر LCP هستند.
  • تجزیه و تحلیل داده‌های کاربر واقعی از Chrome نشان می‌دهد که اکثر افراد مبدا با LCP ضعیف کمتر از 10٪ از زمان LCP p75 خود را صرف دانلود تصویر LCP می‌کنند.
  • در میان صفحاتی که LCP ضعیفی دارند، بارگیری تصاویر LCP آنها در صدک 75 1290 میلی ثانیه بر روی مشتری به تأخیر می افتد - که بیش از نیمی از بودجه برای یک تجربه سریع است.
  • از صفحاتی که عنصر LCP یک تصویر بود، 39٪ از آن تصاویر دارای URL های منبعی بودند که در پاسخ اولیه HTML قابل کشف نبودند (مانند <img src="..."> یا <link rel="preload" href="..."> )، که به اسکنر پیش بارگذاری مرورگر اجازه می دهد تا آنها را در اسرع وقت کشف کند.
  • بر اساس وب سالنامه، تنها 0.03٪ از صفحات واجد شرایط از ویژگی fetchpriority HTML برای دادن اولویت بیشتر به منابع - از جمله مواردی که می توانند LCP صفحه را با تلاش نسبتا کمی بهبود بخشند، استفاده می کردند.

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

پشتیبانی مرورگر

  • کروم: 102.
  • لبه: 102.
  • فایرفاکس: پشت پرچم
  • سافاری: 17.2.

منبع

در جایی که مشکل تأخیر بارگذاری منبع است، بسیار مهم است که به خاطر داشته باشید که اگر صفحه باید منتظر بماند تا CSS یا جاوا اسکریپت به طور کامل قبل از بارگیری تصاویر شروع شود، برای دستیابی به LCP خوب دیر شده باشد . علاوه بر این، مدت زمان بارگذاری منبع یک تصویر LCP را می توان با اولویت بندی مجدد آن کاهش داد تا پهنای باند بیشتری دریافت کند و بنابراین با استفاده از ویژگی fetchpriority HTML سریعتر بارگیری شود.

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

  • تصویر را با استفاده از عنصر <img> با ویژگی src یا srcset بارگیری کنید. از ویژگی های غیر استاندارد مانند data-src که برای رندر کردن به جاوا اسکریپت نیاز دارند استفاده نکنید، زیرا همیشه کندتر خواهد بود. از صفحات تصویر LCP خود را در پشت data-src پنهان می کنند.
  • رندر سمت سرور (SSR) را به رندر سمت سرویس گیرنده (CSR) ترجیح دهید، زیرا SSR نشان می دهد که نشانه گذاری کامل صفحه (از جمله تصویر) در منبع HTML وجود دارد. راه حل های CSR برای اجرا قبل از کشف تصویر به جاوا اسکریپت نیاز دارند.
  • اگر تصویر شما نیاز به ارجاع از یک فایل CSS یا JS خارجی دارد، همچنان می توانید با استفاده از تگ <link rel="preload"> آن را در منبع HTML قرار دهید. توجه داشته باشید که تصاویر ارجاع شده توسط سبک های درون خطی توسط اسکنر پیش بارگیری مرورگر قابل کشف نیستند، بنابراین حتی اگر در منبع HTML یافت می شوند، ممکن است کشف آنها همچنان در بارگذاری منابع دیگر مسدود شود، بنابراین بارگذاری اولیه می تواند در این موارد کمک کند.

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

  • ویژگی fetchpriority="high" را به تگ <img> یا <link rel="preload"> تصویر LCP خود اضافه کنید. این اولویت منبع تصویر را افزایش می دهد تا زودتر بارگذاری شود.
  • ویژگی loading="lazy" را از تگ <img> تصویر LCP خود حذف کنید. این امر از تأخیر بارگذاری ناشی از تأیید اینکه تصویر در یا نزدیک درگاه دید ظاهر می شود جلوگیری می کند.
  • منابع غیر حیاتی را در صورت امکان به تعویق بیندازید. انتقال این منابع به انتهای سند، بارگیری تنبل تصاویر یا iframe ، یا بارگیری ناهمزمان آنها با استفاده از جاوا اسکریپت به بارگیری سریعتر منابع مهمتری مانند تصویر LCP کمک می کند.
### 2. پیمایش های فوری را هدف بگیرید {:#lcp-instant} تجربه کاربری ایده آل این است که هرگز منتظر نباشید تا صفحه بارگیری شود. بهینه‌سازی‌های LCP مانند کشف‌پذیری منابع و اولویت‌بندی در کاهش مدت زمانی که کاربر برای بارگیری و رندر شدن عنصر LCP منتظر می‌ماند مؤثر است - اما محدودیت فیزیکی برای سرعت بارگیری آن بایت‌ها در شبکه و رندر شدن در صفحه وجود دارد. قبل از رسیدن به آن حد، تلاش بسیار زیادی برای اصلاح چند میلی ثانیه دیگر لازم است. بنابراین، برای دستیابی به ناوبری فوری، باید رویکردی کاملاً متفاوت را در پیش بگیریم. پیمایش‌های فوری سعی می‌کنند صفحه را بارگیری و ارائه کنند _قبل از_ کاربر شروع به پیمایش در آنجا کند. به این ترتیب، صفحه از پیش اجرا شده را می توان بلافاصله با LCP نزدیک به صفر نمایش داد. ترمیم و حدس و گمان دو راه برای انجام این کار است. هنگامی که کاربر به صفحه‌ای که قبلاً بازدید کرده بود به عقب یا جلو می‌رود، می‌توان آن را به سرعت از حافظه پنهان بازیابی کرد و دقیقاً همانطور که کاربر آن را ترک کرده ظاهر می‌شود. از طرف دیگر، برنامه‌های کاربردی وب می‌توانند پیش‌بینی کنند که کاربر به کجا می‌رود – و در صورت درست بودن، صفحه بعدی قبلاً بارگیری شده و تا زمانی که کاربر در آنجا حرکت می‌کند، ارائه شده است. بازیابی صفحاتی که قبلاً بازدید شده‌اند توسط [حافظه پنهان عقب و جلو (bfcache)](/articles/bfcache) امکان‌پذیر است. برای استفاده از آن، باید مطمئن شوید که صفحات شما [معیارهای واجد شرایط بودن bfcache] (/articles/bfcache#optimize) را برآورده می‌کنند. دلایل متداول عدم واجد شرایط بودن صفحات برای bfcache به این دلیل است که با دستورالعمل های ذخیره سازی ['no-store'](/articles/bfcache#minimize-no-store) ارائه می شوند یا ['unload'](/articles/ bfcache#never-use-the-unload-event) شنوندگان رویداد. بازیابی صفحات کاملاً رندر شده نه تنها عملکرد بارگذاری، بلکه ثبات طرح‌بندی را نیز بهبود می‌بخشد. در بخش [اطمینان از واجد شرایط بودن صفحات برای bfcache] (#cls-bfcache) می‌توانید درباره bfcache و میزان مؤثر بودن آن برای بهبود CLS اطلاعات بیشتری کسب کنید.

پشتیبانی مرورگر

  • کروم: 109.
  • لبه: 109.
  • فایرفاکس: پشتیبانی نمی شود.
  • سافاری: پشتیبانی نمی شود.
اجرای قبلی صفحه بعدی که کاربر از آن بازدید می‌کند روش مؤثر دیگری برای بهبود چشمگیر عملکرد LCP است و توسط [API قوانین Speculation] (https://developer.chrome.com/docs/web-platform/prerender-pages) امکان‌پذیر شده است. اما برای درک این دستاوردها، اطمینان حاصل کنید که صفحات صحیح از قبل اجرا شده اند. گمانه زنی های نادرست منابع را هم روی سرور و هم روی مشتری هدر می دهد که می تواند به عملکرد آسیب برساند. بنابراین، هرچه کمتر به صفحه بعدی اطمینان داشته باشید، باید محافظه‌کارتری در اجرای پیش‌پرداخت آن باشید. در صورت شک، داده های تجزیه و تحلیل شما می تواند به شما اطمینان دهد که صفحاتی را که مشتاقانه تر از قبل اجرا می کنند با بالاترین احتمال بازدید بعدی به شما می دهد.

3. از CDN برای بهینه سازی TTFB استفاده کنید

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

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

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

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

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

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

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

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

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

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

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

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

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

پشتیبانی مرورگر

  • کروم: 88.
  • لبه: 88.
  • فایرفاکس: 89.
  • سافاری: 15.

منبع

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

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

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

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

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

صاحبان سایت باید بررسی کنند که آیا صفحات برای bfcache واجد شرایط هستند یا خیر و دلایل عدم واجد شرایط بودن آنها را برطرف کنند. Chrome یک آزمایش‌کننده bfcache در DevTools دارد و همچنین می‌توانید از Not Restored Reasons API برای تشخیص دلایل عدم واجد شرایط بودن در این زمینه استفاده کنید.

3. از انیمیشن ها و ترانزیشن هایی که از ویژگی های 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 هشدار می‌دهد که صفحه ویژگی‌های بالقوه کند CSS را متحرک می‌کند.

نتیجه گیری

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

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

پیوست: تغییر گزارش

تغییرات عمده در این سند در اینجا ردیابی می‌شوند تا توضیح دهیم که چه زمانی و چرا توصیه‌های برتر تغییر کرده‌اند.

سپتامبر 2024

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

  • INP
    • مطابق با راه‌اندازی INP به عنوان معیار اصلی وب حیاتی، این معیار را از FID به INP تغییر دادیم و آن را به برترین معیار در لیست تبدیل کردیم.
    • ما توصیه خود را برای استفاده از isInputPending API به عنوان بخشی از تقسیم وظایف طولانی معکوس کردیم. می توانید در مقاله Optimize Long Tasks درباره استدلال ما بیشتر بدانید.
  • LCP
    • ما توصیه‌های شناسایی و اولویت‌بندی را در یکی ترکیب کردیم.
    • ما یک توصیه جدید برای پیمایش فوری اضافه کردیم.

ژانویه 2023

این لیست اولیه توصیه ها است:

  • LCP
    • اطمینان حاصل کنید که منبع LCP از منبع HTML قابل کشف است
    • اطمینان حاصل کنید که منبع LCP اولویت بندی شده است
    • از CDN برای بهینه سازی TTFB سند و منبع استفاده کنید
  • CLS
    • اندازه های صریح را روی هر محتوای بارگیری شده از صفحه تنظیم کنید
    • اطمینان حاصل کنید که صفحات برای bfcache واجد شرایط هستند
    • از انیمیشن‌ها و انتقال‌هایی که از ویژگی‌های CSS القاکننده طرح‌بندی استفاده می‌کنند اجتناب کنید
  • FID
    • از کارهای طولانی اجتناب کنید یا آن ها را کنار بگذارید
    • از جاوا اسکریپت غیر ضروری خودداری کنید
    • از به‌روزرسانی‌های رندر بزرگ خودداری کنید

همچنین می‌توانید این ارائه Google I/O 2023 را برای یک خلاصه ویدیویی تماشا کنید.

،

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

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

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

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

روی هم، اینها واقع بینانه ترین و تاثیرگذارترین راه هایی هستند که می توانید معیارهای Core Web Vitals خود را بهبود ببخشید. اگر با عملکرد وب تازه کار هستید - یا اگر هنوز تصمیم می گیرید چه چیزی بیشترین بازده سرمایه را به شما می دهد - این بهترین مکان برای شروع است.

تعامل با رنگ بعدی (INP)

به عنوان جدیدترین معیار Core Web Vital، Interaction to Next Paint (INP) برخی از بزرگترین فرصت ها را برای بهبود دارد. با این حال، از آنجایی که تعداد سایت‌های کمتری در مقایسه با نسخه قبلی خود از آستانه تجربه‌های «خوب» عبور می‌کنند، ممکن است شما در میان بسیاری از توسعه‌دهندگان باشید که برای اولین بار نحوه بهینه‌سازی پاسخ‌گویی تعامل را یاد می‌گیرند. برای موثرترین راه‌ها برای بهبود INP، با این تکنیک‌های ضروری شروع کنید.

1. اغلب برای از بین بردن کارهای طولانی تسلیم شوید

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

پشتیبانی مرورگر

  • کروم: 129.
  • لبه: 129.
  • فایرفاکس: پشتیبانی نمی شود.
  • سافاری: پشتیبانی نمی شود.

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

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

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

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

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

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

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

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

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

بهینه سازی کار رندر فرآیند ساده ای نیست و بستگی به هدف شما دارد. با این وجود، در اینجا چند کار وجود دارد که می توانید انجام دهید تا مطمئن شوید که رندر وظایف به کارهای طولانی تبدیل نمی شوند:

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

بزرگترین رنگ محتوایی (LCP) هسته حیاتی وب است که توسعه دهندگان بیشتر با آن مشکل دارند— 40٪ از سایت ها در گزارش Chrome UX آستانه LCP توصیه شده برای تجربه کاربری خوب را برآورده نمی کنند. تیم Chrome تکنیک‌های زیر را به‌عنوان مؤثرترین راه‌ها برای بهبود LCP توصیه می‌کند.

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

تیم Chrome در رابطه با LCP در وب به موارد زیر توجه کرده است:

  • بر اساس سالنامه وب 2022 توسط بایگانی HTTP، 72٪ از صفحات تلفن همراه دارای یک تصویر به عنوان عنصر LCP هستند.
  • تجزیه و تحلیل داده‌های کاربر واقعی از Chrome نشان می‌دهد که اکثر افراد مبدا با LCP ضعیف کمتر از 10٪ از زمان LCP p75 خود را صرف دانلود تصویر LCP می‌کنند.
  • در میان صفحاتی که LCP ضعیفی دارند، بارگیری تصاویر LCP آنها در صدک 75 1290 میلی ثانیه بر روی مشتری به تأخیر می افتد - که بیش از نیمی از بودجه برای یک تجربه سریع است.
  • از صفحاتی که عنصر LCP یک تصویر بود، 39٪ از آن تصاویر دارای URL های منبعی بودند که در پاسخ اولیه HTML قابل کشف نبودند (مانند <img src="..."> یا <link rel="preload" href="..."> )، که به اسکنر پیش بارگذاری مرورگر اجازه می دهد تا آنها را در اسرع وقت کشف کند.
  • بر اساس وب سالنامه، تنها 0.03٪ از صفحات واجد شرایط از ویژگی fetchpriority HTML برای دادن اولویت بیشتر به منابع - از جمله مواردی که می توانند LCP صفحه را با تلاش نسبتا کمی بهبود بخشند، استفاده می کردند.

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

پشتیبانی مرورگر

  • کروم: 102.
  • لبه: 102.
  • فایرفاکس: پشت پرچم
  • سافاری: 17.2.

منبع

در جایی که مشکل تأخیر بارگذاری منبع است، بسیار مهم است که به خاطر داشته باشید که اگر صفحه باید منتظر بماند تا CSS یا جاوا اسکریپت به طور کامل قبل از بارگیری تصاویر شروع شود، برای دستیابی به LCP خوب دیر شده باشد . علاوه بر این، مدت زمان بارگذاری منبع یک تصویر LCP را می توان با اولویت بندی مجدد آن کاهش داد تا پهنای باند بیشتری دریافت کند و بنابراین با استفاده از ویژگی fetchpriority HTML سریعتر بارگیری شود.

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

  • تصویر را با استفاده از عنصر <img> با ویژگی src یا srcset بارگیری کنید. از ویژگی های غیر استاندارد مانند data-src که برای رندر کردن به جاوا اسکریپت نیاز دارند استفاده نکنید، زیرا همیشه کندتر خواهد بود. از صفحات تصویر LCP خود را در پشت data-src پنهان می کنند.
  • رندر سمت سرور (SSR) را به رندر سمت سرویس گیرنده (CSR) ترجیح دهید، زیرا SSR نشان می دهد که نشانه گذاری کامل صفحه (از جمله تصویر) در منبع HTML وجود دارد. راه حل های CSR برای اجرا قبل از کشف تصویر به جاوا اسکریپت نیاز دارند.
  • اگر تصویر شما نیاز به ارجاع از یک فایل CSS یا JS خارجی دارد، همچنان می توانید با استفاده از تگ <link rel="preload"> آن را در منبع HTML قرار دهید. توجه داشته باشید که تصاویر ارجاع شده توسط سبک های درون خطی توسط اسکنر پیش بارگیری مرورگر قابل کشف نیستند، بنابراین حتی اگر در منبع HTML یافت می شوند، ممکن است کشف آنها همچنان در بارگذاری منابع دیگر مسدود شود، بنابراین بارگذاری اولیه می تواند در این موارد کمک کند.

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

  • ویژگی fetchpriority="high" را به تگ <img> یا <link rel="preload"> تصویر LCP خود اضافه کنید. این اولویت منبع تصویر را افزایش می دهد تا زودتر بارگذاری شود.
  • ویژگی loading="lazy" را از تگ <img> تصویر LCP خود حذف کنید. این امر از تأخیر بارگذاری ناشی از تأیید اینکه تصویر در یا نزدیک درگاه دید ظاهر می شود جلوگیری می کند.
  • منابع غیر حیاتی را در صورت امکان به تعویق بیندازید. انتقال این منابع به انتهای سند، بارگیری تنبل تصاویر یا iframe ، یا بارگیری ناهمزمان آنها با استفاده از جاوا اسکریپت به بارگیری سریعتر منابع مهمتری مانند تصویر LCP کمک می کند.
### 2. پیمایش های فوری را هدف بگیرید {:#lcp-instant} تجربه کاربری ایده آل این است که هرگز منتظر نباشید تا صفحه بارگیری شود. بهینه سازی های LCP مانند کشف منابع و اولویت بندی در کاهش مدت زمانی که کاربر منتظر بارگیری و ارائه عنصر LCP باشد ، مؤثر است - اما یک حد فیزیکی برای اینکه چقدر سریع آن بایت ها از طریق شبکه بارگیری می شود وجود دارد و در یک صفحه ارائه می شود. خوب قبل از رسیدن به این حد ، تلاش بسیار زیادی برای اصلاح چند میلی ثانیه دیگر لازم است. بنابراین ، برای دستیابی به ناوبری های فوری ، باید رویکردی کاملاً متفاوت داشته باشیم. ناوبری های فوری سعی می کنند صفحه _before_ را بارگیری و ارائه دهند. کاربر شروع به حرکت در آنجا می کند. به این ترتیب ، صفحه پیش نویس می تواند بلافاصله با LCP نزدیک صفر نمایش داده شود. ترمیم ها و گمانه زنی ها دو راه برای انجام این کار است. هنگامی که یک کاربر به صفحه ای که قبلاً بازدید شده بود ، حرکت می کند ، می توان آن را به سرعت از یک حافظه نهان حافظه بازیابی کرد و دقیقاً در حالی که کاربر آن را ترک کرد ، ظاهر می شود. از طرف دیگر ، برنامه های وب می توانند سعی کنند پیش بینی کنند که یک کاربر به کجا می رود - و هنگامی که صحیح باشد ، صفحه بعدی تا زمانی که کاربر در آنجا حرکت می کند بارگیری و ارائه می شود. بازیابی صفحات قبلی بازدید شده توسط [حافظه نهان عقب/رو به جلو (BFCACHE)] (/مقالات/bfcache) امکان پذیر است. برای استفاده از آن ، باید اطمینان حاصل کنید که صفحات شما [معیارهای واجد شرایط بودن BFCACHE] (/مقالات/bfcache#بهینه سازی) را برآورده می کنند. دلایل متداول چرا صفحات واجد شرایط برای BFCACHE نیستند زیرا آنها با [`` no-store`] (/مقالات/bfcache#به حداقل رساندن-فروشگاه) دستورالعمل های ذخیره شده یا داشتن ["تخلیه"] (/مقاله/ BFCACHE#شنوندگان رویداد Never-Use-the-Unload-Event). بازگرداندن صفحات کاملاً ارائه شده نه تنها بارگذاری عملکرد را بهبود می بخشد ، بلکه ثبات طرح را نیز بهبود می بخشد. شما می توانید در مورد BFCache و چقدر مؤثر در بهبود CL در [اطمینان از صفحات واجد شرایط برای BFCACHE] (#CLS-BFCACHE) اطلاعات بیشتری کسب کنید.

پشتیبانی مرورگر

  • کروم: 109.
  • لبه: 109.
  • Firefox: پشتیبانی نمی شود.
  • سافاری: پشتیبانی نشده است.
از قبل مراجعه به صفحه بعد ، بازدید کاربر یکی دیگر از راههای مؤثر برای بهبود چشمگیر عملکرد LCP است و توسط [API قوانین حدس و گمان] (https://developer.chrome.com/docs/web-platform/prerender-pages) امکان پذیر است. با این حال ، برای تحقق این دستاوردها ، اطمینان حاصل کنید که صفحات صحیح از قبل تنظیم شده اند. گمانه زنی های نادرست منابع را در سرور و مشتری هدر می دهد ، که می تواند به عملکرد آسیب برساند. بنابراین هرچه نسبت به صفحه بعد چه اطمینان داشته باشید ، باید محافظه کارانه تر باشید که باید با استفاده از آن استفاده کنید. هنگامی که شک دارید ، داده های تحلیلی شما می توانند به شما اعتماد به نفس را به صفحات با اشتیاق تر با بالاترین احتمال بازدید در بعدی به شما بدهند.

3. برای بهینه سازی TTFB از CDN استفاده کنید

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

این زمان به عنوان زمان بایت اول (TTFB) شناخته می شود. بهترین راه برای کاهش TTFB به این موارد است:

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

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

CDN ها همچنین می توانند اسناد HTML را ذخیره و ذخیره کنند ، اما طبق وب Almanac ، تنها 29 ٪ درخواست های اسناد HTML از CDN ارائه شده است . این بدان معناست که فرصتی قابل توجه برای سایت ها برای تحقق پس انداز اضافی وجود دارد.

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

  • اسناد HTML استاتیک حافظه پنهان حتی برای مدت کوتاهی. به عنوان مثال ، آیا مهم است که محتوا همیشه تازه باشد؟ یا می تواند چند دقیقه بی رنگ باشد؟
  • بررسی کنید که آیا می توانید منطق پویا را روی سرور Origin خود به سمت لبه حرکت دهید ، که این ویژگی بیشتر CDN های مدرن است.

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

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

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

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

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

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

پشتیبانی مرورگر

  • کروم: 88.
  • لبه: 88.
  • Firefox: 89.
  • سافاری: 15.

منبع

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

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

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

همانطور که قبلاً در این راهنما گفته شد ، حافظه نهان عقب/رو به جلو (BFCACHE) فوراً صفحه ای را از قبل یا بعد در تاریخ مرورگر از یک عکس فوری بارگیری می کند. در حالی که BFCACHE یک بهینه سازی عملکرد قابل توجه در سطح مرورگر است که LCP را بهبود می بخشد ، اما به طور کامل تغییرات طرح را از بین می برد. در حقیقت ، معرفی BFCACHE در سال 2022 مسئول بزرگترین پیشرفت در CLS بود که در آن سال دیدیم.

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

صاحبان سایت باید بررسی کنند که آیا صفحات واجد شرایط BFCache هستند و به هر دلیلی که دلیل این امر نیستند را برطرف می کنند. Chrome دارای یک تستر BFCache در Devtools است و همچنین می توانید از دلایل عدم ترمیم شده API برای تشخیص دلایل عدم صلاحیت در این زمینه استفاده کنید.

3. از انیمیشن ها و انتقال هایی که از خواص CSS ناشی از طرح استفاده می کنند ، خودداری کنید

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

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

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

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

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

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

اجتناب از انیمیشن های غیرقابل ترکیب حسابرسی فانوس دریایی هشدار می دهد که یک صفحه به طور بالقوه خواص CSS را کند می کند.

نتیجه گیری

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

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

پیوست: تغییر ورود به سیستم

تغییرات اساسی در این سند در اینجا ردیابی می شود تا به توضیح اینکه چه موقع و چرا توصیه های برتر تغییر کرده است ، کمک می کند.

سپتامبر 2024

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

  • INP
    • ما این متریک را از FID به INP مطابق با راه اندازی INP به عنوان یک متریک اصلی وب مهم تغییر دادیم و آن را به عنوان متریک برتر در لیست قرار دادیم.
    • ما توصیه خود را برای استفاده از API isInputPending به عنوان بخشی از شکستن کارهای طولانی معکوس کردیم. می توانید در مورد استدلال ما در مقاله بهینه سازی کارهای طولانی اطلاعات بیشتر کسب کنید.
  • LCP
    • ما توصیه های کشف و اولویت بندی را در یک ترکیب کردیم.
    • ما یک توصیه جدید برای هدف ناوبری فوری اضافه کردیم.

ژانویه 2023

این لیست اولیه توصیه ها است:

  • LCP
    • اطمینان حاصل کنید که منبع LCP از منبع HTML قابل کشف است
    • اطمینان حاصل کنید که منبع LCP در اولویت قرار دارد
    • برای بهینه سازی سند و منبع TTFB از CDN استفاده کنید
  • CLS
    • اندازه های صریح را در هر محتوای بارگذاری شده از صفحه تنظیم کنید
    • اطمینان حاصل کنید که صفحات واجد شرایط برای bfcache هستند
    • از انیمیشن ها و انتقال هایی که از خواص CSS ناشی از طرح استفاده می کنند ، خودداری کنید
  • FID
    • از انجام کارهای طولانی جلوگیری کنید یا از هم جدا شوید
    • از جاوا اسکریپت غیر ضروری خودداری کنید
    • از به روزرسانی های بزرگ ارائه دهید

همچنین می توانید این نمایش 2023 Google I/O را برای خلاصه ویدیو تماشا کنید.