چگونه سرعت صفحه را بهبود دهیم تا از ارزیابی Core Web Vitals گوگل عبور کنیم

یاد بگیرید که چگونه Core Web Vitals خود را بهینه کنید تا سرعت وب‌سایت، تجربه کاربری بهتر و رتبه‌بندی بالاتر در صفحات نتایج موتور جستجو (SERP) را به دست آورید.
این پست توسط DebugBear حمایت شده است. نظرات بیان شده در این مقاله مربوط به اسپانسر است.
یک وب‌سایت سریع‌تر تجربه‌ای لذت‌بخش‌تر برای کاربران فراهم می‌کند و می‌تواند منجر به نرخ تبدیل بالاتر شود. اما گوگل نیز سرعت وب‌سایت را به عنوان بخشی از Core Web Vitals در نظر می‌گیرد و از آن به عنوان یک عامل رتبه‌بندی استفاده می‌کند.
یاد بگیرید که ارزیابی Core Web Vitals گوگل چگونه کار می‌کند و چه کاری می‌توانید انجام دهید تا اطمینان حاصل کنید که وب‌سایت شما به سرعت بارگذاری می‌شود و پس از بارگذاری تجربه خوبی را ارائه می‌دهد.
در این راهنما:

1. Core Web Vitals چیست؟
2. ارزیابی Core Web Vitals گوگل چیست؟
3. چگونه سرعت Largest Contentful Paint (LCP) را افزایش دهیم
4. چگونه تعامل با Interaction to Next Paint (INP) را بهبود دهیم
5. چگونه Cumulative Layout Shift را کاهش دهیم
6. نظارت بر سرعت صفحه و Core Web Vitals

Core Web Vitals چیست؟

Core Web Vitals گوگل (CWV) به منظور اندازه‌گیری کیفیت وب‌سایت و تجربه کاربری طراحی شده‌اند. برای این کار چندین متریک جدید توسعه داده شده که می‌توان آن‌ها را در مرورگر Chrome جمع‌آوری کرد. سه مورد از این متریک‌ها، Core Web Vitals را تشکیل می‌دهند:

• Largest Contentful Paint
• Interaction to Next Paint
• Cumulative Layout Shift

Largest Contentful Paint

متریک Largest Contentful Paint (LCP) اندازه‌گیری می‌کند که بزرگ‌ترین قطعه محتوای صفحه چقدر سریع پس از باز شدن صفحه توسط بازدیدکننده روی صفحه ظاهر می‌شود. شما می‌توانید مثالی از LCP را در <LINK> فیلم سرعت صفحه DebugBear ببینید که نشان می‌دهد چه محتوایی در نقاط مختلف زمانی برای کاربران قابل مشاهده است.

در اینجا محتوا پس از فقط 1.27 ثانیه شروع به نمایش می‌کند. اما تصویری که در سمت راست مشاهده می‌شود توسط Chrome به عنوان عنصر LCP شناسایی شده و این تصویر تنها 2.33 ثانیه پس از ناوبری نمایش داده می‌شود.
Largest Contentful Paint به دو متریک دیگر Web Vitals که جزو Core Web Vitals نیستند نیز نزدیک است: زمان اولین بایت (Time to First Byte) و اولین رنگ محتوایی (First Contentful Paint).

Time To First Byte

زمان اولین بایت (TTFB) اندازه‌گیری می‌کند که سرور چقدر سریع به درخواست سند HTML که در ابتدای فرآیند بارگذاری صفحه بارگیری می‌شود پاسخ می‌دهد. بدون سند HTML مرورگر نمی‌تواند هیچ محتوایی را نمایش دهد یا شروع به بارگذاری منابع دیگر کند.

First Contentful Paint

اولین رنگ محتوایی (FCP) بررسی می‌کند که چقدر زودتر هر محتوایی روی صفحه ظاهر می‌شود. محتوا در اینجا معمولاً به معنای متن یا تصویر است. با این حال، هنگامی که این نقطه عطف توسط صفحه حاصل می‌شود، ممکن است اکثر محتوا هنوز برای بازدیدکننده در دسترس نباشد. FCP نمی‌تواند قبل از نقطه عطف TTFB رخ دهد. به نوبه خود، Largest Contentful Paint همیشه بیشتر یا برابر با First Contentful Paint است. این بدان معناست که TTFB و FCP حد پایین‌تری بر LCP می‌گذارند و نگاه کردن به این دو متریک می‌تواند به شما در درک رفتار بارگذاری وب‌سایتتان کمک کند.

Interaction To Next Paint

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

• ورودی کاربر، به عنوان مثال، یک کلیک یا فشار کلید.
• به‌روزرسانی بصری بعدی (“نقاشی”) وب‌سایت (فرقی نمی‌کند محتوا تغییر کند یا نه).

برای مثال، این فیلم نشان می‌دهد که یک دکمه “مشاهده جزئیات” کلیک می‌شود. کلیک توسط کد JavaScript در صفحه پردازش می‌شود و اجرای این کد زمان‌بر است. در حالی که کلیک در حال پردازش است، رابط کاربری وب‌سایت ثابت می‌ماند. پس از اتمام پردازش CPU، مرورگر محتوای جدید را رندر می‌کند.

از نظر فنی، Interaction to Next Paint هنوز یکی از Core Web Vitals نیست، اما گوگل اعلام کرده که INP جایگزین متریک قدیمی First Input Delay در مارس 2024 خواهد شد.

Cumulative Layout Shift

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

CLS به “تجمعی” نامیده می‌شود زیرا تاثیر تغییرات مختلف جمع می‌شود. در ابتدا این مدت زمانی که صفحه باز است را پوشش می‌داد اما این به ناحق به برنامه‌های تک‌صفحه‌ای که مدت زمان طولانی باز بودند امتیاز ضعیفی می‌داد. گوگل اکنون به تعریف windowed CLS تغییر کرده که فقط به یک پنجره زمانی تا پنج ثانیه نگاه می‌کند.

ارزیابی Core Web Vitals گوگل چیست؟

گوگل یک ارزیابی Core Web Vitals در وب‌سایت شما انجام می‌دهد و از نتایج آن به عنوان یک سیگنال رتبه‌بندی استفاده می‌کند. اگر وب‌سایت شما Core Web Vitals را برآورده نکند، هشدارهایی در ابزارهای مختلف دریافت خواهید کرد، به عنوان مثال، هشدار “ارزیابی Core Web Vitals: ناموفق” در Page Speed Insights.

داده‌های ارزیابی Core Web Vitals از گزارش تجربه کاربری Chrome (CrUX) می‌آید که داده‌های واقعی کاربر را از کاربران Chrome جمع‌آوری می‌کند. علاوه بر PageSpeed Insights، کنسول جستجوی گوگل نیز وضعیت Core Web Vitals شما را بررسی می‌کند و توضیح می‌دهد که کدام URLها “خوب” در نظر گرفته نمی‌شوند.

چه چیزی یک ارزیابی Core Web Vitals خوب را ایجاد می‌کند؟

گوگل آستانه‌های “خوب”، “ضعیف” و “نیاز به بهبود” را برای هر متریک تعریف کرده است.

برای اینکه بیشترین بهره‌مندی از رتبه‌بندی را کسب کنید، وب‌سایت شما باید در هر سه Core Web Vitals رتبه “خوب” را داشته باشد. همانطور که وب‌سایت شما بدتر می‌شود، این به تدریج بر رتبه‌بندی شما تأثیر می‌گذارد تا زمانی که به آستانه “ضعیف” برسد.

چگونه سرعت Largest Contentful Paint (LCP) را افزایش دهیم

برای بهبود LCP خود، باید محتوای اصلی وب‌سایت شما سریع‌تر بارگذاری شود. یک تست سرعت رایگان وب‌سایت را اجرا کنید تا بفهمید چه چیزی باعث کندی محتوای اصلی صفحه وب شما می‌شود.
بینش‌ها را از فیلم بصری و متریک‌های عملکرد سطح بالا دریافت کرده و بررسی کنید تا ببینید گام بعدی شما چیست. از این بینش‌ها برای بهینه‌سازی سرعت بارگذاری صفحه خود استفاده کنید.
سپس می‌توانید به عمق بیشتری در متریک خاص بپردازید با کلیک کردن روی عنوان متریک “Largest Contentful Paint” در نتیجه تست.
این به شما نشان می‌دهد:

• چه عنصری از صفحه مسئول Largest Contentful Paint است.
• اگر LCP یک تصویر است، URL تصویر چیست و چه اولویتی برای درخواست توسط مرورگرها استفاده شده است.
• اگر LCP یک تصویر است، چه درخواست‌های دیگری به فایل تصویر وابسته است.

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

چگونه Interaction to Next Paint (INP) را بهبود دهیم

تنها 64% از وب‌سایت‌های موبایل در حال حاضر تجربه INP خوبی ارائه می‌دهند که آن را به یک متریک مهم برای بهینه‌سازی تبدیل می‌کند. متریک INP ممکن است سخت باشد که اشکال‌زدایی شود زیرا به یک تعامل کاربر وابسته است که به راحتی قابل آزمایش نیست.
شما می‌توانید به صورت دستی تعاملات صفحه را آزمایش کرده و با استفاده از نمایه عملکرد Chrome DevTools آن‌ها را اندازه‌گیری کنید. این روش به خوبی کار می‌کند اگر بدانید که کاربران معمولاً با کدام عناصر صفحه تعامل دارند. DevTools همچنین بسیار مفید است هنگامی که شما یک تعامل کند را شناسایی کرده‌اید، زیرا ابزارهای توسعه‌دهنده Chrome به شما دقیقاً می‌گویند مرورگر در طول آن تعامل وقت خود را صرف چه چیزی کرده است.
ابزار INP Debugger نیز می‌تواند مفید باشد زیرا به طور خودکار تعاملات با عناصر مختلف صفحه را شبیه‌سازی می‌کند. تنها کاری که باید انجام دهید این است که یک URL وب‌سایت وارد کنید.

با این حال، Debugger INP نمی‌تواند تمام تعاملات را شناسایی کند، به خصوص اگر آن‌ها بخشی از یک جریان طولانی‌تر کاربر باشند. در اینجا جمع‌آوری نظارت واقعی کاربر (RUM) مفید است زیرا به شما اجازه می‌دهد تا بهینه‌سازی‌های خود را دقیقاً در جای مناسب متمرکز کنید.
با داده‌های RUM می‌توانید دقیقاً ببینید که بیشتر کاربران با کدام عناصر صفحه تعامل دارند و آیا آن‌ها با تأخیرهای تعاملی مواجه هستند.

شما همچنین می‌توانید یک تقسیم‌بندی RUM به اجزای مختلف آن ببینید:

• تاخیر ورودی (Input Delay): اندازه‌گیری می‌کند که چقدر پس از تعامل کاربر مرورگر شروع به پردازش ورودی کاربر می‌کند. یک تاخیر ورودی بالا نشان می‌دهد که وظایف پس‌زمینه یا پردازش‌های قبلی رویدادها تعامل کاربر را مسدود می‌کنند.
• زمان پردازش (Processing Time): زمان واقعی صرف شده برای پردازش ورودی کاربر را اندازه‌گیری می‌کند. اگر این زمان کند باشد، توسعه‌دهندگان شما باید بررسی کنند که چه کدی در پاسخ به تعامل اجرا می‌شود و چگونه می‌توان آن کد را بهینه کرد.
• تاخیر ارائه (Presentation Delay): اندازه‌گیری می‌کند که چقدر زمان بین پردازش رویداد و نقاشی بعدی سپری شده است. این عدد می‌تواند بالا باشد اگر رندر صفحه پیچیده باشد یا اگر پردازش CPU دیگری در حین پردازش تعامل در صف قرار گرفته باشد.

چگونه Cumulative Layout Shift را کاهش دهیم

مشابه با INP، Cumulative Layout Shift می‌تواند سخت باشد که رفع شود زیرا اغلب هنگامی رخ می‌دهد که کاربر به پایین صفحه پیمایش می‌کند یا هنگامی که محتوای اضافی پس از کلیک کاربر روی یک عنصر UI ظاهر می‌شود.
اگر تغییر طرح‌بندی در طول بارگذاری اولیه صفحه رخ دهد، شناسایی آن آسان است:

• اجرای یک تست سرعت صفحه.
• کلیک بر روی عنوان متریک “Cumulative Layout Shift” تا ببینید کدام عناصر صفحه حرکت کرده‌اند.
• رفع عنصری که باعث تغییر می‌شود.

برای مثال، اینجا محتوای اضافی بارگذاری شد که باعث تغییر طرح‌بندی شد.

چگونه تغییرات طرح‌بندی را رفع کنیم

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

نظارت بر سرعت صفحه و Core Web Vitals

اگر شما برای عبور از ارزیابی Core Web Vitals مشکل دارید، نظارت DebugBear می‌تواند به شما در شناسایی مشکلات در وب‌سایتتان کمک کند و اطمینان حاصل کنید که وقتی مشکلی پیش می‌آید، اعلان‌ها دریافت می‌کنید.
به سادگی یک آزمایش رایگان را شروع کنید و URLهای وب‌سایت خود را وارد کنید. تمام متریک‌های سرعت صفحه خود را به یک نگاه در داشبورد مشاهده کنید. DebugBear همچنین امتیازات Lighthouse و داده‌های واقعی کاربر گوگل که بر رتبه‌بندی‌ها تاثیر می‌گذارند را ردیابی می‌کند.

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

علاوه بر نمای کلی Web Vitals سطح بالا، DebugBear RUM به شما امکان می‌دهد تا تجربیات کاربر را بر اساس سرعت صفحه، کشور یا مرورگر وب تجزیه کنید.

داشتن گزارش‌های آزمایشگاهی دقیق و داده‌های واقعی کاربر به شما امکان می‌دهد جلوتر از داده‌های CrUX گوگل که بر رتبه‌بندی‌ها تاثیر می‌گذارند و با تاخیر 28 روز گزارش می‌شوند، باشید. DebugBear بینش‌های قدرتمندی در مورد Core Web Vitals شما ارائه می‌دهد و به شما کمک می‌کند با بقیه تیم و مدیریت خود ارتباط برقرار کنید.
آماده بهینه‌سازی وب‌سایت خود هستید؟ برای DebugBear ثبت نام کنید و داده‌هایی که برای ارائه تجربیات کاربری عالی نیاز دارید را دریافت کنید.
DebugBear را رایگان امتحان کنید

منبع: https://www.searchenginejournal.com/improve-core-web-vitals-debugbear-spa/501049/