تقرير مؤشرات أداء الويب الأساسية (Google Search Console)

الخلاصة — يوضح تقرير مؤشرات أداء الويب الأساسية في Google Search Console أداء صفحاتك لدى الزوار الحقيقيين وفق مقاييس Google الثلاثة للسرعة والثبات: LCP وINP وCLS. وهي بيانات واقعية من مستخدمي Chrome، مجمعة في حزم من الصفحات المتشابهة ومقسمة إلى تبويبي Mobile وDesktop. التقرير أداة فرز على مستوى الموقع، لا مدقق سرعة صفحة بصفحة؛ وقد لا يعرض أي بيانات أصلًا إذا كان موقعك صغيرًا أو جديدًا.

ما تقرير مؤشرات أداء الويب الأساسية؟

ستجده في Google Search Console ضمن قسم Experience. ويصفه Google في جملة واحدة بأنه “shows how your pages perform, based on real world usage data (sometimes called field data).” (الترجمة العربية) «يعرض أداء صفحاتك استنادًا إلى بيانات الاستخدام الفعلية، التي تسمى أحيانًا بيانات ميدانية».

أهم ما ينبغي توضيحه منذ البداية: هذا تقرير، وليس المقاييس نفسها. مؤشرات أداء الويب الأساسية، أي LCP وINP وCLS، ثلاثة قياسات لشعور الزائر الحقيقي تجاه الصفحة: سرعة تحميل المحتوى الرئيسي، وسرعة استجابة الصفحة للمس، ومقدار تحرك العناصر أثناء التحميل. تُشرح هذه المقاييس بالتفصيل في مواضع أخرى من الموقع. أما هذه المقالة فتتناول التقرير: الأداة الموجودة في Search Console التي تعرض تلك الأرقام وتنظمها.

من أين تأتي البيانات؟

لا يشغّل التقرير اختبار سرعة، بل يسحب بيانات ميدانية من Chrome User Experience Report ‏(CrUX): أزمنة مجهولة الهوية من مستخدمي Chrome الفعليين الذين زاروا صفحاتك. وهذا يختلف عن اختبار مختبري مثل PageSpeed Insights، الذي يحمّل صفحتك مرة واحدة في بيئة مضبوطة. تسجل البيانات الميدانية ما حدث فعلًا لأشخاص حقيقيين، ويُحسب متوسطها خلال آخر 28 يومًا.

كيف يُنظم التقرير؟

هناك ثلاثة أمور ينبغي معرفتها عن طريقة تجميع عناوين URL:

• Mobile وDesktop تبويبان منفصلان. قد تكون الصفحة Good على الجوال وPoor على سطح المكتب في الوقت نفسه، ولا يُحسب لهما متوسط مشترك مطلقًا.
• ثلاث فئات للحالة: Poor وNeed improvement وGood. تحدد أسوأ قيمة حالة URL؛ فقيمة واحدة سيئة تخفض حالة الصفحة كلها.
• تُجمع عناوين URL ولا تُقيّم واحدًا تلو الآخر. يضع Google الصفحات المتشابهة، وغالبًا التي تستخدم قالب الصفحة نفسه، في حزمة واحدة؛ لذلك سترى كثيرًا مشكلة واحدة تؤثر في دفعة كاملة من العناوين.

أكثر ما يسيء الناس فهمه

لا يستطيع هذا التقرير أن يخبرك بثقة إن كانت صفحة بعينها بطيئة. يقول Google بوضوح إنه “not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” (الترجمة العربية) «لم يُصمم لمعرفة حالة URL محدد، بل لرؤية أداء الموقع ككل». الغرض منه اكتشاف المشكلات العامة على مستوى الموقع أو القالب. لفحص صفحة واحدة استخدم PageSpeed Insights أو أداة URL Inspection بدلًا منه.

ثمة أمران آخران يجدر معرفتهما مبكرًا:

• ظهور «No data available» شائع، ولا يعني عادةً أن هناك مشكلة في صفحاتك. يعني أحد أمرين: أن الموقع جديد تمامًا في Search Console، أو أن زيارات Chrome غير كافية لنوع الجهاز الذي تعرضه، سواء الجوال أو سطح المكتب، لتجاوز عتبة Google الخاصة بالتقرير.
• يتأخر التقرير نحو شهر. لأنه متوسط 28 يومًا، لن يظهر الإصلاح الذي تنشره اليوم كاملًا قبل مرور أسابيع. استخدم PageSpeed Insights للحصول على ملاحظات أسرع.

هل تريد الآليات الكاملة: كيف يعمل تجميع عناوين URL، ولماذا لا يطابق PageSpeed Insights، ومسار التحقق، وما الذي حدث لـFID؟ انتقل إلى تبويب Advanced.

الخلاصة — يعرض تقرير مؤشرات أداء الويب الأساسية بيانات CrUX الميدانية ضمن نافذة متحركة من 28 يومًا وعند المئين 75 لعناوين URL المفهرسة، ولا يحسب شيئًا جديدًا. يجمع العناوين حسب الجهاز في تبويبي Mobile وDesktop مستقلين، وحسب الحالة Poor وNeed improvement وGood حيث تفوز أسوأ قيمة، وحسب URL group، أي مجموعات من صفحات ذات قوالب متشابهة تتشارك حالة واحدة. لا تظهر إلا العناوين المفهرسة، ويعرض التقرير عينة لا كل URL. عندما لا تجمع مجموعة URL بيانات كافية لعرضها مع الحفاظ على خصوصية المستخدمين، يرجع Google إلى origin group أعلى مستوى؛ وإذا لم تجمع حتى تلك المجموعة بيانات تتجاوز العتبة، يظهر «No data available». لن يطابق PageSpeed Insights لأن الأول يعرض المجموعة والثاني URL منفردًا، ولأن GSC يبقي معاملات URL مميزة بينما يزيلها PSI. الغرض منه الفرز على مستوى الموقع لا فحص URL منفرد. أزيل FID في 12 مارس 2024 عندما أصبح INP أحد مؤشرات الأداء الأساسية؛ حذفته GSC فورًا، بينما أبقاه PSI وCrUX طوال فترة انتقالية مدتها ستة أشهر قبل إيقافه نهائيًا. أصلح Poor أولًا، وتحقق عبر Start Tracking، وتوقع أن تلحق البيانات الميدانية بعد نحو شهر.

إنه تقرير لا إعادة تعريف للمقاييس

الإطار الأكثر فائدة لهذه المقالة هو أن تقرير مؤشرات أداء الويب الأساسية نافذة على بيانات موجودة أصلًا، وليس قياسًا جديدًا. يوضح Google أن “the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (الترجمة العربية) «تأتي بيانات تقرير مؤشرات أداء الويب الأساسية من تقرير CrUX، الذي يجمع مقاييس مجهولة الهوية عن أزمنة الأداء من مستخدمين فعليين يزورون URL، وتجمع قاعدة CrUX معلومات عن العناوين سواء كانت جزءًا من موقع في Search Console أم لا».

لذلك يحتوي التقرير على صفر من البيانات المختبرية: لا درجات Lighthouse ولا اختبارات اصطناعية. إنه بيانات ميدانية بنسبة 100% من مستخدمي Chrome الحقيقيين، ضمن نافذة متحركة من 28 يومًا، ومقيسة عند المئين 75، ومقسمة حسب الجهاز. ستجد تعريفات المقاييس وعتباتها ووزنها كإشارة ترتيب في مسرد Core Web Vitals وموضوع web-vitals؛ ولن أعيد شرحها هنا. فهذا القسم عن الأداة.

عناوين URL المفهرسة فقط، وعينة فقط

يفوت الناس ثلاث قواعد للنطاق. أولًا، والأهم: لا تظهر مجموعة URL حتى تتجاوز عتبة البيانات لكل من LCP وCLS معًا؛ وإذا لم تتوافر بيانات تقرير كافية لكليهما، تُحذف المجموعة من التقرير تمامًا ولا تُسجل ناجحة. ثانيًا: “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (الترجمة العربية) «لا تظهر في التقرير إلا عناوين URL المفهرسة. وليس التقرير قائمة شاملة لكل العناوين المفهرسة، بل يعرض عينة من الصفحات لمساعدتك في تقييم أداء الموقع». فلا تقرأه كتدقيق شامل. ثالثًا، وهو تفصيل يربك المعتادين على تقارير GSC الأخرى: “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (الترجمة العربية) «تُنسب البيانات إلى URL الفعلي، لا URL الأساسي كما في معظم التقارير الأخرى». تجمع أغلب تقارير Search Console البيانات عند canonical؛ أما هذا فلا يفعل.

Mobile وDesktop مجموعتا بيانات مستقلتان

يقسم التقرير كل شيء حسب الجهاز، والتبويبان منفصلان تمامًا ولا يُحسب متوسطهما. قد تكون مجموعة URL ‏Good على الجوال وNeed improvement على سطح المكتب في آن واحد، لأنهما مجموعتا CrUX مختلفتان تمثلان أجهزة وشبكات وفئات معالجات مختلفة. افحص التبويبين دائمًا؛ فقد يخفي ملخص Good في أحدهما فئة Poor في الآخر.

الحالة: تفوز أسوأ قيمة

تقع كل مجموعة URL في إحدى ثلاث فئات: Poor أوNeed improvement أوGood، وحالة المجموعة هي حالة أسوأ مقاييسها أداءً. فالمجموعة ذات LCP جيد وINP جيد وCLS ضعيف تصبح Poor. تفسر قاعدة «تفوز أسوأ قيمة» كيف يمكن لعنصر تخطيط واحد غير مستقر أن يدفع قالبًا سريعًا في سائر الجوانب إلى فئة Poor.

العتبات الأساسية هي LCP ‏≤ 2,5s وINP ‏≤ 200ms وCLS ‏≤ 0,1 لحالة Good، وكلها عند p75. وهذه تعريفات المقاييس المشروحة في مسرد Core Web Vitals. ومن الجدير بالذكر أن وثائق Search Central الحية عند بحثي ما زالت تسرد هذه الأرقام الأصلية. إذا رأيت ادعاء بأن Google خفض سرًا عتبة LCP الجيدة إلى ثانيتين، أو أن تحديثًا أساسيًا في أواخر 2025 جعل Core Web Vitals عامل ترتيب أكبر كثيرًا، فلم أستطع التحقق من أي منهما في مصدر مملوك لـGoogle، والوثائق تناقضهما. عاملهما كشائعة.

مجموعات URL: الآلية الأساسية

هذه السمة المميزة للتقرير، وأكبر تحول في النموذج الذهني لمن اعتاد فحص URL منفردًا في PageSpeed Insights. يقول Google: “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (الترجمة العربية) «تُجمع عناوين URL في التقرير ضمن صفحات تقدم تجربة مستخدم متشابهة، وتنطبق حالة LCP وINP وCLS على المجموعة كلها. قد تكون لبعض العناوين الشاذة قيم أفضل أو أسوأ في بعض الزيارات، لكن 75% من زيارات كل عناوين المجموعة شهدت الحالة المعروضة».

وصف John Mueller الآلية في 2021: “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (الترجمة العربية) «نفعل ذلك ببيانات Chrome User Experience Report، أي بيانات العالم الحقيقي الميدانية، حيث نحاول معرفة الصفحات المتشابهة بما يكفي لنجمعها». والأهم أن بيانات المجموعة يمكن أن تحل محل بيانات URL لا يملك بيانات خاصة: “If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.” (الترجمة العربية) «إذا وجدنا URL جديدًا ينتمي إلى المجموعة، فلا نحتاج إلى بيانات خاصة به؛ يمكننا الاعتماد على بيانات المجموعة ككل».

ولهذا قد يبدو التقرير مقلقًا عندما تكون المشكلة في الواقع خللًا واحدًا. يقول Mueller أيضًا: “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (الترجمة العربية) «قد تكون لدينا مجموعة واحدة للموقع لكنها تحتوي آلاف عناوين URL، ولذلك سيعرض تقرير Search Console أن آلاف العناوين تعاني المشكلة». خلل واحد في قالب واحد، وآلاف العناوين الموسومة.

وهذا بالضبط ما يجعل التجميع مفيدًا لا مزعجًا. كتبت في دليل Ahrefs لمؤشرات أداء الويب الأساسية: “This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” (الترجمة العربية) «تجميع الصفحات منطقي جدًا لأن معظم تحسينات Core Web Vitals تُجرى على قالب صفحة محدد يؤثر في صفحات كثيرة». وفي دليل PageSpeed Insights: “The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” (الترجمة العربية) «فائدة GSC أنها تجمع العناوين المتشابهة، وغالبًا ستعمل مع الصفحات المجموعة في نظام أو قالب واحد». أصلح القالب مرة فتصلح المجموعة كلها. وكما صغتها في مقابلة مع Outside Communications: “Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.” (الترجمة العربية) «هذه مجموعات ذات مشكلات تتشارك على الأرجح القالب نفسه؛ تصلحها مرة فتصلح المشكلة في كل تلك الصفحات».

عتبة الخصوصية وآلية الرجوع إلى مجموعة الأصل

ليس التجميع وسيلة راحة فقط، بل شرط للخصوصية. يقول Google: “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (الترجمة العربية) «احترامًا لخصوصية المستخدم، يجب أن تملك مجموعة URL حدًا أدنى من البيانات كي تظهر. وإذا لم تكن المعلومات كافية، ينشئ Search Console مجموعة أصل أعلى مستوى يُفترض أن تحتوي عناوين وبيانات كافية». إذن التسلسل هو: URL group ← origin group ← لا شيء. وعندما لا يتجاوز الأصل نفسه العتبة يظهر «No data available». وهذا هو السبب التقني لظهور تجميعات واسعة النطاق وقليلة الدقة، أو لغياب البيانات تمامًا، في المواقع قليلة الزيارات.

لماذا قد تضم مجموعة Poor صفحات سريعة؟

لأن الحالة تنطبق على المجموعة كلها عند المئين 75، قد ينجرف URL سريع منفرد إلى مجموعة بطيئة. الانتماء إلى Poor لا يثبت أن ذلك العنوان بطيء؛ بل يعني أن المجموعة ككل تعاني مشكلة. لا تفترض ذنب كل عضو، فالمجموعة هي وحدة التحليل.

قراءة التقرير: المخطط مقابل الجدول

هذه نقطة مربكة فعلًا وتتجاوزها أغلب الأدلة الخارجية. يعد مخطط البداية وجدول المشكلات بطريقة مختلفة: “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (الترجمة العربية) «يعد المخطط كل URL مرة واحدة فقط وفق أبطأ مشكلة تؤثر فيه، بينما يعد الجدول كل مشكلة مرتبطة به». لذلك يظهر URL له مشكلة Poor وأخرى Need improvement مرة واحدة في المخطط بوصفه Poor، لكنه يظهر في صفي الجدول معًا. لهذا لا تتطابق المجاميع؛ إنه تصميم مقصود لا خطأ. ويمنحك النقر على مشكلة، كما أصفه، “gives you a breakdown of page groups that are impacted” (الترجمة العربية) «تفصيلًا لمجموعات الصفحات المتأثرة»، مع عناوين مثال مرتبة حسب مرات الظهور.

التحقق من الإصلاحات: مسار Start Tracking

للتقرير حلقة تحقق مدمجة يسهل إغفالها. يقول Google: “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (الترجمة العربية) «عندما تعتقد أنك أصلحت مشكلة محددة، انقر Start Tracking في صفحة تفاصيل المشكلة». يبدأ ذلك جلسة مراقبة لمدة 28 يومًا؛ يراقب Google تراكم البيانات الميدانية للمجموعة طوال النافذة بدل إعادة فحصها فورًا. وهناك ثلاثة أمور ينبغي معرفتها: قد يمنع URL متأثر واحد ما زال يفشل اجتياز المشكلة كلها؛ حالات المشكلة هي Not started وStarted وLooking good وPassed وN/A وFailed، وحالات كل URL هي Pending وPassed وFailed؛ ولا يؤدي النقر على Start Tracking إلى إعادة الفهرسة أو أي زحف نشط، فهو مجرد علم مراقبة على بيانات يجمعها Google أصلًا. هذه الطريقة الصحيحة لتأكيد وصول الإصلاح إلى الميدان، لا مجرد التحديق في المخطط المجمع والأمل.

تقرير Core Web Vitals مقابل PageSpeed Insights

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

• المجموعة مقابل الفرد. يقول Google: “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (الترجمة العربية) «يجمع Core Web Vitals البيانات والحالة في مجموعات URL، بينما يعرض PageSpeed Insights عادةً بيانات عناوين منفردة». قد يكون URL واحد شاذًا في مجموعته، فلا تتطابق حالة المجموعة مع رقم PSI لذلك العنوان.
• معاملات URL. “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (الترجمة العربية) «يأخذ Core Web Vitals معاملات URL في الحسبان عند تمييز الصفحة، بينما يزيل PageSpeed Insights كل المعاملات وينسب النتائج إلى URL المجرد». وهذا يفسر وحده كثيرًا من شكاوى عدم اتفاق الأداتين.

وهناك فرق في اتساع البيانات ينبغي إبقاؤه واضحًا لأن مصطلحي البيانات الميدانية والمختبرية يُستخدمان بتساهل. تقرير GSC هو بيانات CrUX ميدانية مجمعة فقط ولا شيء غير ذلك. أما PageSpeed Insights فيجمع ثلاثة أشياء منفصلة: بيانات CrUX الميدانية على مستوى URL، والرجوع إلى بيانات CrUX على مستوى الأصل عندما لا يملك العنوان ما يكفي، وتشغيل Lighthouse مختبري حي. وكما أذكر في دليل PSI: “PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” (الترجمة العربية) «يسحب PageSpeed Insights أيضًا بيانات مستوى الصفحة والأصل وبيانات الاختبار المختبري الآتية من Lighthouse». لا توجد تلك الطبقة المختبرية في تقرير GSC؛ إنه ميداني فقط.

مساري الفعلي، والنصيحة العملية التي تفوت معظم المقالات المنافسة: شخّص المشكلة وتحقق منها سريعًا ببيانات PSI المختبرية، ثم انتظر التأكيد الميداني الأبطأ في GSC. كتبت في دليل PSI: “The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” (الترجمة العربية) «ستستغرق بيانات CWV وقتًا أطول لإظهار أثر التغييرات لأنها متوسط 28 يومًا، لذا استخدم PSI أو بياناته في Ahrefs للتحقق من تحسن مقاييس الاختبار المختبري». تحصل فورًا على دليل مختبري بأن التغيير ساعد، ثم تنتظر لحاق بيانات GSC الميدانية خلال الأسابيع التالية.

«No data available» والمواقع قليلة الزيارات

يفسر Google ذلك هكذا: “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (الترجمة العربية) «إذا ظهرت شاشة لا تتوفر بيانات، فإما أن الموقع جديد في Search Console، أو لا توجد بيانات كافية في CrUX لتقديم معلومات ذات معنى لنوع الجهاز المختار». لدى CrUX عتبة أهلية؛ يحتاج URL أو الأصل إلى زيارات Chrome كافية قبل ظهور أي بيانات ميدانية.

ما مدى شيوع ذلك؟ شائع جدًا. في دراستي في يناير 2022 التي طابقت CrUX مع 43,66 مليون صفحة فريدة في Site Audit، “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (الترجمة العربية) «وجدنا أن 5,21 ملايين فقط، أي نحو 11,9%، امتلكت مقياسًا واحدًا على الأقل، وأن 93% منها، أو نحو 4,85 ملايين إجمالًا، امتلكت المقاييس الثلاثة». درست العينة بيانات CrUX الخام، وهي المصدر نفسه الذي يستخدمه تقرير GSC، لا GSC ذاته؛ والرقم من يناير 2022، فاعتبره مقياسًا للحجم لا نسبة حالية. تظل الفكرة أن معظم صفحات الويب لا تحصل على زيارات Chrome كافية لإنتاج بيانات ميدانية. لذلك يعتمد التقرير على تجميع الأصل ويرى كثير من المواقع لا شيء. إذا كنت منها فذلك ليس شهادة سلامة؛ اختبر عناوين فردية في PageSpeed Insights أو Lighthouse.

اختفى FID: ما الذي تغير في مارس 2024؟

ينبغي ضبط هذه النقطة لأن الأدلة القديمة ما زالت تعرضها خطأ. حل Interaction to Next Paint ‏(INP) محل First Input Delay ‏(FID) كمؤشر أساسي في 12 مارس 2024. والتفصيل الخاص بـSearch Console الذي يكاد لا يغطيه أحد جاء في إعلان فريق Chrome على web.dev: “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (الترجمة العربية) «سيُزال FID من Google Search Console فور أن يصبح INP مؤشرًا أساسيًا في 12 مارس. أما الأدوات الأخرى مثل PageSpeed Insights وCrUX فستتيح فترة انتقالية مدتها ستة أشهر كي يحدّث المطورون شيفراتهم قبل إيقاف FID نهائيًا». حذفت GSC ‏FID فورًا من دون فترة انتقالية، بينما أبقاه PSI وCrUX ستة أشهر أخرى. أي لقطة Search Console تعرض FID تعود إلى ما قبل مارس 2024.

ماذا حدث لتقرير Page Experience؟

هذه نقطة التباس حقيقية ما زالت مطلوبة في البحث. أزال Google تقرير Page Experience المستقل، أي لوحة التجميع القديمة التي كانت تجمع Core Web Vitals مع HTTPS وإشارات تجربة أخرى، من Search Console في 19 أبريل 2023. وبقي تقرير Core Web Vitals وتقرير HTTPS مستقلين. اختفى الملخص المجمع فقط. فإذا بحثت عن لوحة Page Experience ولم تجدها فهذا هو السبب؛ ما زال التقريران اللذان كانا تحتها موجودين. وتغطي تقارير شقيقة مثل Performance وPage Indexing بقية نطاق Search Console.

ترتيب الأولويات وإصلاح ما يجده التقرير

يقسم Google إرشاداته بين مسارين، غير تقني وللمطورين، وهو دليل لطيف على اختلاف جماهير التقرير. قاعدة الأولوية للجميع: أصلح Poor أولًا، ثم Need improvement. وفي مسار المطورين تُرتب عناوين المجموعة تنازليًا حسب مرات الظهور، لذلك تؤثر العناوين في الأعلى أكثر في حالة المجموعة.

إصلاحات مستوى الصفحة التي يذكرها Google مباشرة لكنها حقيقية: “Reduce your page size: best practice is less than 500KB for a page and all its resources.” (الترجمة العربية) «قلل حجم الصفحة؛ أفضل ممارسة هي أن يقل مجموع الصفحة وكل مواردها عن 500KB». أما كيفية تحسين LCP وINP وCLS فتخص موضوع كل مقياس، ولن أكررها هنا. وظيفة التقرير أن يخبرك أي القوالب تحتاج إلى إصلاح، لا أن يصلحها عنك.

لماذا تغيرت حالتي مع أنني لم ألمس شيئًا؟

هذا شائع جدًا ولا يكون خطأ عادةً. يقول Google في استكشاف الأخطاء: “If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” (الترجمة العربية) «إذا لم تغيّر الموقع ورأيت تغيرًا كبيرًا في حالة صفحات كثيرة، فربما كانت صفحات كثيرة على الحد ودفعها حدث على مستوى الموقع إلى تجاوزه». قد يؤدي تغير مزيج الزيارات أو زمن CDN أو مضيف الصور أو تحديث متصفح واسع الانتشار إلى دفع دفعة من عناوين كانت على الحد عبر العتبة معًا، لأن التقرير تجميع p75 لمدة 28 يومًا.

وأحيانًا يتقلب عدد العناوين المؤهلة فحسب. في واقعة يوليو 2025 التي انخفض فيها عدد عناوين URL ذات البيانات المؤهلة، وخصوصًا للجوال، وصف John Mueller ذلك بأنه تغير طبيعي في حجم العينة لا مشكلة؛ فالتقارير تقوم على عينات مما يعرفه Google عن الموقع، وتتغير أحجام العينات، ولا يدل ذلك على عطل. وأقر Barry Pollard من فريق Core Web Vitals بالانخفاض وقال إن إصلاحًا يُطرح. الدرس هو أن عدد العناوين المؤهلة وجودة المقاييس الأساسية أمران مختلفان؛ تغير العينة لا يعني أن الصفحات تباطأت.

هل يؤثر التقرير في الترتيب؟

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

ملاحظة سريعة عن Bing

لا يوجد مكافئ مباشر في Bing: تقرير مخصص بنمط CrUX يجمع عناوين URL لمؤشرات أداء الويب الأساسية داخل Bing Webmaster Tools. تركز Bing على Performance Report للنقرات ومرات الظهور وعلى Site Scan للتدقيق التقني، لا على تفصيل ميداني لمؤشرات الأداء. تشير إرشاداتها إلى مقاييس شبيهة بـCore Web Vitals، لكنها لم تطلق تقرير بيانات ميدانية مجمعًا مثل Google. تتغير أدوات Bing كثيرًا، فتحقق من وثائق Bing Webmaster Tools الحالية إن كان الأمر مهمًا لك.

موضع هذا التقرير

هذا واحد من عدة تقارير في Google Search Console. يغطي Performance أداءك الفعلي في البحث من نقرات ومرات ظهور وموضع، ويغطي Page Indexing جانب التغطية والفهرسة. أما المقاييس التي يعرضها هذا التقرير، وهي Core Web Vitals وCrUX وPageSpeed Insights بوصفه الرفيق المختبري، فلها شروح مستقلة في مجموعة أداء الويب.

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

نسخة مكثفة من تبويب Advanced:

• هذا تقرير لا المقاييس. يعرض تقرير Core Web Vitals في GSC ← Experience بيانات CrUX الميدانية لعناوين URL المفهرسة ضمن نافذة متحركة من 28 يومًا وعند المئين 75. لا يحسب شيئًا جديدًا ولا يحتوي بيانات مختبرية.
• ثلاثة أنواع للتجميع: الجهاز في تبويبي Mobile وDesktop المستقلين اللذين لا يُحسب متوسطهما، والحالة Poor وNeed improvement وGood حيث تفوز أسوأ قيمة، وURL group أي مجموعات صفحات ذات قوالب متشابهة تتشارك حالة واحدة.
• مجموعة URL هي الوحدة الأساسية لا العنوان المنفرد. قد يزيل إصلاح قالب واحد آلاف العناوين الموسومة، كما أوضح Mueller. وقد تضم مجموعة Poor صفحات سريعة.
• تدرّج العرض للحفاظ على الخصوصية: URL group ← origin group ← No data available. غالبًا لا ترى المواقع الجديدة أو قليلة الزيارات شيئًا؛ وفي دراسة Patrick لعام 2022 لم يملك أي بيانات CrUX سوى نحو 12% من الصفحات.
• لن يطابق PageSpeed Insights: بيانات مجموعة مقابل URL منفرد، وتبقي GSC معاملات URL مميزة بينما يزيلها PSI إلى العنوان المجرد.
• شرط الأهلية: تحتاج مجموعة URL إلى بيانات عتبة لكل من LCP وCLS قبل أن تظهر؛ وإذا نقصت بيانات أي منهما تُحذف ولا تسجل ناجحة. لا تظهر إلا العناوين المفهرسة، وهي عينة؛ وتُنسب البيانات إلى URL الفعلي لا canonical.
• يختلف عد المخطط والجدول: المخطط يعد كل URL مرة واحدة وفق أسوأ مشكلة، والجدول يعد كل مشكلة، لذلك لا تتطابق المجاميع.
• أزيل FID في 12 مارس 2024 عندما أصبح INP مؤشرًا أساسيًا؛ حذفته GSC فورًا، بينما أبقاه PSI وCrUX طوال فترة انتقالية مدتها ستة أشهر قبل إيقافه نهائيًا.
• أزيل تقرير Page Experience في أبريل 2023؛ وبقي تقريري Core Web Vitals وHTTPS.
• المسار: أصلح Poor أولًا وتحقق عبر Start Tracking؛ وهي جلسة مراقبة 28 يومًا يمنع فيها أي URL ما زال يفشل الاجتياز، ولا يعاد فهرسة شيء. شخّص سريعًا في PSI وانتظر نحو شهر لتلحق البيانات الميدانية. غالبًا ترجع تغيرات الحالة بلا تغييرات في الموقع إلى عناوين على الحد تجاوزت العتبة أو ضوضاء حجم العينة.

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

وثائق Google من المصادر الأولية.

Google

• تقرير Core Web Vitals — صفحة المساعدة المرجعية: مصدر CrUX، والتنظيم حسب الجهاز والحالة ومجموعة URL، وNo data available، والرجوع إلى مجموعة الأصل، واختلاف عد المخطط والجدول، والفروق عن PageSpeed Insights، ومسار التحقق Start Tracking.
• أصبح Interaction to Next Paint مؤشرًا أساسيًا في 12 مارس — إعلان فريق Chrome، بما فيه السطر الخاص بـSearch Console الذي يفيد بإزالة FID من GSC فورًا مع إتاحة فترة انتقالية مدتها ستة أشهر في PSI وCrUX قبل إيقافه.
• تقديم INP إلى Core Web Vitals — إعلان Google Search Central في مايو 2023 عن الانتقال من FID إلى INP.
• فهم مؤشرات أداء الويب الأساسية ونتائج بحث Google — نظرة Search Central العامة بالعتبات الحالية، التي ظلت 2,5s و200ms و0,1 عند وقت البحث.

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

تصريحات مسجلة من Google. كل رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google: ماهية التقرير ومصدر البيانات

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (الترجمة العربية) «يعرض تقرير مؤشرات أداء الويب الأساسية أداء صفحاتك استنادًا إلى بيانات الاستخدام الفعلية، التي تسمى أحيانًا بيانات ميدانية». — Search Console Help. الانتقال إلى الاقتباس
• “The data for the Core Web Vitals report comes from the CrUX report… The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (الترجمة العربية) «تأتي بيانات التقرير من CrUX، وتجمع قاعدة CrUX معلومات عن عناوين URL سواء كانت ضمن موقع في Search Console أم لا». الانتقال إلى الاقتباس
• “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (الترجمة العربية) «لا تظهر إلا عناوين URL المفهرسة، وليس التقرير قائمة شاملة لكل العناوين المفهرسة، بل عينة تساعدك في تقييم أداء الموقع». الانتقال إلى الاقتباس
• “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (الترجمة العربية) «تُنسب البيانات إلى URL الفعلي لا URL الأساسي كما في معظم التقارير الأخرى». الانتقال إلى الاقتباس

Google: مجموعات URL وآلية الرجوع للحفاظ على الخصوصية

• “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (الترجمة العربية) «تُجمع عناوين URL في صفحات ذات تجربة مستخدم متشابهة، وتنطبق حالة LCP وINP وCLS على المجموعة كلها. قد تكون بعض العناوين الشاذة أفضل أو أسوأ، لكن 75% من زيارات كل عناوين المجموعة شهدت الحالة المعروضة». الانتقال إلى الاقتباس
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (الترجمة العربية) «احترامًا لخصوصية المستخدم، يجب أن تملك مجموعة URL حدًا أدنى من البيانات. وإذا لم تكف المعلومات، ينشئ Search Console مجموعة أصل أعلى مستوى يفترض أن تضم عناوين وبيانات كافية». الانتقال إلى الاقتباس

Google: قراءة التقرير والتحقق من الإصلاحات

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (الترجمة العربية) «يعد المخطط كل URL مرة واحدة وفق أبطأ مشكلة تؤثر فيه، بينما يعد الجدول كل مشكلة مرتبطة به». الانتقال إلى الاقتباس
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” (الترجمة العربية) «لم يُصمم التقرير لمعرفة حالة URL محدد، بل لرؤية أداء الموقع ككل واستكشاف مشكلات تؤثر في صفحات متعددة». الانتقال إلى الاقتباس
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (الترجمة العربية) «عندما تعتقد أن مشكلة محددة أُصلحت، انقر Start Tracking في صفحة تفاصيلها في تقرير Search Console». الانتقال إلى الاقتباس

Google: المقارنة مع PageSpeed Insights وNo data available

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (الترجمة العربية) «يجمع Core Web Vitals البيانات والحالة في مجموعات URL، بينما يعرض PageSpeed Insights عادةً بيانات عناوين منفردة». الانتقال إلى الاقتباس
• “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (الترجمة العربية) «يأخذ Core Web Vitals معاملات URL في الحسبان عند تمييز الصفحة، بينما يزيل PageSpeed Insights كل المعاملات وينسب النتائج إلى URL المجرد». الانتقال إلى الاقتباس
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (الترجمة العربية) «إذا ظهرت شاشة لا تتوفر بيانات، فإما أن الموقع جديد في Search Console، أو لا توجد في CrUX بيانات كافية لنوع الجهاز المختار». الانتقال إلى الاقتباس

Google: الانتقال من FID إلى INP في Search Console، فريق Chrome وweb.dev

• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (الترجمة العربية) «عندما يصبح INP مؤشرًا أساسيًا في 12 مارس، سيُحذف FID من Search Console مباشرة؛ وستتيح بقية الأدوات فترة انتقالية مدتها ستة أشهر ليحدّث المطورون شيفراتهم قبل إيقاف FID نهائيًا». الانتقال إلى الاقتباس

John Mueller من Google: لماذا يجمع التقرير عناوين URL (2021)

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (الترجمة العربية) «نفعل ذلك ببيانات Chrome User Experience Report الميدانية، حيث نحاول تمييز الصفحات المتشابهة بما يكفي لنجمعها».
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (الترجمة العربية) «قد تكون لدينا مجموعة واحدة للموقع لكنها تحتوي آلاف عناوين URL؛ لذلك سيعرض تقرير Search Console أن آلاف العناوين تعاني المشكلة». اقرأ التغطية

أي أداة أو مسار أختار؟

«أريد فحص مؤشرات أداء الويب الأساسية لصفحة واحدة محددة». ← ليس هذا التقرير. استخدم PageSpeed Insights، الذي يوفر بيانات ميدانية ومختبرية لذلك العنوان، أو URL Inspection. فتقرير Core Web Vitals «لم يُصمم لمعرفة حالة URL محدد».

«يقول التقرير No data available». ← هل الموقع جديد تمامًا؟ امنح CrUX بضعة أيام ليجمع البيانات. ← وإلا فالسبب شبه المؤكد هو قلة الزيارات؛ إذ لا تتجاوز حتى مجموعة الأصل عتبة الخصوصية. اختبر العناوين منفردة في PageSpeed Insights أو Lighthouse. لا تعني قلة البيانات شهادة سلامة.

«المجموعة Poor، فما الذي أصلحه أولًا؟» ← أصلح كل ما يحمل Poor قبل ما يحمل Need improvement. ← داخل المجموعة ترتب العناوين تنازليًا حسب مرات الظهور؛ وتؤثر التي في الأعلى أكثر في الحالة. ← تحدد أسوأ قيمة حالة المجموعة؛ اعرف أي من LCP أوINP أوCLS يفشل وأصلح ذلك المقياس.

«تختلف حالة GSC وPageSpeed Insights لعنوان URL نفسه». ← هذا متوقع. تعرض GSC المجموعة، ويعرض PSI العنوان المنفرد الذي قد يكون شاذًا. كما تبقي GSC معاملات URL منفصلة، بينما يزيلها PSI إلى العنوان المجرد. لا تخطئ أي منهما؛ فهما تقيسان شيئين مختلفين.

«نشرت إصلاحًا؛ كيف أتأكد من نجاحه؟» ← افحص النتيجة المختبرية في PageSpeed Insights فورًا للحصول على ملاحظات سريعة. ← انقر Start Tracking على المشكلة في GSC للتحقق في الميدان. ← ثم انتظر؛ فالنافذة المتحركة من 28 يومًا تعني أن التقرير يحتاج إلى نحو شهر ليعكس التغيير كاملًا.

«تغيرت حالتي مع أنني لم ألمس الموقع». ← غالبًا تجاوزت عناوين على الحد العتبة بسبب تغير خارجي مثل مزيج الزيارات أو زمن CDN والصور أو تحديث متصفح، أو كان الأمر مجرد تقلب في حجم العينة. تحقق هل المتغير هو عدد العناوين المؤهلة أم جودة المقياس الأساسية؛ فهما شيئان مختلفان.

قائمة تحقق سليمة لقراءة تقرير Core Web Vitals

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

• فحصت تبويبي Mobile وDesktop معًا؛ فهما مستقلان وقد يختلفان.
• تعاملت مع مجموعات URL لا العناوين الفردية بوصفها الوحدة؛ فغالبًا يمسح إصلاح واحد المجموعة كلها.
• تفهم أن مجموعة Poor قد تضم صفحات سريعة لأن الحالة هي p75 للمجموعة.
• تعرف أن المخطط والجدول لن يتطابقا؛ فالمخطط يعد كل URL مرة وفق أسوأ مشكلة، والجدول يعد كل مشكلة.
• تصلح Poor قبل Need improvement، وترتب الأولوية بحسب العناوين الأعلى ظهورًا.
• حددت أي مقياس من LCP وINP وCLS يقرر حالة كل مجموعة قبل لمس الشيفرة.
• تحولت لفحص URL منفرد إلى PageSpeed Insights أوURL Inspection، لا هذا التقرير.
• لا تتوقع أن تطابق GSC ‏PageSpeed Insights بسبب المجموعة مقابل العنوان والإبقاء على المعاملات مقابل حذفها.
• عند ظهور No data available تحققت من الزيارات والأهلية بدل افتراض أن الصفحات سليمة.
• بعد الإصلاح نقرت Start Tracking ومنحت البيانات الميدانية نحو شهر للحاق.
• لا تطارد تغير حالة سببه في الواقع حافة العتبة أو ضوضاء حجم العينة.

النماذج الذهنية

1. إنه تقرير لا مقياس لحظي. كل رقم هو بيانات CrUX ميدانية من مستخدمي Chrome الحقيقيين ضمن نافذة متحركة من 28 يومًا وعند المئين 75. يعرض التقرير تلك البيانات ولا يحسب شيئًا جديدًا ولا يملك طبقة مختبرية. لذلك يصف الماضي القريب دائمًا، لا «الآن».

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

3. تفوز أسوأ قيمة. تحدد أضعف قيمة بين LCP وINP وCLS حالة المجموعة. قبل تحسين أي شيء اعرف أي مقياس يفشل؛ فأنت لا تصلح «المجموعة» بل المقياس الذي يسحبها إلى الأسفل.

4. يفسر تدرّج العرض للحفاظ على الخصوصية الفجوات. URL group ← origin group ← No data available. إذا لم تكف الزيارات لعرض البيانات مع الحفاظ على الخصوصية، يلجأ التقرير إلى تجميع أوسع على مستوى الأصل، أو لا يعرض بيانات أصلًا. وتعني No data أن بيانات CrUX غير كافية، لا أن الموقع سليم.

5. أداتان ومهمتان: شخّص سريعًا وأكد ببطء. PageSpeed Insights لعنوان منفرد مع بيانات ميدانية ومختبرية وملاحظات فورية. أما تقرير GSC فمجمّع وميداني فقط ومتأخر نحو شهر. شخّص الإصلاح وتحقق منه في مختبر PSI، ثم انتظر بيانات GSC الميدانية لتؤكده في الواقع.

ورقة مختصرة لتقرير Core Web Vitals

طريقة التنظيم

تقرير GSC مقابل PageSpeed Insights

حقائق سريعة

• مصدر البيانات: بيانات CrUX الميدانية ضمن نافذة متحركة من 28 يومًا وعند p75 لكل جهاز.
• لا تظهر إلا العناوين المفهرسة، وهي عينة لا كلها، وتُنسب إلى URL الفعلي لا canonical.
• No data available تعني موقعًا جديدًا أو زيارات CrUX غير كافية وفق التسلسل URL group ← origin group ← لا شيء.
• يعد المخطط كل URL مرة وفق أسوأ مشكلة، ويعد الجدول كل مشكلة، لذلك لن تتطابق المجاميع.
• أزيل FID من GSC في 12 مارس 2024 فورًا، بينما أبقاه PSI وCrUX ستة أشهر أخرى.
• أزيل Page Experience في 19 أبريل 2023؛ وبقي تقريري Core Web Vitals وHTTPS.
• أصلح Poor أولًا وتحقق عبر Start Tracking وتوقع نحو 28 يومًا ليعكس التقرير الإصلاح.
• قاعدة Google التقريبية لوزن الصفحة: أقل من 500KB للصفحة وكل مواردها.

أخطاء تقرير Core Web Vitals

اعتبار كل URL في مجموعة Poor بطيئًا بمفرده. تخص الحالة المجموعة عند المئين 75، لذلك قد يكون عضو منفرد أسرع أو أبطأ. شخّص عناوين تمثيلية ثم أصلح القالب أو المكوّن المشترك.

فحص Mobile وحده أوDesktop وحده. مجموعتا البيانات منفصلتان وقد تختلفان. فرّز التبويبين باستقلال بدل دمجهما في قصة واحدة.

اعتبار No data available نجاحًا. يعني عادةً أن URL أو الأصل لا يملك زيارات CrUX مؤهلة كافية للتقرير. استخدم الاختبارات المختبرية ومصادر البيانات الميدانية الأخرى، ولا تدّع أن الصفحة Good.

توقع تطابق GSC مع PageSpeed Insights لعنوان واحد. تعرض GSC المجموعات وتحفظ معاملات URL، بينما يعرض PSI عادةً URL مجردًا منفردًا. افهم وحدة القياس ومعالجة العنوان قبل اعتبار الفرق خطأ.

تحسين مقياس حالته Good أصلًا. يقرر أضعف مقياس حالة المجموعة. حدد هل المسؤول LCP أمINP أمCLS قبل تسليم العمل إلى مطور.

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

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

التحقق من إصلاح Core Web Vitals

استخدم ثلاث طبقات من الإثبات، فلا تكفي أي طبقة وحدها.

1. إثبات النشر

• أعد إنتاج التفاعل البطيء أو العنصر غير المستقر أو أكبر عنصر متأخر التحميل في URL تمثيلي متأثر.
• تأكد من وجود الشيفرة المعدلة في الإنتاج، لا في معاينة فقط، وعلى كل قالب تمثله مجموعة URL.
• شغّل Lighthouse أو تتبعًا مختبريًا آخر قبل التغيير وبعده في الظروف نفسها. يجب أن يتحسن المقياس المستهدف من دون تراجع مؤشر أساسي آخر.

2. إثبات مسار التقرير

• افتح صف المشكلة نفسه وسجل الجهاز والحالة والمقياس ومجموعة URL وعناوين المثال.
• افحص أمثلة في PageSpeed Insights مع تذكر أن URL منفردًا قد يختلف عن مجموعته في GSC.
• انقر Start Tracking بعد اكتمال طرح الإنتاج فقط. راقب حالة تحقق المشكلة بدل إعادة تشغيلها مرارًا.

3. إثبات النتيجة الميدانية

• انتظر حتى تستوعب نافذة CrUX المتحركة من 28 يومًا زيارات ما بعد الإصدار.
• أكد تحسن المجموعة المتأثرة على الجهاز والمقياس نفسيهما اللذين فشلا أصلًا.
• افحص Mobile وDesktop معًا، وميّز تحسن المقياس الحقيقي من تغير العناوين التي امتلكت بيانات كافية للأهلية.
• إذا ظلت GSC بلا تغيير فقارن عناوين مثال المجموعة ببيانات PSI على مستوى URL والأصل قبل الحكم بفشل النشر.

ليس شرط النجاح أن «يصير Lighthouse أخضر مرة واحدة». بل أن يكون إصلاح الإنتاج موجودًا في المجموعة كلها، وأن يتحسن الدليل المختبري المضبوط، وأن تُمسح المشكلة الميدانية ذات الصلة في GSC بعد وصول بيانات مستخدمين حقيقيين كافية.

قياس التقدم من دون اختراع درجة أداء

تتبع هذه المقاييس منفصلة حسب الجهاز والمقياس ومجموعة URL وتاريخ الإصدار:

استخدم عتبات Good التي ينشرها Google: ‏LCP عند 2,5 ثانية أو أقل، وINP عند 200 مللي ثانية أو أقل، وCLS عند 0,1 أو أقل، وكلها عند المئين 75، بوصفها معيار الجودة. لا تخترع موعدًا نهائيًا عالميًا أو هدف نسبة تحسن. الاتجاه المفيد هو انخفاض العناوين المؤهلة في المجموعات الفاشلة، واجتياز عمليات تحقق المشكلات، واستقرار المكاسب خلال نوافذ 28 يومًا متعاقبة من دون التضحية بمقياس لمصلحة آخر.

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

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

• ما مؤشرات أداء الويب الأساسية وكيف تحسنها؟ — دليلي إلى المقاييس نفسها وكيف يجمع تقرير GSC الصفحات المتأثرة حسب القالب.
• دليل Google PageSpeed Insights لمتخصصي SEO والمطورين — الرفيق المختبري ومساري “diagnose in PSI, monitor in GSC” (الترجمة العربية) «شخّص في PSI وراقب في GSC»، وفيه نصيحة التأخر 28 يومًا.
• دراسة بيانات Core Web Vitals باستخدام CrUX و5,2 ملايين صفحة — دراستي واسعة النطاق عن قلة الصفحات التي تملك أي بيانات CrUX أصلًا، وفيها رقم نحو 12% الذي يفسر معظم شاشات No data available.

محاضراتي ومقابلاتي

• مؤشرات أداء الويب الأساسية من Google للشركات الصغيرة والمتوسطة: حوار مع Patrick Stox (Outside Communications) — شرح قصير غير تقني لغرض التقرير: “you fix it once, you fix that issue for all those pages.” (الترجمة العربية) «تصلحه مرة فتصلح المشكلة في كل تلك الصفحات».

رسمي

• تقرير Core Web Vitals في مساعدة Search Console — المرجع الأساسي لكل ما في المقالة.
• أصبح INP مؤشرًا أساسيًا في 12 مارس على web.dev — تفصيل إزالة FID من GSC فورًا.

من أنحاء الصناعة

• Google يناقش تجميع عناوين URL لدرجات Core Web Vitals (Search Engine Journal) — نص Office Hours مع John Mueller عن سبب قدرة مجموعة واحدة على وسم آلاف العناوين.
• كيفية استخدام تقرير Core Web Vitals في Google Search Console (DebugBear) — مسار عملي من الإعداد إلى الإصلاح وشرح جيد لدخول صفحات سريعة في مجموعات بطيئة.
• إصلاح Core Web Vitals وتحسينها في Google Search Console (Quattr) — مسار تحسين منظم: فرز ← تحديد أولوية ← اختبار ← حل ← تحقق.
• اختفاء تقرير Page Experience من Google Search Console (Search Engine Land) — تغطية إزالة ملخص Page Experience في أبريل 2023.
• تحديث تقرير Core Web Vitals داخل Google Search Console (Search Engine Land) — إضافة طبقة الرجوع إلى origin group في مارس 2023.
• تحديث Core Web Vitals في Google Search Console (Search Engine Roundtable) — انخفاض العناوين المؤهلة في يوليو 2025، مع Mueller وPollard عن تقلب حجم العينة.

إحصاءات جديرة بالاستشهاد

• امتلك نحو 12% فقط من 43,66 مليون صفحة Site Audit فريدة في عينة يناير 2022 أي مقياس CrUX. ذكرت في دراستي: “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (الترجمة العربية) «وجدنا أن 5,21 ملايين فقط، أي نحو 11,9%، امتلكت مقياسًا واحدًا على الأقل، وأن 93% منها، أو نحو 4,85 ملايين إجمالًا، امتلكت المقاييس الثلاثة». هذه هي مجموعة بيانات CrUX الأساسية التي يعتمد عليها التقرير، وتوضح أرقامها مدى نقص التغطية الذي يفسر ظهور No data available في مواقع كثيرة.
• أزيل FID من GSC في 12 مارس 2024 فورًا من دون فترة انتقالية، بينما أبقاه PSI وCrUX طوال فترة انتقالية مدتها ستة أشهر قبل إيقافه نهائيًا. المصدر
• قاعدة تقريبية لوزن الصفحة: أقل من 500KB للصفحة وكل مواردها، وفق إرشاد Google في قسم Fix issues من التقرير. المصدر
• أزيل تقرير Page Experience في 19 أبريل 2023، وبقي تقريرا Core Web Vitals وHTTPS من ذلك الملخص القديم. التغطية

اختبر نفسك: تقرير مؤشرات أداء الويب الأساسية

خمسة أسئلة سريعة عن طريقة عمل تقرير Core Web Vitals في Search Console. اختر إجابة لكل سؤال ثم تحقق.

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