Core Web Vitals در سیستم‌های رتبه‌بندی Google استفاده می‌شود، اما خوب بودن این معیارها تضمین رتبهٔ بالا نیست. راهنمای رسمی Search Central این دو نکته را کنار هم بیان می‌کند. برای مدیر سایت، نتیجهٔ عملی این است که سرعت و پایداری رابط را به‌عنوان کیفیت تجربه پیگیری کند و از وعدهٔ افزایش تعداد مشخصی رتبه پرهیز کند. نتیجهٔ جست‌وجو به عوامل دیگری هم وابسته است و نمی‌توان آن را از یک امتیاز کارایی محاسبه کرد.
نسخهٔ قبلی مقاله یک مطالعهٔ ده‌میلیون‌صفحه‌ای و افزایش رتبه‌های عددی برای LCP، INP و CLS نقل می‌کرد، اما منبع قابل بررسی نداشت. آن اعداد و وعدهٔ بازگشت سرمایهٔ تضمین‌شده حذف شده‌اند. حتی یک همبستگی واقعی نیز به‌تنهایی نشان نمی‌دهد که تغییر یک معیار، همان مقدار افزایش رتبه ایجاد می‌کند. محتوای سایت، نوع Query، رقابت و تغییرهای هم‌زمان باید در تحلیل دیده شوند. دقت در این مرز از تصمیم مالی بر اساس یک نمودار بی‌زمینه جلوگیری می‌کند.
هر معیار به یک تجربهٔ مشخص اشاره می‌کند
LCP دربارهٔ زمان نمایش بزرگ‌ترین محتوای قابل مشاهده در محدودهٔ دید است. INP به پاسخ‌گویی تعامل‌ها مربوط می‌شود و CLS جابه‌جایی‌های غیرمنتظرهٔ چیدمان را می‌سنجد. معرفی Web Vitals در web.dev تعریف و دامنهٔ این معیارها را توضیح می‌دهد. این سه را یک عدد عمومی «سرعت سایت» فرض نکنید. ممکن است تصویر اصلی دیر برسد، ولی دکمه‌ها پاسخ مناسبی داشته باشند؛ یا صفحه زود نمایش داده شود و هنگام کلیک کند عمل کند.
برای مثال، در یک صفحهٔ محتوایی فرضی، تصویر بزرگ بالای صفحه دیر دریافت می‌شود. در همان صفحه، دکمهٔ باز کردن فهرست سریع پاسخ می‌دهد و چیدمان ثابت است. مسئلهٔ اول را باید در مسیر دریافت و نمایش محتوای اصلی جست‌وجو کرد. تغییر handler دکمه لزوماً آن را حل نمی‌کند. در صفحه‌ای دیگر، تصویر به‌موقع نمایش داده می‌شود ولی فیلتر سنگین فهرست، پاسخ کلیک را به تأخیر می‌اندازد. نیاز این دو صفحه متفاوت است.
آستانه‌ها برای تفسیرند، نه وعدهٔ رتبه
برای وضعیت خوب، مرجع رسمی LCP را حداکثر ۲٫۵ ثانیه، INP را حداکثر ۲۰۰ میلی‌ثانیه و CLS را حداکثر ۰٫۱ معرفی می‌کند. این مرزها با ارزیابی در صدک هفتاد و پنجم تجربه‌های بازدید و تفکیک مناسب محیط همراه‌اند. صفحهٔ توضیح آستانه‌های Core Web Vitals زمینهٔ این انتخاب‌ها را شرح می‌دهد. این اعداد را نباید به فرمولی مانند «هر صد میلی‌ثانیه برابر یک رتبه» تبدیل کرد.
صدک، میانگین نیست. اگر بخشی از کاربران تجربهٔ ضعیفی داشته باشند، یک میانگین خوشایند ممکن است آن گروه را پنهان کند. از سوی دیگر، یک اجرای آزمایشی بسیار کند نیز به‌تنهایی وضعیت همهٔ مخاطبان را توضیح نمی‌دهد. برای گزارش مدیریتی، نوع عدد را نام ببرید و دامنهٔ آن را حفظ کنید. عبارت «صفحه در دو ثانیه باز می‌شود» بدون دستگاه، شبکه و نوع معیار، نتیجه‌ای کامل و قابل پیگیری نیست.
دادهٔ آزمایشگاهی و دادهٔ کاربران واقعی
اندازه‌گیری آزمایشگاهی با شرایط کنترل‌شده به پیدا کردن مشکل کمک می‌کند. دادهٔ میدانی تجربهٔ بازدیدهای واقعی را جمع می‌کند و تحت تأثیر دستگاه‌ها و شبکه‌های متنوع است. اختلاف این دو الزاماً خطای ابزار نیست. یک laptop سریع در آزمایش محلی ممکن است handler سنگین را زود تمام کند، در حالی که گوشی ضعیف‌تر برای همان کار وقت بیشتری لازم دارد. هدف این است که هر منبع را برای سؤال مناسب استفاده کنیم.
اگر صفحه بازدید کافی برای گزارش میدانی ندارد، نبود عدد را با خوب بودن وضعیت یکی ندانید. در این حالت، دادهٔ محدود و آزمایش‌های هدفمند هنوز برای شناخت مسیر مفیدند، اما نتیجه باید با محدودیتش گزارش شود. گرفتن میانگین چند صفحهٔ متفاوت و نسبت دادن آن به هر URL نیز می‌تواند مشکل را پنهان کند. صفحهٔ پرداخت و مقالهٔ کوتاه ممکن است منابع و تعامل‌های بسیار متفاوتی داشته باشند و نیاز به گروه‌بندی جدا داشته باشند.
LCP را از مسیر محتوای اصلی پیگیری کنید
برای تصویر اصلی، اندازهٔ فایل، زمان کشف منبع و اولویت دریافت می‌توانند مهم باشند. اما پیش از کوچک کردن هر تصویر، مشخص کنید عنصر LCP واقعی چیست. شاید در یک صفحه عنوان بزرگ باشد و در صفحهٔ دیگر تصویر. بهینه‌سازی فایل نامرتبط، عدد مورد نظر را تغییر نمی‌دهد. از فهرست منابع و مسیر رندر سرنخ بگیرید و تغییر را به همان عنصر متصل کنید. یک دستور عمومی برای تمام فایل‌های سایت، جای تشخیص را نمی‌گیرد.
اندازهٔ نمایش و فایل دریافتی باید با هم تناسب داشته باشند. ارسال تصویر بسیار بزرگ برای یک جای کوچک هزینهٔ شبکه ایجاد می‌کند، ولی فشرده‌سازی افراطی نیز ممکن است خواندن محتوا را سخت کند. کیفیت مورد نیاز را با نقش تصویر بسنجید؛ نوشتهٔ داخل نمودار با عکس تزئینی فرق دارد. برای ادامه، راهنمای اندازه و فرمت تصویر وب مرتبط است. نتیجهٔ هر تغییر باید به کیفیت و زمان دریافت همان صفحه محدود بماند.
INP به کاری که بعد از تعامل انجام می‌شود مربوط است
اگر کلیک یک فیلتر، پردازش سنگینی را در مسیر اصلی مرورگر انجام دهد، نمایش پاسخ ممکن است عقب بیفتد. کوچک کردن تصویر اصلی لزوماً این کار را سبک نمی‌کند. ابتدا وظیفهٔ handler را مرور کنید: آیا همهٔ محاسبات همان لحظه لازم‌اند؟ آیا دادهٔ بی‌ربط پردازش می‌شود؟ آیا رندر تعداد زیادی آیتم ایجاد می‌کند؟ پاسخ این پرسش‌ها مسیر اصلاح را روشن می‌کند. نام فریمورک نیز به‌تنهایی کیفیت پاسخ‌گویی را تضمین نمی‌کند.
بازخورد بصری باید معنی روشنی داشته باشد. نمایش حالت در حال انجام برای یک عملیات شبکه‌ای به کاربر کمک می‌کند، ولی نباید شکست واقعی را پنهان کند. اگر دکمه فقط ظاهراً پاسخ دهد و نتیجه هیچ‌گاه معلوم نشود، بهبود یک رفتار نمایشی کافی نیست. متن وضعیت، موفقیت و خطا باید بخشی از جریان باشند. کیفیت تعامل با معیار قابل اندازه‌گیری مرتبط است، اما تمام معنای تجربهٔ کاربر در همان عدد خلاصه نمی‌شود.
CLS را با فضای مورد انتظار محتوا کنترل کنید
تصویری که پس از دریافت، محتوای پایین را جابه‌جا می‌کند، نمونه‌ای از مشکل چیدمان است. تعیین اندازه یا نسبت مناسب برای جای آن می‌تواند از جابه‌جایی جلوگیری کند. برای اعلان، تبلیغ و محتوای پویا هم باید رفتار مشخص باشد. اضافه شدن یک بلوک بالای دکمه‌ای که کاربر آمادهٔ کلیک آن است، مسئله‌ای واقعی ایجاد می‌کند. طراحی فضای مورد انتظار باید با محتوای محصول هماهنگ باشد، نه اینکه فقط عدد گزارش را هدف بگیرد.
تعویض فونت نیز ممکن است شکست خط و اندازهٔ عناصر را تغییر دهد. اگر عنوان از دو خط به سه خط تبدیل شود، بخش‌های پایین حرکت می‌کنند. انتخاب fallback نزدیک‌تر و مرور اندازه‌ها به فهم مشکل کمک می‌کند. راهنمای تشخیص فونت فارسی برای این بخش مرتبط است. هر جابه‌جایی را به یک منبع مشخص وصل کنید تا تیم به‌جای تغییر تصادفی marginها، علت واقعی را اصلاح کند.
SEO را با مسئلهٔ محتوای صفحه کنار هم ببینید
صفحه‌ای که به سؤال کاربر جواب نمی‌دهد، با امتیاز کارایی خوب به پاسخ مناسب تبدیل نمی‌شود. راهنمای Page Experience در Google تجربهٔ خوب را در کنار عوامل دیگر توضیح می‌دهد. بنابراین برنامهٔ بهبود باید هم کیفیت محتوا و هم اصطکاک استفاده را در نظر بگیرد. تقسیم کار میان نویسنده و توسعه‌دهنده مفید است، اما هدف هر دو باید همان صفحه و نیاز خواننده باشد.
برای بودجه‌بندی، مشکل را با دامنهٔ اثر و هزینهٔ اصلاح بنویسید. اگر یک component مشترک در چند صفحه جابه‌جایی ایجاد می‌کند، اصلاح آن ممکن است به گروه بزرگی از صفحات کمک کند. اگر مشکل فقط یک فایل قدیمی است، دامنه کوچک‌تر خواهد بود. این ارزیابی بهتر از وعدهٔ درآمد تضمین‌شده است. پس از تغییر، نتیجهٔ قابل مشاهده و محدودیت داده را ثبت کنید و دربارهٔ رتبه فقط چیزی بگویید که گزارش واقعی اجازه می‌دهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!