موثرترین راه ها برای بهبود 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 در وب به موارد زیر توجه کرده است:

  • بر اساس سالنامه وب 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 که برای رندر به جاوا اسکریپت نیاز دارند استفاده نکنید، زیرا همیشه کندتر خواهد بود. 9٪ از صفحات تصویر 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 مانند کشف‌پذیری منابع و اولویت‌بندی در کاهش مدت زمانی که کاربر برای بارگیری و رندر شدن عنصر LCP منتظر می‌ماند مؤثر است - اما محدودیت فیزیکی برای سرعت بارگیری آن بایت‌ها در شبکه و رندر شدن در صفحه وجود دارد. قبل از رسیدن به آن حد، تلاش بسیار زیادی برای اصلاح چند میلی ثانیه دیگر لازم است. بنابراین، برای دستیابی به ناوبری فوری، باید رویکردی کاملاً متفاوت را در پیش بگیریم.

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

بازیابی صفحاتی که قبلاً بازدید شده‌اند توسط حافظه پنهان عقب/ جلو (bfcache) امکان‌پذیر است. برای استفاده از آن، باید مطمئن شوید که صفحات شما معیارهای واجد شرایط بودن bfcache را دارند. دلایل متداول عدم واجد شرایط بودن صفحات برای bfcache به این دلیل است که با دستورالعمل‌های ذخیره‌سازی no-store ارائه می‌شوند یا شنوندگان رویداد را unload می‌کنند.

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

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

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

اجرای قبلی صفحه بعدی که کاربر بازدید می کند روش موثر دیگری برای بهبود چشمگیر عملکرد LCP است و توسط Speculation Rules API امکان پذیر شده است. اما برای درک این دستاوردها، مطمئن شوید که صفحات صحیح از قبل اجرا شده اند. گمانه زنی های نادرست منابع را هم روی سرور و هم روی مشتری هدر می دهد که می تواند به عملکرد آسیب برساند. بنابراین، هرچه کمتر به صفحه بعدی اطمینان داشته باشید، باید محافظه کارتر در اجرای پیش اجرا آن باشید. در صورت شک، داده های تجزیه و تحلیل شما می تواند به شما اطمینان دهد که صفحاتی را که مشتاقانه تر از قبل اجرا می کنند با بالاترین احتمال بازدید بعدی به شما می دهد.

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 القا کننده طرح‌بندی را تغییر دهید یا متحرک کنید، منجر به تغییر طرح‌بندی می‌شود. اگر این تغییرات طرح‌بندی در ۵۰۰ میلی‌ثانیه از تعامل کاربر نباشد، بر 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 را برای یک خلاصه ویدیویی تماشا کنید.