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

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

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

سنجه‌های Core Web Vitals وردپرس در یک نگاه

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

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

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

چک‌لیست هفت‌موردی پیش از انتشار

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

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

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

LCP؛ سرور، تصویر و فونت

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

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

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

INP؛ تعامل و جاوااسکریپت

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

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

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

CLS؛ پایداری چیدمان

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

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

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

بعد از انتشار؛ پایش و تفسیر داده

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

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

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