راهنمای کامل Core Web Vitals در وردپرس؛ از صفر تا اجرا

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

چرا مخصوص وردپرس؟ چون وردپرس نزدیک ۴۳ درصد همهٔ وب‌سایت‌های جهان را پوشش می‌دهد (W3Techs — تاریخ گردآوری: آبان ۱۴۰۵) و بخش بزرگی از این سایت‌ها با قالب و افزونه اداره می‌شوند که هر کدام می‌توانند بار اضافه سوار کنند. خبر خوب این است که هر سنجه، منشأهای مشخصی دارد و رفع‌شان ترتیب اثر دارد؛ با همان ترتیب پیش می‌رویم.

Core Web Vitals در وردپرس یعنی چه؟ سه سنجه و آستانه‌ها

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

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

از کجا بسنجید؟ دادهٔ میدانی و آزمایشگاهی

دو دید دارید و هر دو لازم‌اند. دادهٔ میدانی، تجربهٔ واقعی بازدیدکنندگان شما در بازهٔ حدوداً ۲۸ روزه است و گزارش Core Web Vitals در سرچ‌کنسول آن را به تفکیک موبایل و دسکتاپ می‌دهد؛ این داده حکم می‌دهد. دادهٔ آزمایشگاهی، تست تک‌بار یک صفحه در ابزار رایگان PageSpeed Insights است؛ این داده عیب‌یابی می‌کند و می‌گوید کدام عنصر، کجای مسیر را کند کرده است.

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

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

ترتیب رفع؛ از پراثر به کم‌اثر

رفع را به ترتیب اثر بچینید، نه به ترتیب سلیقه. لایهٔ اول تصاویر و فونت‌هاست؛ ارزان‌ترین اصلاح‌ها با بیشترین اثر روی LCP. لایهٔ دوم اسکریپت‌های قالب، افزونه و سرویس‌های جانبی است؛ منشأ اصلی INP. لایهٔ سوم رزرو جای عناصر است؛ منشأ اصلی CLS. لایهٔ چهارم خود قالب و صفحه‌ساز است که بار پایهٔ همهٔ صفحات را تعیین می‌کند. لایهٔ پنجم هاست و CDN است؛ وقتی لایه‌های قبلی تمیز شد و فاصله با آستانه‌ها هنوز باز بود.

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

رفع LCP؛ تصاویر، فونت و عنصر اصلی صفحه

عنصر LCP در وردپرس معمولاً تصویر شاخص نوشته یا تصویر هدر است. کارهای پراثر به ترتیب: تصویر را به اندازهٔ واقعی نمایش فشرده کنید — تصویر ۳۰۰۰ پیکسلی برای قابی که ۸۰۰ پیکسل نمایش داده می‌شود فقط بار بی‌مصرف است — فرمت مدرن‌تر انتخاب کنید و تصویر شاخص را زودهنگام بارگیری کنید. تعویق بارگیری برای تصاویر پایین صفحه درست است، ولی برای تصویر LCP خطرناک؛ چون همان عنصری است که باید زود دیده شود.

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

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

رفع INP؛ اسکریپت‌ها و کارهای سنگین مرورگر

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

یک هشدار صادقانه: تعویق اسکریپت خودش می‌تواند منو یا فرم را موقتاً از کار بیندازد یا پرش چیدمان بسازد؛ پس بعد از هر تعویق، منو و دکمه‌های اصلی را دستی تست کنید و دادهٔ میدانی را دوباره بخوانید. به تجربهٔ ما تعویقِ هدفمند دو سه اسکریپت سنگین، مؤثرتر از خاموش‌کردن عمومی همه‌چیز است.

رفع CLS؛ پایداری چیدمان در سه عادت

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

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

پایش؛ روال ماهانه و سه زنگ خطر

پایش یعنی روال، نه نگرانی روزانه. ماهی یک بار گزارش Core Web Vitals سرچ‌کنسول را با بازهٔ ۲۸ روزه باز کنید و سه سنجه را جدا برای موبایل و دسکتاپ یادداشت کنید؛ و بلافاصله بعد از هر تغییر بزرگ — قالب تازه، افزونهٔ تازه، جابه‌جایی هاست — همان گزارش را دوباره بخوانید. یک برگهٔ ساده با چهار ستون (تاریخ، LCP، INP، CLS) کافی است.

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

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

جمع‌بندی؛ از صفر تا اجرا در دو هفته

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

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

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