أسرار الـ Core Web Vitals المخفية

أسرار جوجل الخفية للسرعة

الحصول على العلامة الكاملة في أدوات الفحص لا يعني بالضرورة أن موقعك يقدم تجربة سريعة للمستخدم الحقيقي.

دائماً ما يأتيني أصحاب المتاجر الإلكترونية الكبرى في الرياض وجدة بشكوى متكررة: "يا مهندس، موقعنا يحصل على تقييم 95% في أداة جوجل بيج سبيد، ولكن المبيعات تنخفض، والزوار يغادرون الموقع بسرعة، وجوجل كونسول يظهر لنا أخطاء حمراء!". هذه الشكوى تكشف عن الفجوة العميقة بين ما يقرأه المبرمج على شاشته، وبين ما يعانيه المستخدم الفعلي وهو يمسك بجواله في شبكة إنترنت قد تكون متذبذبة.

مقاييس الأداء الأساسية للويب Core Web Vitals ليست مجرد أرقام تتباهى بها في تقاريرك لمديرك. إنها نبض الموقع، هي الترجمة الرقمية لحالة الإحباط أو السعادة التي يشعر بها عميلك. في هذا الدليل المعمق عبر أكاديميتكم، أكاديمية الجندي سيوتربو لعلوم الويب، لن نتحدث عن القشور التي تجدها في أي مدونة عادية. لن أقول لك "قم بضغط الصور" فهذا أمر بديهي، بل سنغوص معاً في الأسرار الهندسية المعمارية التي تغيب عن بال 90% من مطوري الويب.

سنقوم بتفكيك المقاييس الثلاثة الرئيسية: سرعة العرض الأكبر LCP، ومدى الاستجابة للتفاعلات INP (الذي حل محل FID وأحدث زلزالاً في عالم السيو)، ومتغير التخطيط التراكمي CLS. ستكتشف أن حل هذه المشاكل لا يتطلب إضافة إضافات (Plugins) جديدة تبطئ الموقع أكثر، بل يتطلب فهماً عميقاً لكيفية قيام المتصفح برسم الصفحة على الشاشة.

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

حقيقة مقاييس الأداء الوهمية

دعونا نكشف السر الأول والأخطر الذي يسبب صدمة لكثير من المبرمجين. عندما تقوم بوضع رابط موقعك في أداة مثل Lighthouse أو PageSpeed Insights وتحصل على نتيجة خضراء تسر الناظرين، أنت في الحقيقة ترى "وهم المخيم". هذه الأدوات تقوم باختبار موقعك في بيئة معزولة، باستخدام سرعة إنترنت ثابتة، وجهاز كمبيوتر قوي، وبدون أي تفاعل حقيقي من المستخدم.

لكن جوجل لا يكترث كثيراً لهذه الأرقام المخبرية عند ترتيب موقعك. جوجل يمتلك سلاحاً أقوى بكثير يُسمى تقرير تجربة مستخدم كروم CrUX. هذا التقرير يجمع البيانات الحقيقية من ملايين السعوديين والزوار العرب الذين يدخلون موقعك من أجهزة هواتف قديمة، أو أثناء جلوسهم في مناطق ذات تغطية إنترنت ضعيفة. هذه هي البيانات الميدانية (Field Data) وهي الحقيقة المطلقة.

الفرق بين البيانات المخبرية والميدانية هو ما يفسر لك لماذا يكون موقعك سريعاً جداً على حاسوبك الشخصي أثناء البرمجة، ولكنه يفشل فشلاً ذريعاً في لوحة تحكم مشرفي المواقع (Search Console). المطور التقليدي يكتفي بضغط الصور ورفع التقييم في Lighthouse، بينما المهندس المحترف يراقب تقارير CrUX ويبني استراتيجيته بناءً على أضعف جهاز وأبطأ شبكة يستخدمها عملاؤه [1].

إليك هذا الجدول التفصيلي الذي يوضح الفروق الجوهرية بين نوعي البيانات، لتفهم تماماً أين يجب أن تركز جهودك الهندسية لضمان تصدر نتائج البحث:

لذلك، السر يكمن في مراقبة ما يحدث حقاً. استخدم أدوات قياس أداء المستخدم الحقيقي (Real User Monitoring) لتلتقط لحظات الإحباط التي يمر بها زوارك. عندما تعرف أن زوارك من مدينة معينة يعانون من تأخير في استجابة الخادم، يمكنك حينها توجيه شبكات توصيل المحتوى (CDN) لحل هذه المشكلة الجغرافية بدقة.

الآن وقد فهمنا أننا نلعب في الميدان الحقيقي وليس في المختبر، دعونا ننتقل إلى المقياس الأول والأكثر وضوحاً للزائر: متى تظهر الصورة أو النص الرئيسي على الشاشة؟ هذا ما يعرف بمقياس LCP، وفيه أسرار برمجية دقيقة يجهلها الكثيرون.

خدعة تحميل الصور العريضة

مقياس LCP (Largest Contentful Paint) يقيس ببساطة الوقت الذي يستغرقه المتصفح لعرض أكبر عنصر مرئي في الشاشة الأولى (Above the fold). في 90% من المواقع والمتاجر الإلكترونية، يكون هذا العنصر هو صورة المنتج الرئيسية أو صورة البانر العريضة في أعلى الصفحة. المشكلة أن المطورين يعتقدون أن تحويل الصورة إلى صيغة WebP هو الحل السحري الوحيد.

السر العميق الذي لا يخبرك به أحد هو ما يسمى بـ "تأخير اكتشاف المورد" (Resource Load Delay). المتصفح عندما يقرأ كود HTML، يقرأه من الأعلى للأسفل. إذا كانت صورتك الرئيسية مخفية تحت أكواد جافاسكريبت أو ملفات CSS ضخمة، فإن المتصفح لن يكتشف وجودها إلا بعد وقت متأخر جداً، مما يؤدي إلى انهيار مقياس LCP حتى لو كانت صورتك بحجم 10 كيلوبايت!

الحل الهندسي العبقري هنا هو إجبار المتصفح على اكتشاف هذه الصورة وتحميلها بأولوية قصوى قبل أي شيء آخر. نستخدم تقنية Preload مصحوبة بخاصية حديثة ومهمة جداً تسمى Fetch Priority. هذا الكود البسيط الذي يوضع في قسم الـ Head في موقعك هو بمثابة صافرة إنذار للمتصفح تقول له: "اترك كل ما في يدك وحمل هذه الصورة فوراً".

من الأسرار الأخرى المتعلقة بالـ LCP هو "تأخير عرض المورد" (Resource Render Delay). حتى لو قمت بتحميل الصورة بسرعة فائقة، إذا كان هناك ملف جافاسكريبت ثقيل يقوم بتجميد الخيط الرئيسي (Main Thread) للمتصفح، فإن الصورة ستظل مخفية ولن تُرسم على الشاشة. يجب عليك تأجيل (Defer) أو تحميل غير متزامن (Async) لأي سكربت غير ضروري لظهور الشاشة الأولى.

الشركات الكبرى تعتمد أيضاً على تقنية تقديم الصور بأحجام متكيفة (Responsive Images) باستخدام وسوم srcset. لا يعقل أن تجبر مستخدم الهاتف المحمول على تحميل صورة بعرض 2000 بكسل مخصصة لشاشات الحواسيب المكتبية. تقديم الصورة بالحجم الدقيق الذي يحتاجه الجهاز يوفر أجزاء ثمينة جداً من الثانية في مقياس الـ LCP.

بعد أن نجحنا في عرض المحتوى بسرعة، قد يظن الزائر أن الموقع جاهز للاستخدام فيضغط على زر الشراء، وهنا تحدث الكارثة الأكبر. الموقع لا يستجيب! هذا ينقلنا إلى المقياس الجديد والمرعب الذي أدخلته جوجل مؤخراً لقلب موازين اللعبة.

كابوس استجابة المتصفح الجديد

في مارس 2024، أحدثت جوجل زلزالاً في عالم السيو بإلغاء مقياس التفاعل الأول (FID) واستبداله بالوحش الجديد INP (Interaction to Next Paint). هذا المقياس كشف العيوب البرمجية العميقة في معظم المواقع العربية والمتاجر الإلكترونية. لماذا؟ لأن INP لا يقيس فقط النقرة الأولى للزائر، بل يراقب كل نقرة، وكل تمرير، وكل ضغطة زر طوال فترة بقاء الزائر في الصفحة [2].

لكي تفهم سر هذا المقياس، يجب أن تعرف أن متصفح الويب (مثل جوجل كروم) يمتلك "طريقاً واحداً" لمعالجة العمليات، يسمى الخيط الرئيسي (Main Thread). هذا الخيط هو المسؤول عن قراءة الجافاسكريبت، ورسم الصور، والرد على نقرات المستخدم. إذا كان هناك سكربت ثقيل (مثل أدوات التتبع المفرطة أو أكواد الإعلانات) يحتل هذا الطريق لمدة طويلة (أكثر من 50 ملي ثانية)، فإن أي نقرة من المستخدم ستوضع في قائمة الانتظار حتى ينتهي السكربت.

هذا التأخير في الاستجابة هو ما يسبب الشعور بـ "التعليق" أو بطء الموقع. الزائر يضغط على زر "إضافة للسلة" ولا يحدث شيء لثانية كاملة، فيظن أن الزر معطل ويغادر الموقع. السر الهندسي لحل مشكلة INP لا يكمن في حذف الجافاسكريبت، بل في تجزئة المهام الطويلة (Breaking up Long Tasks).

المطور المحترف يستخدم تقنيات متقدمة مثل `setTimeout` أو واجهة برمجة التطبيقات الجديدة `scheduler.yield()` لتقطيع الوظائف البرمجية الثقيلة إلى أجزاء صغيرة جداً. هذا التقسيم يسمح للمتصفح بالتقاط أنفاسه بين كل جزء وآخر، واستقبال نقرات المستخدم والرد عليها فوراً دون تأخير، مما يحافظ على سلاسة التجربة ونبض الموقع حياً.

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

بينما نحن نكافح لجعل الموقع يستجيب بسرعة، قد يحدث أمر آخر يثير غضب المستخدم أكثر من البطء نفسه. تخيل أن الزائر يقرأ مقالاً أو يهم بالنقر على رابط، وفجأة يهتز المحتوى للأسفل ويضغط على إعلان بالخطأ! هذا هو أسوأ كابوس لتجربة المستخدم.

اهتزاز الشاشات المدمر للمبيعات

متغير التخطيط التراكمي CLS (Cumulative Layout Shift) هو المقياس الذي يعبر عن الاستقرار البصري لصفحة الويب. إذا كان موقعك يقفز ويهتز أثناء التحميل، فإن هذا المقياس سيرتفع، وجوجل سيعاقبك بوضوح لأنه يعتبر هذا الاهتزاز تدميراً منهجياً لتجربة المستخدم (وخاصة على شاشات الجوال الصغيرة).

السر الأول الذي يغفل عنه المطورون في مقياس CLS هو أن الاهتزاز لا يحدث فقط أثناء التحميل الأولي، بل يتم قياسه طوال فترة بقاء المستخدم في الصفحة. إذا قمت بإدراج محتوى ديناميكي (مثل رسالة "اشترك في النشرة البريدية" أو شريط إخباري) في أعلى الصفحة بعد أن يكون المستخدم قد بدأ في القراءة، فهذا يعتبر انحرافاً تخطيطياً كارثياً.

الحل الهندسي الأمثل لمنع اهتزاز الصور والفيديوهات هو قاعدة رياضية بسيطة جداً: حجز المساحة مسبقاً. يجب أن يحتوي كل وسم صورة `` على خصائص العرض والطول الأصلية `width` و `height`. بالإضافة إلى استخدام كود CSS العبقري `aspect-ratio` للحفاظ على النسبة المئوية للصورة حتى قبل أن يتم تحميلها. المتصفح سيرسم مربعاً فارغاً بحجم الصورة تماماً، وعندما يتم تحميلها، ستسقط في مكانها دون أن تدفع النص للأسفل.

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

الخطوط العربية وتأخير العرض

الخطوط العربية الجميلة (مثل Cairo و Tajawal) تعطي هوية بصرية رائعة للموقع، ولكنها في عالم الـ Core Web Vitals تعتبر وحوشاً تلتهم السرعة وتسبب اهتزازات مزعجة. حجم ملف الخط العربي غالباً ما يكون أكبر من الخط الإنجليزي لأنه يحتوي على أشكال متعددة لنفس الحرف (في أول ووسط وآخر الكلمة).

الخطأ الشائع هنا هو ترك المتصفح يخفي النص تماماً حتى يتم تحميل الخط المخصص (ظاهرة تسمى FOIT). الزائر يحدق في شاشة فارغة تماماً لعدة ثوانٍ رغم تحميل كل شيء آخر! السر الأول لحل هذه الأزمة هو استخدام كود `font-display: swap` في ملف الـ CSS. هذا الكود يجبر المتصفح على عرض النص فوراً بخط النظام الأساسي الافتراضي، وعندما يتم تحميل الخط المخصص، يتم استبداله.

لكن مهلاً، هذا الاستبدال يسبب مشكلة أخرى! خط النظام قد يكون أصغر أو أكبر من الخط المخصص، مما يؤدي إلى إعادة ترتيب الكلمات وتغير ارتفاع الأسطر، وهذا يرفع مقياس الاهتزاز (CLS) بشكل جنوني. هنا نلجأ إلى السر الهندسي الثاني وهو استخدام خصائص CSS الحديثة لضبط تطابق الخطوط Font Metrics Override مثل `size-adjust` و `ascent-override` لمطابقة أبعاد خط النظام مع الخط المخصص لمنع أي قفزة بصرية.

والسر الثالث والأقوى هو تقنية Subsetting. لماذا تجبر المستخدم على تحميل ملف خط يحتوي على 1000 حرف ورمز ولغات لا تستخدمها في موقعك؟ يجب عليك استخدام أدوات لتقطيع ملف الخط واستخراج الحروف العربية والأرقام فقط التي تحتاجها. هذه الخطوة وحدها قادرة على تقليص حجم ملف الخط من 200 كيلوبايت إلى 20 كيلوبايت فقط، مما يجعله يحمل بسرعة البرق ويدعم مقياس LCP بقوة.

بالطبع، كل هذه الحيل البرمجية في واجهة الموقع (Frontend) ستكون بلا فائدة إذا كان الخادم نفسه (Backend) نائماً وبطيئاً في الاستجابة. أساس كل مقاييس الأداء يبدأ من اللحظة التي يكتب فيها المستخدم رابط موقعك ويضغط Enter.

هندسة الخوادم وتقليل الاستجابة

يغفل الكثير من المطورين عن المقياس الأم الذي تتفرع منه بقية المقاييس وهو TTFB (Time to First Byte)، أو وقت استجابة الخادم لتقديم أول بايت من البيانات. إذا كان الخادم يستغرق ثانية كاملة ليرد على طلب المستخدم، فهذا يعني أن مقياس LCP الخاص بك سيبدأ متأخراً بثانية كاملة، مما يجعل الوصول للعلامة الخضراء شبه مستحيل.

السر في تقليل الـ TTFB للمواقع المستهدفة للسوق السعودي هو الجغرافيا أولاً. لا يعقل أن يكون زوارك من الرياض، وتستضيف موقعك على خادم رخيص في غرب الولايات المتحدة! المسافة الفيزيائية للإشارات تعني تأخيراً حتمياً (Latency). المهندس المحترف يعتمد على شبكات توصيل المحتوى المتقدمة CDN، مثل Cloudflare، ليس فقط لتخزين الصور، بل لتخزين صفحة الـ HTML بالكامل (Edge Caching) في خوادم قريبة من الزائر في جدة أو الرياض.

بالإضافة إلى ذلك، يجب هندسة قاعدة البيانات بعناية. بطء الـ TTFB غالباً ما يكون سببه استعلامات معقدة وبطيئة لقاعدة البيانات (Database Queries). استخدام تقنيات التخزين المؤقت على مستوى الخادم مثل Redis أو Memcached يضمن أن الطلبات المتكررة يتم الرد عليها من الذاكرة العشوائية السريعة جداً بدلاً من استنزاف موارد قاعدة البيانات في كل مرة.

استخدام أحدث بروتوكولات الاتصال مثل HTTP/3 و QUIC يوفر سرعة استجابة هائلة على شبكات الجوال غير المستقرة، لأنه يلغي الحاجة لخطوات التحقق الطويلة الموجودة في البروتوكولات القديمة. هذه التعديلات المعمارية في السيرفر هي التي تصنع الفارق الحقيقي في المواقع ذات الزيارات المليونية.

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

خريطة التطبيق العملي للسرعة

لكي نضمن تحويل هذا الشرح الأكاديمي والتقني العميق إلى نتائج واقعية تراها بعينك في تقارير مشرفي المواقع (Search Console)، صممت لك هذه الخريطة المصغرة. اعتبر هذا الجدول بمثابة "مراجعة جراحية" (Checklist) يجب أن تمرر عليها موقعك الحالي لتصحيح المسار.

السر في النجاح ليس في تطبيق كل شيء دفعة واحدة وكسر هيكل الموقع، بل في التطبيق المتدرج واختبار كل تغيير على حدة. ابدأ بالأمور التي تعطي تأثيراً مباشراً بأقل جهد (Quick Wins)، ثم تعمق في إصلاح أجزاء الجافاسكريبت المعقدة.

إليك خريطة العمل الإلزامية التي يتبعها كبار مهندسي السيو التقني لتحقيق العلامة الكاملة والمستقرة في بيانات المستخدمين الحقيقيين.

التمرين العملي المباشر لك الآن: افتح موقعك على متصفح كروم، واضغط على (F12) لفتح أدوات المطورين، ثم اذهب إلى تبويب (Performance). قم بتسجيل تحميل الصفحة وانظر إلى قسم (Main). أي شريط أصفر طويل تراه هناك هو "مهمة طويلة" (Long Task) تدمر مقياس INP لموقعك. تعرف على السكربت المسبب لها وابدأ في تحجيمه فوراً.

أتمنى أن يكون هذا الدليل العميق قد أزال الغمامة عن عينيك وكشف لك الأسرار التقنية التي تفصل بين المواقع الناجحة والمواقع البطيئة المنسية. نحن في أكاديمية الجندي سيوتربو نؤمن بأن المعرفة الدقيقة هي أقوى سلاح للمطور العربي لاكتساح محركات البحث. نلقاكم في مقالات تقنية قادمة مليئة بالأسرار والتطبيقات العملية.

مصادر موثوقة