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

یک وب سایت سریع تجربه لذت بخشی را برای کاربران فراهم می کند و می تواند منجر به نرخ تبدیل بالاتری شود.

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

بیاموزید که ارزیابی Core Web Vitals چگونه کار می‌کند و چه کارهایی می‌توانید انجام دهید تا مطمئن شوید وب‌سایتتان سریع بار می‌شود و پس از بارگیری، تجربه خوبی را ارائه می‌دهد.

Core Web Vitals چیست؟

Google’s Core Web Vitals (CWV) با هدف اندازه گیری کیفیت وب سایت و تجربه کاربر است.

برای انجام این کار، چندین معیار جدید ایجاد شد که می‌توان آنها را در مرورگر کروم جمع‌آوری کرد.

سه مورد از این معیارها Core Web Vitals را تشکیل می دهند:

• بزرگترین رنگ محتوایی
• تعامل با Next Paint.
• تغییر چیدمان تجمعی.

بزرگترین رنگ محتوایی

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

می‌توانید نمونه‌ای از LCP را در این نوار فیلم سرعت صفحه نمایش DebugBear مشاهده کنید، که نشان می‌دهد چه محتوایی برای کاربران در مقاطع مختلف زمانی قابل مشاهده است.

در اینجا محتوا پس از 1.27 ثانیه شروع به نمایش می کند.

با این حال، تصویر سمت راست توسط کروم به عنوان عنصر 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 گزارش می دهد که بین دو مهر زمانی در طول یک تعامل صفحه چقدر زمان سپری شده است:

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

برای مثال، این نوار فیلم نشان می‌دهد که روی دکمه «مشاهده جزئیات» کلیک می‌شود.

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

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

تغییر چیدمان تجمعی

متریک تغییر چیدمان تجمعی (CLS) بررسی می کند که آیا محتوای صفحه پس از ظاهر شدن از نظر بصری پایدار است یا خیر.

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

این اسکرین شات نمونه ای از تغییر چیدمان را نشان می دهد که در طول فرآیند بارگذاری صفحه اتفاق می افتد.

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

CLS “تجمعی” نامیده می شود زیرا تأثیر تغییرات مختلف جمع می شود.

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

ارزیابی حیاتی وب اصلی گوگل چیست؟

گوگل یک ارزیابی Core Web Vitals را در وب سایت شما انجام می دهد و از نتایج به عنوان سیگنال رتبه بندی استفاده می کند.

اگر وب‌سایت شما با Core Web Vitals مطابقت نداشته باشد، در ابزارهای مختلف، به عنوان مثال، هشدار «ارزیابی هسته‌های حیاتی وب: ناموفق» در Page Speed ​​Insights هشدار دریافت خواهید کرد.

داده‌های ارزیابی Core Web Vitals از گزارش تجربه کاربر Chrome (CrUX) می‌آید که داده‌های واقعی کاربر را از کاربران Chrome جمع‌آوری می‌کند.

علاوه بر PageSpeed ​​Insights، کنسول جستجوی Google همچنین موارد حیاتی وب شما را بررسی می‌کند و توضیح می‌دهد که چه URLهایی «خوب» در نظر گرفته نمی‌شوند.

چه چیزی باعث می شود که یک ارزیابی حیاتی وب اصلی خوب انجام شود؟

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

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

نحوه سرعت بخشیدن به بزرگترین رنگ محتوایی (LCP)

برای بهبود LCP خود، باید محتوای اصلی وب سایت خود را سریعتر بارگذاری کنید.

1. برای درک اینکه چه چیزی باعث تاخیر محتوای اصلی صفحه وب شما می شود، یک تست سرعت وب سایت رایگان اجرا کنید.
2. دریافت و بررسی بینش از نوار فیلم بصری و معیارهای عملکرد سطح بالا برای کشف مراحل بعدی شما.
3. از این بینش ها برای بهینه سازی سرعت بارگذاری صفحه خود استفاده کنید.

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

این به شما نشان می دهد:

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

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

نتیجه آزمون DebugBear همچنین بسیاری از توصیه های خودکار را ارائه می دهد و آنها را بر اساس تأثیر مورد انتظار رتبه بندی می کند.

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

تنها 64 درصد از وب سایت های تلفن همراه در حال حاضر یک تجربه INP خوب ارائه می دهند، که آن را به یک معیار مهم برای بهینه سازی تبدیل می کند.

اشکال زدایی معیار INP ممکن است سخت باشد زیرا به تعامل کاربر بستگی دارد که به راحتی قابل آزمایش نیست.

می‌توانید تعاملات صفحه را به‌صورت دستی آزمایش کنید و با استفاده از نمایه عملکرد Chrome DevTools اندازه‌گیری کنید.

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

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

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

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

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

• تاخیر ورودی
• زمان پردازش.
• تاخیر ارائه

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

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

تأخیر ارائه، مدت زمان سپری شده بین رویدادی که انجام می شود و رنگ بعدی را اندازه می گیرد. در صورتی که رندر صفحه پیچیده باشد، یا اگر پردازش های دیگر CPU در زمان انجام تعامل در صف قرار گرفته باشد، این عدد می تواند زیاد باشد.

نحوه کاهش تغییر چیدمان تجمعی

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

اگر تغییر چیدمان در حین بارگذاری اولیه صفحه اتفاق بیفتد، تشخیص آن با موارد زیر آسان است:

1. اجرای تست سرعت صفحه
2. با کلیک بر روی عنوان متریک “Cumulative Layout Shift” ببینید چه عناصر صفحه جابجا شده اند.
3. رفع عنصری که باعث جابجایی می شود.

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

نحوه رفع تغییرات چیدمان

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

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

اگر تکرار نمره CLS شما سخت است، می‌توانید از مانیتورینگ کاربر واقعی DebugBear استفاده کنید تا ببینید چه چیزی باعث تغییر چیدمان برای کاربران واقعی شما می‌شود.

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

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

اگر برای قبولی در ارزیابی Core Web Vitals مشکل دارید، مانیتورینگ DebugBear می‌تواند به شما کمک کند تا مشکلات وب‌سایت خود را شناسایی کنید و مطمئن شوید که در صورت بروز مشکل هشدار دریافت می‌کنید.

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

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

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

داشتن گزارش‌های آزمایشگاهی دقیق و داده‌های واقعی کاربر به شما امکان می‌دهد از داده‌های Google CrUX که بر رتبه‌بندی تأثیر می‌گذارد و با تأخیر ۲۸ روزه گزارش می‌شود، پیشی بگیرید. DebugBear بینش های قدرتمندی را در مورد Core Web Vitals ارائه می دهد و به شما کمک می کند با بقیه تیم و مدیریت خود ارتباط برقرار کنید.

برای شروع بهینه سازی وب سایت خود آماده اید؟ برای DebugBear ثبت نام کنید و داده هایی را که برای ارائه تجربیات عالی به کاربر نیاز دارید، دریافت کنید.