Core Web Vitals وردپرس چیست؟ راهنمای بهبود LCP، INP و CLS

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

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

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

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

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

مقادیر استاندارد LCP، INP و CLS چقدر است؟

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

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

Core Web Vitals چه تأثیری بر سئو سایت وردپرسی دارد؟

Core Web Vitals بخشی از مجموعه گسترده‌تر تجربه صفحه است. گوگل اعلام کرده است که سیستم‌های رتبه‌بندی اصلی آن به تجربه مناسب صفحه توجه می‌کنند و رسیدن به وضعیت خوب این شاخص‌ها می‌تواند به موفقیت در جست‌وجو کمک کند. با این حال، نباید تصور کرد که یک صفحه فقط با کسب امتیاز ۱۰۰ PageSpeed به رتبه اول می‌رسد.

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

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

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

روش صحیح تست Core Web Vitals وردپرس

بزرگ‌ترین اشتباه در ارزیابی سرعت، تکیه بر یک بار اجرای PageSpeed Insights است. برای تشخیص درست باید تفاوت میان داده میدانی و داده آزمایشگاهی را بدانید و چند ابزار را کنار هم قرار دهید.

داده میدانی یا Field Data چیست؟

داده میدانی از تجربه کاربران واقعی مرورگر Chrome جمع‌آوری می‌شود و شرایط واقعی دستگاه، شبکه و موقعیت کاربران را منعکس می‌کند. گزارش Core Web Vitals در Search Console و بخش بالایی PageSpeed Insights از داده‌های Chrome User Experience Report یا CrUX استفاده می‌کنند.

برای تصمیم‌گیری نهایی، داده میدانی اهمیت بیشتری دارد؛ زیرا نشان می‌دهد بازدیدکنندگان واقعی چه تجربه‌ای داشته‌اند. البته یک سایت جوان یا یک URL کم‌ترافیک ممکن است داده کافی نداشته باشد. در این حالت PageSpeed Insights ممکن است اطلاعات کل دامنه یا Origin را نشان دهد، نه همان URL مشخص.

داده آزمایشگاهی یا Lab Data چیست؟

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

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

بررسی گزارش Core Web Vitals در Search Console

در Google Search Console وارد بخش Experience و سپس Core Web Vitals شوید. گزارش موبایل و دسکتاپ را جداگانه باز کنید. گوگل URLهای مشابه را در گروه‌هایی قرار می‌دهد؛ زیرا صفحات ساخته‌شده با یک قالب معمولاً علت مشترکی برای مشکل دارند.

به‌عنوان نمونه، اگر تمام نوشته‌های وبلاگ تصویر شاخص بزرگ و یک قالب یکسان دارند، ممکن است همه در یک گروه LCP ضعیف قرار بگیرند. در چنین حالتی نباید فقط URL نمونه را اصلاح کرد؛ باید قالب نوشته، روش بارگذاری تصویر شاخص یا CSS مشترک تمام گروه بررسی شود.

پس از اصلاح همه URLهای مربوط به یک مشکل می‌توانید فرایند Validate Fix یا Start Tracking را آغاز کنید. این فرایند درخواست ایندکس فوری نیست. Search Console یک دوره حدود ۲۸روزه را برای مشاهده داده‌های جدید کاربران واقعی آغاز می‌کند؛ بنابراین نتیجه اصلاح Core Web Vitals بلافاصله در این گزارش تغییر نمی‌کند.

استفاده از PageSpeed Insights

در PageSpeed Insights ابتدا بخش «Discover what your real users are experiencing» را بررسی کنید. سپس برای تشخیص مشکل به بخش Diagnostics و Opportunities بروید. عنصر LCP، منابع مسدودکننده رندر، JavaScript استفاده‌نشده، وظایف طولانی Main Thread و عناصر ایجادکننده Layout Shift را یادداشت کنید.

امتیاز کلی Performance با Core Web Vitals یکسان نیست. ممکن است امتیاز آزمایشگاهی ۹۰ باشد اما داده واقعی CLS ضعیف نشان دهد. عکس این وضعیت نیز ممکن است رخ دهد. معیار نهایی قبولی، آستانه سه شاخص در داده کاربران واقعی است، نه صرفاً عدد دایره‌ای بالای گزارش Lighthouse.

استفاده از Chrome DevTools

برای عیب‌یابی دقیق، صفحه را در Chrome باز کنید و از پنل Performance یک Performance Trace بگیرید. در این گزارش می‌توان عنصر LCP، Long Taskها، Layout Shiftها و فعالیت Main Thread را مشاهده کرد. تب Network نیز زمان شروع و پایان درخواست تصویر اصلی، فایل CSS، فونت‌ها و اسکریپت‌ها را نمایش می‌دهد.

در تست Core Web Vitals وردپرس فقط صفحه اصلی را بررسی نکنید. حداقل این قالب‌ها را آزمایش کنید:

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

بهینه سازی LCP وردپرس؛ چگونه محتوای اصلی سریع‌تر نمایش داده شود؟

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

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

چهار بخش اصلی زمان LCP

زمان LCP را می‌توان به چهار قسمت تقسیم کرد:

1. TTFB: زمان دریافت اولین بایت سند HTML از سرور؛
2. تأخیر شروع بارگیری منبع: فاصله دریافت HTML تا شروع دانلود تصویر یا منبع LCP؛
3. مدت بارگیری منبع: زمان لازم برای دریافت فایل تصویر، فونت یا منبع اصلی؛
4. تأخیر رندر عنصر: فاصله پایان دانلود منبع تا نمایش نهایی آن در صفحه.

اگر فقط حجم تصویر را کم کنید ولی عنصر تا پایان اجرای JavaScript مخفی بماند، LCP تغییر زیادی نمی‌کند. اگر تصویر بهینه باشد اما TTFB چهار ثانیه طول بکشد، رسیدن به آستانه ۲٫۵ ثانیه تقریباً ممکن نیست. بهینه سازی LCP وردپرس باید تمام مسیر بارگذاری را پوشش دهد.

۱. زمان پاسخ سرور و TTFB را کاهش دهید

TTFB بالا معمولاً از هاست ضعیف، PHP قدیمی، پردازش سنگین WordPress، کوئری‌های کند پایگاه داده، گزینه‌های Autoload حجیم، نبود کش صفحه، Redirectهای متعدد یا فاصله زیاد کاربر تا سرور ایجاد می‌شود.

برای بهبود این بخش، نسخه پشتیبانی‌شده و مناسب PHP را استفاده کنید، OPcache را فعال نگه دارید، کش تمام‌صفحه را در سرور یا افزونه معتبر تنظیم کنید، پایگاه داده را بررسی کنید و افزونه‌هایی را که در هر درخواست عملیات سنگین انجام می‌دهند شناسایی کنید. در سایت‌های دارای کاربران متعدد یا کوئری‌های زیاد، Persistent Object Cache مانند Redis می‌تواند تعداد مراجعه به پایگاه داده را کاهش دهد.

مستندات وردپرس توصیه می‌کند حجم گزینه‌های Autoload تا حد امکان کنترل شود و مجموع آن معمولاً زیر حدود ۸۰۰ کیلوبایت نگه داشته شود. حذف دستی داده از جدول wp_options بدون شناخت ساختار افزونه‌ها خطرناک است؛ ابتدا نسخه پشتیبان تهیه کنید و تغییر را روی Staging آزمایش کنید.

۲. کش صفحه، کش مرورگر و CDN را درست تنظیم کنید

کش صفحه خروجی HTML آماده را به کاربر تحویل می‌دهد و نیاز به اجرای کامل PHP و WordPress در هر بازدید را کاهش می‌دهد. کش مرورگر نیز باعث می‌شود فایل‌های ثابت مانند CSS، JavaScript، تصویر و فونت در بازدیدهای بعدی دوباره دانلود نشوند.

CDN منابع ثابت را از نقطه‌ای نزدیک‌تر به کاربر تحویل می‌دهد و می‌تواند زمان شبکه را کاهش دهد. با این حال، CDN درمان همه مشکلات نیست. اگر HTML دیر تولید شود، تصویر LCP دیر کشف شود یا JavaScript رندر را مسدود کند، فعال‌کردن CDN به‌تنهایی کافی نخواهد بود.

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

۳. تصویر LCP را Lazy Load نکنید

یکی از مهم‌ترین قواعد این است که تصویر اصلی بالای صفحه نباید با Lazy Load بارگذاری شود. Lazy Loading برای تصاویر پایین صفحه مفید است، اما استفاده از loading=”lazy” روی عنصر LCP باعث می‌شود مرورگر دانلود آن را دیرتر آغاز کند.

در تنظیمات افزونه بهینه‌سازی، تصویر هیرو یا تصویر شاخص بالای صفحه را از Lazy Load خارج کنید. سپس بررسی کنید که آدرس واقعی تصویر در HTML اولیه داخل src یا srcset وجود داشته باشد و به‌وسیله data-src یا JavaScript پنهان نشده باشد.

نمونه مناسب برای تصویری که احتمالاً LCP است:

<img
  src="/uploads/wordpress-core-web-vitals.webp"
  srcset="/uploads/wordpress-core-web-vitals-768.webp 768w,
          /uploads/wordpress-core-web-vitals-1280.webp 1280w"
  sizes="(max-width: 768px) 100vw, 1280px"
  width="1280"
  height="720"
  fetchpriority="high"
  decoding="async"
  alt="راهنمای بهبود Core Web Vitals وردپرس">

ویژگی fetchpriority=”high” به مرورگر اعلام می‌کند که تصویر اهمیت زیادی دارد. این ویژگی را روی تعداد زیادی تصویر قرار ندهید؛ زیرا اگر همه منابع اولویت بالا داشته باشند، عملاً اولویت‌بندی بی‌اثر می‌شود.

۴. تصویر اصلی را متناسب با محل نمایش تولید کنید

آپلود تصویر چندمگابایتی و نمایش آن در عرض ۷۰۰ پیکسل یکی از مشکلات رایج وردپرس است. تصویر باید در ابعاد متناسب تولید شود و WordPress بتواند نسخه مناسب را با srcset به دستگاه تحویل دهد.

فرمت WebP معمولاً نسبت به JPEG و PNG حجم کمتری دارد و AVIF در بسیاری از تصاویر می‌تواند فشرده‌سازی بیشتری ارائه کند. انتخاب فرمت باید بر اساس نوع تصویر و سازگاری فرایند سایت انجام شود. لوگو و آیکون ساده ممکن است با SVG بهتر باشند؛ تصاویر عکاسی معمولاً با WebP یا AVIF مناسب‌ترند.

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

۵. تصویر LCP را در HTML اولیه قابل کشف کنید

اگر تصویر هیرو به‌عنوان background-image در یک فایل CSS خارجی تعریف شده باشد، مرورگر ابتدا باید HTML و سپس CSS را دریافت و پردازش کند تا به آدرس تصویر برسد. این فرایند تأخیر شروع بارگیری منبع را افزایش می‌دهد.

تا حد امکان تصویر اصلی را با عنصر img یا picture در HTML قرار دهید. اگر استفاده از background-image ضروری است، تصویر را با preload معرفی کنید:

<link
  rel="preload"
  as="image"
  href="/uploads/hero-core-web-vitals.webp"
  type="image/webp"
  fetchpriority="high">

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

۶. CSS مسدودکننده رندر را کاهش دهید

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

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

۷. فونت فارسی را سبک و زودهنگام بارگذاری کنید

لود چند وزن از یک یا چند خانواده فونت، به‌خصوص فایل‌های بزرگ WOFF، می‌تواند زمان نمایش تیتر اصلی را افزایش دهد. فقط وزن‌هایی را نگه دارید که واقعاً استفاده می‌شوند. فونت‌ها را ترجیحاً از دامنه خود سایت ارائه کنید، فرمت WOFF2 داشته باشید و برای فونت‌های ضروری preload محدود در نظر بگیرید.

در صورت استفاده از فونت ایران‌یکان، دانا یا پیدا، بارگذاری هم‌زمان وزن‌های Regular، Medium، Bold، ExtraBold و Black در تمام صفحات معمولاً ضروری نیست. یک سیستم تایپوگرافی منظم می‌تواند با دو یا سه وزن، هم ظاهر حرفه‌ای داشته باشد و هم درخواست‌های کمتری ایجاد کند.

۸. اسکریپت‌های شخص ثالث را محدود کنید

چت آنلاین، نقشه، پیکسل تبلیغاتی، ابزار Heatmap، ویدئوی Embed، شبکه‌های اجتماعی و Tag Manager می‌توانند شبکه و Main Thread را اشغال کنند. هر اسکریپت باید بر اساس ارزش واقعی آن ارزیابی شود. ابزار کم‌استفاده‌ای که چندصد کیلوبایت JavaScript و چند اتصال خارجی اضافه می‌کند، ممکن است هزینه عملکردی بیشتری از فایده تجاری خود داشته باشد.

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

کاهش INP سایت وردپرس؛ چگونه تعاملات سریع و روان ایجاد کنیم؟

INP یا Interaction to Next Paint پاسخ‌گویی کلی صفحه به تعاملات کاربر را اندازه می‌گیرد. مرورگر تعامل‌هایی مانند کلیک، لمس و فشردن کلید را در طول بازدید بررسی می‌کند و معمولاً طولانی‌ترین تعامل را با حذف برخی داده‌های پرت گزارش می‌دهد.

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

سه بخش تشکیل‌دهنده INP

تأخیر یک تعامل از سه قسمت تشکیل می‌شود:

1. Input Delay: زمان انتظار از فرمان کاربر تا شروع اجرای Event Handler؛
2. Processing Duration: مدت اجرای کد مربوط به تعامل؛
3. Presentation Delay: زمان لازم برای محاسبه Layout، Paint و نمایش نتیجه بعدی.

برای کاهش INP سایت وردپرس باید مشخص شود تأخیر در کدام بخش ایجاد شده است. اگر Main Thread درگیر اجرای یک فایل JavaScript سنگین باشد، تعامل کاربر در صف می‌ماند. اگر Handler کلیک محاسبات طولانی انجام دهد، پردازش کند می‌شود. اگر تغییر DOM بزرگ باشد، مرحله نمایش فریم بعدی طول می‌کشد.

دلایل رایج INP ضعیف در وردپرس

• فایل‌های JavaScript بزرگ قالب و صفحه‌ساز؛
• افزونه‌هایی که کد خود را در تمام صفحات بارگذاری می‌کنند؛
• منوهای پیچیده، اسلایدرها، پاپاپ‌ها و انیمیشن‌های سنگین؛
• فیلتر Ajax محصولات ووکامرس؛
• جست‌وجوی زنده، مقایسه محصول و افزودن سریع به سبد؛
• چت آنلاین و ابزارهای رهگیری شخص ثالث؛
• DOM بسیار بزرگ در صفحات ساخته‌شده با Page Builder؛
• اجرای چند Event Listener روی یک تعامل؛
• اسکریپت‌های قدیمی، بدون Minify یا بدون تقسیم مناسب؛
• تغییرات سنگین Layout پس از کلیک کاربر.

۱. JavaScript استفاده‌نشده را شناسایی کنید

در Lighthouse بخش Reduce unused JavaScript و در Chrome DevTools بخش Coverage را بررسی کنید. ممکن است یک افزونه اسلایدر، فرم، آیکون یا فروشگاه فایل‌های خود را در صفحاتی بارگذاری کند که اصلاً از قابلیت آن استفاده نمی‌کنند.

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

۲. اسکریپت‌های غیرحیاتی را Defer یا Delay کنید

ویژگی defer باعث می‌شود JavaScript پس از پردازش HTML اجرا شود و ترتیب فایل‌های Deferred حفظ شود. Delay اجرای بعضی اسکریپت‌ها را تا تعامل کاربر عقب می‌اندازد. این دو روش یکسان نیستند و استفاده نادرست از آن‌ها ممکن است منو، فرم، اسلایدر، سبد خرید یا آمارگیری را مختل کند.

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

۳. Long Taskها را کوتاه کنید

وظیفه‌ای که Main Thread را برای مدت طولانی اشغال کند، فرصت پاسخ‌گویی مرورگر را کاهش می‌دهد. در کد اختصاصی باید عملیات بزرگ به وظایف کوچک‌تر تقسیم شود تا مرورگر میان آن‌ها امکان پردازش تعامل و رندر داشته باشد.

در سایت‌هایی که تمام رابط با افزونه‌های آماده ساخته شده است، دسترسی مستقیم به کد Event Handler محدود است. در این شرایط راه‌حل عملی معمولاً حذف قابلیت سنگین، جایگزینی افزونه، کاهش تعداد Widgets، ساده‌کردن انیمیشن‌ها یا استفاده از نسخه سبک‌تر کامپوننت است.

۴. DOM صفحه را کوچک‌تر کنید

صفحه‌سازها گاهی برای یک طراحی ساده، تعداد زیادی Wrapper و عنصر تو در تو تولید می‌کنند. DOM بزرگ باعث افزایش هزینه Style Calculation، Layout و Paint می‌شود. پس از تعامل کاربر، مرورگر باید تعداد بیشتری عنصر را دوباره محاسبه کند و این موضوع Presentation Delay را افزایش می‌دهد.

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

۵. تعاملات ووکامرس را جداگانه آزمایش کنید

در فروشگاه وردپرسی، صفحه محصول، فیلتر دسته‌بندی، تغییر Variation، افزودن به سبد، Mini Cart، کوپن و تسویه‌حساب تعاملات مهمی هستند. ممکن است صفحه در حالت بدون تعامل سریع باشد اما پس از انتخاب ویژگی محصول یا کلیک دکمه خرید، JavaScript و درخواست Ajax تأخیر زیادی ایجاد کنند.

هر مسیر اصلی خرید را در Performance Panel ضبط کنید. اگر یک افزونه فیلتر یا مقایسه محصول Long Task ایجاد می‌کند، تنظیمات آن را ساده کنید یا جایگزین مناسب‌تری انتخاب کنید. حذف کامل قابلیت تجاری مهم فقط برای گرفتن امتیاز بهتر منطقی نیست؛ باید نسخه‌ای سبک‌تر و پایدارتر پیاده‌سازی شود.

۶. اسکریپت‌های شخص ثالث را پس از رضایت یا نیاز بارگذاری کنید

ابزارهای چت، نقشه و ویدئو را می‌توان با نمای اولیه سبک جایگزین کرد و پس از کلیک کاربر، محتوای اصلی را بارگذاری کرد. این روش هم منابع اولیه را کاهش می‌دهد و هم احتمال ایجاد Long Task در زمان بارگذاری را کمتر می‌کند.

برای ویدئوهای YouTube می‌توان ابتدا تصویر بندانگشتی و دکمه پخش را نمایش داد و Iframe را پس از تعامل ساخت. برای نقشه نیز تصویر یا لینک مسیر می‌تواند جایگزین بارگیری فوری Embed کامل شود؛ مگر اینکه تعامل مستقیم با نقشه بخش ضروری صفحه باشد.

۷. Main Thread را هنگام بارگذاری آزاد نگه دارید

کاربر ممکن است پیش از پایان کامل بارگیری روی منو یا دکمه کلیک کند. اگر مرورگر در همان لحظه مشغول Parse و Execute چند فایل بزرگ باشد، Input Delay افزایش می‌یابد. کاهش حجم JavaScript، حذف کدهای بلااستفاده و محدودکردن قابلیت‌های اولیه، امکان پاسخ‌گویی سریع‌تر را فراهم می‌کند.

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

رفع مشکل CLS وردپرس؛ چگونه از جابه‌جایی عناصر جلوگیری کنیم؟

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

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

۱. برای تصاویر و ویدئوها width و height تعیین کنید

مرورگر باید قبل از دریافت تصویر بداند چه مقدار فضا برای آن رزرو کند. WordPress در حالت عادی ابعاد تصاویر کتابخانه رسانه را در HTML قرار می‌دهد، اما قالب سفارشی، Lazy Load غیر استاندارد یا کد صفحه‌ساز ممکن است این اطلاعات را حذف کند.

<img
  src="/uploads/core-web-vitals-dashboard.webp"
  width="1200"
  height="675"
  loading="lazy"
  decoding="async"
  alt="تست Core Web Vitals وردپرس">

در طراحی واکنش‌گرا همچنان می‌توان از max-width:100% و height:auto استفاده کرد. وجود width و height نسبت ابعاد را به مرورگر می‌دهد و مانع از کشیدگی اجباری تصویر نمی‌شود.

۲. برای Iframe، تبلیغ و Embed فضای ثابت رزرو کنید

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

.video-frame {
  width: 100%;
  aspect-ratio: 16 / 9;
  overflow: hidden;
}

.video-frame iframe {
  width: 100%;
  height: 100%;
  border: 0;
}

در موبایل نیز باید ارتفاع واقعی بررسی شود. استفاده از min-height بسیار بزرگ فقط برای حذف CLS می‌تواند فضای مرده و تجربه ضعیف ایجاد کند. فضای رزروشده باید به اندازه محتوای نهایی نزدیک باشد.

۳. بنرها، پیام‌ها و نوارهای اطلاع‌رسانی را روی محتوا اضافه نکنید

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

برای پیام‌هایی که باید پس از تعامل نمایش داده شوند، استفاده از Overlay یا عنصر Fixed می‌تواند از جابه‌جایی Layout جلوگیری کند؛ به شرطی که محتوای اصلی را نپوشاند، بستن آن ساده باشد و دسترس‌پذیری رعایت شود.

۴. فونت فارسی را با Fallback مناسب بارگذاری کنید

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

در @font-face مقدار font-display را آگاهانه انتخاب کنید. font-display:swap متن را سریع نمایش می‌دهد، اما ممکن است هنگام جایگزینی فونت تغییر Layout ایجاد شود. font-display:optional در بعضی سناریوها از جایگزینی دیرهنگام جلوگیری می‌کند، ولی ممکن است فونت برند همیشه نمایش داده نشود.

راه‌حل حرفه‌ای، انتخاب Fallback نزدیک و تنظیم معیارهای فونت با size-adjust، ascent-override، descent-override و line-gap-override است. همچنین فونت ضروری بالای صفحه را زود بارگذاری کنید و تعداد وزن‌ها را محدود نگه دارید.

۵. اسلایدر و Carousel را با ارتفاع مشخص بسازید

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

برای اسلایدر بالای صفحه نسبت ابعاد یا حداقل ارتفاع متناسب تعریف کنید. تصاویر اسلایدها باید ابعاد یکسان داشته باشند. همچنین بهتر است فقط اسلاید اول در بارگذاری اولیه اولویت بالا بگیرد و تصاویر اسلایدهای پنهان با اولویت پایین‌تر دریافت شوند.

۶. انیمیشن را با transform و opacity اجرا کنید

انیمیشن ویژگی‌هایی مانند top، left، width، height و margin می‌تواند محاسبه Layout را تحریک کند و سایر عناصر را جابه‌جا کند. برای حرکت و ظاهرشدن عناصر، transform و opacity معمولاً انتخاب مناسب‌تری هستند؛ زیرا می‌توانند بدون تغییر چیدمان اصلی اجرا شوند.

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

۷. فضای فرم و پیام اعتبارسنجی را مدیریت کنید

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

پیام خطا را نزدیک فیلد نمایش دهید، فضای منطقی برای آن در نظر بگیرید و از قراردادن یک پیام بلند در ابتدای فرم که تمام صفحه را پایین می‌برد خودداری کنید.

برنامه عملی بهبود Core Web Vitals وردپرس

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

مرحله اول: ثبت خط پایه

پیش از هر تغییر، نتایج موبایل و دسکتاپ را ثبت کنید. URL، نوع صفحه، داده میدانی، مقدار LCP، INP و CLS، عنصر LCP، TTFB و مهم‌ترین Diagnostics را در یک جدول بنویسید. بدون خط پایه نمی‌توان فهمید کدام تغییر مؤثر بوده است.

مرحله دوم: انتخاب صفحات نماینده

یک URL از هر Template انتخاب کنید: خانه، خدمات، مقاله، دسته، محصول و تسویه‌حساب. اگر Search Console گروه URL ساخته است، همان URL نمونه را مبنای عیب‌یابی قرار دهید، ولی اصلاح را روی Template مشترک اجرا کنید.

مرحله سوم: رفع مشکلات سرور و TTFB

کش صفحه، PHP، پایگاه داده، Autoload، Redirect، CDN و منابع خارجی را بررسی کنید. تا زمانی که سرور HTML را دیر تحویل می‌دهد، بهینه‌سازی تصویر و CSS نتیجه محدودتری خواهد داشت.

مرحله چهارم: اصلاح LCP بالای صفحه

عنصر اصلی را مشخص کنید، تصویر مناسب تولید کنید، Lazy Load را از آن بردارید، fetchpriority را فقط در صورت نیاز اضافه کنید و کشف منبع در HTML اولیه را کنترل کنید. سپس CSS و فونت‌های مسدودکننده نمایش را کاهش دهید.

مرحله پنجم: کاهش JavaScript و بهبود INP

فایل‌های بلااستفاده، Long Taskها، Event Handlerهای سنگین و اسکریپت‌های شخص ثالث را پیدا کنید. هر قابلیت باید فقط در صفحات لازم بارگذاری شود. مسیرهای واقعی تعامل مانند منو، فرم و خرید را آزمایش کنید.

مرحله ششم: تثبیت Layout و رفع CLS

ابعاد تصویر، ویدئو و Embed را مشخص کنید؛ فضای بنرها و اعلان‌ها را رزرو کنید؛ فونت‌ها و اسلایدرها را اصلاح کنید و از ایجاد نسخه‌های تکراری موبایل و دسکتاپ در DOM جلوگیری کنید.

مرحله هفتم: کنترل Regression

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

بهبود سرعت موبایل وردپرس برای Core Web Vitals

نسخه موبایل نباید فقط نسخه کوچک‌شده دسکتاپ باشد. کاربران موبایل پردازنده، حافظه، شبکه و فضای نمایش محدودتری دارند. یک اسکریپت که روی لپ‌تاپ سریع اجرا می‌شود ممکن است روی گوشی میان‌رده Long Task ایجاد کند.

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

در صفحه‌سازها از ساخت دو سکشن کامل و یکسان برای موبایل و دسکتاپ خودداری کنید. مخفی‌کردن یک سکشن با CSS الزاماً باعث نمی‌شود HTML، تصویر و فایل‌های آن بارگذاری نشوند. یک ساختار مشترک با طراحی واکنش‌گرا معمولاً DOM کوچک‌تر و نگهداری آسان‌تری دارد.

تست موبایل را فقط با شبیه‌ساز انجام ندهید. حداقل یک گوشی Android میان‌رده را با اینترنت موبایل بررسی کنید. منو، فرم، اسکرول، فیلتر، افزودن به سبد و بازشدن پاپاپ را چند بار اجرا کنید تا تأخیرهایی که در تست خودکار ثبت نمی‌شوند دیده شوند.

آیا افزونه افزایش سرعت می‌تواند همه مشکلات Core Web Vitals را حل کند؟

افزونه بهینه‌سازی می‌تواند کش صفحه، Minify، Delay JavaScript، Lazy Load، Preload، پاک‌سازی پایگاه داده و CDN را مدیریت کند؛ اما نتیجه به تنظیمات، قالب، هاست و ساختار سایت وابسته است. هیچ افزونه‌ای نمی‌تواند یک تصویر طراحی‌شده با ابعاد اشتباه، DOM بسیار بزرگ، منطق سنگین فیلتر محصولات یا هاست ناپایدار را به‌طور کامل جبران کند.

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

پس از فعال‌سازی هر گزینه، کش را پاک کنید و صفحات مهم را در حالت ناشناس، موبایل، حساب کاربری و فرایند خرید آزمایش کنید. Delay JavaScript ممکن است امتیاز آزمایشگاهی را بهتر کند ولی منوی موبایل، فرم یا آمارگیری را از کار بیندازد. معیار موفقیت فقط عدد PageSpeed نیست؛ عملکرد صحیح کسب‌وکار نیز باید حفظ شود.

اشتباهات رایج در رفع خطای Core Web Vitals

تمرکز روی امتیاز ۱۰۰ به‌جای داده کاربران واقعی

امتیاز Lighthouse یک ابزار تشخیص است، نه هدف نهایی. رسیدن از ۹۶ به ۱۰۰ معمولاً ارزش کمتری از اصلاح یک فرم کند یا تصویر جابه‌جاشونده دارد.

Lazy Load کردن تصویر اصلی

Lazy Load برای تصاویر پایین صفحه مناسب است، اما تصویر LCP باید در سریع‌ترین زمان کشف و بارگیری شود.

Preload کردن تعداد زیادی منبع

Preload بیش‌ازحد رقابت شبکه ایجاد می‌کند. فقط تصویر، فونت یا منبع واقعاً حیاتی را پیش‌بارگذاری کنید.

استفاده هم‌زمان از چند افزونه بهینه‌سازی

هم‌پوشانی کش، Minify، Delay و Lazy Load باعث تداخل، خطای ظاهری و دشوارشدن عیب‌یابی می‌شود.

حذف قابلیت‌های مهم بدون تحلیل تجاری

فرم، فیلتر یا چت ممکن است برای تبدیل ضروری باشد. هدف، اجرای سبک‌تر است، نه حذف کورکورانه امکانات مفید.

نادیده‌گرفتن تفاوت صفحه و Origin

گاهی PageSpeed داده کل دامنه را نشان می‌دهد. پیش از نتیجه‌گیری بررسی کنید داده مربوط به همان URL است یا Origin.

انتظار تغییر فوری در Search Console

گزارش Search Console بر داده واقعی و پنجره زمانی متکی است. تغییر کد امروز الزاماً فردا وضعیت گزارش را سبز نمی‌کند.

بهینه‌سازی فقط صفحه اصلی

مقاله‌ها، دسته‌ها، محصولات و تسویه‌حساب ممکن است Template و مشکلات متفاوتی داشته باشند. هر قالب اصلی باید آزمایش شود.

بهینه سازی سرعت وردپرس برای سئو چگونه اولویت‌بندی شود؟

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

ترتیب مناسب برای هر URL استراتژیک عبارت است از:

1. بررسی Index و Canonical؛
2. تطابق عنوان، H1 و نیت جست‌وجو؛
3. ثبت داده فعلی کلیک، نمایش و رتبه؛
4. بررسی داده Core Web Vitals موبایل و دسکتاپ؛
5. اصلاح مشکل اصلی بدون تغییر غیرضروری محتوا؛
6. کنترل فرم، CTA و تبدیل؛
7. پایش داده جدید در Search Console و ابزارهای عملکرد.

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

Core Web Vitals چه ارتباطی با ChatGPT Search و جست‌وجوی هوش مصنوعی دارد؟

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

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

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

چه زمانی به بررسی تخصصی Core Web Vitals وردپرس نیاز داریم؟

اگر PageSpeed فقط پیشنهادهای عمومی نمایش می‌دهد، Search Console چند گروه URL ضعیف دارد، امتیازها پس از هر تست تغییر شدید می‌کنند یا فعال‌کردن افزونه کش باعث خرابی سایت شده است، بررسی تخصصی می‌تواند از تغییرات پرریسک جلوگیری کند.

در یک بررسی حرفه‌ای باید هاست، TTFB، Waterfall شبکه، عنصر LCP، فایل‌های مسدودکننده، Main Thread، Long Task، Layout Shift، قالب، افزونه‌ها، فونت‌ها، تصاویر، ووکامرس و ابزارهای شخص ثالث کنار هم تحلیل شوند. خروجی مناسب فقط یک امتیاز نیست؛ باید شامل علت، اولویت، اقدام اجرایی، ریسک و نتیجه قابل‌اندازه‌گیری باشد.

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

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

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

Core Web Vitals وردپرس چیست؟

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

عدد مناسب LCP در وردپرس چقدر است؟

LCP خوب ۲٫۵ ثانیه یا کمتر است. مقدار بین ۲٫۵ تا ۴ ثانیه نیازمند بهبود و مقدار بیشتر از ۴ ثانیه ضعیف محسوب می‌شود. برای رفع خطای LCP در وردپرس باید عنصر اصلی، TTFB، تصویر، CSS و زمان رندر بررسی شود.

عدد مناسب INP چقدر است؟

INP مناسب ۲۰۰ میلی‌ثانیه یا کمتر است. مقدار بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه نیازمند بهبود و بیشتر از ۵۰۰ میلی‌ثانیه ضعیف است. کاهش INP سایت وردپرس معمولاً به کاهش JavaScript، Long Taskها و پردازش سنگین تعاملات نیاز دارد.

عدد مناسب CLS چقدر است؟

CLS خوب ۰٫۱ یا کمتر است. مقدار بین ۰٫۱ تا ۰٫۲۵ نیازمند بهبود و مقدار بیشتر از ۰٫۲۵ ضعیف است. تعیین ابعاد تصاویر، رزرو فضای Embed و مدیریت فونت‌ها از روش‌های اصلی رفع مشکل CLS وردپرس است.

آیا INP جایگزین FID شده است؟

بله. INP معیار فعلی پاسخ‌گویی در Core Web Vitals است و تعاملات مختلف را در طول بازدید بررسی می‌کند. FID فقط تأخیر اولین تعامل را می‌سنجید و دیگر معیار اصلی Core Web Vitals نیست.

آیا افزونه کش برای بهبود Core Web Vitals کافی است؟

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

چرا PageSpeed Insights و Search Console نتایج متفاوتی دارند؟

Search Console بر داده کاربران واقعی و یک پنجره زمانی متکی است، اما بخش Lighthouse در PageSpeed یک آزمایش کنترل‌شده است. تفاوت دستگاه، شبکه، ترافیک، کش و URL یا Origin باعث تفاوت نتایج می‌شود.

چقدر طول می‌کشد نتیجه اصلاح در Search Console نمایش داده شود؟

Search Console برای تأیید اصلاح Core Web Vitals یک دوره پایش حدود ۲۸روزه دارد. این زمان ممکن است با توجه به حجم داده و بازدید سایت متفاوت باشد. تست آزمایشگاهی معمولاً نتیجه فنی تغییر را سریع‌تر نشان می‌دهد.

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

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

برای بهبود سرعت موبایل وردپرس از کجا شروع کنیم؟

ابتدا داده موبایل را در Search Console و PageSpeed بررسی کنید. سپس تصویر LCP، زمان پاسخ سرور، JavaScript، فونت‌ها، منوی موبایل، پاپاپ‌ها و DOM را اصلاح کنید. تست روی گوشی واقعی نیز ضروری است.

آیا Lazy Load همیشه به افزایش سرعت کمک می‌کند؟

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

آیا فونت فارسی می‌تواند LCP و CLS را خراب کند؟

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

آیا ووکامرس Core Web Vitals را ضعیف می‌کند؟

ووکامرس به‌خودی‌خود الزاماً کند نیست، اما امکاناتی مانند فیلتر Ajax، Variation، Mini Cart، اسکریپت‌های پرداخت و افزونه‌های جانبی می‌توانند منابع بیشتری مصرف کنند. صفحات فروشگاه باید جداگانه آزمایش و بهینه شوند.

برای رفع خطای Core Web Vitals بهتر است قالب عوض شود؟

تعویض قالب باید آخرین تصمیم باشد، نه اولین اقدام. ابتدا علت دقیق را مشخص کنید. اگر ساختار قالب، DOM، CSS و JavaScript آن به‌صورت بنیادی سنگین باشد و اصلاح مقرون‌به‌صرفه نباشد، بازطراحی یا تعویض قالب قابل بررسی است.

جمع‌بندی

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

برای بهبود Core Web Vitals وردپرس ابتدا باید داده میدانی و آزمایشگاهی را از یکدیگر جدا کنید، عنصر یا تعامل مشکل‌دار را پیدا کنید و اصلاحات را به ترتیب اولویت اجرا کنید. کاهش TTFB، بارگذاری زودهنگام تصویر LCP، کنترل CSS و JavaScript، محدودکردن فونت‌ها، کوچک‌کردن DOM و تعیین ابعاد عناصر، مهم‌ترین اقدامات این مسیر هستند.

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

برای دریافت بررسی تخصصی و برنامه اجرایی متناسب با قالب، افزونه‌ها و زیرساخت سایت، می‌توانید از طریق سامانه سفارش آنلاین تابان درخواست بهینه‌سازی سرعت یا مشاوره سئو ثبت کنید.

منابع رسمی استفاده‌شده

• راهنمای Core Web Vitals در Google Search Central
• راهنمای تجربه صفحه در نتایج گوگل
• گزارش Core Web Vitals در Search Console
• راهنمای رسمی بهینه‌سازی LCP
• راهنمای رسمی بهینه‌سازی INP
• راهنمای رسمی بهینه‌سازی CLS
• راهنمای رسمی بهینه‌سازی WordPress