البيانات الميدانية مقابل بيانات المختبر

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

طريقتان لقياس الصفحة

لا توجد سوى طريقتين لمعرفة سرعة صفحتك:

• دع أداة تحمّلها مرة واحدة ضمن إعداد ثابت للجهاز وسرعة الشبكة والموقع. هذه بيانات المختبر، وهي طريقة Lighthouse وقسم التشخيص في PageSpeed Insights.
• راقب ما حدث فعلًا لأشخاص حقيقيين على أجهزتهم واتصالاتهم. هذه البيانات الميدانية. ولأغراض SEO تأتي من تقرير تجربة مستخدم Chrome (CrUX)، المبني على مستخدمي Chrome الذين وافقوا على مشاركة بيانات التجربة.

تعرّف وثائق web.dev البيانات الميدانية بأنها “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (ترجمة) «تُحدد بمراقبة جميع مستخدمي الصفحة وقياس مجموعة من مؤشرات الأداء لكل تجربة فردية». أما بيانات المختبر فـ*“is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.”* (ترجمة) «تُحدد بتحميل الصفحة في بيئة مضبوطة بشروط شبكة وجهاز محددة مسبقًا».

الفكرة الوحيدة التي ينبغي تذكرها

يعتمد Google في الترتيب على البيانات الميدانية. نتيجة Lighthouse أو PageSpeed رقم مختبري وليست ما يستخدمه Google للترتيب. وكما أوضح John Mueller، لا يستخدم Google نتيجة Lighthouse من 0 إلى 100 في البحث، بل يستخدم مؤشرات Core Web Vitals منفصلة مقيسة من مستخدمين حقيقيين. مرجع المصدر: https://www.searchenginejournal.com/do-google-lighthouse-scores-affect-seo/425347/

لذلك لا يوجد تناقض إذا ظهرت نتيجة PageSpeed Insights باللون الأخضر بينما يصنف تقرير Core Web Vitals في Search Console الصفحة «ضعيفة». إنهما مجموعتا بيانات مختلفتان:

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

يختلفان كثيرًا، وعند الاختلاف تكون البيانات الميدانية هي المعتمدة في SEO.

أيهما أستخدم؟

• «كيف هو أدائي للترتيب؟» → البيانات الميدانية في تقرير Core Web Vitals في Search Console أو أعلى PageSpeed Insights.
• “What’s making my page slow / what do I fix?” (ترجمة) «ما الذي يبطئ الصفحة، وماذا أصلح؟» → بيانات المختبر؛ شغّل Lighthouse لتظهر المشكلات.
• «أجريت تغييرًا، فهل نجح؟» → اختبره فورًا في المختبر، ثم انتظر تحديث البيانات الميدانية ضمن نافذتها المتحركة البالغة 28 يومًا.

هل تريد فهم أسباب اختلاف الرقمين، وحساب المئين 75 ونافذة 28 يومًا، وأدوات كل نوع والخرافات الشائعة؟ انتقل إلى علامة التبويب المتقدم. يقدم دليل الفروق بين بيانات المختبر والميدان مرجعًا إضافيًا.

الخلاصة — البيانات الميدانية توزيع لقياسات مستخدمين حقيقيين (RUM)، وتمثلها في SEO بيانات CrUX المجمعة عند المئين 75 خلال نافذة متحركة من 28 يومًا. أما بيانات المختبر فهي ملاحظة واحدة مضبوطة على جهاز وشبكة وموقع ثابت، مثل Lighthouse؛ أي أداة تشخيص لا مدخل ترتيب. لا توجد واحدة «أدق» دائمًا؛ فالاختيار يتبع السؤال. تختلفان بسبب التخزين المؤقت والجغرافيا وتنوع الأجهزة والشبكات وملفات الخنق وتوقيت التفاعل. ويمكن للمختبر تسجيل INP محليًا لتفاعل معاد يدويًا، لكنه لا يصنع توزيعًا سكانيًا. استخدم المختبر للاختبار والتصحيح السريعين، والميدان لتأكيد الأثر الحقيقي وكل ما يتعلق بالترتيب. ويظل CrUX خاصًا بمستخدمي Chrome الموافقين، مع حالات حدية في تجميع الصفحة والنطاق. ولا ينشر Bing نظيرًا له؛ فهذا إطار منظومة Google وChrome.

التعريفان بدقة

تقدم صفحة Google لماذا قد تختلف بيانات المختبر والميدان أوضح تعريفين:

• البيانات الميدانية “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (ترجمة) «تُحدد بمراقبة جميع مستخدمي الصفحة وقياس مؤشرات الأداء لكل تجربة فردية».
• بيانات المختبر “is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (ترجمة) «تُحدد بتحميل الصفحة في بيئة مضبوطة بشروط شبكة وجهاز محددة مسبقًا». ويتكون الاختبار من “a single device… connected to a single network… run from a single geographic location.” (ترجمة) «جهاز واحد متصل بشبكة واحدة ويعمل من موقع جغرافي واحد».

إذا كانت خلفيتك في DevOps، فأنت تعرف هذين النوعين باسمين آخرين. تربطهما MDN بوضوح: البيانات الميدانية هي مراقبة المستخدم الحقيقي (RUM)، أي “the performance of a page from real users’ machines,” (ترجمة) «أداء الصفحة على أجهزة المستخدمين الحقيقيين»، حيث “the browsers of real users report back performance metrics experienced” (ترجمة) «ترسل متصفحات المستخدمين الحقيقيين مؤشرات الأداء التي اختبروها». أما بيانات المختبر فهي المراقبة الاصطناعية، أي “monitoring the performance of a page in a ‘laboratory’ environment” (ترجمة) «مراقبة أداء الصفحة في بيئة مختبرية»، عبر “deploying scripts to simulate the path an end user might take.” (ترجمة) «تشغيل نصوص برمجية لمحاكاة المسار الذي قد يسلكه المستخدم النهائي». الميدان = RUM، والمختبر = مراقبة اصطناعية؛ إنه التقسيم نفسه بمفردتين مختلفتين.

بعيدًا عن المصطلحات، هما نوعان مختلفان بنيويًا من الأدلة. البيانات الميدانية توزيع: مئات أو ملايين جلسات المستخدمين الحقيقيين تُجمع في مجتمع إحصائي تقرؤه عند مئين محدد. أما بيانات المختبر فهي ملاحظة واحدة مضبوطة الإعداد: توليفة جهاز وشبكة وموقع اختيرت عمدًا وشُغّلت مرة أو بضع مرات كي تكون قابلة للتكرار. لا يوجد نوع «أدق» في كل الأحوال؛ فالدليل المناسب يتوقف على السؤال، والمجتمع الذي تريد تمثيله، وكيف جُمعت الأرقام. تجيب البيانات الميدانية: «كيف كان أداء المستخدمين الحقيقيين فعلًا؟»، بينما تجيب بيانات المختبر: «ما الآلية التي تجعل هذه الصفحة بطيئة؟». وتؤيد صياغة Google ذلك مباشرة: بيانات المختبر والبيانات الميدانية كلتاهما جزء مهم من قياس الأداء الفعال، ولكل منهما نقاط قوة وحدود.

شرح البيانات الميدانية

في SEO تعني البيانات الميدانية مجموعة CrUX: “a public dataset of field data gathered from a segment of real Google Chrome users from millions of websites.” (ترجمة) «مجموعة عامة من بيانات ميدانية جُمعت من شريحة من مستخدمي Chrome الحقيقيين عبر ملايين المواقع». وتُجمع التجارب في توزيعات على مستوى الصفحة والنطاق.

آليات مهمة:

• الاشتراك اختياري والبيانات من Chrome فقط. يجمع CrUX البيانات فقط من مستخدمين فعّلوا إرسال إحصاءات الاستخدام ومزامنة سجل المتصفح، ولم يضعوا عبارة مرور للمزامنة، وعلى المنصات المدعومة. وتوضح منهجية CrUX أنه يستبعد Chrome على iOS وAndroid WebView ومتصفحات Chromium الأخرى مثل Microsoft Edge. لذلك قد لا يمثل إلا أقلية من جمهور يعتمد بكثافة على Safari أو Edge.
• المئينات، لا المتوسطات. تنص أفضل ممارسات Google للقياس الميداني على: “Whenever possible, rely on percentiles instead of averages,” (ترجمة) «اعتمد على المئينات بدل المتوسطات كلما أمكن»، لأن “percentiles across a distribution… better describe the full range of user experiences.” (ترجمة) «المئينات عبر التوزيع تصف النطاق الكامل لتجارب المستخدمين بصورة أفضل». وتحدد أيضًا: “To ensure you’re meeting the recommended Core Web Vitals thresholds, you’ll need your report to display the value of each metric at the 75th percentile.” (ترجمة) «للتأكد من استيفاء العتبات الموصى بها، يجب أن يعرض تقريرك قيمة كل مؤشر عند المئين 75». وهذا هو p75 الذي ستراه في كل مكان.
• نافذة 28 يومًا. بيانات Core Web Vitals المرتبطة بالترتيب تجميع متحرك على مدى 28 يومًا. وكما كتبت في دليل Ahrefs لـCore Web Vitals: “the CWV data is on a 28 day rolling average. Any changes you make won’t be seen in the CWV data for a while but will be reflected in lab test data after the changes are made.” (ترجمة) «تعتمد بيانات CWV متوسطًا متحركًا على 28 يومًا؛ لن تظهر تغييراتك فيها لبعض الوقت، لكنها ستظهر في بيانات الاختبار المختبري فور تنفيذها». وهذا التأخر هو سبب الحاجة إلى بيانات المختبر بوصفها حلقة ملاحظات سريعة.

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

• توزيعا مستوى الصفحة ومستوى النطاق مختلفان، ولكل منهما عتبات أهلية مختلفة. قد لا يجمع عنوان URL زيارات تكفي لظهوره منفردًا، بينما يجمع النطاق زيارات كافية. وتعرّف منهجية CrUX المستويين كلًا على حدة؛ فلا تعامل رقم النطاق كأنه رقم صفحة بعينها، ولا العكس.
• قد يجمع تطبيع URL صفحات تراها أنت مختلفة. يزيل CrUX سلاسل الاستعلام والأجزاء من معرّف الصفحة قبل التجميع، ولذلك قد تُدمج النسخ ذات المعلمات من عنوان URL في سجل واحد، وقد يجمع ذلك في حالات نادرة تجارب صفحات يتعامل معها تطبيقك كصفحات منفصلة.
• يُنسب محتوى iframe المضمن إلى الصفحة العليا ولا يظهر كسجل صفحة مستقل؛ فإذا كان iframe تابع لطرف ثالث بطيئًا، انعكس بطؤه في أرقام الصفحة التي تحتويه.
• قد تظل تغييرات المسار في تطبيق أحادي الصفحة منسوبة إلى العرض الأول. بسبب قيود القياس الأساسية في منصة الويب، لا يحصل الانتقال بين المسارات المدفوع بـJavaScript في تطبيق SPA دائمًا على سجل CrUX مستقل، بل قد يظل مدمجًا في التحميل الأول.
• البيانات المفقودة تعني «غير متاحة»، لا صفرًا ولا «جيدة». إذا لم تتجاوز الصفحة أو النطاق عتبة الشعبية والأهلية في CrUX، فالقراءة الصادقة هي «لا تتوفر لدينا بيانات ميدانية»، لا نتيجة ناجحة ولا تقدير مختبري يحل محلها؛ راجع ملاحظة الرجوع إلى مستوى النطاق أدناه.

البيانات الميدانية ليست مفهومًا مجردًا، بل مجموعة بيانات ضخمة تتجدد باستمرار. وفق ملاحظات إصدار CrUX، غطى إصدار مايو 2026، المنشور في 9 يونيو 2026، 18 445 974 منشأ ويب؛ حقق 55,9 % منها Core Web Vitals جيدة إجمالًا، و68,6 % نتائج جيدة في LCP، و81,3 % في CLS، و86,6 % في INP. وعدم اجتياز نحو نصف المناشئ يثبت أن بيانات الميدان والمختبر تختلف فعلًا على نطاق واسع.

شرح بيانات المختبر

في SEO تعني بيانات المختبر Lighthouse والأدوات المبنية عليه: قسم المختبر في PageSpeed Insights وWebPageTest ولوحة Performance في Chrome DevTools. يحمل Lighthouse الصفحة مرة في بيئة مضبوطة واتصال مخنوق ثم يبلغ بما حدث.

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

لكن Lighthouse ليس بديلًا للبيانات الميدانية. فهو “primarily a diagnostic tool listing potential issues” (ترجمة) «أداة تشخيص تسرد المشكلات المحتملة أساسًا»، والتوجيه أن نعطي مؤشرات Core Web Vitals الميدانية الأولوية دائمًا. Evidence for this claim Google Search uses real-user Core Web Vitals, while Lighthouse lab metrics and scores are diagnostic and can differ from field data. Scope: Google Search Core Web Vitals use and web.dev tooling guidance. Confidence: high · Verified: 2026-07-14 Google Search Central: Core Web Vitals web.dev: Core Web Vitals tools وقد كتبت في شرح PageSpeed Insights: “you can have a good score but still have a slow page that doesn’t pass CWV,” (ترجمة) «قد تحصل الصفحة على نتيجة جيدة وتظل بطيئة ولا تجتاز مؤشرات Core Web Vitals»، لأن الشبكة وحمل الخادم والتخزين المؤقت وجهاز المستخدم تؤثر في زمن التحميل.

لماذا تختلفان؟ الآليات

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

• التخزين المؤقت. يبدأ Lighthouse كل مرة بذاكرة تخزين مؤقت باردة. أما المستخدمون الحقيقيون فيشملون زوارًا عائدين لديهم ذاكرة دافئة، ولذلك قد تكون تجربتهم الفعلية أسرع من التحميل البارد في المختبر، أو أبطأ لأسباب لا يستطيع ذلك التحميل كشفها.
• الجغرافيا وتفاوت الشبكات. يعمل المختبر من موقع واحد وبملف خنق واحد، بينما يتوزع جمهورك الحقيقي على دول وشركات اتصال وأنواع اتصالات متعددة. وكما أوضحت في دليل Ahrefs لـCWV: “field data looks at real users, network conditions, devices, caching, etc. But lab data is consistently tested based on the same conditions to make the test results repeatable.” (ترجمة) «تراعي البيانات الميدانية المستخدمين الحقيقيين وظروف الشبكة والأجهزة والتخزين المؤقت وغيرها، بينما تُختبر بيانات المختبر باستمرار في الظروف نفسها كي تكون النتائج قابلة للتكرار».
• الجهاز. يقابل هاتفًا متوسط الفئة محاكى في المختبر كامل طيف العتاد الحقيقي، من الأجهزة الرائدة إلى هواتف Android الاقتصادية القديمة.
• الخنق مقابل الواقع. يحاكي ملف Lighthouse الافتراضي للهاتف اتصالًا بطيئًا، يقارب «4G البطيء»: نحو 1,6 Mbps وزمن ذهاب وإياب يقارب 150 ms، مع إبطاء CPU بنحو 4×، وفق تحليل DebugBear. وقد يكون ذلك أشد أو أخف كثيرًا من شبكة مستخدم حقيقي بعينه.
• توقيت التفاعل. ينتظر Lighthouse انتهاء التحميل ويقيس تحميلًا سلبيًا للصفحة، بينما يمرر المستخدمون الحقيقيون وينقرون ويتنقلون. ولهذا قد تقلل أدوات المختبر تقدير تغيرات التخطيط التي لا تحدث إلا بعد التفاعل. والقول إن INP «لا يمكن قياسه في المختبر» تبسيط مخل: تستطيع لوحة Performance في Chrome DevTools تسجيل قيمة INP محلية حين تعيد تفاعلًا يدويًا، وهو ما تفعله شاشة Live metrics. لكن المختبر لا يمنحك توزيعًا سكانيًا؛ فنقرة شخص واحد على زر مرة واحدة ليست توزيع المئين 75 لجمهورك الحقيقي، ولذلك لا يخبرك سجل INP محلي جيد بشيء عن تقييم CWV الميداني.

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

ما الأدوات التي تقدم كل نوع؟

تلخص وثائق PageSpeed Insights ذلك: “PSI provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics.” (ترجمة) «يوفر PSI بيانات مختبر وميدان. يفيد المختبر في التصحيح ضمن بيئة مضبوطة لكنه قد لا يلتقط اختناقات الواقع؛ ويفيد الميدان في التقاط تجربة المستخدم الحقيقية لكن بمؤشرات أقل».

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

ما الذي يعتمد عليه Google فعلًا في الترتيب؟

البيانات الميدانية عبر CrUX عند p75 على مدى 28 يومًا هي مجموعة البيانات وراء سؤال الترتيب، لا رقم المختبر. تقرير Core Web Vitals في Search Console ميداني فقط: فهو “shows how your pages perform, based on real world usage data (sometimes called field data),” (ترجمة) «يعرض أداء صفحاتك استنادًا إلى بيانات الاستخدام الواقعي، التي تسمى أحيانًا بيانات ميدانية»، كما أن “the data… comes from the CrUX report.” (ترجمة) «البيانات تأتي من تقرير CrUX». ويلزم ضبط ما يثبته ذلك وما لا يثبته: تقول Google إن Core Web Vitals تدخل أنظمة الترتيب وإن مصدر تقرير Search Console هو CrUX، لكن أيًا من المصدرين لا ينشر الآلية الداخلية الدقيقة لاستهلاك قيمة CrUX عامة بعينها كمدخل ترتيب لكل URL. لذلك فقول «CrUX هي البيانات الميدانية التي يرتب Google بناءً عليها» دقيق، أما قول «هذا الرقم العام نفسه هو مدخل الترتيب الداخلي حرفيًا» فيتجاوز ما تدعمه الوثائق. ومن المهم أيضًا أن تقرير Search Console يجمع عناوين URL ذات التجارب المتشابهة بدل أن يكون أداة بحث دقيقة لكل URL؛ وللتحقق من حالة عنوان محدد يكون PageSpeed Insights أداة أفضل.

حافظ ممثلو Google على هذا التمييز لسنوات. أوضح Martin Splitt عام 2020 أن البيانات الميدانية تأتي من مستخدمين حقيقيين، بينما تأتي بيانات المختبر من جهاز قوي واتصال إنترنت جيد، ولذلك قد لا تظهر النتائج نفسها. ووصف John Mueller العلاقة بالطريقة نفسها عام 2021: نتيجة المختبر تقريب في جوهره لما تعتقد أنظمة Google أنه قد يحدث في الميدان، ولذلك يمكنك استخدام بيانات المختبر للتحسين التدريجي، لكن لا تتوقع تطابقًا مباشرًا بينها وبين نتيجة الميدان. أما عن النتيجة نفسها، فكان Mueller واضحًا: لا يستخدم Google نتيجة Lighthouse من X/100 في البحث، بل يستخدم Core Web Vitals كلًا على حدة كما يراها المستخدمون، وهذا يتطلب أولًا قدرًا معينًا من الزيارات الحقيقية. مراجع المصادر: https://www.searchenginejournal.com/google-explains-why-field-data-is-more-reliable-than-lab-data/372404/ وhttps://www.searchenginejournal.com/countries-with-slow-internet-can-affect-core-web-vitals-scores/ وhttps://www.searchenginejournal.com/do-google-lighthouse-scores-affect-seo/425347/

تنبيهان مهمان:

• Core Web Vitals إشارة واحدة بين إشارات كثيرة. تنص وثائق Google عن تجربة الصفحة بوضوح على “There is no single signal,” (ترجمة) «لا توجد إشارة واحدة»، وأن “getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results.” (ترجمة) «الحصول على نتائج جيدة في تقارير مثل Core Web Vitals في Search Console أو أدوات الأطراف الثالثة لا يضمن تصدر صفحاتك نتائج بحث Google». اجتياز CWV شرط أساسي، لا صاروخًا يدفعك إلى القمة.
• CrUX ليست البيانات الميدانية الوحيدة، لكنها المرتبطة بالترتيب. تنتج أي أداة RUM، مثل Cloudflare Web Analytics وSpeedCurve وDebugBear وTreo، «بيانات ميدانية» بالمعنى العام، وقد تكون أدق تفصيلًا وأحدث من CrUX. لكن CrUX وحدها هي ما تستشيره أنظمة ترتيب Google. فلا تخلط بين «لدينا RUM» و«يمكننا رؤية ما يرتب Google بناء عليه». ولا تفترض أن الأداتين ستتفقان لمجرد أن كلتيهما «ميدانية»؛ فقد تختلف منظومة RUM خاصة عن CrUX بصورة مشروعة بسبب اختلاف المتصفحات وحالات الموافقة والأجهزة ومعدلات أخذ العينات والجلسات وتوقيت التقاط المؤشرات.
• نتيجة المختبر ليست تنبؤًا بالترتيب. تحسن رقم Lighthouse دليل على أنك أصلحت آلية، لا دليل على أن ترتيبك سيتحرك؛ فمجموعتا البيانات تقيسان شيئين مختلفين، والرقم الميداني وحده هو القريب من نقاش الترتيب.

لشرح LCP وINP وCLS وعتباتها وأدواتها، راجع مركز Core Web Vitals ومركز أدوات أداء الويب.

ماذا يفعل Bing، أو لا يفعل؟

لا ينشر Bing أي نظير عام لـCrUX. فلا توجد مجموعة بيانات ميدانية من مستخدمين حقيقيين تابعة لـBing يمكنك الاستعلام عنها، ولا إطار ترتيب «ميدان مقابل مختبر» مماثل لما توثقه Google وChrome وweb.dev. أداة Site Scan في Bing Webmaster Tools أداة زحف وتدقيق اصطناعية شبيهة بالمختبر، وليست منتج RUM. ويذكر Bing أن سرعة الصفحة تسهم في تجربة المستخدم بالمعنى العام، لكنه لا يشير إلى مجموعة بيانات شبيهة بـCrUX. لذلك تعامل مع إطار الميدان مقابل المختبر كله بوصفه مفهومًا خاصًا بمنظومة Google وChrome؛ يعمل Bing على Chromium داخليًا، لكنه لم يطرح مجموعة بيانات موازية أو موقفًا عامًا. وعندما تقرأ «بيانات ميدانية» في سياق SEO، فالمقصود Google.

استخدام النوعين عمليًا

ليسا متنافسين، بل خط عمل واحد:

1. اعثر على الصفحات الفاشلة بالبيانات الميدانية. ابدأ من تقرير Core Web Vitals في Search Console لرؤية الموقع كله، أو من القسم العلوي في PageSpeed Insights لعنوان URL واحد. يخبرك ذلك بموقعك بالنسبة إلى الترتيب.
2. شخّص بالبيانات المختبرية. شغّل Lighthouse أو قسم المختبر في PSI أو DevTools لمعرفة السبب، مثل مورد يمنع العرض أو صورة ضخمة أو تغير في التخطيط.
3. كرّر بسرعة في المختبر. لأن بيانات المختبر فورية وقابلة للتكرار، فهي حلقة الملاحظات أثناء تنفيذ التغييرات.
4. انتظر حتى تلحق البيانات الميدانية. تعني النافذة المتحركة البالغة 28 يومًا أن الإصلاح لن يظهر كاملًا في CWV وCrUX فورًا؛ وهذا طبيعي، وليس دليلًا على فشل الإصلاح.
5. أكد الأثر الواقعي ميدانيًا. أعد فحص Search Console أو قسم الميدان في PSI للتحقق من تحسن تجربة المستخدمين الحقيقيين فعلًا.

ضابطان يحافظان على صدق المسار:

• قارن المتماثل قبل أن تنسب الفضل إلى إصلاح أو تلومه. قبل قراءة تغير الرقم الميداني على أنه «تحرك»، تأكد من أنك تقارن المجتمع نفسه وفئة الجهاز نفسها والنافذة نفسها والمئين نفسه مع خط الأساس. فالانتقال من بيانات مستوى النطاق إلى مستوى الصفحة، أو تغير مزيج الأجهزة أو المئين، لا يعني نجاح الإصلاح أو فشله؛ بل يعني أنك تقيس شيئًا مختلفًا.
• لا تشخّص آلية من تشغيل مختبري واحد. حتى البيئة المضبوطة ليست قابلة للتكرار تمامًا؛ فقد تغير الشبكة وعتاد العميل وتنافس الموارد في الخلفية نتيجة تشغيل Lighthouse واحد. كرر الاختبار المختبري قبل أن تنسب أثر الإصلاح إلى سبب محدد.

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

خرافات ينبغي التخلص منها

• «نتيجة 100/100 في Lighthouse تعني أنني سأجتاز Core Web Vitals أو أحقق ترتيبًا جيدًا». لا؛ Lighthouse تحميل بارد محاكى واحد، بينما CWV بيانات ميدانية من مستخدمين حقيقيين عند p75 خلال 28 يومًا. كثيرًا ما تختلفان، والبيانات الميدانية وحدها تغذي الترتيب.
• «إذا لم تتطابق بيانات الميدان والمختبر فهناك خلل». لا؛ تصف Google الاختلاف بأنه طبيعي. لكل مجموعة نقاط قوة وحدود مقصودة.
• «نتيجة Performance في Lighthouse عامل ترتيب». لا؛ وفق Mueller يستخدم Google قيم Core Web Vitals الميدانية، لا نتيجة 0–100.
• «تُحدَّث بيانات CrUX فورًا، ولذلك لا يمكنني اختبار شيء لمدة 28 يومًا». الصياغة التي يمكن الدفاع عنها هي: استخدم بيانات المختبر للاختبار الفوري، وتعامل مع البيانات الميدانية كتأكيد واقعي متأخر. وقد تسمع ادعاءً أقوى في المجال بأن عمر بيانات CrUX يقارب يومين لا 28 يومًا؛ وهذه وجهة نظر معقولة يطرحها بعض العاملين في المجال، لكنها ليست صياغة Google الرسمية، فتعامل معها بحذر.
• «إذا لم تحصل الصفحة على زيارات، يقدّر Google مؤشرات CWV من صفحات مشابهة أو من بيانات المختبر». لا؛ يرجع PSI إلى البيانات الميدانية على مستوى النطاق، وإذا لم تكفِ هي أيضًا فلن يعرض أي بيانات لمستخدمين حقيقيين. ولا يوجد إحلال لبيانات المختبر في نظام الترتيب.
• «لدى Bing نظير لـCrUX، لكنه أقل شهرة». لا؛ لا توجد مجموعة بيانات عامة مماثلة لدى Bing.

أسئلة شائعة

هل يستخدم Google بيانات Lighthouse المختبرية للترتيب؟ لا؛ نتيجة Lighthouse ليست مدخل ترتيب، بل يستخدم Google بيانات Core Web Vitals الميدانية من CrUX.

لماذا تبدو نتيجة PageSpeed/Lighthouse رائعة بينما يعرض Search Console «ضعيف»؟ لأنهما مجموعتان مختلفتان: تحميل مختبري بارد محاكى مقابل توزيع مستخدمين حقيقيين عند p75 خلال 28 يومًا.

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

هل CrUX المصدر الوحيد للبيانات الميدانية؟ لا؛ كل أداة RUM تنتجها عمومًا، لكن CrUX هو المصدر الذي تستخدمه أنظمة ترتيب Google.

هل لدى Bing نسخة من CrUX؟ لا يوجد نظير عام وقت الكتابة.

هل أحسّن أداء المختبر أم الأداء الميداني؟ استخدم بيانات المختبر للاختبارات السريعة القابلة للتكرار أثناء تنفيذ التغييرات، ثم أكد الأثر الواقعي وكل ما يرتبط بالترتيب بالبيانات الميدانية، فهي ما يقيس Google بناء عليه.

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

خلاصة موجزة للنسخة المتقدمة:

• نوعان من الأدلة، لا نتيجتان متنافستان. البيانات الميدانية توزيع لقياسات مستخدمين حقيقيين (RUM)، ويمثلها في SEO CrUX مجمعة عند المئين 75 خلال نافذة متحركة من 28 يومًا. أما بيانات المختبر فهي ملاحظة اصطناعية واحدة مضبوطة الإعداد عبر Lighthouse، أي أداة تشخيص لا مدخل ترتيب. ولا يوجد نوع «أدق» دائمًا؛ فالاختيار يتوقف على السؤال.
• RUM مقابل المراقبة الاصطناعية هو التقسيم نفسه بمصطلحات DevOps: الميدان = RUM، والمختبر = مراقبة اصطناعية، وفق MDN.
• أسباب الاختلاف: التخزين المؤقت، أي تحميل مختبري بارد مقابل ذاكرة حقيقية دافئة؛ والجغرافيا؛ وتفاوت الأجهزة والشبكات؛ وملفات الخنق، حيث يقارب Lighthouse اتصال 4G بطيئًا مع إبطاء CPU بنحو 4×؛ وتوقيت التفاعل. ويحتاج INP إلى دقة: يمكن لأداة مختبر مشاهدة تفاعل واحد تعيده يدويًا، لكن ذلك ليس مجتمعًا ميدانيًا. وتتعامل Google مع الاختلاف بوصفه طبيعيًا.
• حالات السكان والتجميع: مستوى الصفحة ومستوى النطاق درجتا أهلية مختلفتان؛ يزيل CrUX سلاسل الاستعلام والأجزاء وقد يجمع نسخ URL؛ وينسب iframe إلى الصفحة العليا؛ وقد تبقى انتقالات SPA منسوبة إلى التحميل الأول؛ والبيانات المفقودة غير متاحة، وليست صفرًا ولا «جيدة».
• ما يعتمد عليه Google: بيانات Core Web Vitals الميدانية عند p75 خلال 28 يومًا، لا نتيجة Lighthouse من 0 إلى 100. وCWV إشارة واحدة بين إشارات كثيرة؛ لا تضمن النتيجة الجيدة الصدارة، ولا توثق Google أو Search Console الآلية الداخلية الدقيقة لمسار CrUX إلى ترتيب كل URL. لذلك فقول إن CrUX هي مجموعة البيانات الميدانية التي تغذي الترتيب دقيق، لا القول إن رقمًا عامًا بعينه هو مدخل الترتيب حرفيًا.
• الرجوع إلى النطاق: إذا افتقر URL إلى عينات CrUX، يعرض PSI بيانات مستوى النطاق؛ وإذا لم تكفِ أيضًا فلن يعرض بيانات ميدانية. ولا تحل بيانات المختبر محلها.
• Bing: لا يوجد نظير عام لـCrUX؛ فهذا إطار خاص بمنظومة Google وChrome.
• مسار العمل: Search Console للعثور على الصفحات الفاشلة، مع تذكر أنه يجمع عناوين URL المتشابهة ولا يبحث بدقة عن كل URL → Lighthouse أو مختبر PSI للتشخيص، مع تكرار التشغيل قبل الثقة بالسبب → تكرار سريع في المختبر → انتظار نحو 28 يومًا → تأكيد ميداني على المجتمع والنافذة نفسيهما. المختبر للاختبار، والميدان للترتيب.

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

وثائق المصادر الأولية عن بيانات الميدان والمختبر.

Google

• لماذا قد تختلف بيانات المختبر والميدان — التعريفات والأسباب وأولوية الميدان.
• أدوات Core Web Vitals الميدانية والمختبرية — CrUX مصدر الميدان وLighthouse ليس بديلًا له.
• أفضل ممارسات قياس Web Vitals ميدانيًا — المئينات وعتبة p75.
• حول PageSpeed Insights v5 — قسما المختبر والميدان والرجوع للنطاق.
• فهم تجربة الصفحة في نتائج Google — لا توجد إشارة واحدة ولا تضمن النتائج الجيدة الترتيب.
• تقرير Core Web Vitals في Search Console — تقرير ميداني مصدره CrUX.
• منهجية Chrome UX Report وملاحظات الإصدار.

MDN: مصطلحات عابرة للمنظومات

• RUM مقابل المراقبة الاصطناعية — اسما الميدان والمختبر في DevOps.

Bing / Microsoft

• لا ينشر Bing نظيرًا لـCrUX أو إطار ترتيب للميدان والمختبر. تتعامل إرشاداته مع السرعة ضمن تجربة المستخدم بلا مجموعة مستخدمين حقيقية عامة؛ راجع مساعدة Bing Webmaster Tools.

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

تصريحات مسجلة من Google وممثليه، مع روابط عميقة إلى المقاطع المقتبسة.

Google — التعريفان

• “Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” (ترجمة) «تُحدد البيانات الميدانية بمراقبة جميع مستخدمي الصفحة وقياس مؤشرات الأداء لكل تجربة فردية». — web.dev. الانتقال إلى الاقتباس
• “Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” (ترجمة) «تُحدد بيانات المختبر بتحميل الصفحة في بيئة مضبوطة بشروط شبكة وجهاز محددة مسبقًا». الانتقال إلى الاقتباس

Google — ما الذي يقدم، ولماذا يختلفان

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (ترجمة) «إذا توفر النوعان للصفحة، فاستخدم البيانات الميدانية لترتيب أولويات جهودك». الانتقال إلى الاقتباس
• “PSI provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics.” (ترجمة) «يوفر PSI النوعين؛ يفيد المختبر في التصحيح لكنه قد لا يلتقط اختناقات الواقع، ويفيد الميدان في التجربة الحقيقية لكن بمؤشرات أقل». — About PageSpeed Insights. الانتقال إلى الاقتباس

Google — الميدان هو ما يستخدمه Search Console والترتيب

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (ترجمة) «يعرض تقرير Core Web Vitals أداء صفحاتك بناءً على بيانات الاستخدام الحقيقي، وتسمى أحيانًا بيانات ميدانية». — Search Console Help. الانتقال إلى الاقتباس
• “There is no single signal.” (ترجمة) «لا توجد إشارة واحدة». — وثائق تجربة الصفحة. الانتقال إلى الاقتباس

Google — قياس الميدان عند المئين 75

• “Whenever possible, rely on percentiles instead of averages. Percentiles across a distribution for a given performance metric better describe the full range of user experiences.” (ترجمة) «اعتمد المئينات بدل المتوسطات متى أمكن، فهي تصف كامل نطاق تجارب المستخدمين أفضل». — web.dev. الانتقال إلى الاقتباس

Martin Splitt، Google (عبر Search Engine Journal، يونيو 2020)

• “Field data is coming from real users, whereas lab data comes from a quite strong machine with probably good internet from somewhere around the world. So you might not see the same results.” (ترجمة) «تأتي بيانات الميدان من مستخدمين حقيقيين، والمختبر من جهاز قوي واتصال جيد؛ لذلك قد لا ترى النتائج نفسها». قراءة التغطية

John Mueller، Google (عبر Search Engine Journal)

• “One of the things that generally happens with the lab versus field data is that with the lab data it’s basically an assumption. It’s an approximation of what our systems think might happen in the field.” (ترجمة) «بيانات المختبر افتراض في الأساس؛ فهي تقريب لما تعتقد أنظمتنا أنه قد يحدث ميدانيًا». قراءة التغطية
• “Google doesn’t use the X/100 lighthouse score for search, we use the core web vitals separately (lcp, cls, fid)… Google uses the values as users see them, which requires a certain amount of traffic first.” (ترجمة) «لا يستخدم Google نتيجة Lighthouse من 100 في البحث؛ بل يستخدم Core Web Vitals منفصلة كما يراها المستخدمون، وهذا يتطلب قدرًا من الزيارات أولًا». (حُفظت حالة أحرف lighthouse ومؤشر FID القديم كما وردا.) قراءة التغطية

أي مجموعة بيانات أنظر إليها؟

مسار سريع للسؤال الذي يربك الناس فعلًا.

البداية: ما الذي أحاول فعله؟

• «معرفة هل أجتاز متطلبات الترتيب وSEO». → الميدان. للموقع: تقرير Core Web Vitals في Search Console؛ ولـURL واحد: أعلى PSI. لا بيانات؟ لم تكف الزيارات، ولا يجوز تقييم إشارة الترتيب بنتيجة المختبر.

• «معرفة سبب بطء الصفحة وما يجب إصلاحه». → المختبر. شغّل Lighthouse أو قسم PSI السفلي أو Performance في DevTools.

• «أجريت تغييرًا؛ هل ساعد؟» → المختبر أولًا لملاحظات فورية، ثم الميدان للتأكيد مع توقع تأخر يقارب 28 يومًا.

• «اختبار صفحة خلف تسجيل دخول». → المختبر فقط عبر Lighthouse في DevTools؛ لا يرى CrUX وPSI العام عناوين URL الخاصة.

• «فحص أداء منافس لدى المستخدمين». → الميدان عبر PSI لأي URL عام لديه عينات CrUX كافية.

القاعدة: الميدان للتقييم والترتيب، والمختبر للتشخيص والتكرار السريع. وعند الاختلاف يعتمد SEO على الميدان. راجع أيضًا تقرير Core Web Vitals في Search Console.

ورقة مرجعية: الميدان مقابل المختبر

الفرق الأساسي

الأدوات

• الميدان: CrUX، أعلى PSI، تقرير Search Console، لوحة CrUX في DevTools.
• المختبر: Lighthouse، أسفل PSI، WebPageTest، لوحة Performance.

حقائق سريعة

• يعتمد Google على CrUX عند p75/28 يومًا، لا نتيجة المختبر من 100.
• قد تنجح الصفحة مختبريًا وتفشل ميدانيًا؛ هذا طبيعي.
• عند غياب بيانات URL يرجع PSI للنطاق، ثم يعرض لا شيء إن لم تكف.
• CrUX خاص بمستخدمي Chrome الموافقين، ولا يشمل iOS Chrome أو WebView أو Edge/Safari/Firefox.
• لا يملك Bing نظيرًا عامًا لـCrUX.
• القاعدة: المختبر للتصحيح، والميدان للتأكيد والترتيب.

تفشل البيانات الميدانية بينما ينجح المختبر

1. أكد مجموعتي البيانات. سجل نطاق CrUX وفئة الجهاز والنافذة البالغة 28 يومًا والمؤشر، إلى جانب ملف الجهاز والشبكة في المختبر. وإذا كانت إحدى النتيجتين رجوعًا إلى مستوى النطاق أو كانت لمؤشر مختلف، فصحح المقارنة أولًا.
2. حدد الشريحة الميدانية المتأثرة. افصل الهاتف عن سطح المكتب وافحص مجموعات URL أو القوالب. وإذا لم تظهر المشكلة إلا على مستوى النطاق، فاختبر عينات من القوالب البطيئة بدل ضبط الصفحة الناجحة.
3. أعد إنتاج ظروف واقعية. أعد الاختبار المختبري بجهاز وشبكة أبطأ، وبحالتَي التخزين المؤقت البارد والدافئ، وبحالة الصفحة نفسها التي يراها المستخدم الحقيقي. إذا ظهرت المشكلة فاستخدم سجل التتبّع لتحديد عنق الزجاجة، وإن لم تظهر فواصل التحقيق.
4. استخدم RUM من الطرف الأول متى توفر. جزّئ البيانات حسب الجغرافيا والجهاز والمتصفح والقالب ونوع التنقل. وإذا اختلفت زيارات المتصفحات غير Chrome، فسجّل ذلك فجوة في تمثيل الجمهور، لا خطأ في CrUX.
5. انشر إصلاحًا واحدًا يمكن إسناد أثره إليه. تحقق من الآلية فورًا في المختبر وراقب RUM لرصد الحركة المبكرة. وإذا تراجعت مؤشرات CWV المجاورة، فتراجع عن التغيير أو عدّله.
6. انتظر حكم الميدان. CrUX تجميع متحرك على مدى 28 يومًا؛ فقارن نوافذ متماثلة مع خروج الزيارات القديمة تدريجيًا. ولا تعلن فشل الإصلاح في اليوم الأول.

ما الذي لا ينبغي فعله؟

أخطاء متكررة تنشأ من خلط مجموعتي البيانات:

• مطاردة نتيجة 100/100 في Lighthouse واعتبار المهمة منتهية. نتيجة المختبر ليست إشارة الترتيب، وقد تجاور جولة مختبر مثالية تقييمًا ميدانيًا فاشلًا. وتحذر وثائق Google لتجربة الصفحة من أن السعي إلى نتيجة مثالية لأسباب SEO وحدها قد لا يكون أفضل استخدام لوقتك.
• اعتبار اختلاف الميدان والمختبر خللًا يجب «إصلاحه». الاختلاف متوقع؛ فكل مجموعة تُقاس عمدًا بطريقة مختلفة، ولذلك يكون التباين حالة طبيعية لا خطأ.
• الحكم على إشارة ترتيبك من صفحة بلا بيانات ميدانية. إذا لم يعرض PSI أو Search Console بيانات CrUX، فلن تخبرك نتيجة المختبر بشيء عن وضعك في ترتيب CWV. فلا تحل رقم المختبر محل الرقم الميداني المفقود.
• توقع ظهور الإصلاح فورًا في البيانات الميدانية. تعني النافذة المتحركة البالغة 28 يومًا أن بيانات المستخدمين الحقيقيين تتأخر. اختبر الإصلاح مختبريًا للحصول على ملاحظات فورية، وامنح البيانات الميدانية وقتها.
• افتراض أن بيانات أي أداة RUM هي ما يرتب Google بناءً عليه. تنتج Cloudflare وSpeedCurve وDebugBear وTreo كلها بيانات ميدانية، لكن CrUX وحدها تغذي أنظمة ترتيب Google. ولا تضمن أرقام RUM الممتازة من طرف ثالث اجتياز تقييم CrUX.
• افتراض أن Bing يعمل مثل Google هنا. لا يوجد نظير لـCrUX لدى Bing؛ فلا تطبق عليه إطار الترتيب القائم على الميدان مقابل المختبر.
• التحسين لملف خنق مختبري واحد فقط. يستخدم جمهورك الحقيقي أجهزة وشبكات ومواقع متنوعة. وقد تنجح صفحة ضُبطت لاجتياز تشغيل محاكى واحد على 4G بطيء، ثم تفشل لدى جمهور حقيقي في ظروف أسوأ فعلًا أو مختلفة فحسب.

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

خمسة أسئلة سريعة عن مجموعتي البيانات وأيهما يعتمد عليه Google في الترتيب. اختر إجابة ثم تحقق.

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

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

• ما Core Web Vitals وكيف تحسنها؟ — الفرق بين الميدان والمختبر ونافذة 28 يومًا وموضع CrUX.
• Google PageSpeed Insights لمحترفي SEO والمطورين — فصل PSI بين CrUX وLighthouse ولماذا قد تظل الصفحة بطيئة رغم النتيجة الجيدة.
• دليل المبتدئ إلى SEO التقني — موضع قياس الأداء في الصورة الأوسع.

محاضراتي

• كيف يعمل البحث — شرح الزحف والعرض والفهرسة والترتيب وموضع تجربة الصفحة. وينطبق تنبيهي المعتاد: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة، ولن يكون كاملًا أو دقيقًا بنسبة 100 %».

رسمي

• لماذا قد تختلف بيانات المختبر والميدان وأدوات Core Web Vitals.
• حول PageSpeed Insights وتقرير Core Web Vitals.
• منهجية CrUX وملاحظات الإصدار.

من مصادر المجال

• لماذا تعد البيانات الميدانية أوثق من المختبر — Martin Splitt.
• أثر الإنترنت البطيء في Core Web Vitals — Mueller عن المختبر كتقريب.
• هل تؤثر نتائج Lighthouse في SEO؟ — لا يستخدم Google نتيجة X/100.
• لماذا لا تطابق بيانات Lighthouse المختبرية الميدان؟ — أرقام الخنق والآليات.
• البيانات الميدانية والمختبرية: الفرق والاستخدام — مقارنة عملية.
• RUM مقابل المراقبة الاصطناعية — مصطلحات MDN.
• r/TechSEO — مجتمع Core Web Vitals وتصحيح الأداء.

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