PageSpeed Insights (PSI)

الخلاصة — PageSpeed Insights (PSI) أداة مجانية من Google تقيّم الصفحة بطريقتين مختلفتين: كيف اختبرها الزوار الفعليون بالفعل (البيانات الميدانية)، وكيف سار تشغيل اختبار محاكى واحد (النتيجة المختبرية من 0 إلى 100). رقم 0–100 هو ما يستحوذ على اهتمام الجميع، لكنه ليس ما تستخدمه Google للترتيب. لذلك لا تفزع من نتيجة حمراء.

ما هو PageSpeed Insights

يتوفر PageSpeed Insights على pagespeed.web.dev. وهو مجاني، ولا يتطلب تسجيل الدخول، ويعمل مع أي URL عام، بما في ذلك عناوين منافسيك. تلصق عنوان URL، فيختبر كلاً من الجوال وسطح المكتب (الجوال هو علامة التبويب الافتراضية، ونتائجه أقل في معظم الأحيان).

الشيئان اللذان يعرضهما PSI

هذا هو الجزء الذي يربك الجميع، لذا سأبقيه بسيطاً. يعرض PSI تقريرين منفصلين للصفحة نفسها:

1. البيانات الميدانية — ما اختبره الأشخاص الفعليون. تأتي من Chrome UX Report (CrUX)، أي من مستخدمي Chrome الفعليين الذين زاروا صفحتك خلال آخر 28 يوماً. وهو القسم الموسوم “Discover what your real users are experiencing.” (ترجمة) «اكتشف ما يختبره مستخدموك الفعليون». هنا تحصل على تقييم Core Web Vitals، أي نتيجة بسيطة: اجتاز أو أخفق.
2. بيانات المختبر — اختبار محاكى واحد. يشغّل PSI أيضاً Google Lighthouse مرة واحدة على هاتف وشبكة محاكيين، ويخرج بنتيجة الأداء من 0 إلى 100 إلى جانب قائمة بالإصلاحات المقترحة.

الشيء الوحيد الذي ينبغي تذكره

نتيجة 0–100 ليست عامل ترتيب. ترتّب Google الصفحات بناءً على مؤشرات Core Web Vitals الميدانية: Largest Contentful Paint وInteraction to Next Paint وCumulative Layout Shift، مقيسة من المستخدمين الفعليين. أما نتيجة المختبر من 0 إلى 100 فهي رقم منفصل صادر عن نظام منفصل. قد تحصل على 72 وتظل مجتازاً لمؤشرات Core Web Vitals.

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

• تتغير النتيجة في كل مرة تشغّل فيها الاختبار. إنه اختبار محاكى واحد، لذا يتقلب الرقم. شغّله عدة مرات ولا تبالغ في تفسير تغير يتراوح بين 3 و5 نقاط.
• لا تحتاج إلى 100. لا يكاد أحد يحرز 100. استهدف اجتياز Core Web Vitals، لا بلوغ رقم مثالي.
• النتيجة الجيدة لا تضمن صفحة سريعة للمستخدمين الفعليين، والنتيجة “السيئة” لا تعني أن المستخدمين الفعليين يعانون.

بصراحة، ما لم يكن موقعك بطيئاً فعلاً، فلن أبدأ من هنا. هل تريد التفصيل الكامل: الميدان مقابل المختبر، وحدود p75، وآليات الرجوع إلى بيانات بديلة، وكيف يختلف PSI عن Lighthouse وSearch Console؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — يعرض PSI (pagespeed.web.dev) تحليلين مستقلين لعنوان URL واحد: بيانات ميدانية من Chrome UX Report، مبنية على مستخدمين فعليين خلال فترة متحركة من 28 يوماً، وهي التي تحدد تقييم Core Web Vitals بالاجتياز أو الإخفاق عند المئين 75؛ وبيانات مختبرية من تشغيل Lighthouse واحد، تمنح نتيجة الأداء من 0 إلى 100 إلى جانب التشخيصات. نتيجة 0–100 هي بيانات مختبرية وليست عامل ترتيب؛ فالترتيب يستخدم مؤشرات Core Web Vitals الميدانية (LCP/INP/CLS). تحتاج البيانات الميدانية إلى عينات كافية من CrUX (على مستوى URL، ثم الرجوع إلى مستوى المصدر، وإلا تظهر “No data” (ترجمة) «لا توجد بيانات»). كما تتغير النتيجة المختبرية من تشغيل إلى آخر، لذا شغّل الاختبار عدة مرات. PSI هو واجهة الويب؛ وLighthouse هو المحرك؛ أما تقرير Search Console فهو عرض آخر لبيانات CrUX.

PSI أداتان تحت غطاء واحد

أهم شيء على الإطلاق لفهم PageSpeed Insights هو أنه ليس تحليلاً واحداً، بل تحليلان معروضان في واجهة واحدة. يلخص web.dev ذلك بوضوح: “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (ترجمة) «PSI أداة تعرض بيانات ميدانية من CrUX وبيانات مختبرية من Lighthouse لصفحة معينة». يأتي النصفان من نظامين مختلفين، ويقيسان أشياء مختلفة، ويهمان لأسباب مختلفة. إذا خلطت بينهما أصبح كل سؤال تقريباً عن PSI مربكاً؛ وإذا فصلت بينهما اتضح كل شيء.

البيانات الميدانية: ما اختبره المستخدمون الفعليون

يعمل القسم العلوي، “Discover what your real users are experiencing” (ترجمة) «اكتشف ما يختبره مستخدموك الفعليون»، بواسطة Chrome UX Report (CrUX). يصف web.dev واجهة CrUX API بأنها تتيح “low-latency access to aggregated real-user experience data at page and origin granularity” (ترجمة) «وصولاً منخفض زمن الاستجابة إلى بيانات مجمعة عن تجربة المستخدمين الفعليين على مستوى الصفحة والمصدر» في صورة “28-day rolling average.” (ترجمة) «متوسط متحرك لمدة 28 يوماً». يحدّث PSI بياناته يومياً؛ أما مجموعة بيانات CrUX في BigQuery فتصدر شهرياً.

بعض الآليات المهمة:

• يكون تقييم Core Web Vitals اجتيازاً/إخفاقاً عند p75. وفقاً لوثائق Chrome، “to pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” (ترجمة) «لاجتياز التقييم، يجب تصنيف المئين بأنه “جيد” في مؤشرات Core Web Vitals الثلاثة كلها؛ وإلا ظهر التقييم “مخفقاً”». والمؤشرات الثلاثة هي Largest Contentful Paint (الجيد < 2,5s)، وInteraction to Next Paint (الجيد < 200ms)، وCumulative Layout Shift (الجيد < 0,1). يعرض PSI أيضاً FCP وTTFB ضمن “Other metrics” (ترجمة) «مقاييس أخرى»؛ وهي مفيدة للمعلومات، لكنها ليست جزءاً من الحكم.
• هناك استثناء موثق واحد، وهو خاص بـINP وحده. إذا لم تكن لدى الصفحة عينات كافية من CrUX للإبلاغ عن INP تحديداً، يفيد دليل PSI الحالي بأنه يستطيع مع ذلك تقييم الاجتياز/الإخفاق بالاعتماد على قيمتي p75 الجيدتين لـLCP وCLS وحدهما. ولا يوجد استثناء مماثل لـLCP أو CLS؛ فإذا كان أحدهما هو المقياس الذي يفتقر إلى بيانات كافية، فلا تعتبر ذلك اجتيازاً؛ فنقص البيانات ليس إعفاءً موثقاً لأي مقياس باستثناء INP.
• p75 يعني المئين 75. القيمة المعروضة هي التجربة التي كانت 75% من مشاهدات الصفحة أسرع منها. اختار web.dev المئين 75 ليكون الرقم “resistant to outliers” (ترجمة) «مقاوماً للقيم المتطرفة»، وهو هدف أشد صرامة من الوسيط.
• حل INP محل FID في مارس 2024. إذا كنت تنظر إلى لقطات شاشة أو أدلة قديمة (بما فيها كتابتي القديمة على Ahrefs عن PageSpeed Insights وCore Web Vitals)، فقد لا تزال تعرض FID؛ أما التقييم الآن فيستخدم INP.
• آلية الرجوع URL ← المصدر ← “No data”. إذا لم تتوافر بيانات CrUX كافية لعنوان URL المحدد، يرجع PSI إلى بيانات مستوى المصدر (المجمعة عبر الموقع كله). وإذا لم توجد بيانات CrUX إطلاقاً، فسترى “No data” (ترجمة) «لا توجد بيانات»، لكن Lighthouse يظل يعمل. وكما يذكر web.dev، “CrUX data is only available when sites meet certain eligibility criteria” (ترجمة) «لا تتوافر بيانات CrUX إلا عندما تستوفي المواقع معايير أهلية معينة» و*“PSI is only available for public URLs.”* (ترجمة) «لا يتوافر PSI إلا لعناوين URL العامة». كثيراً ما تفتقر الصفحات منخفضة الزيارات والصفحات الجديدة تماماً إلى بيانات ميدانية على مستوى URL.

اقرأ وسم النطاق قبل كتابة الاستنتاج. تصف بيانات CrUX على مستوى URL العينة الميدانية المؤهلة المنسوبة إلى ذلك العنوان. أما الرجوع إلى مستوى المصدر فهو إشارة مفيدة للموقع كله، لكنه لا يستطيع تشخيص الصفحة المختبرة بمفرده. تعني “No data” (ترجمة) «لا توجد بيانات» أن العينة الميدانية غير متاحة أو غير كافية، لا أن الصفحة اجتازت أو أخفقت أو لم تتلقَّ أي زيارات. ويمكن لنتيجة Lighthouse أدناه أن تشخّص ذلك التشغيل المختبري المضبوط، لكنها لا تسد فجوة البيانات الميدانية المفقودة.

البيانات المختبرية: نتيجة Lighthouse من 0 إلى 100

القسم السفلي هو تشغيل واحد من Lighthouse على جهاز وشبكة محاكيين، وينتج نتيجة الأداء وقائمة بالفرص والتشخيصات. تصنيفات Google هي: “A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.” (ترجمة) «تُعد النتيجة 90 أو أعلى جيدة، والنتيجة من 50 إلى 89 بحاجة إلى تحسين، وما دون 50 يُعد ضعيفاً».

ما ينبغي معرفته عن التشغيل المختبري:

• إنه محاكى، وتشغيل الجوال بطيء عمداً. يحاكي الجوال هاتفاً متوسط الإمكانات على اتصال مخفَّض السرعة، بينما يستخدم سطح المكتب ملفاً محاكى أسرع. ولهذا تكون نتيجة الجوال أقل من سطح المكتب في معظم الأحيان، ولهذا أيضاً تبدو بيانات المستخدمين الفعليين الميدانية غالباً أفضل مما توحي به التشخيصات المختبرية.
• النتيجة متغيرة. كل تشغيل هو تدقيق Lighthouse جديد من جانب الخادم؛ فالصفحة ومركز بيانات Google وظروف الشبكة وحتى إصدار Chrome/Lighthouse يمكن أن تغيّر الرقم بين تشغيل وآخر. أوصي بتشغيله عدة مرات (3–5) والنظر إلى النطاق بدلاً من اعتبار أي تشغيل منفرد حقيقة مطلقة. تغير بضع نقاط ضوضاء.
• إذا كنت تقارن التشغيلات، فاحفظ أكثر من النتيجة. تحمل استجابة API طابعاً زمنياً، وعنوان URL المطلوب والنهائي، وشكل الجهاز، والبيئة المحاكية، وإصدار Lighthouse، وأي تحذيرات؛ فاحتفظ بها مع كل نتيجة. نتيجتان مقدار كل منهما “72” لا تصلحان للمقارنة إذا كان إحداهما على إصدار مختلف من Lighthouse أو واجهت إعادة توجيه لم تواجهها الأخرى. لا تحسب متوسط نتائج بلا وسوم؛ ضع لها وسوماً أو لا تقارنها.
• تتحرك إصدارات Lighthouse بصورة مستقلة عن PSI API. بقي PSI على API v5، لكن محرك Lighthouse الذي يعمل تحته يواصل إصدار تحديثات جديدة (أحدث إصدار مذكور في ملاحظات إصدار Google وقت هذه المراجعة هو Lighthouse 13.0، بتاريخ 2025-10-20)؛ وقد تتغير حقول التدقيق وأوزانه ونطاقاته مع إصدار المحرك حتى إن لم يتغير عقد API.
• “Estimated savings” (ترجمة) «الوفورات المقدرة» ليست قابلة للجمع. تفترض الثواني المعروضة بجانب كل تشخيص أن ذلك الإصلاح يُنفذ منفرداً. تتفاعل المشكلات، وتكون المكاسب الفعلية دائماً تقريباً أقل من مجموع التقديرات الفردية. تعامل معها بوصفها مؤشرات اتجاهية، لا ميزانية يمكنك جمعها.
• تتغير أوزان المقاييس مع إصدارات Lighthouse. نتيجة الأداء مزيج موزون من مقاييس المختبر (تحمل مقاييس وقت التحميل وTotal Blocking Time وCLS أكبر وزن)، لكن الأوزان الدقيقة تتغير بين إصدارات Lighthouse؛ راجع حاسبة النتائج الحالية بدلاً من الوثوق بتقسيم ثابت.

الخرافة الأكثر ضرراً: “النتيجة عامل ترتيب”

ليست كذلك. نتيجة الأداء من 0 إلى 100 هي رقم مختبري من Lighthouse، ولم أجد أي مصدر رسمي حالي من Google Search يوثق النتيجة نفسها بوصفها مدخلاً للترتيب أو يربط تغير النتيجة بتغير الترتيب. بدلاً من ذلك، تشير وثائق تجربة الصفحة لدى Google إلى مؤشرات Core Web Vitals الميدانية، أي بيانات المستخدمين الفعليين المستندة إلى CrUX، وهي نوع البيانات نفسه الذي يعرضه قسم PSI الميداني عند p75. (تنبيه يستحق الدقة: عرض PSI الميداني العام هو واجهة إبلاغ لها قواعد أهلية ورجوع خاصة بها؛ ولم تنشر Google المسار الداخلي الدقيق الذي يغذي الترتيب، لذا تعامل مع “البيانات الميدانية” بوصفها النوع نفسه من الإشارة بدلاً من افتراض تطابقها بايتاً ببايت مع ما يعرضه PSI.) قد تبقى نتيجة صفحة عند 72 في المختبر ومع ذلك تجتاز تقييم Core Web Vitals لأن بيانات مستخدميها الفعليين جيدة؛ أرقام مختلفة من نظامين مختلفين. والخرافة الملازمة، “a good lab score equals a good real-user experience” (ترجمة) «النتيجة المختبرية الجيدة تعني تجربة جيدة للمستخدم الفعلي»، تفشل للسبب نفسه: ظروف المختبر ليست ظروف زوارك. عندما تختلف البيانات الميدانية والمختبرية، تكون البيانات الميدانية الأوثق صلة بتحسين محركات البحث.

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

كيف تقرأ تقرير PSI فعلياً

1. اقرأ البيانات الميدانية أولاً. هل كانت نتيجة تقييم Core Web Vitals اجتيازاً أم إخفاقاً؟ هذا هو الحكم المتصل بتحسين محركات البحث. إذا قال “No data” (ترجمة) «لا توجد بيانات»، فلا توجد زيارات كافية في CrUX بعد، وأنت تعمل بالبيانات المختبرية وحدها.
2. تحقق من الجوال وسطح المكتب كل على حدة. الجوال هو الافتراضي وعادةً ما يكون الأضعف؛ وهو أيضاً الأهم غالباً لأن Google تفهرس للجوال أولاً.
3. ثم استخدم التشخيصات المختبرية للعثور على السبب. البيانات المختبرية هي حلقة الملاحظات السريعة للعثور على أصل المشكلة وإصلاحه: الموارد المانعة للعرض، والصور الضخمة، ومصادر تغيّر التخطيط، والمهام الطويلة.
4. أصلح، ثم انتظر. البيانات الميدانية نافذة متحركة من 28 يوماً، لذا قد يستغرق ظهور إصلاح تنشره اليوم بالكامل في تقييم Core Web Vitals ما يصل إلى 28 يوماً. استخدم البيانات المختبرية لتأكيد الإصلاح فوراً، والميدانية لتأكيد أنه حسّن تجربة المستخدمين الفعليين بالفعل.
5. قارن بالمنافسين. لأن PSI يعمل على أي URL عام، يمكنك تشغيله على صفحات منافس ومقارنة مؤشرات Core Web Vitals الميدانية لديهم بمؤشراتك؛ وهي حالة استخدام لا تذكرها معظم الأدلة.

PSI مقارنةً بالأدوات التي يختلط بها

• PSI مقابل Lighthouse. Lighthouse هو المحرك؛ أما PSI فهو واجهة ويب تشغّل Lighthouse وتضيف فوقه بيانات CrUX الميدانية. شغّل Lighthouse بنفسك (في Chrome DevTools أو CLI) فتحصل على التدقيق المختبري، لكن على جهازك وشبكتك، ومن دون بيانات ميدانية.
• PSI مقابل تقرير Core Web Vitals في Search Console. كلاهما مستند إلى CrUX، ومن ثم يعكسان المستخدمين الفعليين. الفرق أن Search Console يجمع عناوين URL المتشابهة ويعرض تقارير على نطاق واسع عبر موقعك كله، بينما يعمل PSI لكل URL (أو يرجع إلى مستوى المصدر). إذا بدا أن GSC وPSI مختلفان، فعادةً ما يكون التجميع هو السبب.
• PSI مقابل Chrome DevTools / WebPageTest / DebugBear / Ahrefs Site Audit. توفر هذه الأدوات إعدادات أكثر (أجهزة ومواقع وخفض سرعة مخصص)، وفي بعض الحالات مراقبة للمستخدمين الفعليين. تتمثل قوة PSI في كونه مجانياً، بلا إعداد، ومرتبطاً بمجموعة بيانات CrUX الخاصة بـGoogle.

واجهة PSI API (للاختبارات المجمعة)

لست مضطراً إلى استخدام واجهة الويب لعنوان URL واحد كل مرة. تعيد واجهة PageSpeed Insights API (الأساس https://www.googleapis.com/pagespeedonline/v5) البيانات نفسها برمجياً. المعاملات الرئيسية: url (مطلوب)، وstrategy (mobile أو desktop)، وcategory (performance، وaccessibility، وbest-practices، وseo). تنقسم الاستجابة بالطريقة نفسها في الواجهة: loadingExperience (بيانات ميدانية على مستوى URL)، وoriginLoadingExperience (بيانات ميدانية على مستوى المصدر)، و lighthouseResult (التدقيق المختبري). هكذا يمكنك اختبار مجموعة من عناوين URL وفق جدول زمني بدلاً من النقر عليها يدوياً.

لا تنشئ أتمتة دائمة للبيانات الميدانية على هذه الواجهة. تبدأ وثائق API الخاصة بـGoogle الآن بإشعار يفيد بأنها تخطط للتوقف عن تضمين بيانات CrUX الفعلية في PSI API، وتوجه من يريد الأتمتة إلى CrUX API أو CrUX History API المخصصتين بدلاً منها. واصل استخدام PSI API لتدقيق Lighthouse المختبري، فهذا الجزء غير متأثر، لكن إذا كنت تجدول سحباً مجمعاً للبيانات الميدانية، فابنه على API خاصة بـCrUX، لا على loadingExperience/originLoadingExperience في استجابة PSI.

موضع هذه الأداة في أداء الويب

PSI أداة قياس، لا غاية. المقاييس التي يعرضها، Largest Contentful Paint وInteraction to Next Paint وCumulative Layout Shift، هي Core Web Vitals، والمركز الخاص بها (الحدود، ومعنى كل منها، وكيفية تحسينها) هو وجهتك التالية. Lighthouse هو محرك المختبر الذي يشغّله PSI؛ أما CrUX (أي Chrome UX Report) فهو مصدر البيانات الميدانية الذي يغذي أعلى كل تقرير PSI. افهم هذه الثلاثة ولن يبقى PSI صندوقاً غامضاً.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للإصدار المتقدم:

• PSI = أداتان في واجهة واحدة. بيانات ميدانية من Chrome UX Report (مستخدمون فعليون) وبيانات مختبرية من تشغيل Lighthouse واحد للعنوان نفسه على pagespeed.web.dev. مجاني، بلا تسجيل دخول، لأي URL عام، للجوال وسطح المكتب.
• البيانات الميدانية تحدد تقييم Core Web Vitals، اجتيازاً أو إخفاقاً، عند المئين 75، عبر LCP (<2,5s) وINP (<200ms) وCLS (<0,1). نافذة متحركة من 28 يوماً تُحدّث يومياً. يظهر FCP وTTFB لكنهما لا يدخلان في الحكم.
• البيانات المختبرية هي نتيجة الأداء من 0 إلى 100 (90+ جيد، و50–89 بحاجة إلى تحسين، و<50 ضعيف) إلى جانب التشخيصات. يخضع الجوال لخفض السرعة وتكون نتيجته أقل من سطح المكتب.
• نتيجة 0–100 ليست موثقة بوصفها عامل ترتيب. تستخدم أنظمة ترتيب Google مؤشرات Core Web Vitals الميدانية (بيانات مستخدمين فعليين مستندة إلى CrUX، وهي النوع نفسه الذي يعرضه قسم PSI الميداني، مع أن Google لم تنشر المسار الداخلي الدقيق بوصفه مطابقاً لعرض PSI العام). قد تحرز صفحة 72 وتظل مجتازة لـCWV؛ أرقام مختلفة من أنظمة مختلفة.
• رجوع CrUX: مستوى URL ← مستوى المصدر ← “No data” (ترجمة) «لا توجد بيانات» (ويظل Lighthouse يعمل). كثيراً ما تفتقر الصفحات الجديدة ومنخفضة الزيارات إلى بيانات ميدانية على مستوى URL.
• النتيجة متغيرة من تشغيل إلى آخر؛ شغّلها 3–5 مرات. “Estimated savings” (ترجمة) «الوفورات المقدرة» لا تُجمع. لا تحتاج إلى 100.
• اقرأ البيانات الميدانية أولاً (اجتياز/إخفاق)، ثم استخدم التشخيصات المختبرية للعثور على السبب؛ انشر الإصلاح، ثم انتظر ما يصل إلى 28 يوماً حتى تعكسه البيانات الميدانية.
• PSI مقابل Lighthouse (المحرك مقابل الواجهة+الميدان) ومقابل تقرير CWV في Search Console (هو أيضاً من CrUX، لكنه مجمع على نطاق واسع). CWV إجمالاً مدخل ترتيب صغير.

الوثائق الرسمية

وثائق من المصادر الأولية لدى Google وفريقي Chrome وweb.dev.

Google / PageSpeed Insights

• أداة PageSpeed Insights — الأداة نفسها.
• واجهة PageSpeed Insights API — نبذة — ما يفعله PSI، ونوعا البيانات، ونطاقات نتيجة 0–100.
• واجهة PSI API — مرجع runPagespeed — المعاملات (url، وstrategy، وcategory) وبنية الاستجابة.

Chrome UX Report (مصدر البيانات الميدانية)

• استخدام CrUX في PageSpeed Insights — كيفية عمل القسم الميداني وتقييم الاجتياز/الإخفاق.
• منهجية CrUX — الأهلية والاشتراك والصفحات المشمولة.
• واجهة CrUX API — المتوسط المتحرك لمدة 28 يوماً الذي يغذي بيانات PSI الميدانية.
• نظرة عامة على CrUX — كيف يغذي CrUX إشارة ترتيب تجربة الصفحة.

web.dev / Core Web Vitals

• ما أدوات Core Web Vitals؟ — موضع PSI بين أدوات CrUX/Lighthouse.
• Core Web Vitals — حدود LCP/INP/CLS وقاعدة المئين 75.
• تحديد حدود Core Web Vitals — سبب استخدام p75.
• Core Web Vitals وبحث Google — سياق إشارة الترتيب.

اقتباسات من المصدر

عبارات منقولة حرفياً، يرتبط كل منها بالموضع الوارد فيه في صفحة المصدر.

Google / Chrome / web.dev — كيفية عمل PSI

• “PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page.” (ترجمة) «PSI أداة تعرض بيانات ميدانية من CrUX وبيانات مختبرية من Lighthouse لصفحة معينة». — web.dev. الانتقال إلى الاقتباس
• “PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.” (ترجمة) «لا يتوافر PSI إلا لعناوين URL العامة، ولا يمكن استخدامه على مواقع التطوير غير المتاحة للعامة». — web.dev. الانتقال إلى الاقتباس
• يوصف القسم الميداني بأنه “Discover what your real users are experiencing.” (ترجمة) «اكتشف ما يختبره مستخدموك الفعليون». — Chrome للمطوّرين، ‏CrUX في PSI. الانتقال إلى الاقتباس
• “To pass, the percentile must be categorized as ‘good’ in all three Core Web Vitals. Otherwise, the assessment appears as ‘failed’.” (ترجمة) «لاجتياز الاختبار، يجب أن يُصنَّف المئين ضمن “جيد” في مؤشرات Core Web Vitals الثلاثة كلها؛ وإلا يظهر التقييم “فاشلًا”». — Chrome للمطوّرين، ‏CrUX في PSI. الانتقال إلى الاقتباس
• تمنح واجهة CrUX API “low-latency access to aggregated real-user experience data at page and origin granularity” (ترجمة) «وصولاً منخفض زمن الاستجابة إلى بيانات مجمعة عن تجربة المستخدمين الفعليين على مستوى الصفحة والمصدر» في صورة “28-day rolling average.” (ترجمة) «متوسط متحرك لمدة 28 يوماً». — Chrome للمطوّرين، ‏واجهة CrUX البرمجية. الانتقال إلى الاقتباس

web.dev — الحدود

• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (ترجمة) «الحد الجيد للقياس هو المئين 75 من مرات تحميل الصفحة، مقسماً بين أجهزة الجوال وسطح المكتب». — web.dev، ‏Core Web Vitals. الانتقال إلى الاقتباس
• “if at least 75 percent of page views to a site meet the ‘good’ threshold, the site is classified as having ‘good’ performance.” (ترجمة) «إذا استوفت 75 في المئة على الأقل من مشاهدات صفحات الموقع الحد “الجيد”، صُنّف الموقع على أن أداءه “جيد”». — web.dev، تحديد الحدود. الانتقال إلى الاقتباس

المجال — الفرق بين النتيجة والترتيب (منقول، وليس عن Google)

• “The Performance score on PageSpeed Insights does not impact SEO directly. However, the real-user Core Web Vitals assessment does impact Google rankings.” (ترجمة) «لا تؤثر نتيجة الأداء في PageSpeed Insights مباشرةً في تحسين محركات البحث، لكن تقييم Core Web Vitals للمستخدمين الفعليين يؤثر في ترتيب Google». — Matt Zeunert، ‏DebugBear. المصدر
• “Core Web Vitals are the only metrics Google explicitly uses for grading.” (ترجمة) «Core Web Vitals هي المقاييس الوحيدة التي تستخدمها Google صراحةً للتقييم». و*“Running the same URL just minutes apart can yield different scores.”* (ترجمة) «قد يؤدي تشغيل عنوان URL نفسه بفاصل بضع دقائق فقط إلى نتائج مختلفة». — Ryan Sullivan، ‏SiteCare. المصدر

ورقة مرجعية سريعة لتقرير PSI

كل قسم في PSI: ميداني أم مختبري، وماذا يعني

حدود “الجيد” لمؤشرات Core Web Vitals (ميداني، p75)

نطاقات نتيجة Lighthouse (مختبري)

• 90–100 — جيد · 50–89 — بحاجة إلى تحسين · <50 — ضعيف

الرجوع في البيانات الميدانية

• CrUX على مستوى URL ← إذا لم يكفِ، مستوى المصدر ← إذا لم يوجد، “No data” (ترجمة) «لا توجد بيانات» (ويظل Lighthouse يعمل).

حقائق سريعة

• البيانات الميدانية = 28 يوماً متحركة، تُحدّث يومياً؛ قد يستغرق ظهور الإصلاح ما يصل إلى 28 يوماً.
• نتيجة 0–100 متغيرة؛ شغّل الاختبار 3–5 مرات وتجاهل تغيراً من 3 إلى 5 نقاط.
• “Estimated savings” (ترجمة) «الوفورات المقدرة» لا تُجمع؛ فهي تفترض تنفيذ كل إصلاح منفرداً.
• الجوال هو علامة التبويب الافتراضية وعادةً ما يحرز نتيجة أقل من سطح المكتب.
• حل INP محل FID في مارس 2024.

أدوات مرتبطة بـPSI

• PageSpeed Insights (pagespeed.web.dev) — الأداة نفسها: ميداني (CrUX) + مختبري (Lighthouse)، للجوال وسطح المكتب، ولأي URL عام.
• Google Lighthouse — محرك المختبر الذي يشغّله PSI. شغّله محلياً في Chrome DevTools (لوحة Lighthouse) أو عبر CLI لإجراء التدقيق المختبري على جهازك/شبكتك (من دون بيانات ميدانية).
• Google Search Console — تقرير Core Web Vitals — العرض الآخر المستند إلى CrUX؛ يجمع عناوين URL المتشابهة ويعرض البيانات الميدانية عبر موقعك كله.
• CrUX Vis / CrUX API / BigQuery — انتقل مباشرةً إلى البيانات الميدانية خلف PSI لمتابعة الاتجاهات بمرور الوقت. (أُوقفت CrUX Dashboard القديمة في Looker Studio في نهاية نوفمبر 2025؛ وتؤكد ملاحظات إصدار Google ومنشورها المخصص للإيقاف التاريخ وتشيران إلى CrUX Vis (cruxvis.withgoogle.com) بوصفها البديل. إذا كان دليل لا يزال يطلب منك استخدام Dashboard، فهو قديم.)
• PSI API — لاختبار عدة عناوين URL برمجياً (url، وstrategy، وcategory)؛ وتنقسم الاستجابة إلى loadingExperience وoriginLoadingExperience وlighthouseResult. أعلنت Google أنها تخطط للتوقف عن تضمين بيانات مستخدمي CrUX الفعلية في هذه الواجهة، وتوصي الآن باستخدام CrUX API أو CrUX History API المخصصتين لأتمتة ميدانية دائمة؛ فلا تنشئ مساراً يفترض بقاء كائنات البيانات الميدانية في PSI API على المدى الطويل.
• Ahrefs Site Audit وWebPageTest / DebugBear — إعدادات أكثر، وفي بعض الحالات مراقبة للمستخدمين الفعليين تتجاوز تشغيل Lighthouse واحداً.

أخطاء PageSpeed Insights التي تشوه الأولويات

• اعتبار نتيجة 0–100 عامل ترتيب. النتيجة تشغيل مختبري واحد من Lighthouse. أما تقييم Core Web Vitals المتصل بالترتيب فيأتي من بيانات CrUX الميدانية.
• قراءة الرجوع إلى مستوى المصدر بوصفه أداء URL. عندما يفتقر URL إلى عينات كافية، قد يعرض PSI بيانات على مستوى المصدر. تحقق من وسم النطاق قبل الادعاء بأن الصفحة نفسها اجتازت أو أخفقت.
• التفاعل مع تشغيل مختبري واحد. تتغير استجابة الخادم والبيئة الاصطناعية. كرر تشغيلات متطابقة واستخدم النطاق أو الوسيط للتمييز بين الإشارة والضوضاء.
• جمع وفورات الفرص. تتداخل تقديرات التدقيق وتفترض أن كل إصلاح يحدث مستقلاً. تعامل معها بوصفها أدلة اتجاهية، لا مجموعاً مضموناً.
• توقع أن يغيّر النشر البيانات الميدانية فوراً. CrUX عرض متحرك لمدة 28 يوماً. استخدم قسم المختبر للتشخيص الفوري والقسم الميداني للتأكيد بمرور الوقت.
• مقارنة نتائج الجوال وسطح المكتب كأن الظروف متطابقة. قيّم كل ملف مقابل نفسه وجمهورك بدلاً من اعتبار الأرقام مقياساً واحداً.

يعرض PSI عبارة “No data” (ترجمة) «لا توجد بيانات»

العَرَض: لا يتضمن القسم الميداني نتيجة من CrUX، لكن تقرير Lighthouse يعمل.

السبب المحتمل: لا يستوفي URL والمصدر متطلبات أهلية CrUX أو حجم العينة، أو أن الصفحة جديدة أو منخفضة الزيارات.

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

اختلاف PSI وSearch Console

العَرَض: يبدو URL سليماً في PSI بينما مجموعته في Search Console ضعيفة، أو العكس.

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

الإصلاح والتأكيد: طابق الجوال/سطح المكتب، وافحص نطاق بيانات PSI، وخذ عينة من عدة عناوين URL في مجموعة Search Console قبل استنتاج أن أحد التقريرين خاطئ.

تتقلب النتيجة المختبرية بين التشغيلات

العَرَض: ينتج تكرار PSI نتائج أو قيم مقاييس مختلفة بدرجة ملحوظة.

السبب المحتمل: غيّرت استجابة خادم متغيرة أو طلب من طرف ثالث أو ضوضاء مختبرية طبيعية في تشغيل واحد مسار التتبع.

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

يظهر الإصلاح في Lighthouse لكن ليس في البيانات الميدانية

العَرَض: يتحسن المقياس المختبري فوراً، بينما يظل تقييم Core Web Vitals الميداني بلا تغيير.

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

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

سحب نتيجة PSI واحدة من API

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

curl --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode "url=$TARGET_URL" \
  --data 'strategy=mobile' \
  --data-urlencode "key=$PSI_KEY" \
  --output psi.json

احتفظ بالاستجابة الخام حتى يظل تاريخ الاختبار والاستراتيجية ونطاق البيانات قابلة للتدقيق.

فصل النطاق الميداني عن النتيجة المختبرية

باستخدام jq، استخرج فئة الحقل على مستوى URL، وفئة الرجوع إلى مستوى المصدر، ونتيجة Lighthouse بدلاً من دمجها في رقم واحد:

jq '{
  url_field: .loadingExperience.overall_category,
  origin_field: .originLoadingExperience.overall_category,
  lab_score: (.lighthouseResult.categories.performance.score * 100)
}' psi.json

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

تكرار التشغيل المختبري من دون إخفاء العينات

for run in 1 2 3; do
  curl --silent --get 'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
    --data-urlencode "url=$TARGET_URL" \
    --data 'strategy=mobile' \
    --data-urlencode "key=$PSI_KEY" \
  | jq -r "[$run, (.lighthouseResult.categories.performance.score * 100)] | @tsv"
done

أبلغ عن جميع العينات أو عن ملخص موثق؛ ولا تختر أفضل نتيجة وحدها.

اختبر نفسك: PageSpeed Insights

خمسة أسئلة سريعة عن قراءة PSI بطريقة صحيحة. اختر إجابة لكل منها، ثم تحقق.

موارد تستحق وقتك

كتاباتي ذات الصلة

• Google PageSpeed Insights: دليل مناسب للمبتدئين — شرحي على Ahrefs (ملاحظة: يسبق استبدال FID بـINP).
• Core Web Vitals: دليل كامل — الميدان مقابل المختبر ورأيي في مدى أهمية CWV فعلياً.
• دليل المبتدئين إلى تحسين محركات البحث التقني — موضع الأداء في الصورة الأكبر.

رسمي

• استخدام CrUX في PageSpeed Insights — شرح Chrome للقسم الميداني.
• ما أدوات Core Web Vitals؟ — علاقة PSI وLighthouse وCrUX وSearch Console.

من آخرين

• كيفية استخدام PageSpeed Insights — Matt Zeunert ‏(DebugBear)؛ عمق تقني قوي حول النتيجة والتشخيصات.
• PageSpeed Insights: أداة Google التشخيصية التي يساء فهمها بشدة — Ryan Sullivan ‏(SiteCare)؛ تفنيد جيد للخرافات.
• عامل ترتيب Core Web Vitals أكثر من مجرد كاسر تعادل — تغطية Search Engine Journal لتعليقات Gary Illyes التي تضع أثر CWV في سياقه.
• تحديث تجربة الصفحة من Google أكثر من مجرد كاسر تعادل — ‏SE Roundtable؛ تقرير Barry Schwartz عن الكيفية التي وصف بها ممثلو Google إشارة تجربة الصفحة.

إحصاءات تستحق الاستشهاد

• لا يكاد أحد يحرز 100. لا تبلغ النتيجة المثالية 100 سوى نحو 2% من الصفحات المختبرة، ونتيجة 50 تضعك بالفعل ضمن أعلى 25%؛ وهو سياق مفيد لأي شخص يفزع من رقم دون 90. المصدر
• البيانات الميدانية متوسط متحرك لمدة 28 يوماً. قد يستغرق انعكاس الإصلاح بالكامل في تقييم Core Web Vitals ما يصل إلى نحو 28 يوماً؛ استخدم البيانات المختبرية للحصول على ملاحظات سريعة في غضون ذلك. المصدر
• حد “الجيد” هو المئين 75. تقيّم Google عند p75 بحيث “a majority of visits experienced the target level of performance” (ترجمة) «اختبرت غالبية الزيارات مستوى الأداء المستهدف»؛ ما يعني أنه حتى مع LCP مجتاز مقداره 2,5s، انتظر ربع الزوار مدة أطول. المصدر

سجل التغييرات