لقد بذلت الجهد المطلوب. ضغطت الصور، أجّلت تحميل السكريبتات، ونظّفت الـ CSS. تُشغّل اختبار PageSpeed Insights وتجد… الأرقام لا تزال ليست على ما يُرام. الـ LCP بطيء. الـ CLS لا يتوقف عن القفز. نتائجك تتعثّر في المنطقة الصفراء بشكل مزعج.
إليك شيئًا لا يتحدث عنه كثير من المطوّرين: Core Web Vitals هي جزئيًا فقط مشكلة front-end. بيئة الاستضافة — السيرفر والشبكة وطبقة الـ caching — تلعب دورًا ضخمًا في نتائجك. وإذا كنت تُحسّن الطبقة الخطأ، فأنت تترك أداءً حقيقيًا يضيع دون استفادة.
هذا المقال يشرح بالتفصيل كيف تؤثر قرارات Core Web Vitals في الاستضافة على نتائجك، وما الذي يمكنك فعله حيال ذلك فعلًا.
ما الذي تقيسه Core Web Vitals فعلًا (الملخّص السريع)
مقاييس Core Web Vitals من Google هي ثلاثة مقاييس محددة:
- LCP (Largest Contentful Paint) — المدة حتى يتحمّل أكبر عنصر مرئي. الهدف: أقل من 2.5 ثانية.
- INP (Interaction to Next Paint) — مدى سرعة استجابة الصفحة لتفاعل المستخدم. الهدف: أقل من 200ms.
- CLS (Cumulative Layout Shift) — مقدار تحوّل التخطيط أثناء التحميل. الهدف: أقل من 0.1.
الـ LCP هو الأكثر ارتباطًا مباشرةً بإعداد السيرفر والاستضافة. لكن الـ INP أيضًا يمكن أن يتأثر إذا كان سيرفرك بطيئًا في الاستجابة للطلبات التي تُشغّل التفاعلات الديناميكية.
العلاقة بين Core Web Vitals في الاستضافة
فكّر في الأمر هكذا: قبل أن يتمكن المتصفح من عرض أي شيء، يحتاج إلى بيانات من سيرفر. إذا وصلت هذه البيانات ببطء، فكل ما يأتي بعدها يتأخر. لا يوجد أي قدر من تحسينات الـ front-end يعوّض عن سيرفر بطيء الاستجابة.
TTFB: المضاعف الخفي
الـ Time to First Byte (TTFB) هو المدة التي ينتظرها المتصفح قبل أن يستقبل أول بايت من الاستجابة. هو ليس أحد Core Web Vitals بحد ذاته، لكنه مضاعف مباشر لنتيجة الـ LCP.
توجيهات Google واضحة: يجب أن يكون الـ TTFB أقل من 800ms. ومثاليًا أقل من 200ms. سيرفر يستغرق 1.5 ثانية للاستجابة يعني أن الـ LCP لن يصل واقعيًا إلى 2.5 ثانية — فقد أنفقت معظم ميزانيتك قبل أن تبدأ الصفحة بالعرض أصلًا.
ما الذي يُسبّب ضعف الـ TTFB؟ عادةً أحد هذه الأسباب:
- أجهزة سيرفر ضعيفة (RAM أو CPU غير كافٍ لحجم الزيارات)
- غياب الـ page caching — تطبيقك يُعيد بناء الصفحة مع كل طلب
- استعلامات قاعدة البيانات التي تعمل مع كل تحميل صفحة دون أي طبقة caching
- البُعد الجغرافي بين سيرفرك وزوّارك
Page Caching: الإصلاح الأسرع
إذا كان موقعك يعمل على WordPress (أو أي CMS ديناميكي)، فالـ page caching هو التغيير الأعلى تأثيرًا الذي يمكنك إجراؤه على الـ TTFB والـ LCP. الصفحة المحفوظة في الـ cache لا تُشغّل PHP ولا تستعلم قاعدة البيانات — بل تُقدّم ملف HTML جاهزًا مباشرةً. يمكن أن تنخفض أوقات الاستجابة من 800ms إلى أقل من 50ms.
المضيف المُدار الجيد يتعامل مع هذا على مستوى السيرفر، باستخدام NGINX FastCGI caching أو آليات مشابهة، بدلًا من الاعتماد على إضافة WordPress للقيام بالمهمة. الـ caching على مستوى السيرفر أسرع ولا يُضيف عبء الإضافات.
موقع السيرفر والـ CDN: مشكلة الجغرافيا
الفيزياء لا تُهزم. البيانات التي تنتقل من سيرفر في فرانكفورت إلى زائر في سيدني تأخذ وقتًا — نحو 250ms فقط لرحلة الإشارة ذهابًا وإيابًا، بغضّ النظر عن سرعة سيرفرك.
بالنسبة لـ Core Web Vitals في الاستضافة، هذا مهم لأن عناصر الـ LCP (صور الهيرو، الخطوط، المحتوى فوق الطيّة) كلها تحتاج إلى إتمام تلك الرحلة قبل أن تتمكن من العرض.
ما الذي يفعله CDN فعلًا لنتائجك
شبكة توصيل المحتوى (CDN) تنسخ أصولك الثابتة — الصور والـ CSS والـ JS والخطوط — إلى سيرفرات حول العالم. حين يُحمّل الزائر صفحتك، تأتي هذه الأصول من أقرب نقطة edge، لا من سيرفرك الأصلي.
التأثير يمكن أن يكون كبيرًا. صورة كانت تستغرق 400ms للتحميل من مصدر بعيد قد تُحمَّل في 40ms من نقطة CDN قريبة. هذا وحده يمكن أن يدفع الـ LCP من "يحتاج تحسينًا" إلى المنطقة الخضراء.
بعض الأشياء التي يجب البحث عنها في إعداد الـ CDN:
- رؤوس cache صحيحة على الأصول الثابتة (قيم max-age لا تقل عن سنة للملفات ذات البصمة)
- تفعيل الضغط على الـ edge (Brotli أو gzip)
- دعم HTTP/2 أو HTTP/3 لتحميل الأصول بشكل متوازٍ
كيف تؤثر قرارات Core Web Vitals في الاستضافة على CLS
الـ CLS هو المقياس الأصعب لأنه يبدو وكأنه مشكلة front-end خالصة (وهو كذلك في معظمه). لكن السيرفرات البطيئة تُسهم فيه بطريقة خفية.
حين تتحمل الصفحة ببطء، غالبًا ما تصل الخطوط متأخرة. يعرض المتصفح النص بخط احتياطي أولًا، ثم يتحوّل إلى الخط المخصص — مما يُسبّب انزياحًا في التخطيط. نفس الشيء يحدث مع الصور التي لا تحمل سمات width وheight محددة: المتصفح لا يعرف كم من المساحة يُخصّص حتى تتحمل الصورة.
السيرفر السريع يُضيّق النافذة الزمنية التي يمكن أن تحدث فيها هذه الانزياحات. والـ HTTP caching الصحيح يعني أن الخطوط والصور تُخدَّم من الـ cache المحلي للمتصفح في الزيارات المتكررة، مما يُحسّن نتائج الـ CLS بشكل ملحوظ للزوّار العائدين.
إصلاحات عملية تُحرّك الـ CLS فعلًا
- أضف سمات width وheight صريحة لجميع الصور — هذا يُتيح للمتصفح حجز المساحة فورًا
- استخدم font-display: optional لمنع تبديل الخطوط كليًا عند التحميل الأول
- قم بـ preload لخط الويب الرئيسي باستخدام <link rel="preload" as="font"> حتى يصل قبل عرض النص
- تجنّب حقن محتوى فوق الطيّة ديناميكيًا بعد التحميل (الإعلانات، بانرات الكوكيز، إلخ)
موارد السيرفر والـ INP
الـ INP يقيس مدى سرعة استجابة الصفحة لتفاعل المستخدم — نقرة، لمسة، ضغطة مفتاح. وبينما هذه في معظمها مشكلة JavaScript، يمكن للعوامل من جهة السيرفر أن تتسلل للمواقع التي تُجري API calls أو استعلامات قاعدة بيانات عند التفاعل.
إذا كان النقر على زر يُطلق طلبًا للسيرفر والسيرفر تحت ضغط (CPU مرتفع، ضغط على الذاكرة، قاعدة بيانات بطيئة)، فسيبدو ذلك التفاعل متثاقلًا حتى لو كان كود الـ front-end نظيفًا. تحديد حجم سيرفرك بما يتناسب مع مستويات الزيارات الفعلية أهم مما يُدرك معظم الناس.
طريقة سريعة للتحقق: شغّل موقعك تحت حمل محاكى باستخدام أداة مثل k6 أو Loader.io وراقب كيف يرتفع الـ TTFB مع زيادة المستخدمين المتزامنين. إذا تدهور بحدة، فسيرفرك أصغر من اللازم.
أدوات لتشخيص مشكلات Core Web Vitals في الاستضافة
قبل التحسين، قِس. هذه الأدوات تستحق المعرفة:
- PageSpeed Insights — يستخدم بيانات واقعية من Chrome User Experience Report (CrUX) إلى جانب نتائج المعمل. بيانات الميدان هي ما تستخدمه Google فعلًا للترتيب.
- WebPageTest — رسوم waterfall تفصيلية تُظهر الـ TTFB وترتيب تحميل الأصول وتوقيت الاتصال. لا غنى عنها لتشخيص التأخيرات على مستوى السيرفر.
- Chrome DevTools ← تبويب Network — صفّ حسب نوع المستند لترى وقت استجابة HTML. صف "Waiting (TTFB)" يُخبرك بالضبط كم استغرق سيرفرك للاستجابة.
- Google Search Console ← تقرير Core Web Vitals — يُظهر بيانات المستخدمين الحقيقيين مُجمَّعة على مدى 28 يومًا، مقسّمة حسب الجوال وسطح المكتب.
انظر دائمًا إلى بيانات الميدان (المستخدمون الحقيقيون) جنبًا إلى جنب مع بيانات المعمل (المحاكاة). يمكن أن تبدو نتائج المعمل رائعة بينما تعاني النتائج الفعلية — خاصة إذا كان زوّارك الحقيقيون يستخدمون اتصالات أو أجهزة أبطأ.
قائمة التدقيق: ما الذي تراجعه على جانب الاستضافة
إذا كانت نتائج Core Web Vitals في الاستضافة لديك دون المستوى، اعمل على هذه النقاط قبل أن تلمس كود الـ front-end:
- تحقق من الـ TTFB في WebPageTest — أي قيمة فوق 600ms تُعدّ إشارة تحذير
- تأكد أن الـ page caching على مستوى السيرفر مُفعَّل (ليس مجرد إضافة)
- تحقق أن الأصول الثابتة لها مدد cache طويلة وتُخدَّم مع الضغط
- تأكد أن سيرفرك في نفس المنطقة الجغرافية لغالبية زوّارك
- فكّر في CDN للأصول الثابتة إذا كنت تخدم زيارات دولية
- راجع استخدام موارد سيرفرك خلال ذروة الزيارات — ضغط الـ CPU والذاكرة كلاهما يُضر بأوقات الاستجابة
نحن نُشغّل الـ caching على مستوى السيرفر بشكل افتراضي في بيئات الاستضافة لدينا، مما يُلغي في العادة الـ TTFB كعائق لمعظم مواقع WordPress مباشرةً من البداية. لكن حتى مع ذلك، لا يزال عمل الـ front-end مهمًا — سيرفر سريع يُقدّم صفحة غير مُحسَّنة لن يأخذك بعيدًا.
الفوز الحقيقي يأتي من الطبقتين معًا: سيرفر يستجيب بسرعة، وصفحة تُعرض بكفاءة. احصل على هذا المزيج الصحيح وستعكس نتائج Core Web Vitals في الاستضافة لديك ذلك.
