Core Web Vitals چیست؛ چک‌لیست ۱۴ موردی قبل از انتشار

در چک‌لیست Core Web Vitals در وردپرس؛ ۷ مورد قبل از انتشار چک‌لیست هفت‌موردیِ وردپرس‌محور را نوشته‌ایم؛ آن مقاله از پنجرهٔ وردپرس و افزونه‌ها نگاه می‌کند. این مقاله چهارده موردِ مستقل از پلتفرم است — برای هر سایت فارسی، چه وردپرس چه اختصاصی — و ترتیبش از همان منطق سه سنجه پیروی می‌کند؛ آن مقاله ابزار را می‌بیند، این مقاله قواعد را.

چرا چک‌لیست پیش از انتشار؟ چون این سنجه‌ها بعد از انتشار با دادهٔ کاربران واقعی پر می‌شوند و افتشان را دیر می‌بینید: گزارش میدانی جمع‌شدنش هفته‌ها طول می‌کشد و در این فاصله، تجربهٔ بد به اعتماد و رفتار کاربران هزینه می‌زند. بیست دقیقه بازبینی پیش از انتشار، ارزان‌ترین بیمهٔ سرعت سایت است.

Core Web Vitals چیست؛ سه سنجه و آستانه‌های رسمی

Core Web Vitals چیست و چطور خوانده می‌شود؟ سه سنجه را با آستانه‌های رسمی مستندات web.dev گوگل بخوانید (تاریخ گردآوری: آبان ۱۴۰۵): LCP — بزرگ‌ترین عنصر محتوایی صفحه — باید در حد ۲٫۵ ثانیه یا کمتر رندر شود؛ INP — سنجهٔ پاسخ‌گویی به تعامل — در حد ۲۰۰ میلی‌ثانیه؛ و CLS — جابه‌جایی چیدمان — در حد ۰٫۱ یا کمتر. این سه، تجربهٔ سرعت را در سه بعد می‌سنجند: بارگذاری، تعامل و پایداری.

نکتهٔ خواندن این اعداد، حاشیهٔ سکوتشان است: آستانه‌ها «خوب» را تعریف می‌کنند، نه سقف بی‌ریسک. صفحه‌ای که همیشه نزدیک مرز حرکت می‌کند، با هر اسکریپت تازه به سمت «بد» می‌لغزد؛ به تجربهٔ ما هدف عملی تیم باید میانگینِ راحت زیر آستانه باشد، نه لب‌مرزی بودن. به همین دلیل چک‌لیست پیش از انتشار را جدی بگیرید؛ بعد از انتشار، وضعیت صفحه با دادهٔ کاربران ثبت می‌شود و اصلاح دیرتر، اثرش را هم با تأخیر نشان می‌دهد. در بخش‌های سه تا پنج، هر سنجه را به تیک‌های اجرایی تقسیم کرده‌ایم.

دادهٔ میدانی یا آزمایشگاهی؛ تفاوتی که تصمیم را عوض می‌کند

دو منبع داده را از هم تفکیک کنید، چون تصمیم‌های متفاوتی از هرکدام می‌آید. دادهٔ آزمایشگاهی، اندازه‌گیری کنترل‌شده در محیط تست است — ابزارهایی مثل لایت‌هاوس — و ارزشش این است که قبل از انتشار و در حالت تکرارپذیر ایراد را نشان می‌دهد؛ دقیقاً همان چیزی که چک‌لیست این مقاله می‌سنجد. دادهٔ میدانی، تجربهٔ واقعی کاربران در ده‌ها دستگاه و شبکهٔ متفاوت است و تنها داوری نهایی سرعت صفحه است.

خطای رایج، قضاوت فقط با یکی از این دو است: تیمی که فقط آزمایشگاهی تست می‌کند، شبکهٔ کند و گوشی ارزان کاربرش را نمی‌بیند؛ تیمی که فقط میدانی رصد می‌کند، بعد از انتشار و با تأخیر متوجه می‌شود. به تجربهٔ ما ترکیب درست این است: پیش از انتشار با دادهٔ آزمایشگاهی ببندید، پس از انتشار با دادهٔ میدانی راستی‌آزمایی کنید و اختلاف دو عدد را سرنخ بگیرید، نه بهانهٔ بحث. اختلاف بزرگ این دو عدد هم معمولاً یعنی دستگاه یا شبکهٔ مخاطب واقعی شما ضعیف‌تر از محیط تست است؛ آن را در تصمیم بعدی لحاظ کنید، نه در گزارش توجیهی.

شش مورد برای LCP؛ از سرور تا فونت

شش مورد LCP را از سطح سرور شروع کنید. تیک اول، پاسخ اولیهٔ سرور است: اگر درخواست اول دیر برگردد، بقیهٔ بهینه‌سازی‌ها دیر شروع می‌شوند؛ تشخیص و رسیدگی به آن را در آموزش گام‌به‌گام TTFB و سرعت سرور؛ از هاست تا لایهٔ کش کامل نوشته‌ایم. تیک دوم، وزن و فرمت تصویر اصلی است؛ بزرگ‌ترین عنصر LCP اغلب همان تصویر شاخص است و فشرده‌سازی و فرمت نوین، بیشترین اثر واحد را دارد. تیک سوم، پیش‌بارگذاری تصویر اصلی و فونت‌های حیاتی است تا کشف دیرهنگام، رندر را عقب نبرد.

تیک چهارم، تعویق اسکریپت‌های غیرضروری است؛ هر جاوااسکریپتی که در مسیر رندر اولیه نباشد باید به بعد از بارگذاری منتقل شود. تیک پنجم، لایهٔ کش و توزیع محتواست تا نسخهٔ آماده برای کاربر تکراری و کاربر دور سریع‌تر برسد. تیک ششم، آزمون واقع‌گرایانه است: صفحه را روی دستگاه ضعیف‌تر و شبکهٔ کند آزمایش کنید؛ عددی که روی لپ‌تاپ قوی خوب است، هنوز معیار کاربر موبایل شما نیست.

چهار مورد برای INP؛ تعامل بدون معطلی

چهار مورد INP همه به یک پرسش برمی‌گردند: وقتی کاربر کلیک می‌کند، صفحه چقدر سریع جواب رفتاری می‌دهد؟ تیک اول، حجم جاوااسکریپت در مسیر تعامل است؛ کد سنگین روی رشتهٔ اصلی، کلیک را پشت صف نگه می‌دارد. تیک دوم، شکستن کارهای طولانی است: وظایفی که چندصد میلی‌ثانیه رشتهٔ اصلی را می‌گیرند باید تکه‌تکه شوند تا تعامل وسطشان جا شود.

تیک سوم، بازخورد بصری فوری است: حالت فشرده‌شدن دکمه، پیام «در حال ثبت» یا چرخ‌دندهٔ کوچک، درک کاربر از پاسخ‌گویی را حتی وقتی پردازش ادامه دارد حفظ می‌کند؛ INP بدترین تعامل را می‌سنجد، پس مهم‌ترین تعامل‌ها — منو، فرم، افزودن به سبد — را اول بسنجید. تیک چهارم، آزمون انگشتی است: منو و فرم و مودال را روی موبایل واقعی بزنید و معطلی را حس کنید؛ عدد را تجربهٔ انگشت هم تأیید یا رد می‌کند و نتیجهٔ آزمون را در فرم انتشار ثبت کنید. صفحه‌ای که همهٔ تیک‌های LCP را دارد ولی فرمش سه ثانیه سکوت می‌کند، هنوز منتشرشدنی نیست.

چهار مورد برای CLS؛ پایداری چیدمان

چهار مورد CLS از جنس «چیزها از جایشان تکان نخورند» است. تیک اول، ابعاد صریح تصاویر و ویدیوهاست: عرض و ارتفاع در خود تگ یا با نسبت ابعاد اعلام شود تا مرورگر جایش را از اول رزرو کند. تیک دوم، فضای رزروشده برای بنرها، جاسازی‌ها و بلوک‌های دیررس است؛ هر عنصری که بعداً از بالا می‌آید و متن را پایین می‌راند، همان لحظهٔ بدِ کلیک‌به‌جای‌دیگر را می‌سازد.

تیک سوم، فونت‌هاست: از نمایش جایگزین با فونت fallback هم‌اندازه استفاده کنید تا جایگزینی فونت نهایی، متن را نلغزاند؛ تفاوت یک‌دو پیکسلی در کل پاراگراف، جمع می‌شود و عدد CLS را بالا می‌برد. تیک چهارم، پرهیز از تزریق محتوا بالای خط‌تا پس از رندر است: اعلان‌ها و نوارهای دیررس را جای ثابت بدهید یا پایین صفحه بگذارید. پایداری چیدمان کمتر دیده می‌شود ولی بیشترین اعتمادسوزی را دارد؛ کاربر دکمه را نشانه می‌گیرد و صفحه قاف را جابه‌جا می‌کند؛ برای همین هر چهار تیک را پیش از انتشار روی صفحهٔ واقعی اجرا کنید، نه در ذهن.

رصد پس از انتشار؛ سرچ‌کنسول و ریتم بازبینی

پس از انتشار، رصد را با گزارش Core Web Vitals سرچ‌کنسول انجام دهید؛ این گزارش صفحات را بر اساس دادهٔ میدانی در سه وضعیت می‌گذارد و صفحات ضعیف را تفکیک می‌کند (تاریخ گردآوری: آبان ۱۴۰۵). ریتم پیشنهادی ما بازبینی هفتگیِ فهرست صفحات ضعیف و بررسی ماهانهٔ روند کلی است؛ پرش یک‌روزه را با تغییرات اخیر سایت تطبیق بدهید — افزونهٔ تازه، قالب تازه یا بنر جدید معمولاً متهم اول است.

اگر عدد بعد از انتشار افت کرد، اول علت را پیدا کنید و بعد دست به اصلاح بزنید؛ فهرست آمادهٔ خطاهای رایج را در ۱۰ اشتباه رایج در Core Web Vitals در وردپرس و راه‌حل هرکدام نوشته‌ایم. به تجربهٔ ما اصلاح‌های پراکنده و هم‌زمان، مسئولیت‌پذیری را گم می‌کند: هر تغییر را جدا اعمال کنید، در پنجرهٔ مشخصی دوباره اندازه بگیرید و فقط آن‌چه عدد را واقعاً جابه‌جا کرد، مکتوب نگه دارید. رصد بدون ثبت، دو ماه بعد همان بحث از اول شروع می‌شود.

جمع‌بندی؛ چهارده تیک، سه سنجه، یک ریتم

جمع‌بندی در سه خط: Core Web Vitals سه سنجهٔ بارگذاری، تعامل و پایداری است با آستانه‌های رسمی که «خوب» را تعریف می‌کنند؛ چهارده تیک این مقاله آن را به بازبینی بیست‌دقیقه‌ای پیش از انتشار تبدیل می‌کند — شش تیک LCP از سرور تا فونت، چهار تیک INP روی تعامل‌های واقعی و چهار تیک CLS برای پایداری چیدمان — و پس از انتشار، دادهٔ میدانی سرچ‌کنسول داوری نهایی است.

اگر بخواهید این ریتم سیستمی شود، هاب سئو فنی نقشهٔ کامل خوشهٔ سئو فنی است و امکانات رصد و انتشار سوئیت نشان می‌دهد رصد و انتشار امن در سوئیت چطور در یک زنجیره جمع شده است. و اگر ندانید صفحه‌های سایت‌تان از کجا باید شروع شوند، ممیزی رایگان دامنه اولویت‌ها را با داده می‌دهد؛ سرعت، بضاعتِ هر تلاش دیگری در صفحه است — صفحه‌ای که دیر می‌آید، حتی محتوای درستش هم دیر دیده می‌شود؛ و چک‌لیست را در فرم انتشار تیم ثبت کنید تا به حافظهٔ افراد وابسته نماند.

رصد ما، رشد شما.