ما هي مؤشرات أداء الويب الأساسية (Core Web Vitals)؟

تطوير الويب وتحسين محركات البحث | تحسين محركات البحث (SEO) | تطوير الويب

مؤشرات أداء الويب الأساسية: قياس تجربة المستخدم التي يحبها جوجل

by محمد قتيبة شيخاني | أكتوبر 21, 2025 | 0 comments

في رحلتنا عبر عالم السيو، تعلمنا أن جوجل لم يعد يهتم بالكلمات المفتاحية والروابط الخلفية فقط. لقد أصبح مهووسًا بـ "تجربة المستخدم".

التشبيه: فكر في موقعك على أنه مطعم. السيو (الكلمات المفتاحية والروابط) هو ما يجعل مطعمك يظهر في المرتبة الأولى عندما يبحث الناس عن "أفضل مطعم".

لكن ماذا يحدث عندما يدخل الزائر إلى مطعمك؟ هل الخدمة سريعة؟ هل الأجواء مريحة ومستقرة؟ أم أن الأرض تهتز والطاولات تقفز؟

لفترة طويلة، كان قياس "جودة الخدمة" هذا أمرًا غامضًا.

لكن الآن، أصبح لدى جوجل طريقة لقياسها رقميًا. هذه الطريقة هي مؤشرات أداء الويب الأساسية (Core Web Vitals).

لقد أشرنا إليها مرارًا وتكرارًا في مقالات السيو التقني و Google Search Console، والآن حان الوقت لنضعها تحت المجهر. هذا المقال هو دليلك المفصل لفهم هذه المؤشرات، وكيفية قياسها، ولماذا هي حاسمة لنجاحك.

لماذا أنشأ جوجل هذه المؤشرات؟ (التحول من قياس الآلة إلى قياس "الإحساس")

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

المشكلة: المقاييس التقليدية كانت تخبر نصف الحقيقة فقط

في الماضي، كنا نقيس سرعة الموقع بأرقام تقنية بحتة وموجهة للآلة، مثل:

• "وقت تحميل الصفحة بالكامل" (Page Load Time): وهو الوقت الذي يستغرقه المتصفح لتحميل كل عنصر في الصفحة، بما في ذلك الإعلانات غير المرئية والسكريبتات التي تعمل في الخلفية.
• "DOMContentLoaded": وهو مقياس تقني يخبر المطورين متى تم بناء هيكل الصفحة الأولي.

هذه المقاييس مفيدة للمطورين، لكنها لا تعكس التجربة الإنسانية الفعلية.

التشبيه (خدمة التوصيل)

تخيل أنك طلبت طعامًا من مطعمين مختلفين.

المطعم الأول: عامل التوصيل يطرق بابك بعد 5 دقائق ويسلمك الطبق الرئيسي ساخنًا. لكنه يعود بعد 20 دقيقة أخرى ليسلمك المشروبات والمناديل.

تقنيًا، استغرق "اكتمال الطلب" 25 دقيقة، لكنك شعرت بالرضا لأنك بدأت بالأكل بسرعة.

المطعم الثاني: عامل التوصيل يطرق بابك بعد 15 دقيقة ويسلمك كل شيء دفعة واحدة. تقنيًا، كان هذا الطلب "أسرع" في الاكتمال، لكنك شعرت بالانزعاج لأنك انتظرت 15 دقيقة جائعًا.

هذه هي بالضبط المشكلة التي كانت تواجه جوجل. مقياس "وقت تحميل الصفحة بالكامل" لا يفرق بين المطعمين.

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

الحل: التحول إلى قياس الأداء المُدرَك (Perceived Performance)

أدركت جوجل أن هدفها الأساسي هو رضا المستخدم. والمستخدم لا يهتم بالأرقام التقنية؛ بل يهتم بـ "إحساسه" بالسرعة والاستجابة.

لهذا السبب، قررت إنشاء مجموعة جديدة من المقاييس التي تجيب على أسئلة بسيطة تتمحور حول الإنسان:

1. هل تبدو سريعة؟ (التحميل): متى يرى المستخدم شيئًا ذا معنى على الشاشة؟ → LCP
2. هل يمكنني التفاعل معها بسرعة؟ (الاستجابة): عندما أنقر على زر، هل يحدث شيء فورًا؟ → INP
3. هل هي مزعجة بصريًا؟ (الاستقرار): هل تقفز العناصر وتتحرك بشكل غير متوقع أثناء القراءة؟ → CLS

مؤشرات أداء الويب الأساسية هي إجابة جوجل الموحدة على هذه الأسئلة. إنها محاولتها لترجمة التجربة الإنسانية الفوضوية إلى لغة رقمية قابلة للقياس.

التأثير على السيو: فرض التعاطف مع المستخدم

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

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

إنها خطوة حاسمة في جعل الويب مكانًا أفضل وأقل إحباطًا للجميع.

المؤشرات الأساسية الثلاثة (ماذا تقيس؟)

تتكون المؤشرات الأساسية حاليًا من ثلاثة مقاييس. دعنا نشرح كل واحد وما يعنيه لك كمطور وخبير سيو.

1. LCP (Largest Contentful Paint) - مقياس "الطبق الرئيسي"

هذا هو المؤشر الأول والأهم لقياس "سرعة التحميل" كما يراها المستخدم.

التشبيه المفصل

تخيل أنك طلبت وجبة في مطعم. هناك مقاييس مختلفة للسرعة:

TTFB (Time to First Byte)

هو الوقت الذي يستغرقه النادل ليأخذ طلبك ويعود من المطبخ ليقول "تم استلام الطلب". (سريع، لكنك لا تزال جائعًا).

FCP (First Contentful Paint)

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

LCP (Largest Contentful Paint)

هو الوقت الذي يستغرقه وصول "الطبق الرئيسي" إلى طاولتك. هذه هي اللحظة التي تشعر فيها بالرضا وأن "التجربة قد بدأت بالفعل".

ما هو بالتحديد؟

يقيس LCP الوقت بالثواني من لحظة بدء تحميل الصفحة حتى يتم عرض (rendering) أكبر كتلة محتوى مرئي (سواء كانت صورة رئيسية، أو فيديو، أو كتلة نصية كبيرة) ضمن "إطار العرض" (viewport)، أي ما يراه المستخدم على شاشته دون الحاجة للتمرير.

هو ليس مقياسًا لـ "أول علامة على الحياة"، بل هو مقياس لـ "أول علامة على الفائدة"، وهي اللحظة التي يرى فيها المستخدم المحتوى الأساسي الذي جاء من أجله.

الهدف (حسب جوجل)

• أقل من 2.5 ثانية: جيد (تجربة سريعة).
• بين 2.5 و 4.0 ثانية: يحتاج إلى تحسين.
• أكثر من 4.0 ثانية: ضعيف (تجربة بطيئة ومحبطة).

صلته المباشرة بمهاراتك (الأسباب الجذرية لمشكلة LCP البطء)

عندما يكون LCP الخاص بك بطيئًا، فهذا يعني أن "الطبق الرئيسي" يستغرق وقتًا طويلاً للوصول. هذا يحدث عادةً لثلاثة أسباب رئيسية مرتبطة مباشرة بمهاراتك:

استجابة الخادم البطيئة (High TTFB)

صلته بما سبق: قبل أن يتمكن المتصفح من رسم أي شيء، يجب أن يتلقى "البايت الأول" من الخادم.

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

هذا التأخير الأولي يضاف إلى كل المقاييس الأخرى ويدمر LCP الخاص بك.

موارد تعيق العرض (Render-Blocking Resources)

صلته بما سبق: هذه مشكلة سيو تقني كلاسيكية تتعلق بكود CSS و JavaScript.

عندما يقرأ المتصفح ملف HTML ويجد في قسم <head> ملف CSS ضخم أو ملف JavaScript، فإنه يتوقف عن بناء الصفحة تمامًا.

يضطر إلى تنزيل هذا الملف بالكامل وتنفيذه قبل أن يتمكن من رسم أي بكسل على الشاشة.

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

بطء تحميل المورد نفسه (العنصر الأكبر)

في كثير من الأحيان، يكون "العنصر الأكبر" الذي يتم قياسه هو الصورة الرئيسية في أعلى الصفحة (Hero Image).

إذا كان هذا المورد نفسه بطيئًا، فسيكون LCP بطيئًا.

مشكلة الصور

(مرتبطة بمهارات HTML/CSS) استخدام صورة بحجم 2 ميجابايت بصيغة PNG غير مضغوطة، بدلاً من صورة بحجم 150 كيلوبايت بصيغة WebP حديثة.

مشكلة الخطوط

(مرتبطة بـ CSS) إذا كانت أكبر كتلة نصية تستخدم خط ويب مخصص (Web Font)، فقد يتأخر ظهورها حتى يتم تحميل هذا الخط، مما يسبب تأخيرًا في LCP.

مشكلة loading="lazy"

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

2. INP (Interaction to Next Paint) - مقياس "الإحساس" بالاستجابة

هذا هو المؤشر الجديد والأكثر تطورًا، وقد أصبح عامل ترتيب رسميًا في عام 2024، ليحل محل مؤشر FID (First Input Delay). هذا التغيير بحد ذاته يخبرنا الكثير.

لماذا هو أهم من سابقه (FID)؟

كان مؤشر FID يقيس "الانطباع الأول" فقط، أي تأخير الاستجابة لأول نقرة يقوم بها المستخدم.

مؤشر INP أكثر صرامة وشمولية بكثير. هو يقيس كل التفاعلات التي تحدث طوال مدة زيارة المستخدم للصفحة، ثم يبلغ عن "أسوأ" تأخير حدث.

هو لا يقيس الانطباع الأول، بل يقيس "التجربة الكاملة" لاستجابة الصفحة.

التشبيه المفصل (النادل اليقظ)

تخيل أنك في مطعم مزدحم:

INP مرتفع (تجربة سيئة)

أنت ترفع يدك لتطلب شيئًا (النقرة). النادل (المتصفح) مشغول جدًا في مهمة أخرى ولا ينظر إليك حتى لمدة ثانيتين.

أنت تشعر بأنك "غير مرئي" وبأن الخدمة سيئة. الصفحة تبدو "متجمدة".

INP منخفض (تجربة جيدة)

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

على الرغم من أن طلبك لم يكتمل بعد، إلا أنك تشعر بالاطمئنان لأنك "مسموع" وأن شيئًا ما يحدث.

ما هو بالتحديد؟

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

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

الهدف (حسب جوجل)

• أقل من 200 مللي ثانية: جيد (استجابة فورية).
• بين 200 و 500 مللي ثانية: يحتاج إلى تحسين.
• أكثر من 500 مللي ثانية: ضعيف (تجربة بطيئة ومحبطة جدًا).

صلته المباشرة بمهاراتك (العدو الأول: JavaScript والخيط الرئيسي)

السبب الأول والأكبر لضعف INP هو انسداد "الخيط الرئيسي" (Main Thread) للمتصفح.

ما هو الخيط الرئيسي؟

فكر في الخيط الرئيسي على أنه "العامل الوحيد في المصنع" (المتصفح). هذا العامل مسؤول عن كل شيء:

• تنفيذ أوامر JavaScript (تجميع الآلة).
• الاستجابة لإدخالات المستخدم (استلام طلبات جديدة).
• رسم التغييرات على الشاشة (طلاء المنتج النهائي).

كيف تحدث المشكلة؟

المشكلة أنه عامل واحد فقط.

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

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

الخلاصة

هذه مشكلة JavaScript بحتة. هي ليست مثل LCP (الذي يتأثر بالخادم والصور) أو CLS (الذي يتأثر بـ HTML/CSS).

إنها تتعلق بكفاءة الكود الذي يعمل في المتصفح، وإدارة المهام الطويلة، وتجنب إبقاء "العامل الوحيد" مشغولاً لفترة طويلة.

3. CLS (Cumulative Layout Shift) - مقياس "الاستقرار البصري"

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

التشبيه المفصل (تجربة النقر المحبطة)

هل حدث لك أن كنت تقرأ مقالاً إخباريًا، وبينما عيناك في منتصف الجملة، ظهر إعلان فجأة في الأعلى ودفع الفقرة التي تقرؤها إلى أسفل الشاشة؟

أو الأسوأ: هل حاولت يومًا النقر على زر "إلغاء"، وفي اللحظة التي كانت إصبعك على وشك أن تلمس الشاشة، قفز زر "تأكيد الشراء" ليحل محله بسبب تحميل عنصر آخر، فنقرت على الزر الخطأ؟

هذا الإحساس المحبط للغاية هو بالضبط ما يقيسه متغيرات التصميم التراكمية (CLS).

ما هو بالتحديد؟ (كيف يتم حسابه؟)

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

حجم العنصر الذي تحرك: (ما هو حجم المساحة التي يشغلها من الشاشة؟)

مسافة الحركة: (ما هي المسافة التي قفزها هذا العنصر؟) هذا يعني أن صورة بانر ضخمة تقفز في منتصف الصفحة ستعطي درجة CLS أسوأ بكثير من أيقونة صغيرة تقفز في زاوية الصفحة.

الهدف (حسب جوجل)

• أقل من 0.1: جيد (مستقر بصريًا).
• بين 0.1 و 0.25: يحتاج إلى تحسين.
• أكثر من 0.25: ضعيف (تجربة مزعجة جدًا).

صلته المباشرة بمهاراتك (الأسباب الجذرية لمشكلة CLS)

هذا المؤشر هو مشكلة تصميم وهيكلة بحتة، وهو مرتبط مباشرة بأساسيات HTML و CSS التي تعلمناها.

الأسباب الأكثر شيوعًا لارتفاع CLS هي:

الصور والفيديوهات بدون أبعاد (width و height)

المشكلة: عندما يقرأ المتصفح كود HTML ويجد وسم <img> بدون سمات width و height، فإنه لا يعرف حجم المساحة التي يجب حجزها للصورة.

ماذا يحدث؟

يقوم المتصفح برسم النص الذي يأتي بعد الصورة أولاً.

بعد بضع ثوانٍ، عندما ينتهي تحميل ملف الصورة، يدرك المتصفح فجأة أنه يحتاج إلى مساحة 600x400 بكسل، فيقوم "بدفع" كل النص الذي رسمه بالفعل لأسفل لإفساح المجال للصورة.

هذه "الدفعة" هي قفزة في التصميم.

الحل: تحديد سمات width و height في وسم <img> يخبر المتصفح مسبقًا بحجز "مساحة فارغة" بالأبعاد الصحيحة، بحيث يتم رسم النص في مكانه النهائي الصحيح من البداية.

الإعلانات والمحتوى الديناميكي (Ads & Banners)

المشكلة:

هذه مشكلة مشابهة ولكنها أصعب. غالبًا ما تكون حاويات الإعلانات فارغة في البداية (<div id="ad-slot"></div>).

بعد ثوانٍ، يقوم سكريبت JavaScript بتحميل الإعلان وإدراجه في الحاوية، فتتوسع فجأة من ارتفاع 0 بكسل إلى 250 بكسل، وتدفع كل ما تحتها لأسفل.

الحل:

هنا يأتي دور CSS. الحل الاحترافي هو إعطاء حاوية الإعلان حجمًا ثابتًا مسبقًا باستخدام min-height: 250px; أو aspect-ratio: 300/250;.

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

الخطوط التي يتم تحميلها متأخرًا (Web Fonts)

المشكلة:

هذا سبب خفي. يقوم المتصفح أولاً بعرض النص باستخدام خط "احتياطي" قياسي (مثل Arial).

بعد لحظات، ينتهي تحميل ملف خط الويب المخصص (مثل 'Cairo'). إذا كان خط 'Cairo' أعرض أو أطول قليلاً من Arial، فسيضطر المتصفح إلى إعادة حساب ورسم كتلة النص بأكملها، مما يسبب "وميض" وقفزة بصرية طفيفة.

الحل: استخدام تقنيات CSS حديثة لتحميل الخطوط مسبقًا (Preload) أو استخدام أدوات لـ "مطابقة" حجم الخط الاحتياطي مع الخط المخصص.

كيف تقيس وتصلح هذه المؤشرات؟

لديك طريقتان رئيسيتان لقياس هذه المؤشرات:

1. البيانات الميدانية (Field Data): ماذا يرى المستخدمون الفعليون؟

عندما تختبر موقعك على جهاز الكمبيوتر الخاص بك، فأنت تعيش في "فقاعة مثالية".

جهازك غالبًا ما يكون قويًا، واتصال الإنترنت لديك سريع ومستقر. لكن ماذا عن المستخدم الحقيقي؟

قد يكون المستخدم الحقيقي يتصفح موقعك من هاتف محمول قديم، عبر اتصال 4G متقطع في قطار مزدحم.

تجربتك في "المختبر" ليست هي التجربة الحقيقية. لهذا السبب، تعد "البيانات الميدانية" هي مصدر الحقيقة المطلقة.

مصدر البيانات: تقرير تجربة مستخدمي كروم (CrUX)

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

هذه قاعدة البيانات العامة والضخمة تسمى "تقرير تجربة مستخدمي كروم" (CrUX).

الأداة: تقرير "مؤشرات أداء الويب الأساسية" في GSC

تقرير "مؤشرات أداء الويب الأساسية" في Google Search Console هو نافذتك المخصصة إلى قاعدة بيانات CrUX.

هو يأخذ كل هذه البيانات العالمية ويقوم بتصفيتها ليُظهر لك البيانات المتعلقة بموقعك فقط.

التشبيه: فكر في هذا التقرير على أنه "التقرير الطبي الدوري" الذي يأتيك بناءً على آراء آلاف "المرضى" (الزوار) الحقيقيين الذين زاروا "مستشفاك" (موقعك) خلال الـ 28 يومًا الماضية.

كيف يخبرك "بما هو الخطأ"؟ (التشخيص على نطاق واسع)

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

Good (جيد): (باللون الأخضر) - صفحاتك التي تقدم تجربة ممتازة لغالبية الزوار.

Need Improvement (يحتاج إلى تحسين): (باللون الأصفر) - صفحاتك التي على الحافة، وتقدم تجربة متوسطة.

Poor (ضعيف): (باللون الأحمر) - هذه هي "الأضواء الحمراء" في لوحة قيادتك. هذه الصفحات تقدم تجربة بطيئة ومحبطة لعدد كبير من زوارك، وهي التي تضر بترتيبك بشكل مباشر.

القيمة الاستراتيجية (ماذا تفعل بهذه المعلومات؟)

عند النقر على إحدى هذه الفئات (مثل "ضعيف")، لا يتوقف التقرير عند هذا الحد.

بل يمنحك قائمة بمجموعات الصفحات المتأثرة (على سبيل المثال، "كل صفحات مقالات مدونتك تعاني من مشكلة LCP").

هذا التقرير هو "نقطة البداية" المثالية. إنه يخبرك بـ "ما هو الخطأ" و "أين هو الخطأ" على نطاق واسع.

لكنه لا يخبرك بـ "لماذا هو خطأ" على المستوى التقني الدقيق.

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

2. البيانات المختبرية (Lab Data): كيف تشخص المشكلة؟

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

نحن بحاجة إلى إجراء "فحوصات مخبرية" دقيقة لهذه الصفحات المريضة لمعرفة "لماذا" هي بطيئة.

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

الأدوات التشخيصية: PageSpeed Insights و Lighthouse

لديك أداتان رئيسيتان، وكلاهما يستخدمان نفس "محرك" التحليل المسمى Lighthouse:

PageSpeed Insights (PSI) - (الأداة العامة على الويب)

ما هي؟ هي أداة ويب مجانية من جوجل.

قوتها الخارقة: هي الأداة الوحيدة التي تعرض لك كلا النوعين من البيانات في مكان واحد:

1. البيانات الميدانية (Field Data): تعرض لك بيانات CrUX الحقيقية (التي رأيتها في GSC) لآخر 28 يومًا.
2. البيانات المختبرية (Lab Data): تقوم بإجراء اختبار محاكاة فوري لصفحتك.

التشبيه: هذه الأداة هي "التقرير الطبي الكامل" الذي يعرض "نتائجك من العالم الحقيقي" (Field) وبجانبها "نتائج الفحص المخبري الفوري" (Lab).

Lighthouse - (الأداة المدمجة في متصفحك)

ما هي؟ هي الأداة المدمجة مباشرة في "أدوات المطورين" (DevTools) في متصفح كروم (اضغط F12 ثم اذهب إلى تبويب Lighthouse).

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

• موقعك على الخادم المحلي (localhost) قبل إطلاقه.
• الصفحات التي تتطلب تسجيل دخول.
• النسخة التجريبية (Staging) من موقعك.

كيف تخبرك هذه الأدوات بـ "لماذا"؟ (تشريح التقرير)

عند تشغيل الاختبار، ستقدم لك الأداة تقريرًا مفصلاً، وأهم ما فيه هو قسم "فرص التحسين" (Opportunities) و "التشخيصات" (Diagnostics).

هذه هي "الوصفة الطبية" الدقيقة التي تخبرك "لماذا" صفحتك بطيئة.

لتشخيص مشكلة LCP (سرعة التحميل)

ما تراه في GSC: "صفحات المقالات لديك ضعيفة في مؤشر LCP".

ما تراه في Lighthouse (التشخيص): ستجد في قسم "Opportunities" توصيات واضحة مثل:

Properly size images (تحجيم الصور بشكل صحيح): "أنت ترسل صورة بحجم 2000 بكسل لعرضها في مساحة 300 بكسل. قم بتصغيرها."

Eliminate render-blocking resources (إزالة الموارد التي تعيق العرض): "ملف CSS هذا يمنعني من رسم الصفحة. حاول تحميله بشكل غير متزامن."

Reduce initial server response time (تقليل وقت استجابة الخادم): "الخادم نفسه بطيء في الرد"، وهي مشكلة استضافة كما ناقشنا.

لتشخيص مشكلة INP (الاستجابة)

ما تراه في GSC: "صفحات منتجاتك ضعيفة في مؤشر INP".

ما تراه في Lighthouse (التشخيص): ستجد توصيات مثل:

Reduce JavaScript execution time (تقليل وقت تنفيذ JavaScript): "السكريبت الفلاني استغرق 3 ثوانٍ للعمل، مما جمد الصفحة."

Minimize main-thread work (تقليل العمل على الخيط الرئيسي): "العامل الوحيد في المصنع مشغول جدًا. حاول تقسيم المهام الكبيرة."

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

لتشخيص مشكلة CLS (الاستقرار)

ما تراه في GSC: "الصفحة الرئيسية لديك ضعيفة في مؤشر CLS".

ما تراه في Lighthouse (التشخيص): ستجد توصيات مثل:

Image elements do not have explicit width and height (عناصر الصور لا تحتوي على أبعاد واضحة): "لم تخبرني بحجم هذه الصورة، لذا قفزت عندما تم تحميلها."

صلته بما سبق: هذا إصلاح مباشر في كود HTML يتطلب إضافة سمات width و height التي تعلمناها.

الخلاصة

البيانات المختبرية هي "الأشعة السينية" التي لا غنى عنها. هي تأخذ التقرير العام من GSC وتحوله إلى قائمة مهام تقنية ومحددة.

سير العمل الاحترافي هو دائمًا: اكتشف "أين" المشكلة باستخدام GSC، ثم شخص "لماذا" المشكلة باستخدام Lighthouse.

الهندسة وتجربة المستخدم وجهان لعملة واحدة

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

لقد رأينا كيف أن جوجل لم يعد "يخمن" ما إذا كان موقعك جيدًا، بل أصبح "يقيس" تجربة المستخدم الفعلية بدقة عبر مؤشرات LCP, INP, و CLS.

الأهم من ذلك، أننا اكتشفنا أن هذه المؤشرات ليست أرقامًا غامضة أو مشاكل تقنية معقدة، بل هي النتيجة المباشرة للمهارات الأساسية التي تعلمناها معًا:

• مشكلة LCP البطيء هي غالبًا مشكلة استضافة أو صور غير محسنة.
• مشكلة INP البطيء هي في جوهرها مشكلة JavaScript غير فعال يعيق "الخيط الرئيسي".
• مشكلة CLS المرتفع هي مشكلة HTML و CSS، تنتج عن إهمال تحديد أبعاد العناصر.

لقد ربطنا الآن بشكل قاطع كل ما تعلمناه في سلسلة تطوير الويب بأهداف سلسلة السيو.

أنت الآن لا تعرف فقط "ما هي" هذه المؤشرات، بل تمتلك "سير العمل" الكامل للمحترفين:

1. استخدم Google Search Console لاكتشاف "ما هو الخطأ" على نطاق واسع
2. ثم استخدم Lighthouse لتشخيص "لماذا هو خطأ" على المستوى التقني
3. ثم استخدم مهاراتك البرمجية لإصلاح المشكلة من جذورها.

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

شارك هذا الموضوع:

• المشاركة على X (فتح في نافذة جديدة) X
• شارك على فيس بوك (فتح في نافذة جديدة) فيس بوك
• المشاركة على Telegram (فتح في نافذة جديدة) Telegram
• المشاركة على WhatsApp (فتح في نافذة جديدة) WhatsApp

معجب بهذه:

إعجاب جاري التحميل…

محتوى تقني عربي | بناء موقع ويب | تحسين محركات البحث | تعلم السيو | سيو (SEO)

محمد قتيبة شيخاني

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

• Follow
• Follow

مقالات قد تهمك

 

مطور الواجهات الأمامية: المهندس المعماري للويب المرئي

نوفمبر 5, 2025

واجهة برمجة التطبيقات (API): نادل العالم الرقمي

نوفمبر 4, 2025

البيانات المنظمة (Schema): كيف تجعل جوجل يفهم محتواك كالبشر

نوفمبر 4, 2025

« Older Entries

شاركني رأيك أو تجربتك

اترك ردإلغاء الرد