كيفية تحسين LCP في ووردبريس خطوة بخطوة
حسّن LCP في ووردبريس بتحديد أكبر عنصر ظاهر وتقليل TTFB وإعطاء الصورة الرئيسية الأولوية وإزالة تأخر اكتشاف المورد ورسمه.
اعرف LCP Element ثم قس مسارها: استجابة السيرفر، وقت اكتشاف المورد، زمن تحميله، وتأخير رسمه. لا تفترض أن الصورة هي السبب دائماً.
يقيس Largest Contentful Paint الوقت حتى رسم أكبر صورة أو كتلة نص أو فيديو ظاهر في بداية الصفحة. الهدف الجيد هو 2.5 ثانية أو أقل عند 75th Percentile، بصورة مستقلة للموبايل والكمبيوتر.
قبل تثبيت إضافة أداء جديدة، اعرف العنصر الذي يمثل LCP وأي جزء من زمنه هو الأكبر. الهدف هو علاج الجزء البطيء في المسار، لا جمع إعدادات تحسين لا تعرف أثرها.
حدد العنصر في صفحات حقيقية
ابدأ من Field Data في Search Console وPageSpeed، ثم استخدم Lighthouse أو Chrome DevTools على Templates مختلفة:
- الرئيسية.
- مقال أو صفحة.
- Product أو Category.
- زيارة Mobile بدون Login.
قد تكون LCP صورة Hero أو Featured Image أو Heading أو Background داخل Page Builder. وقد يختلف العنصر حسب Viewport أو A/B Test.
يوضح الفرق بين PageSpeed وSearch Console لماذا تختلف نتيجة المختبر عن زيارات المستخدمين.
افهم الأجزاء الأربعة لزمن LCP
استخدم النموذج التالي:
- TTFB: من بدء التنقل حتى أول Byte من HTML.
- Resource Load Delay: من TTFB حتى بدء طلب مورد LCP.
- Resource Load Duration: وقت نقل المورد.
- Element Render Delay: من انتهاء المورد حتى رسم العنصر.
إذا كان العنصر Text فلن توجد صورة منفصلة، لكن CSS أو Font قد تمنع الرسم.
ابدأ بأكبر جزء. ضغط الصورة لن يعالج TTFB مدتها ثانيتان.
قلل TTFB في ووردبريس
قس صفحة عامة لمستخدم Anonymous من مناطق قريبة من جمهورك. الصفحات العامة القابلة للتخزين يفترض غالباً أن تأتي من Full Page Cache دون تشغيل WordPress وكل Plugins وقاعدة البيانات في كل طلب.
افحص:
- Cache HIT وMISS.
- تشبع PHP-FPM.
- Slow Queries وAutoloaded Options الضخمة.
- API Calls داخل بناء الصفحة.
- Object Cache للصفحات الديناميكية.
- بُعد Origin وسياسة CDN.
لا تخزن Cart أو Session أو Preview كـPublic HTML. ضع Bypass Rules واضحة.
احذف Plugins غير اللازمة وقس Hooks الثقيلة. ترقية السيرفر قد تساعد، لكنها لا تصلح Query غير محدودة أو HTTP Call متزامنة.
اجعل صورة LCP ظاهرة للمتصفح مبكراً
يجب أن تظهر الصورة في HTML الأولية:
<img
src="/uploads/hero-1280.webp"
srcset="
/uploads/hero-640.webp 640w,
/uploads/hero-960.webp 960w,
/uploads/hero-1280.webp 1280w
"
sizes="(max-width: 760px) 100vw, 1200px"
width="1280"
height="720"
alt="وصف دقيق للصورة"
fetchpriority="high"
>
لا تستخدم Lazy Loading لصورة LCP الحالية. قد يضيف WordPress Attributes تلقائياً، ثم تعيد Theme أو Builder أو CDN Plugin كتابتها. افحص HTML النهائي.
استخدم fetchpriority="high" لمورد واحد مهم، لا لعدة صور تتنافس على الشبكة.
Background Image في CSS لا تكتشف إلا بعد وصول Stylesheet. استخدم <img> أو <picture> للمحتوى الدلالي. إذا اضطررت إلى Preload فتأكد أنه لا يحمل صورة Desktop غير مستخدمة على Mobile.
أرسل الحجم الصحيح من الصورة
لا ترسل صورة بعرض 4000px إلى مكان يعرض 700px. أنشئ Sizes مناسبة، واستخدم srcset وsizes بدقة.
قارن WebP وAVIF بالجودة المطلوبة؛ لا يوجد Format يفوز في كل الصور. أضف width وheight أو aspect-ratio لحجز المساحة ومنع CLS.
راجع Cache Headers وCDN HIT. تحويل الصور عند أول Request لكل مقاس قد يضغط Origin؛ ولّد المقاسات الشائعة مسبقاً أو استخدم Image Service مدروسة.
أزل تأخير الاكتشاف والرسم
يتأخر Request عندما ينتظر المتصفح JavaScript أو Slider ليضيف الصورة. ويتأخر الرسم بسبب CSS كبيرة أو Font أو Animation تخفي العنصر.
حلول عملية:
- ضع Hero الأولى داخل Server HTML.
- لا تعتمد على Carousel لعرض أول صورة.
- اجعل Critical CSS صغيرة ومحددة.
- أخر Scripts غير المهمة واحذف Assets غير المستخدمة.
- حمّل Chat وAnalytics وفق حاجة واضحة.
- استخدم
font-displayولا تعمل Preload لكل الخطوط. - أزل Entrance Animation التي تجعل LCP شفافة.
أفضل تحسين لـThird-party Script قد يكون عدم تحميلها في هذه الصفحة.
اكتشف تعارض إضافات ووردبريس
اختبر في Staging بطبقة Optimization واحدة في كل مرة. تداخل Cache وMinify وLazy Load وCDN قد يعيد كتابة العنصر نفسه.
ابحث عن:
loading="lazy"على صورة LCP.- Preloads مكررة.
- صورة Desktop على Mobile.
- تجميع CSS يؤخر Background.
- Cookie Banner أصبح أكبر عنصر.
- Slider يستبدل الصورة بعد التحميل.
- Cache Variants كثيرة تقلل HIT Ratio.
امسح Cache المتأثرة فقط بعد التغيير، واختبر Cold وWarm.
تحقق ببيانات المختبر والمستخدمين
بعد النشر:
- تحقق من LCP Element في عدة اختبارات Mobile.
- قارن أجزاء LCP الأربعة قبل وبعد.
- افحص HTML وPriority وCache والصورة المختارة من
srcset. - راقب Real User LCP حسب Template والجهاز.
- سجل تاريخ Release وانتظر تحرك نافذة CrUX.
أخطاء شائعة
الأخطاء المتكررة: Lazy Load للـHero، Preload لصور كثيرة، تجاهل TTFB، اختبار الرئيسية فقط، الاعتماد على Run واحدة، وتكديس Plugins دون قراءة HTML.
إذا وجدت PHP-FPM تنهار أثناء التحقيق، استخدم دليل حل 502 بدلاً من رفع المهلات عشوائياً.
أسئلة شائعة
هل أحمّل الصورة الرئيسية مسبقاً في ووردبريس؟
بعد إثبات أنها مورد LCP وأن طلبها يبدأ متأخراً فقط. قد يكفي HTML واضح وfetchpriority؛ Preload غير اللازمة قد تنافس CSS أو صورة Mobile الصحيحة.
هل تستطيع إضافة أداء واحدة إصلاح LCP؟
فقط عندما تعالج الجزء المقاس. Cache قد تقلل TTFB، لكنها لا تصلح صورة ضخمة أو اكتشافاً متأخراً عبر JavaScript أو Theme تحجب الرسم.
مراجع رسمية
لديك سؤال عن هذا الدليل أو فكرة لتعاون تقني؟ تواصل مع بكري عبر المركز التقني.
نهاية الملاحظة.