در طول سالها، جامعه وب، دانش زیادی را در زمینه بهینهسازی عملکرد وب ایجاد کرده است. در حالی که هر بهینهسازی ممکن است عملکرد بسیاری از سایتها را بهبود بخشد، اما همه آنها به طور همزمان میتوانند بسیار طاقتفرسا به نظر برسند و در واقع، فقط برخی از آنها برای هر سایتی قابل اجرا هستند.
مگر اینکه عملکرد وب کار روزانه شما باشد، احتمالاً مشخص نیست که کدام بهینه سازی برای سایت شما تأثیرگذارتر خواهد بود. احتمالاً برای همه آنها وقت نخواهید داشت، بنابراین مهم است که از خود بپرسید تأثیرگذارترین بهینه سازی هایی که می توانید برای بهبود عملکرد کاربران خود انتخاب کنید کدامند؟
حقیقت در مورد بهینه سازی عملکرد اینجاست: شما نمی توانید آنها را صرفاً بر اساس شایستگی های فنی آنها قضاوت کنید. شما همچنین باید عوامل انسانی و سازمانی را که بر میزان احتمال اینکه بتوانید هر بهینه سازی داده شده را پیاده سازی کنید، در نظر بگیرید. برخی از بهبودهای عملکرد ممکن است در تئوری بسیار تأثیرگذار باشند، اما در واقعیت، تعداد کمی از توسعه دهندگان زمان یا منابع لازم برای پیاده سازی آنها را خواهند داشت. از سوی دیگر ممکن است بهترین شیوه های عملکرد بسیار تاثیرگذار وجود داشته باشد که تقریباً همه از قبل از آنها پیروی می کنند. این راهنما بهینه سازی های عملکرد وب را شناسایی می کند که:
- بیشترین تأثیر را در دنیای واقعی داشته باشید
- مرتبط هستند و برای اکثر سایت ها قابل اجرا هستند
- برای اکثر توسعه دهندگان برای پیاده سازی واقع بینانه هستند
روی هم، اینها واقع بینانه ترین و تاثیرگذارترین راه هایی هستند که می توانید معیارهای Core Web Vitals خود را بهبود ببخشید. اگر با عملکرد وب تازه کار هستید - یا اگر هنوز تصمیم می گیرید چه چیزی بیشترین بازده سرمایه را به شما می دهد - این بهترین مکان برای شروع است.
تعامل با رنگ بعدی (INP)
به عنوان جدیدترین معیار Core Web Vital، Interaction to Next Paint (INP) برخی از بزرگترین فرصتها را برای بهبود دارد. با این حال، از آنجایی که تعداد سایتهای کمتری در مقایسه با نسخه قبلی خود از آستانه تجربههای «خوب» عبور میکنند، ممکن است شما در میان بسیاری از توسعهدهندگان باشید که برای اولین بار نحوه بهینهسازی پاسخگویی تعامل را یاد میگیرند. برای موثرترین راهها برای بهبود INP، با این تکنیکهای ضروری شروع کنید.
1. اغلب برای از بین بردن کارهای طولانی تسلیم شوید
Tasks هر قطعه ای از کار مجزا است که مرورگر انجام می دهد، از جمله رندر، طرح بندی، تجزیه، کامپایل، یا اجرای اسکریپت ها. وقتی یک کار از 50 میلی ثانیه بیشتر شود، به یک کار طولانی تبدیل می شود. وظایف طولانی مشکل ساز هستند زیرا می توانند موضوع اصلی را از پاسخ سریع به تعاملات کاربر مسدود کنند.
پشتیبانی مرورگر
در حالی که همیشه باید تلاش کنید تا کمترین کار ممکن را در جاوا اسکریپت انجام دهید، میتوانید با جدا کردن کارهای طولانی به موضوع اصلی کمک کنید. میتوانید این کار را با تسلیم شدن به رشته اصلی انجام دهید تا رندر بهروزرسانیها و سایر تعاملات کاربر زودتر اتفاق بیفتد.
Scheduler API به شما امکان می دهد با استفاده از سیستمی از اولویت ها، کار را در صف قرار دهید. به طور خاص، API Scheduler.yield() وظایف طولانی را تجزیه میکند و در عین حال اطمینان میدهد که تعاملات میتوانند بدون رها کردن جای خود در صف وظایف مدیریت شوند.
با جدا کردن کارهای طولانی، به مرورگر فرصت های بیشتری می دهید تا در کارهای مهم و مسدود کننده کاربر جا بیفتد.
2. از جاوا اسکریپت غیر ضروری خودداری کنید
وب سایت ها جاوا اسکریپت بیشتری نسبت به قبل ارسال می کنند و به نظر نمی رسد روند تغییر کند. هنگامی که جاوا اسکریپت زیادی ارسال می کنید، محیطی ایجاد می کنید که در آن وظایف برای جلب توجه موضوع اصلی رقابت می کنند. این می تواند بر روی پاسخگویی وب سایت شما تأثیر بگذارد، به خصوص در آن دوره راه اندازی حیاتی.
با این حال، این یک مشکل غیر قابل حل نیست و شما گزینه هایی دارید:
- به جای پیاده سازی های اضافی و مبتنی بر جاوا اسکریپت، از ویژگی های پلت فرم وب به طور گسترده در دسترس استفاده کنید.
- از ابزار پوشش در Chrome DevTools برای یافتن کدهای استفاده نشده در اسکریپت های خود استفاده کنید. با کاهش حجم منابع مورد نیاز در هنگام راهاندازی، میتوانید اطمینان حاصل کنید که صفحات زمان کمتری را برای تجزیه و کامپایل کد صرف میکنند، که تجربه کاربری اولیه روانتری را فراهم میکند.
- از تقسیم کد برای ایجاد یک بسته جداگانه برای کد استفاده کنید که برای رندر اولیه ضروری نیست، اما همچنان بعدا استفاده خواهد شد.
- اگر از یک مدیر برچسب استفاده می کنید، به صورت دوره ای برچسب های خود را بهینه کنید . برچسبهای قدیمیتر با کد استفاده نشده را میتوان حذف کرد تا ردپای جاوا اسکریپت مدیر برچسب شما کاهش یابد.
3. از به روز رسانی های رندر بزرگ خودداری کنید
اجرای جاوا اسکریپت تنها یکی از مواردی است که روی پاسخگویی وب سایت شما تأثیر می گذارد. رندر به خودی خود یک نوع کار گران قیمت است - و در طول به روز رسانی های رندر بزرگ، وب سایت شما ممکن است کندتر به تعاملات کاربر پاسخ دهد.
بهینه سازی کار رندر فرآیند ساده ای نیست و بستگی به هدف شما دارد. با این وجود، در اینجا چند کار وجود دارد که می توانید انجام دهید تا مطمئن شوید که رندر وظایف به کارهای طولانی تبدیل نمی شوند:
- خواندن و نوشتن DOM را در کد جاوا اسکریپت خود سازماندهی مجدد کنید تا از چیدمان اجباری و چیدمان جلوگیری کنید.
- اندازه های DOM را کوچک نگه دارید . اندازه DOM و شدت کار چیدمان با هم مرتبط هستند. هنگامی که رندر باید طرح را برای یک DOM بسیار بزرگ به روز کند، کار مورد نیاز برای محاسبه مجدد طرح آن می تواند به میزان قابل توجهی افزایش یابد.
- از محتویات CSS برای نمایش تنبلی محتویات DOM خارج از صفحه استفاده کنید . همیشه ساده نیست، اما با جداسازی مناطق حاوی طرحبندیهای پیچیده، میتوانید از چیدمان و رندر غیرضروری اجتناب کنید.
بزرگترین رنگ محتوایی (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 کاهش دهند.
در جایی که مشکل تأخیر بارگذاری منبع است، بسیار مهم است که به خاطر داشته باشید که اگر صفحه باید منتظر بماند تا 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 کمک می کند.
پشتیبانی مرورگر
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
هستند، که ممکن است با بارگیری این تصاویر و کشف ابعاد آنها توسط مرورگر، باعث تغییر طرح شود. این یک فرصت بزرگ برای وب جمعی است - و این فرصت به تلاش کمتری نسبت به سایر توصیههای پیشنهاد شده در این راهنما نیاز دارد.
تصاویر تنها مشارکت کنندگان در 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 میلی ثانیه بیشتر شود، به یک کار طولانی تبدیل می شود. وظایف طولانی مشکل ساز هستند زیرا می توانند موضوع اصلی را از پاسخ سریع به تعاملات کاربر مسدود کنند.
پشتیبانی مرورگر
در حالی که همیشه باید تلاش کنید تا کمترین کار ممکن را در جاوا اسکریپت انجام دهید، میتوانید با جدا کردن کارهای طولانی به موضوع اصلی کمک کنید. میتوانید این کار را با تسلیم شدن به رشته اصلی انجام دهید تا رندر بهروزرسانیها و سایر تعاملات کاربر زودتر اتفاق بیفتد.
Scheduler API به شما امکان می دهد با استفاده از سیستمی از اولویت ها، کار را در صف قرار دهید. به طور خاص، API Scheduler.yield() وظایف طولانی را تجزیه میکند و در عین حال اطمینان میدهد که تعاملات میتوانند بدون رها کردن جای خود در صف وظایف مدیریت شوند.
با جدا کردن کارهای طولانی، به مرورگر فرصت های بیشتری می دهید تا در کارهای مهم و مسدود کننده کاربر جا بیفتد.
2. از جاوا اسکریپت غیر ضروری خودداری کنید
وب سایت ها جاوا اسکریپت بیشتری نسبت به قبل ارسال می کنند و به نظر نمی رسد روند تغییر کند. هنگامی که جاوا اسکریپت زیادی ارسال می کنید، محیطی ایجاد می کنید که در آن وظایف برای جلب توجه موضوع اصلی رقابت می کنند. این می تواند بر روی پاسخگویی وب سایت شما تأثیر بگذارد، به خصوص در آن دوره راه اندازی حیاتی.
با این حال، این یک مشکل غیرقابل حل نیست و شما گزینه هایی دارید:
- به جای پیاده سازی های اضافی و مبتنی بر جاوا اسکریپت، از ویژگی های پلت فرم وب به طور گسترده در دسترس استفاده کنید.
- از ابزار پوشش در Chrome DevTools برای یافتن کدهای استفاده نشده در اسکریپت های خود استفاده کنید. با کاهش حجم منابع مورد نیاز در هنگام راهاندازی، میتوانید اطمینان حاصل کنید که صفحات زمان کمتری را برای تجزیه و کامپایل کد صرف میکنند، که تجربه کاربری اولیه روانتری را فراهم میکند.
- از تقسیم کد برای ایجاد یک بسته جداگانه برای کد استفاده کنید که برای رندر اولیه ضروری نیست، اما همچنان بعدا استفاده خواهد شد.
- اگر از یک مدیر برچسب استفاده می کنید، به صورت دوره ای برچسب های خود را بهینه کنید . برچسبهای قدیمیتر با کد استفاده نشده را میتوان حذف کرد تا ردپای جاوا اسکریپت مدیر برچسب شما کاهش یابد.
3. از به روز رسانی های رندر بزرگ خودداری کنید
اجرای جاوا اسکریپت تنها یکی از مواردی است که روی پاسخگویی وب سایت شما تأثیر می گذارد. رندر به خودی خود یک نوع کار گران قیمت است - و در طول به روز رسانی های رندر بزرگ، وب سایت شما ممکن است کندتر به تعاملات کاربر پاسخ دهد.
بهینه سازی کار رندر فرآیند ساده ای نیست و بستگی به هدف شما دارد. با این وجود، در اینجا چند کار وجود دارد که می توانید انجام دهید تا مطمئن شوید که رندر وظایف به کارهای طولانی تبدیل نمی شوند:
- خواندن و نوشتن DOM را در کد جاوا اسکریپت خود سازماندهی مجدد کنید تا از چیدمان اجباری و چیدمان جلوگیری کنید.
- اندازه های DOM را کوچک نگه دارید . اندازه DOM و شدت کار چیدمان با هم مرتبط هستند. هنگامی که رندر باید طرح را برای یک DOM بسیار بزرگ به روز کند، کار مورد نیاز برای محاسبه مجدد طرح آن می تواند به میزان قابل توجهی افزایش یابد.
- از محتویات CSS برای نمایش تنبلی محتویات DOM خارج از صفحه استفاده کنید . همیشه ساده نیست، اما با جداسازی مناطق حاوی طرحبندیهای پیچیده، میتوانید از چیدمان و رندر غیرضروری اجتناب کنید.
بزرگترین رنگ محتوایی (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 کاهش دهند.
در جایی که مشکل تأخیر بارگذاری منبع است، بسیار مهم است که به خاطر داشته باشید که اگر صفحه باید منتظر بماند تا 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 کمک می کند.
پشتیبانی مرورگر
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
هستند ، که ممکن است هنگام بارگیری این تصاویر باعث تغییر چیدمان شود و مرورگر ابعاد آنها را کشف کند. این یک فرصت بزرگ برای وب جمعی است - و این فرصت نیاز به تلاش کمتری نسبت به برخی از توصیه های دیگر که در این راهنما پیشنهاد شده است.
تصاویر تنها مشارکت کننده 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 را برای خلاصه ویدیو تماشا کنید.