آموزش رفع مشکل LCP در وردپرس؛ چرا سرچ کنسول خطای LCP می‌دهد؟

3. مرورگر تصویر LCP را دیر کشف می‌کند

گاهی حجم Hero مناسب است اما درخواست آن خیلی دیر شروع می‌شود. این حالت معمولاً وقتی دیده می‌شود که تصویر از طریق CSS Background، JavaScript یا اسلایدر ساخته شده باشد. Preload Scanner مرورگر تصاویر استانداردی را که مستقیم در HTML قرار دارند زودتر پیدا می‌کند، اما منابعی که داخل CSS یا JavaScript پنهان هستند دیرتر کشف می‌شوند.

اگر طراحی اجازه می‌دهد، برای یک تصویر محتوایی مهم بالای صفحه استفاده از عنصر استاندارد <img> معمولاً مسیر کشف ساده‌تری نسبت به Background Image دارد.

4. TTFB و پاسخ اولیه سرور بالا است

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

web.dev عدد حدود 0.8 ثانیه یا کمتر را به‌عنوان یک هدف تقریبی برای TTFB مناسب پیشنهاد می‌کند؛ این عدد یک آستانه Core Web Vitals نیست، اما برای تشخیص وضعیت پاسخ اولیه مفید است.

در وردپرس موارد زیر را بررسی کنید:

• Page Cache برای صفحات عمومی
• Persistent Object Cache مانند Redis در صورت پشتیبانی و نیاز سایت
• نسخه مناسب PHP و منابع کافی هاست
• Queryهای سنگین دیتابیس و افزونه‌های پرمصرف
• تعداد Redirectهای قبل از رسیدن به URL اصلی
• موقعیت جغرافیایی سرور نسبت به کاربران و استفاده مناسب از CDN

برای عیب‌یابی دقیق‌تر این بخش به مقاله کاهش TTFB در وردپرس مراجعه کنید. راهنمای کلی افزایش سرعت سایت وردپرسی نیز اقدامات عمومی‌تر را پوشش می‌دهد.

5. CSS و JavaScript رندر عنصر را عقب می‌اندازند

فایل CSS به‌صورت طبیعی می‌تواند Render Blocking باشد، چون مرورگر برای نمایش صحیح صفحه باید Styleها را پردازش کند. اگر حجم CSS بالا باشد یا منابع غیرضروری زیادی در Head قرار گرفته باشند، زمان Paint عناصر بالای صفحه عقب می‌افتد.

JavaScript هم ممکن است LCP را مستقیماً به تأخیر بیندازد؛ مخصوصاً وقتی Hero، اسلایدر، انیمیشن ورودی یا کل Layout بعد از اجرای JavaScript نمایش داده می‌شود. در این حالت حتی اگر تصویر کاملاً دانلود شده باشد، Element Render Delay همچنان بالا می‌ماند.

Delay یا Defer کردن JavaScript می‌تواند مفید باشد، اما این تنظیمات را کورکورانه فعال نکنید. اگر اسکریپتی برای ساخت یا نمایش Hero ضروری باشد، تأخیر دادن همان فایل می‌تواند LCP را بدتر کند.

6. فونت وب باعث تأخیر در نمایش LCP متنی می‌شود

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

تعداد وزن‌های فونت را محدود کنید، فقط فرمت‌های موردنیاز را بارگذاری کنید، Cache مناسب برای فایل‌های فونت داشته باشید و مقدار font-display را متناسب با طراحی انتخاب کنید. برای فونت‌های واقعاً Critical می‌توان Preload را بررسی کرد، اما Preload کردن تمام فایل‌های فونت نتیجه معکوس دارد و پهنای باند منابع مهم‌تر را اشغال می‌کند.

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

7. اسلایدر، انیمیشن و صفحه‌ساز Hero را دیر نمایش می‌دهند

اسلایدرهای بالای صفحه از رایج‌ترین عوامل LCP ضعیف هستند. اسلاید اول باید بلافاصله در HTML قابل کشف و قابل نمایش باشد. اگر تصویر اسلاید بعد از اجرای کتابخانه JavaScript وارد DOM شود یا روی تمام اسلایدها Lazy Load و Animation سنگین فعال باشد، LCP بالا می‌رود.

در Elementor و سایر صفحه‌سازها نیز ممکن است تصویر Hero به‌صورت Background یک Section یا Container ساخته شود. اگر PageSpeed نشان می‌دهد Resource Load Delay زیاد است، نحوه خروجی HTML و CSS همین بخش را بررسی کنید.

آموزش رفع مشکل LCP در وردپرس مرحله‌به‌مرحله

مرحله 1: URL مشکل‌دار را از Search Console انتخاب کنید

در Search Console وارد گزارش Core Web Vitals شوید، Mobile یا Desktop را انتخاب کنید و روی ردیف مربوط به LCP کلیک کنید. چند URL نمونه از گروه را بررسی کنید. اگر همگی یک نوع صفحه هستند، مثلاً نوشته‌های وبلاگ، احتمال دارد مشکل از Template مشترک باشد.

فقط یک URL را اصلاح نکنید و نتیجه را به کل گروه تعمیم ندهید. حداقل چند صفحه از همان گروه را در PageSpeed بررسی کنید تا مطمئن شوید عنصر و علت LCP مشابه است.

مرحله 2: عنصر LCP را در PageSpeed پیدا کنید

اگر عنصر یک تصویر است، URL فایل، ابعاد، نحوه بارگذاری و زمان شروع درخواست را بررسی کنید. اگر عنصر متن است، مسیر CSS و فونت را جدی‌تر بررسی کنید. اگر Background Image یا اسلایدر است، دیر کشف شدن Resource را بررسی کنید.

مرحله 3: اگر تصویر LCP است، حجم و ابعاد را اصلاح کنید

اول تصویر را با اندازه واقعی موردنیاز صفحه تطبیق دهید. سپس کیفیت و فرمت را بهینه کنید. هدف صرفاً رسیدن به یک حجم ثابت مثل «کمتر از 100KB» نیست؛ تصاویر مختلف جزئیات و ابعاد متفاوت دارند. معیار درست این است که کوچک‌ترین فایل قابل قبول از نظر کیفیت و طراحی را تحویل دهید.

همچنین مطمئن شوید Width و Height صحیح تصویر در HTML مشخص است تا مرورگر ابعاد Layout را از ابتدا بداند. این موضوع بیشتر برای CLS مهم است، اما ساختار پایدار صفحه به فرایند رندر کمک می‌کند.

مرحله 4: Lazy Load را از تصویر اصلی حذف کنید

سورس HTML تصویر LCP را بررسی کنید. اگر loading="lazy" روی تصویر بالای صفحه قرار دارد، ابتدا مشخص کنید کدام افزونه یا Page Builder آن را اضافه کرده است و از تنظیم Exclude آن استفاده کنید.

در بسیاری از افزونه‌های Performance گزینه‌هایی مانند Exclude Images، Skip First Images یا Lazy Load Exclusion وجود دارد. نام دقیق گزینه به افزونه بستگی دارد. بهتر است به‌جای خاموش کردن Lazy Load کل سایت، فقط تصویر یا تصاویر بالای Fold را از آن خارج کنید.

مرحله 5: اولویت دانلود تصویر اصلی را بررسی کنید

برای یک تصویر LCP استاندارد که مستقیماً در HTML قرار دارد، مرورگر باید بتواند آن را زود کشف کند. در وردپرس جدید، ابتدا سورس خروجی را ببینید؛ ممکن است هسته از قبل fetchpriority="high" را به تصویر مناسب اضافه کرده باشد.

اگر قالب سفارشی یا Page Builder شما این منطق را دور زده و عنصر LCP بدون اولویت مناسب بارگذاری می‌شود، توسعه‌دهنده می‌تواند خروجی را اصلاح کند. نمونه ساده HTML به شکل زیر است:

<img
  src="/images/hero.webp"
  width="1200"
  height="675"
  loading="eager"
  fetchpriority="high"
  alt="..."
>

این ویژگی را به تعداد زیادی تصویر اضافه نکنید. اگر همه منابع را High Priority کنید، عملاً مفهوم اولویت از بین می‌رود و منابع مهم برای پهنای باند با یکدیگر رقابت می‌کنند.

مرحله 6: برای Background Image فقط در صورت نیاز Preload انجام دهید

تصاویر CSS Background توسط Preload Scanner از HTML مستقیم کشف نمی‌شوند. اگر Hero واقعاً باید Background باشد و PageSpeed نشان می‌دهد Load Delay بالاست، Preload منبع می‌تواند شروع دانلود را جلو بیندازد:

<link
  rel="preload"
  as="image"
  href="/images/hero.webp"
  fetchpriority="high"
>

این راهکار را فقط برای منبع واقعاً Critical استفاده کنید. Preload اشتباه فایل‌های غیرضروری می‌تواند سرعت را بدتر کند. در تصاویر Responsive نیز بهتر است پیاده‌سازی Preload با imagesrcset و imagesizes متناسب با خروجی واقعی انجام شود.

مرحله 7: TTFB را کاهش دهید

اگر بخش TTFB سهم بزرگی از LCP دارد، دیگر دستکاری تصویر اولویت اول نیست. Page Cache را بررسی کنید، Queryهای کند را پیدا کنید، افزونه‌های غیرضروری را حذف کنید و مطمئن شوید هاست منابع کافی برای سایت دارد.

در سایت‌های پرترافیک یا سایت‌هایی که Queryهای تکراری زیادی دارند، Persistent Object Cache می‌تواند به کاهش بار دیتابیس کمک کند؛ اما Object Cache و Page Cache یک چیز نیستند. Page Cache می‌تواند برای صفحات عمومی کل خروجی HTML را سریع‌تر تحویل دهد، در حالی که Object Cache بیشتر نتایج محاسبات و Queryهای تکراری را نگه می‌دارد.

اگر دیتابیس وردپرس حجم زیادی از داده‌های اضافی دارد، راهنمای بهینه‌سازی دیتابیس وردپرس را هم بررسی کنید.

مرحله 8: منابع Render Blocking را بررسی کنید

در PageSpeed بخش Render Blocking Requests و در DevTools مسیر Critical Rendering Path را بررسی کنید. CSS ضروری Above the Fold باید زود در دسترس باشد و CSS غیرضروری نباید نمایش Hero را عقب بیندازد.

اگر افزونه Performance شما قابلیت Remove Unused CSS، Load CSS Asynchronously، Delay JavaScript یا Defer JavaScript دارد، بعد از هر تغییر صفحه را دوباره تست کنید. ترکیب نامناسب این گزینه‌ها ممکن است باعث FOUC، به‌هم‌ریختگی Layout یا دیر ظاهر شدن عنصر LCP شود.

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

فونت‌های متعدد، ابزارهای چت، Heatmap، تبلیغات، Tag Managerهای شلوغ و اسکریپت‌های Third-party هم می‌توانند Thread اصلی یا شبکه را اشغال کنند. همه آن‌ها مستقیماً LCP نیستند، اما اگر پیش از رندر محتوای اصلی منابع زیادی مصرف کنند، زمان نمایش عنصر بزرگ بالا می‌رود.

اسکریپت‌هایی که برای محتوای Above the Fold ضروری نیستند را بعد از محتوای اصلی بارگذاری کنید یا در صورت امکان اجرای آن‌ها را تا تعامل کاربر به تأخیر بیندازید؛ البته فقط وقتی مطمئن هستید خود عنصر LCP به آن اسکریپت وابسته نیست.

اگر عنصر LCP تصویر نیست و متن است چه کنیم؟

وقتی PageSpeed یک Heading یا بلوک متن را به‌عنوان LCP معرفی می‌کند، فشرده‌سازی تصاویر تقریباً مشکل اصلی شما نیست. در این وضعیت سه بخش را بررسی کنید:

• TTFB: آیا HTML دیر به مرورگر می‌رسد؟
• CSS: آیا Styleهای ضروری برای نمایش متن پشت فایل‌های بزرگ یا زنجیره درخواست مانده‌اند؟
• فونت: آیا مرورگر تا دانلود WebFont متن را نامرئی نگه می‌دارد؟

اگر متن با Animation ورودی مثل Fade-in یا تنظیمات «نمایش بعد از Load» مخفی شده باشد، همان Animation می‌تواند Element Render Delay را بالا ببرد. برای H1 و محتوای اصلی بالای صفحه معمولاً بهتر است نمایش اولیه به JavaScript وابسته نباشد.

اگر عنصر LCP ویدیو باشد چه کنیم؟

در صفحات Landing یا صفحه اصلی ممکن است ویدیو یا Poster آن بزرگ‌ترین عنصر باشد. در این حالت Poster را مانند یک تصویر Critical بهینه کنید و مطمئن شوید حجم و ابعاد مناسبی دارد. خود ویدیوی بزرگ را تا حد امکان به شکلی بارگذاری کنید که پهنای باند موردنیاز محتوای اصلی را نگیرد.

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

چرا PageSpeed سبز است ولی Search Console هنوز خطای LCP دارد؟

این یکی از رایج‌ترین سؤال‌ها درباره Core Web Vitals است. دلیل اصلی تفاوت Lab Data و Field Data است.

Lighthouse یک بارگذاری آزمایشگاهی را در شرایط کنترل‌شده شبیه‌سازی می‌کند. اما Search Console از داده CrUX استفاده می‌کند؛ یعنی تجربه واقعی کاربران با گوشی‌ها، شبکه‌ها، موقعیت‌های جغرافیایی و شرایط مختلف. داده‌های Field در PageSpeed Insights نیز یک بازه 28 روزه را پوشش می‌دهند و روزانه بروزرسانی می‌شوند.

پس اگر امروز LCP را از 4.5 به 1.9 ثانیه رساندید، طبیعی است که Search Console همان روز تمام URLها را Good نشان ندهد. داده‌های قدیمی هنوز بخشی از پنجره 28 روزه هستند و باید به مرور با تجربه جدید کاربران جایگزین شوند.

همچنین Search Console URLهای مشابه را گروه‌بندی می‌کند، در حالی که تست Lab معمولاً فقط همان URL را در همان لحظه بررسی می‌کند. ممکن است صفحه‌ای که تست کرده‌اید عالی باشد، اما بقیه اعضای گروه همچنان مشکل داشته باشند.

آیا امتیاز 100 در PageSpeed یعنی LCP سایت حل شده است؟

خیر. Performance Score لایت‌هاوس ترکیبی از چند معیار است و با وضعیت Field Data یکی نیست. هدف اصلی شما نباید صرفاً رسیدن به عدد 100 باشد. اگر کاربران واقعی LCP خوب، INP مناسب و CLS پایین دارند، نتیجه عملی مهم‌تر از امتیاز ظاهری یک تست است.

از طرف دیگر، یک تست سبز هم تضمین نمی‌کند همه Templateهای سایت خوب هستند. صفحه اصلی، نوشته، محصول ووکامرس، دسته‌بندی و Landing Page ممکن است عناصر LCP کاملاً متفاوتی داشته باشند.

بعد از رفع LCP در سرچ کنسول چه کاری انجام دهیم؟

بعد از اینکه چند URL نمونه را در ابزارهای Lab بررسی کردید و مطمئن شدید علت مشترک برطرف شده است، وارد جزئیات مشکل Core Web Vitals در Search Console شوید و فرایند Start Tracking یا Validate Fix را آغاز کنید؛ نام دکمه ممکن است با توجه به زبان و نسخه رابط متفاوت باشد.

طبق مستندات Search Console، این فرایند یک دوره پایش 28 روزه است. شروع Validation باعث نمی‌شود گوگل صفحه را فوراً ایندکس مجدد کند یا تست خاصی روی آن اجرا کند؛ فقط Search Console دوباره داده‌های CrUX را برای بررسی رفع مشکل پایش می‌کند.

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

چک‌لیست رفع مشکل LCP در وردپرس

• URL نمونه را از گزارش Core Web Vitals سرچ کنسول انتخاب کنید.
• همان URL و چند صفحه مشابه از گروه را در PageSpeed Insights تست کنید.
• عنصر دقیق LCP را مشخص کنید: تصویر، متن، ویدیو یا Background.
• 4 بخش TTFB، Load Delay، Load Duration و Render Delay را جدا بررسی کنید.
• اگر تصویر LCP است، ابعاد و حجم آن را متناسب با محل نمایش کنید.
• فرمت مناسب مانند WebP یا AVIF را در صورت سازگاری با نوع تصویر بررسی کنید.
• مطمئن شوید تصویر اصلی بالای صفحه Lazy Load نشده باشد.
• بررسی کنید وردپرس یا قالب از قبل fetchpriority="high" را مدیریت کرده یا نه.
• برای CSS Background فقط در صورت تشخیص دیر کشف شدن، Preload را بررسی کنید.
• TTFB را با Page Cache، هاست مناسب و بهینه‌سازی بک‌اند کاهش دهید.
• CSS و JavaScript مسدودکننده رندر را اصلاح کنید.
• اسلایدر و Animation عنصر Hero را برای وابستگی به JavaScript بررسی کنید.
• فونت‌های Critical و تعداد وزن‌های فونت را بهینه کنید.
• اسکریپت‌های شخص ثالث غیرضروری Above the Fold را کاهش دهید.
• تغییرات را روی موبایل و دسکتاپ جدا تست کنید.
• بعد از رفع مشکل، روند 28 روزه Validation در Search Console را آغاز کنید.

آیا LCP روی سئو و رتبه گوگل تأثیر دارد؟

Core Web Vitals بخشی از سیگنال‌های تجربه صفحه هستند و گوگل توصیه می‌کند سایت‌ها به وضعیت Good برسند؛ اما LCP به‌تنهایی تعیین‌کننده رتبه نیست. صفحه‌ای با LCP عالی اما محتوای ضعیف و نامرتبط صرفاً به‌دلیل سرعت بالا رتبه اول نمی‌گیرد.

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

جمع‌بندی

برای رفع مشکل LCP در وردپرس، از نصب تصادفی افزونه‌های بیشتر شروع نکنید. ابتدا عنصر LCP را پیدا کنید و ببینید زمان در کدام قسمت از مسیر بارگذاری تلف می‌شود. اگر TTFB بالا باشد، مشکل از پاسخ اولیه است؛ اگر تصویر دیر درخواست می‌شود، Resource Load Delay را بررسی کنید؛ اگر فایل دیر دانلود می‌شود، حجم و تحویل منبع مهم است؛ و اگر منبع دانلود شده ولی دیر ظاهر می‌شود، CSS، JavaScript و فونت را بررسی کنید.

در وردپرس، تصویر شاخص و Hero، Lazy Load اشتباه، اسلایدرها، Background Image، صفحه‌سازها، کش و هاست از مهم‌ترین نقاط بررسی هستند. بعد از اصلاح نیز باید تفاوت داده لحظه‌ای PageSpeed با داده واقعی 28 روزه Search Console را در نظر بگیرید و برای تغییر وضعیت گزارش کمی زمان بدهید.