إطار من 3 طبقات لاجتياز Core Web Vitals في ووردبريس

موقعك بيجيب 95 في Lighthouse، وبرضه Google Search Console بيقولك إن الصفحات راسبة في ووردبريس للمحتوى المؤرخ مثل التدوينات والأخبار والشروحات. تُرتّب زمنيًا وتُنظَّم بالتصنيفات والوسوم وتظهر في الأرشيف وخلاصات RSS، بخلاف الصفحات الثابتة.">الصفحة أثناء التحميل. تدخل ضمن إشارات…">Core Web Vitals. المشكلة مش إن فيه حاجة ناقصة تركّبها، المشكلة إنك بتقيس حاجة والزاير بيعيش حاجة تانية. والحل معماري، يعني ترتيب، مش إضافة خامسة فوق الأربعة اللي عندك.

المشكلة الحقيقية: تكديس الإضافات

النمط الخاطئ الأشهر في تحسين أداء ووردبريس هو تكديس الإضافات (Plugin Stacking): إضافة للتخزين المؤقت للصفحات، وثانية لاستخراج Critical CSS، وثالثة لتوليد صور WebP/AVIF، ورابعة لتأجيل السكربتات، ثم سكربت لصيانة السيرفر.">قاعدة البيانات فوقها جميعاً.

النتيجة متوقعة في كل مرة:

• قائمة الهامبرجر في الموبايل تتجمد عند أول ضغطة.
• أخطاء JavaScript في صفحات السلة والدفع الديناميكية في ووكومرس.
• تعارضات عشوائية تظهر بعد أي تحديث للقالب أو لإحدى الإضافات.

كل إضافة تفترض أنها المسؤولة الوحيدة عن الصفحة، والتصادم يقع في المنطقة المشتركة بينها.

الخطوة 1: فرّق بين قياس المعمل وبيانات المستخدم الحقيقي

قبل تعديل أي قاعدة إعادة توجيه أو أي ملف JavaScript، افصل بين نوعين من القياس مختلفين تماماً.

فخ Lighthouse

تشغيل Lighthouse في وضع الموبايل داخل أدوات مطوّري Chrome يُطبّق محاكاة لجهاز Moto G4 مع إبطاء المعالج أربع مرات فوق شبكة مقيّدة. هذه أداة ممتازة لاكتشاف المهام الطويلة (أكثر من 50 مللي ثانية) في الكود، لكنها لا تمثّل جمهورك الفعلي ولا الأجهزة التي يستخدمها.

الإشارة التي تعتمدها Google فعلاً

تقيس خوارزميات الترتيب الشريحة المئوية 75 من زيارات المستخدمين الحقيقيين على مدى 28 يوماً، كما يجمعها تقرير Chrome User Experience Report المعروف اختصاراً بـ CrUX.

ملاحظة: البيانات في Search Console تتحرك ببطء لأنها نافذة متدحرجة مدتها 28 يوماً. لا تحكم على تعديل نفّذته أمس من رقم اليوم.

الخطوة 2: عالج الاختناقات بترتيب قراءة المتصفح للصفحة

الترتيب هنا ليس تفضيلاً شخصياً. حلّ كل طبقة بالترتيب الذي يمر به المتصفح فعلاً، وإلا كنت تحسّن شيئاً لا يراه الزائر أصلاً.

الطبقة الأولى: تجاوز PHP على مستوى السيرفر

إضافات التخزين المؤقت التقليدية تعتمد على ملف advanced-cache.php. حين يصل الطلب، لا يزال السيرفر مضطراً لتشغيل PHP-FPM كي يعثر على الملف المخزّن ويسلّمه، فيبقى TTFB متأرجحاً بين 40 و150 مللي ثانية.

الحل هو قواعد إعادة كتابة أصلية في Nginx أو Apache تجعل السيرفر يبحث عن ملف ثابت مضغوط مسبقاً على القرص ويسلّمه في 1 إلى 5 مللي ثانية، متجاوزاً PHP بالكامل.

# Direct zero-PHP static cache delivery

location / {

    try_files /wp-content/cache/page-cache/$http_host/$uri/index.html.br

              /wp-content/cache/page-cache/$http_host/$uri/index.html.gz

              /wp-content/cache/page-cache/$http_host/$uri/index.html

              $uri $uri/ /index.php?$args;

}

عدّل المسار بحسب المجلد الذي تكتب فيه إضافة الكاش لديك ملفاتها.

تنبيه: يجب استثناء الطلبات التي تحمل كوكيز الجلسات الديناميكية مثل woocommerce_items_in_cart وwordpress_logged_in_ من هذا البلوك، وإلا قدّمت للمستخدم المسجّل نسخة مخزّنة لا تخصّه. اختبر على بيئة الاختبار قبل الإنتاج.

الطبقة الثانية: أولوية صورة الشاشة الأولى

السبب الأول لضعف LCP هو تطبيق التحميل الكسول (Lazy Loading) على صورة الهيرو الظاهرة في أول الشاشة.

التحميل الكسول يطلب من المتصفح تأجيل الصورة حتى يحسب مواضع العناصر، وهذا يمنع ماسح التحميل المسبق السريع من اكتشاف الصورة في أول دفعة HTML. النتيجة: تأخير مباشر في أهم عنصر مرئي في الصفحة.

الإصلاح خطوتان: استثنِ صورة الهيرو من التحميل الكسول، وأضف fetchpriority="high" على العنصر الأساسي في الشاشة الأولى.

// Automatically prioritize the primary hero image in WordPress

add_filter(‘wp_get_attachment_image_attributes’, function($attr, $attachment) {

    static $first = true;

    if ($first && !is_admin() && is_singular()) {

        $attr[’fetchpriority’] = ‘high’;

        unset($attr[’loading’]); // Prevent lazy loading on LCP element

        $first = false;

    }

    return $attr;

}, 10, 2);

ثم استخرج Critical CSS الخاص بالشاشة الأولى وضعه مباشرة داخل الصفحة، ليرسم المتصفح ما يراه الزائر من أول جولة شبكة.

ملاحظة: لو الموقع عربي، الخط جزء أصيل من معادلة LCP. حمّل خط Cairo أو Tajawal من استضافتك بصيغة woff2 مع preload وfont-display: swap، بدلاً من استدعائه من سيرفر خارجي يضيف جولة اتصال كاملة قبل ظهور النص.

الطبقة الثالثة: جدولة السكربتات على ثلاثة مستويات

يقيس مؤشر INP زمن الاستجابة الكامل لكل تفاعل: تأخير الإدخال، ومدة معالجة الحدث، وزمن العرض النهائي.

تأجيل كل ملفات JavaScript حتى أول تفاعل من المستخدم حل كسول يكسر التحقق من النماذج وسلة التسوق المنبثقة. البديل هو تصنيف السكربتات إلى ثلاث طبقات تنفيذ:

1. طبقة التأجيل: سكربتات التخطيط الأساسية، تُنفَّذ عند DOMContentLoaded.
2. طبقة الخمول: التتبع والتحليلات، تُجدوَل عبر requestIdleCallback() في فترات خمول المتصفح.
3. طبقة التفاعل: الأدوات الخارجية الثقيلة مثل الدردشة المباشرة ووحدات التقييمات، لا تُنفَّذ إلا بعد ضغطة أو تمرير.

ولتفتيت العمليات الطويلة دون حجب نقرات المستخدم، استخدم scheduler.yield():

// Yield execution back to the main thread during heavy processing

async function yieldToMain() {

    if (‘scheduler’ in window && ‘yield’ in scheduler) {

        return await scheduler.yield();

    }

    return new Promise(resolve => setTimeout(resolve, 0));

}

تنبيه: استثنِ المسارات الديناميكية /cart/ و/checkout/ ولوحة حساب العميل من أي تأجيل للسكربتات. خسارة عشرين مللي ثانية أهون من سلة لا تُحدَّث.

في Elementor: قبل إضافة أي كود، افتح Elementor ← Settings ← Features وفعّل Optimized DOM Output وImproved Asset Loading وImproved CSS Loading. هذه الخيارات تقلّص حجم الـ DOM ولا تحمّل ملفات الودجات غير المستخدمة في الصفحة، وهي أول ما يجب ضبطه قبل مطاردة المللي ثانية في مكان آخر.

الخطوة 3: تحقّق من النتيجة على مستخدمين حقيقيين

بعد تطبيق التعديلات المعمارية، افصل التحقق إلى مستويين:

• اختبار معملي: تأكد أن TTFB أقل من 50 مللي ثانية وأن First Contentful Paint أقل من ثانية واحدة، عبر تشغيل WebPageTest من أكثر من منطقة جغرافية.
• مراقبة ميدانية: تابع بيانات الـ 28 يوماً المتدحرجة في Google Search Console تحت قسم Core Web Vitals، وراقب انتقال الروابط إلى خانة “Good”.

ملاحظة: شغّل WebPageTest من فرانكفورت لو جمهورك في مصر أو الخليج. القياس من فيرجينيا سيعطيك رقماً لا يعيشه أي زائر لديك. واستضافة قريبة من المنطقة مع CDN تحلّ نصف مشكلة TTFB قبل أن تكتب سطر كود واحداً جرّب Hostinger.

المقارنة في جدول واحد

الخلاصة

اجتياز Core Web Vitals ليس نتيجة إضافة واحدة ذكية، بل نتيجة ترتيب صحيح: سيرفر يسلّم HTML جاهزاً دون تشغيل PHP، ثم شاشة أولى تُكتشف مواردها فوراً، ثم JavaScript مجدول بحسب أهميته للمستخدم. رتّب الطبقات الثلاث بهذا التسلسل وستتوقف عن مطاردة الأرقام المعملية.

ابدأ بالطبقة الأولى الأسبوع ده، وقيس TTFB قبل وبعد. لو الرقم ما اتحركش، المشكلة في الاستضافة نفسها مش في الكود. ولو محتاج حد يبص على معمارية موقعك معاك، احجز جلسة من هنا احجز استشارة مجانية.

مرجع المقال (بالإنجليزية): The 3-Step Architecture Framework to Pass Core Web Vitals in WordPress
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.

الأسئلة الشائعة

لماذا أحصل على 95 في Lighthouse بينما Search Console يخبرني أن الصفحات راسبة؟

لأن Lighthouse اختبار معملي يُحاكي جهازاً ضعيفاً وشبكة بطيئة في لحظة واحدة، بينما تعتمد Google في التقييم على بيانات CrUX الحقيقية: الشريحة المئوية 75 من زيارات المستخدمين خلال 28 يوماً. النتيجتان تقيسان شيئين مختلفين، والثانية وحدها هي التي تؤثر في الترتيب.

ما الفرق بين TTFB وLCP وINP باختصار؟

TTFB هو زمن وصول أول بايت من السيرفر، وLCP هو زمن ظهور أكبر عنصر مرئي في الشاشة الأولى، وINP هو زمن استجابة الموقع لتفاعل المستخدم. الأول مسؤولية السيرفر، والثاني مسؤولية ترتيب تحميل الموارد، والثالث مسؤولية جدولة JavaScript.

هل تأجيل كل ملفات JavaScript حتى أول تفاعل حل جيد؟

لا. التأجيل الشامل يكسر التحقق من النماذج وسلة ووكومرس المنبثقة. الصحيح هو تصنيف السكربتات إلى ثلاث طبقات: تأجيل عادي، وتنفيذ في وقت خمول المتصفح، وتنفيذ عند التفاعل فقط.

كم إضافة سرعة أحتاج على موقع ووردبريس؟

العدد ليس المقياس. المشكلة تبدأ حين تتولى أربع إضافات منفصلة الكاش وCritical CSS وضغط الصور وتأجيل السكربتات، فتتصادم فيما بينها بعد أي تحديث. طبقة واحدة متماسكة أفضل من أربع طبقات متنافسة.

هل يؤثر بُعد السيرفر عن القاهرة أو الرياض في النتيجة؟

نعم، ويظهر أثره مباشرة في TTFB. اختيار مركز بيانات في فرانكفورت مع تفعيل CDN يقلّص المسافة الفعلية، وهو غالباً أرخص تحسين متاح لزوار المنطقة.