بهینه‌سازی Core Web Vitals در وردپرس چگونه انجام می‌شود؟

چند سال پیش روی یک پروژه شرکتی، شش هفته وقت گذاشتم تا امتیاز PageSpeed دسکتاپ را از ۷۲ به ۹۸ برسانم. همان هفته، گزارش میدانی گوگل در Search Console نشان داد سایت در موبایل همچنان قرمز است. آن تجربه به من یاد داد که بهینه‌سازی Core Web Vitals در وردپرس اگر بدون شناخت لایه مقصر انجام شود، فقط عدد آزمایشگاهی را زیبا می‌کند و تجربه کاربر واقعی را تغییر نمی‌دهد.

چرا وردپرس بیشتر از هر پلتفرم دیگری در Core Web Vitals آسیب می‌بیند؟

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

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

نکته دوم این که Core Web Vitals در وردپرس با سایت‌های ساده فرق دارد؛ در وردپرس، هر افزونه می‌تواند فایل خودش را در head تزریق کند، فونت خودش را لود کند، کوئری خودش را در هر بازدید بزند. به همین دلیل، بهینه‌سازی باید از لایه افزونه‌ها شروع شود، نه از لایه CSS و JS. برای درک این ترتیب، افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند؟ تصویر دقیقی از چهار لایه اثر افزونه‌ها می‌دهد.

نکته سوم و شاید مهم‌ترین: بخش بزرگی از سایت‌های وردپرسی روی هاست‌های اشتراکی ارزان اجرا می‌شوند و همان هاست، پیش از هر افزونه‌ای، سقف TTFB (Time To First Byte) را تعیین می‌کند. تا زمانی که این سقف پایین باشد، هر بهینه‌سازی دیگری فقط روی حاشیه اثر می‌گذارد. تحلیل این مسئله در تاثیر هاست بر سرعت سایت چقدر است؟ با هفت کانال مشخص بررسی شده است.

در وردپرس، کندی از جایی می‌آید که کسی به آن نگاه نمی‌کند؛ بهینه‌سازی از جایی شروع می‌شود که آن نقطه کور را پیدا کنید.

Core Web Vitals در وردپرس دقیقاً چه چیزی را می‌سنجد؟

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

LCP (Largest Contentful Paint) سرعت نمایش بزرگ‌ترین عنصر در دید اول را می‌سنجد. در وردپرس، این عنصر تقریباً همیشه یا تصویر شاخص است یا بنر هدر یا یک تیتر بزرگ. CLS (Cumulative Layout Shift) مجموع پرش‌های چیدمانی هنگام بارگذاری را می‌شمارد؛ در وردپرس این پرش‌ها معمولاً از تبلیغات دیررس، فونت‌های بی‌ابعاد، و ویجت‌های JavaScriptی که بعد از رندر ظاهر می‌شوند می‌آید. INP (Interaction to Next Paint) فاصله میان لمس کاربر و نقاشی بعدی صفحه را اندازه می‌گیرد؛ در وردپرس، INP به‌طور مستقیم به تعداد و وزن اسکریپت‌هایی وابسته است که روی main thread اجرا می‌شوند.

درک این تفکیک اهمیت بسیاری دارد؛ چون استراتژی بهینه‌سازی هر شاخص کاملاً متفاوت است. برای مثال، افزونه کش صفحه که LCP و TTFB را به‌شدت بهبود می‌دهد، روی INP تقریباً اثری ندارد؛ و حذف یک اسکریپت سنگین که INP را نجات می‌دهد، LCP را تغییر نمی‌دهد. اگر این مرزها را نشناسید، ممکن است دو هفته روی بهینه‌سازی شاخصی کار کنید که اصلاً مشکل شما نیست.

LCP در وردپرس: چه چیزی آن را می‌شکند و از کجا شروع کنیم؟

چهار مظنون اصلی در وردپرس بیشترین سهم را در خرابی LCP دارند. این ترتیب، بر اساس ده‌ها پروژه‌ای است که در آن‌ها LCP را ریشه‌یابی کرده‌ام و تقریباً همیشه از همین ترتیب پیروی می‌کند.

مظنون اول: سرعت پاسخ سرور مبدأ

اگر TTFB شما بالای هفتصد میلی‌ثانیه باشد، LCP از همان نقطه شروع با بار سنگینی همراه می‌شود. کش صفحه، ارتقای هاست، بهینه‌سازی کوئری و اجرای cron سرور از جمله اقداماتی هستند که این لایه را بهبود می‌دهند. تحلیل دقیق این متغیر در تأثیر TTFB بر سرعت بارگذاری صفحه با عدد و ابزار آمده است.

مظنون دوم: تصویر شاخص

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

مظنون سوم: lazy-load روی عنصر LCP

از وردپرس نسخه پنج و پنج، lazy-load تصاویر به‌صورت پیش‌فرض فعال است. این ویژگی برای تصاویر زیر خط دید یک نعمت است، اما اگر روی عنصر LCP اعمال شود، آن را نابود می‌کند. راه‌حل، استفاده از fetchpriority=high روی عنصر LCP و loading=eager روی همان تصویر است.

مظنون چهارم: CSS و فونت مسدودکننده

استایل‌های حجیم و فونت‌های با font-display مسدودکننده، رندر را عقب می‌اندازند. یکی از اثرگذارترین اقدامات، استخراج CSS بحرانی و بارگذاری بقیه CSS به‌صورت async است. همچنین تعیین font-display: swap و محدود کردن وزن‌های فونت به دو مورد، در بسیاری از پروژه‌ها به‌تنهایی LCP را نصف کرده است.

در LCP، پیدا کردن مقصر ارزشش بیشتر از حذف ده چیز اضافی است؛ چون تنها یک عنصر است که عدد را تعیین می‌کند.

CLS در وردپرس: پرش‌هایی که چشم کاربر را می‌آزارند

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

در وردپرس، سه منبع اصلی CLS را در پروژه‌های واقعی دیده‌ام: بنرهای تبلیغاتی که بعد از بارگذاری اصلی تزریق می‌شوند، فونت‌های بدون ابعاد رزرو شده، و ویجت‌های JavaScriptی مثل اسلایدرها یا فرم‌های شخصی‌سازی‌شده که ارتفاع قطعی ندارند. راه‌حل هر سه این‌ها ساده است اما نیاز به دقت دارد. برای بنر، باید ظرف با min-height مشخص رزرو شود؛ برای فونت، باید با font-display: swap و اندازه‌های نزدیک فونت جایگزین کار کرد؛ و برای ویجت‌ها، ارتفاع حداقلی اعلام‌شده روی کانتینر لازم است.

نکته‌ای که در اصلاح CLS کمتر دیده‌ام: در قالب‌های چندمنظوره، فایل CSS ممکن است دیرتر از HTML به مرورگر برسد و باعث شود مرورگر ابتدا چیدمان پیش‌فرض و بعد چیدمان اصلی را رندر کند. این پدیده به‌ویژه در سایت‌های فارسی که فونت را از CDN خارجی لود می‌کنند شایع است. راه‌حل، preload فایل CSS قالب و استفاده از فونت وب با fallback نزدیک به فونت فارسی اصلی است.

برای درک دقیق این معیار و روش‌های سنجشش، مقاله CLS چیست و چگونه کاهش می‌یابد؟ با مثال‌های واقعی توضیح داده است. اما اگر بخواهم یک راه‌حل عملی بگویم: در Chrome DevTools، در تب Performance، یک ضبط از بارگذاری صفحه بگیرید و ببینید کدام عناصر در طول رندر جابه‌جا می‌شوند. هر عنصری که Layout Shift خودش را ثبت کرده، یک کاندیدای اصلاح است.

INP در وردپرس: وقتی واکنش صفحه به لمس کاربر دیر می‌رسد

INP سخت‌ترین شاخص برای سبز کردن در وردپرس است، چون مقصر اصلی آن تقریباً همیشه افزونه‌ها هستند. هر افزونه‌ای که روی رویداد scroll یا click لیسنر بسته باشد، هر افزونه‌ای که یک polyfill یا کتابخانه جاوااسکریپت را در هر صفحه لود کند، و هر افزونه‌ای که با یک کوئری سنگین در AJAX درخواست‌های متعدد بزند، سهمی در خرابی INP دارد.

روش تشخیص INP در سطح عملی، ضبط تب Performance در DevTools هنگام تعامل با صفحه است. اگر بین لمس و نقاشی بعدی، یک Long Task در درخت اصلی مرورگر دیده شود، آن افزونه مقصر است. در تجربه من، سه افزونه پرتکرار در این زمینه هستند: اسلایدرهای سنگین، پلاگین‌های پاپ‌آپ خبرنامه، و ابزارهای ترجمه سمت کلاینت که کل DOM را بازنویسی می‌کنند.

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

یک نکته مهندسی که ارزش توجه دارد: INP روی میانگین خوب به‌نظر می‌رسد اما در صدک‌های بالا فاجعه است. اگر INP میانه شما ۱۵۰ میلی‌ثانیه و INP صدک ۷۵ برابر ۳۵۰ میلی‌ثانیه باشد، کاربران با دستگاه‌های ضعیف‌تر تجربه بدی دارند. کاهش INP صدک بالا معمولاً از مسیر حذف افزونه‌های سنگین می‌گذرد، نه بهینه‌سازی میکروسکوپی کد.

لایه زیرساخت: هاست، قالب و افزونه

بسیاری از تیم‌ها بهینه‌سازی Core Web Vitals را از سمت دارایی‌ها (تصویر، فونت، JS) شروع می‌کنند، در حالی که مسئله اصلی در لایه زیرساخت است. ترتیب درست این است که ابتدا زیرساخت تثبیت شود، بعد دارایی‌ها بهینه شوند. اگر این ترتیب را رعایت نکنید، هر بهینه‌سازی دارایی روی یک سقف پایین کار می‌کند و اثرش را از دست می‌دهد.

هاست: سقف پایه سرعت وردپرس

هاست‌های اشتراکی با منابع محدود، در ساعات اوج به سرعت به مرز می‌رسند و TTFB را ناپایدار می‌کنند. اگر در گزارش‌های میدانی شما، Core Web Vitals در برخی ساعات روز قرمز و در بقیه سبز است، تقریباً همیشه مسئله هاست و صف CPU است. راه‌حل، مهاجرت به یک هاست وردپرس‌محور با منابع پایدار یا یک VPS مدیریت‌شده است.

قالب: سقف ساختاری

قالب چندمنظوره با ده‌ها فایل CSS و JS، حتی روی یک هاست عالی، نمی‌تواند به سبزی Core Web Vitals برسد. علتش را در چرا بعضی قالب‌های وردپرس باعث کندی سایت می‌شوند؟ با تحلیل پنج علت توضیح داده‌ام. اگر قالب شما جزء آن دسته است، مهاجرت به یک قالب سبک به‌تنهایی بیش از هر بهینه‌سازی دیگری به Core Web Vitals کمک می‌کند. معیارهای انتخاب را در قالب وردپرس سبک چیست و چگونه سرعت سایت را افزایش می‌دهد؟ جدا کرده‌ام.

افزونه‌ها: مالیات هر بازدید

هر افزونه‌ای که در front-end فایل تزریق می‌کند، سهمی در خرابی Core Web Vitals دارد. حذف افزونه‌های غیرضروری، شاید بیشترین اثر را روی INP و دومین اثر را روی LCP داشته باشد. اگر افزونه‌ای صرفاً برای یک قابلیت کوچک نصب شده که با چند خط کد در چایلد تم قابل بازنویسی است، حذفش تصمیمی یک‌طرفه است.

لایه دارایی‌ها: تصویر، فونت و کش

پس از تثبیت زیرساخت، نوبت به دارایی‌ها می‌رسد. این لایه معروف‌ترین بخش بهینه‌سازی Core Web Vitals است و بیشتر مقالات فقط به همین لایه می‌پردازند، در حالی که بدون لایه زیرساخت اثر کامل ندارد.

تصویر

تصاویر باید فرمت مدرن داشته باشند (WebP به‌طور پیش‌فرض، AVIF در مواردی)، در ابعاد درست تحویل داده شوند، و با srcset کامل به مرورگر برسند. تصویر LCP باید eager و با fetchpriority=high باشد و تصاویر پایین صفحه lazy. نقطه شروع این لایه، فشرده‌سازی فایل‌های موجود کتابخانه است، نه فقط آپلودهای جدید.

فونت

فونت‌های وب در سایت‌های فارسی بزرگ‌ترین منبع پنهان هزینه هستند. یک فونت با چهار وزن و هفت‌هزار گلیف می‌تواند چند صد کیلوبایت به هر بازدید اضافه کند. پیشنهاد من محدود کردن به دو وزن، استفاده از font-display: swap، و بارگذاری محلی فونت به‌جای CDN خارجی است.

کش و CDN

کش صفحه، TTFB و LCP را مستقیم بهبود می‌دهد. انتخاب افزونه کش درست بر اساس نوع هاست بسیار مهم است. CDN هم فایل‌های استاتیک را از شانه PHP و سرور مبدأ برمی‌دارد و مخصوصاً برای مخاطب دور از سرور اثری چشمگیر دارد. در تجربه من، ترکیب کش صفحه درست و CDN، سه شاخص Core Web Vitals را به‌طور همزمان بهتر می‌کند.

بهینه‌سازی Core Web Vitals بدون کش، مثل دویدن روی تردمیل است؛ تلاش زیاد و پیشرفت صفر.

سنجش: چطور از آزمایشگاه به داده میدانی عبور کنیم؟

دو نوع داده در Core Web Vitals وجود دارد و بسیاری از تیم‌ها این دو را قاطی می‌کنند. داده آزمایشگاهی (Lighthouse، PageSpeed Insights) نشان می‌دهد پتانسیل سایت چیست. داده میدانی (CrUX، Search Console) نشان می‌دهد کاربران واقعی چه تجربه‌ای دارند. حکم نهایی برای رتبه و تجربه، داده میدانی است، نه آزمایشگاهی.

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

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

یک نکته که در پروژه‌های ایرانی زیاد به کارم آمده: داده CrUX برای سایت‌های کم‌ترافیک یا وجود ندارد یا از نمونه کوچک می‌آید. در این شرایط، به‌جای داده CrUX، از گزارش‌های سرچ کنسول یا یک اسکریپت سفارشی با web-vitals.js روی سایت خودتان استفاده کنید. این اسکریپت به‌تنهایی می‌تواند تصویر روشنی از توزیع LCP و CLS و INP کاربران واقعی بدهد.

زمانی که بهینه‌سازی Core Web Vitals نتیجه نمی‌دهد

یک باور غلط رایج این است که هر تلاشی در جهت Core Web Vitals لزوماً به نتیجه می‌رسد. در عمل، چند سناریو وجود دارد که سرمایه‌گذاری روی این شاخص‌ها نتیجه اقتصادی نمی‌دهد.

اول، سایت‌های کم‌ترافیک. اگر ترافیک ماهانه شما زیر چند هزار بازدید است، اثر Core Web Vitals بر رتبه نزدیک به صفر است؛ چون گوگل بر اساس داده میدانی تصمیم می‌گیرد و شما داده میدانی معتبری ندارید. در این سناریو، تمرکز بر تولید محتوا و بهبود محتوای موجود بازده بیشتری دارد.

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

سوم، سایت‌هایی که رقیب اصلی در بازار بسیار عقب‌تر است. اگر رقیب شما LCP شش ثانیه دارد و شما چهار، بهینه‌سازی تا دو ثانیه لزوماً رتبه را تغییر نمی‌دهد؛ چون فاکتورهای محتوا و لینک وزن بیشتری دارند. این قاعده در تحلیل سئو تکنیکال چیست و چرا مهم است؟ هم آمده: Core Web Vitals یکی از سیگنال‌هاست، نه تنها سیگنال.

چهارم، سایت‌هایی که در حال حاضر همه سه شاخص سبز دارند. اگر LCP شما زیر دو ثانیه و CLS زیر ۰.۰۵ و INP زیر ۱۵۰ میلی‌ثانیه است، بهینه‌سازی بیشتر بازده کمی دارد. در این وضعیت، بهتر است منابع را روی لایه‌های دیگر مثل سئوی محتوا یا نرخ تبدیل بگذارید. برای این کار، مطالعه رابطه Core Web Vitals و نرخ تبدیل چیست؟ نشان می‌دهد دقیقاً از کجا به بعد، بهبود سرعت بازده نزولی دارد.

اشتباهاتی که تلاش شما را بی‌اثر می‌کند

در ده‌ها پروژه‌ای که Core Web Vitals را بهینه کرده‌ام، پنج اشتباه تکراری دیده‌ام که هرکدام می‌تواند تمام تلاش تیم را بی‌اثر کند.

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

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

اشتباه سوم، اعمال چند تغییر همزمان. قانون طلایی من: یک تغییر، یک اندازه‌گیری، یک نتیجه‌گیری. اگر همزمان تصویر را WebP کنید، افزونه کش را تغییر دهید و فونت را عوض کنید، وقتی عدد بهتر شد نمی‌دانید کدام تغییر عاملش بوده؛ و وقتی عدد بدتر شد نمی‌دانید کدام تغییر را باید برگردانید.

اشتباه چهارم، نادیده گرفتن اثر قالب بعد از آپدیت. هر آپدیت قالب می‌تواند فایل CSS یا JS اضافه کند و Core Web Vitals را خراب کند. توصیه من ثبت ماهانه سه عدد LCP و CLS و INP در یک جدول ساده است تا رگرسیون‌ها را زودتر تشخیص دهید.

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

پرسش‌های پرتکرار درباره بهبود Core Web Vitals در وردپرس

آیا Core Web Vitals روی رتبه گوگل تأثیر مستقیم دارد؟

اثر آن غیرمستقیم و تعدیل‌گر است. محتوای بی‌ربط با نمره کامل هم به رتبه اول نمی‌رسد، ولی در رقابت میان دو صفحه هم‌کیفیت، تجربه بهتر برنده است. بنابراین Core Web Vitals یکی از سیگنال‌ها در کنار محتوا، لینک و اعتبار دامنه است.

ترتیب بهینه‌سازی سه شاخص چگونه باید باشد؟

ترتیب درست به وضعیت سایت شما بستگی دارد، اما قاعده سرانگشتی من: اول زیرساخت (هاست و کش)، دوم LCP (تصویر و فونت)، سوم CLS (رزرو ارتفاع)، چهارم INP (کاهش بار JS). چرا LCP قبل از INP؟ چون معمولاً LCP زودتر تجربه کاربر را خراب می‌کند و اصلاح آن سریع‌تر است.

آیا افزونه کش می‌تواند همه سه شاخص را بهبود دهد؟

نه. افزونه کش خوب، LCP و TTFB را به‌شدت بهتر می‌کند، CLS را معمولاً ثابت نگه می‌دارد، و INP را ممکن است حتی بدتر کند؛ چون برخی افزونه‌های کش خودشان اسکریپت اضافه تزریق می‌کنند. انتخاب افزونه کش باید با تست انجام شود، نه بر اساس مقایسه‌های عمومی.

چرا بعد از بهبود LCP، امتیاز PageSpeed تغییر نمی‌کند؟

احتمالاً مسئله اصلی جای دیگری است. PageSpeed Insights یک نمره تجمیعی می‌دهد و بخشی از اجزای آن مربوط به CSS و JS و بایت‌های اضافی است. برای دیدن بهبود LCP، باید به بخش Largest Contentful Paint خود گزارش نگاه کنید، نه به نمره کلی. در غیر این صورت ممکن است بهبود واقعی در گزارش پنهان بماند.

آیا CDN برای Core Web Vitals ضروری است؟

برای سایت‌هایی با مخاطب تک‌منطقه‌ای و سرور محلی، ضروری نیست. برای سایت‌هایی با مخاطب پراکنده جغرافیایی، اثر CDN بر TTFB و LCP محسوس است. اما نصب CDN بدون کش صفحه درست، اثر خود را نشان نمی‌دهد؛ چون CDN فقط دارایی‌های استاتیک را سرو می‌کند و بخش پویا همچنان روی سرور شما می‌ماند.

هر چند وقت یک‌بار باید Core Web Vitals را پایش کنیم؟

پایش حداقلی ماهانه یک بار، و پایش دقیق پس از هر موج تغییر (آپدیت قالب، افزونه جدید، تغییر هاست). سایت‌هایی که رشد ترافیک دارند، بهتر است هر دو هفته یک بار سه عدد کلیدی را در یک جدول ثبت کنند.

نقشه عملی برای شروع از همین امروز

اگر امروز می‌خواهید واقعاً Core Web Vitals سایت وردپرسی خود را بهبود دهید، این نقشه پنج‌گامی را پیشنهاد می‌کنم. گام اول: پیش از هر تغییری، سه عدد LCP و CLS و INP را از گزارش میدانی سرچ کنسول یادداشت کنید. بدون این نقطه مرجع، بعداً نمی‌توانید اثبات کنید که تغییری مؤثر بوده است. گام دوم: هاست و قالب خود را با یک تست کنترل‌شده بسنجید؛ اگر TTFB بالای هفتصد میلی‌ثانیه است، ابتدا به سراغ هاست بروید، نه تصویر.

گام سوم: افزونه‌های front-end را مرور کنید. هر افزونه‌ای که در روز حداقل یک بار به کارش نیاز ندارید، خاموش و بعد حذفش کنید. این حرکت به‌تنهایی در بیشتر پروژه‌ها INP را بهبود می‌دهد. گام چهارم: تصویر شاخص و بنر هدر را بهینه کنید؛ هم ابعاد، هم فرمت، هم lazy-load را درست تنظیم کنید. این گام معمولاً بیشترین اثر را روی LCP می‌گذارد. گام پنجم: کش صفحه را فعال کنید و در صورت نیاز CDN را اضافه کنید؛ سپس حداقل یک هفته صبر کنید تا داده میدانی به‌روز شود و تغییرات را با اعداد قبل مقایسه کنید.

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

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