تحسين سرعة الموقع: دليل Core Web Vitals العملي (LCP وINP وCLS)

لماذا يهمك تحسين سرعة الموقع؟

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

من جهة السيو، تقول Google Search Central إنها توصي بشدة بتحقيق نتائج جيدة في Core Web Vitals للنجاح في البحث، وإن هذه المؤشرات مع باقي جوانب تجربة الصفحة تتوافق مع ما تسعى أنظمة الترتيب لمكافأته. لكن جوجل لا تقول إن السرعة تتفوق على جودة المحتوى وصلته بالبحث. الصفحة السريعة بلا محتوى مفيد لن تتصدر، والصفحة المفيدة البطيئة تخسر جزءًا من زوارها.

لذلك انظر إلى السرعة كجزء من السيو التقني، وليس كهدف منفصل للحصول على رقم 100 في أداة اختبار.

ما هي Core Web Vitals وما حدودها الحالية؟

Core Web Vitals هي ثلاثة مؤشرات من Google تقيس تجربة المستخدم الفعلية: التحميل، والاستجابة، والثبات البصري. الحدود الحالية حسب web.dev هي LCP حتى 2.5 ثانية، وINP حتى 200 ملّي ثانية، وCLS حتى 0.1.

نقطتان مهمتان لفهم هذه الأرقام:

• المئين 75: تُعد الصفحة جيدة إذا حققت الحد المطلوب في 75% من الزيارات على الأقل، مع فصل الهاتف عن الكمبيوتر. أي أن أبطأ ربع من زوارك لا يُحسب ضدك، لكن الأغلبية يجب أن تحصل على تجربة جيدة.
• INP بدل FID: أصبح INP مؤشرًا أساسيًا مستقرًا في 2024 وحل محل FID، لأنه يقيس كل التفاعلات خلال الزيارة وليس أول تفاعل فقط.

بيانات الزوار الحقيقيين مقابل بيانات المختبر

بيانات الحقل (Field Data) هي قياسات من زوار حقيقيين يستخدمون متصفح كروم، وتأتي من تقرير Chrome User Experience Report المعروف بـ CrUX. أما بيانات المختبر (Lab Data) فهي محاكاة لتحميل الصفحة على جهاز وشبكة محددين عبر أداة Lighthouse.

كيف تقيس سرعة موقعك خطوة بخطوة؟

أفضل طريقة للقياس هي الجمع بين PageSpeed Insights لفحص صفحات بعينها، وتقرير Core Web Vitals في Google Search Console لمتابعة الموقع كله. اتبع هذا الترتيب:

لمعرفة كيف تقرأ باقي تقارير الأداة، راجع دليل Google Search Console.

تحسين LCP: أسرع ظهور للمحتوى الرئيسي

تحسين LCP يعني تقليل الوقت حتى يظهر أكبر عنصر في الشاشة الأولى. يقسم web.dev هذا الوقت إلى أربعة أجزاء: وقت أول بايت من الخادم (TTFB)، وتأخر بدء تحميل عنصر LCP، ومدة تحميله، وتأخر عرضه. الإصلاح يستهدف كل جزء.

• خادم أسرع وتخزين مؤقت: يوضح web.dev أن ارتفاع TTFB قد يجعل الوصول إلى 2.5 ثانية صعبًا أو مستحيلًا. استضافة جيدة، وتخزين مؤقت للصفحات (Page Cache)، وتقليل التحويلات (Redirects) كلها تقلل هذا الوقت.
• شبكة توصيل المحتوى (CDN): تقدم الملفات من خادم قريب من الزائر، ويعدها web.dev أفضل طريقة لتقليل مدة تحميل الملفات.
• صيغ صور حديثة: حوّل الصور إلى WebP أو AVIF، واستخدم مقاسات مناسبة لكل شاشة بدل رفع صورة ضخمة وتصغيرها بالكود.
• لا تؤجل تحميل صورة LCP: التحميل الكسول (loading="lazy") ممتاز للصور أسفل الصفحة، لكن web.dev يحذر صراحة من استخدامه مع صورة LCP لأنه يؤخرها دائمًا.
• أولوية تحميل عالية: أضف fetchpriority="high" لصورة LCP، ولا تستخدمه مع أكثر من صورة أو صورتين حتى لا يفقد فائدته.
• التحميل المسبق (preload): إن كانت صورة LCP خلفية في CSS أو تضاف بالجافاسكربت، فاستخدم preload ليكتشفها المتصفح مبكرًا.

تحسين INP وCLS: الاستجابة وثبات التصميم

INP يتحسن بتقليل عمل الجافاسكربت الذي يشغل المتصفح، وCLS يتحسن بحجز مساحة ثابتة لكل عنصر قبل تحميله. المشكلتان مختلفتان، لكنهما غالبًا تظهران معًا في المواقع المثقلة بالإضافات والسكربتات.

إصلاح INP

يتكون كل تفاعل من ثلاث مراحل حسب web.dev: تأخر الإدخال حتى يبدأ تنفيذ الكود، ومدة تنفيذ الكود، وتأخر العرض حتى يرسم المتصفح النتيجة.

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

إصلاح CLS

• أبعاد الصور والفيديو: حدد width وheight أو aspect-ratio ليحجز المتصفح المساحة مسبقًا.
• الإعلانات والتضمينات: احجز لها مساحة بارتفاع أدنى، ولا تُدخل محتوى فوق ما يقرأه الزائر دون أن يطلبه.
• الخطوط: حمّل الخطوط المهمة مسبقًا (preload)، واستخدم font-display، واختر خطًا بديلًا قريب المقاسات. يقترح web.dev قيمة optional لتقليل التحرك، ومع الخطوط العربية الثقيلة يقلل عدد الأوزان المستخدمة الحجم كثيرًا.
• الحركات: حرّك العناصر بخاصية transform بدل تغيير top أو left أو الارتفاع.

جدول المؤشرات وأسبابها وطرق علاجها

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

بأي إصلاح تبدأ؟ ترتيب الأولويات

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

1. ابدأ بالمؤشر الراسب في بيانات الحقل. تقرير Search Console يحدد حالة المجموعة بأسوأ مؤشر فيها، فلا فائدة من تحسين LCP الجيد أصلًا بينما CLS ضعيف.
2. ركز على القوالب لا الصفحات. صفحات الخدمات أو المقالات أو المنتجات تشترك غالبًا في قالب واحد. إصلاح القالب يصلح مئات الصفحات مرة واحدة.
3. ابدأ بالإصلاحات الآمنة: ضغط الصور، وتحديد أبعادها، وإزالة التحميل الكسول من الصورة الأولى، وتفعيل التخزين المؤقت. هذه نادرًا ما تكسر شيئًا في الموقع.
4. ثم انتقل للإصلاحات الأعمق: تأجيل الجافاسكربت، وحذف الإضافات، وتغيير القالب أو الاستضافة. هذه تحتاج اختبارًا أدق للنماذج والقوائم وصفحات الدفع.
5. انتظر بيانات الحقل. نتائج المختبر تتحسن فورًا، لكن بيانات الزوار الحقيقيين متوسط 28 يومًا، فلا تحكم على الإصلاح من اليوم التالي.

التخزين المؤقت وشبكة CDN باختصار

التخزين المؤقت (Caching) هو حفظ نسخة جاهزة من الصفحة أو الملف حتى لا يعيد الخادم بناءها مع كل زيارة. ويعمل على مستويين: كاش الخادم الذي يقلل وقت أول بايت، وكاش المتصفح الذي يجعل الزيارة الثانية أسرع لأن الملفات محفوظة عند الزائر. أما شبكة CDN فتنسخ ملفاتك الثابتة، مثل الصور والخطوط وملفات CSS، على خوادم في مناطق مختلفة، فيحمّلها الزائر من أقرب خادم له. إذا كان أغلب جمهورك في مصر والخليج والخادم في أوروبا أو أمريكا، فاختيار استضافة وCDN لهما نقاط قريبة من جمهورك يستحق التجربة والقياس.

سرعة موقع ووردبريس: نصائح صريحة

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

• إضافة تخزين مؤقت واحدة فقط: اختر إضافة كاش واحدة موثوقة، أو استخدم الكاش الذي تقدمه استضافتك. تشغيل إضافتين بنفس الوظيفة يسبب تعارضًا وأخطاء.
• ميزات ووردبريس المدمجة: حسب فريق ووردبريس، يضيف الإصدار 6.3 وما بعده fetchpriority="high" تلقائيًا للصورة المتوقع أن تكون عنصر LCP، ولا يطبق التحميل الكسول على الصور الأولى في الشاشة. تأكد أن إضافات التحسين لا تلغي هذا السلوك بإضافة lazy لكل الصور.
• منشئات الصفحات (Page Builders): أدوات مثل Elementor تسهل التصميم، لكنها قد تضيف عناصر متداخلة وملفات CSS وJS أكثر. يمكن الحصول على نتائج جيدة بها، بشرط تفعيل خيارات الأداء المتاحة فيها، وتجنب الإضافات الجانبية الكثيرة، وتبسيط الأقسام.
• راجع الإضافات دوريًا: احذف أي إضافة لا تستخدمها، وابحث عن الإضافات التي تحمّل ملفاتها في كل الصفحات وهي تعمل في صفحة واحدة فقط، مثل نماذج التواصل.
• الصور عند الرفع: صغّر الصور قبل رفعها، أو استخدم أداة تحولها إلى WebP أو AVIF تلقائيًا.
• حدّث ووردبريس ونسخة PHP من لوحة الاستضافة، فالإصدارات الأحدث غالبًا أسرع وأكثر أمانًا.

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

الخلاصة

تحسين سرعة الموقع يبدأ بالقياس الصحيح: بيانات الزوار الحقيقيين في PageSpeed Insights وتقرير Core Web Vitals في Search Console، ثم بيانات المختبر لتشخيص الأسباب. استهدف LCP خلال 2.5 ثانية، وINP خلال 200 ملّي ثانية، وCLS لا يتجاوز 0.1 في 75% من الزيارات. عالج LCP بخادم أسرع وتخزين مؤقت وصور خفيفة وأولوية عالية لصورة LCP دون تحميل كسول. عالج INP بتقليل الجافاسكربت، وCLS بحجز المساحات وضبط الخطوط. وفي ووردبريس، ابدأ بالاستضافة والقالب والإضافات قبل البحث عن أداة سحرية. السرعة تخدم الزائر أولًا، والسيو يستفيد بعد ذلك.