سرعة الموقع

نظرة عميقة في Core Web Vitals

Core Web Vitals ثلاثة أرقام تقيس ثلاثة أشياء مختلفة تماما: LCP لسرعة ظهور أكبر عنصر في الصفحة، وINP لسرعة استجابة الصفحة للنقر واللمس، وCLS لمقدار انزياح التخطيط من تلقاء نفسه. ويحكم غوغل على الثلاثة لا من اختبارك أنت بل من الصدك ٧٥ للزوار الحقيقيين، مفصولا بين الهاتف وسطح المكتب.

  • الدرس 3 من 10
  • متوسط
  • مجاني، دون تسجيل

الرقم الذي يقرر هل نجحت

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

0 100
٧٥%الصدك الذي يجري عليه التقييم
  • LCPأكبر عنصر في الصفحة، ٢.٥ ثانية أو أقل
  • INPالاستجابة للنقر واللمس، ٢٠٠ ميلي ثانية أو أقل
  • CLSانزياح التخطيط غير المقصود، ٠.١ أو أقل

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

آخر مراجعة: تُراجع الحقائق وأسماء الأدوات في هذا الدرس مقابل مصادرها في هذا التاريخ.

ماذا يقيس كل رقم من هذه الثلاثة

Core Web Vitals ثلاثة مؤشرات لا درجة واحدة. تأتي أسماؤها معا، فيظن كثيرون أنها ثلاث روايات لشيء واحد. وليست كذلك. فكل منها يلتقط لحظة مختلفة من الزيارة، وكل منها يتعطل عادة لسبب مختلف.

LCP أي Largest Contentful Paint هو لحظة ظهور أكبر عنصر محتوى داخل إطار الرؤية. وهو غالبا صورة كبيرة أو كتلة نص. وتقول وثائق غوغل إن على المواقع أن تسعى إلى LCP قدره ٢.٥ ثانية أو أقل. وهذا الرقم يجيب عن سؤال: هل رأيت شيئا؟

INP أي Interaction to Next Paint هو المسافة بين فعل المستخدم واللحظة التي يرسم فيها المتصفح الإطار التالي. ويكتب غوغل أن على الصفحة أن يكون INP لديها ٢٠٠ ميلي ثانية أو أقل، وأن ما فوق ٥٠٠ ميلي ثانية يعد ضعيفا. وهذا الرقم يجيب عن سؤال: حين ضغطت، هل حدث شيء؟

وهنا بالضبط تخطئ النماذج اللغوية والمقالات القديمة معا. فـ INP هو المؤشر الخلف لـ FID، وصفحة غوغل نفسها تقول ذلك. والفرق ليس صغيرا: كان FID يقيس تأخير الإدخال في أول تفاعل فقط، بينما يرصد INP كل التفاعلات طوال بقاء المستخدم، من تأخير الإدخال مرورا بتشغيل المعالجات وحتى الإطار الذي يرسمه المتصفح أخيرا. فإن رأيت رقم ١٠٠ ميلي ثانية منقولا في مكان ما، فهو يخص مؤشرا لم يعد من Core Web Vitals.

CLS أي Cumulative Layout Shift فلا وحدة زمنية له أصلا. هو رقم بلا وحدة يقول كم تحرك محتوى الصفحة دون أن يطلب المستخدم ذلك. ويكتب غوغل أن على المواقع أن تسعى إلى CLS قدره ٠.١ أو أقل. وهذا الرقم يجيب عن سؤال: هل بقي ما كنت على وشك الضغط عليه في مكانه؟

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

Core Web Vitals: ماذا يقيس كل من المؤشرات الثلاثة

لماذا لا يطابق رقمك ما يراه غوغل

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

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

البيانات الميدانية تُجمع من الزوار الحقيقيين. وتقرير تجربة مستخدم كروم هو هذا تماما: قياس مجهول الهوية لمستخدمين حقيقيين لكل من المؤشرات الثلاثة. وهذه هي البيانات التي يحكم غوغل عليك بها.

وهنا الرقم الذي يقلب كل شيء. يكتب غوغل أنه لضمان بلوغ الهدف الموصى به لدى معظم مستخدميك، فإن العتبة الجيدة للقياس هي الصدك ٧٥ لتحميلات الصفحة، مفصولة بين الهاتف وسطح المكتب. أي أن أبطأ ربع من مستخدميك هو من يقرر نجاحك، وينبغي للأداة التي تقيّم Core Web Vitals ألا تعد الصفحة ناجحة إلا إذا بلغت الهدف عند الصدك ٧٥ في المؤشرات الثلاثة جميعا.

والنتيجة لموقع إيراني مباشرة: اختبار على حاسوبك المحمول باتصال جيد يظهر على الأرجح أفضل الحالات، بينما يأتي صدكك ٧٥ من هاتف على شبكة غير مستقرة. والفجوة بين الرقمين ليست مما يُملأ بالتخمين.

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

رقمان كلاهما صحيح وليسا واحدا

بيانات مخبرية

  • تشغيل محاكى واحد على جهاز وشبكة افتراضيين
  • متاح الآن، حتى لموقع جديد
  • قابل للتكرار، فهو جيد لإيجاد السبب
  • ليس تجربة أحد حقيقي

بيانات ميدانية

  • تُجمع من زوارك الحقيقيين أنت
  • بهذه يحكم غوغل، عند الصدك ٧٥
  • يُحسب الهاتف وسطح المكتب منفصلين
  • قد لا توجد أصلا لموقع قليل الزيارات

ولا عمود من هذين أفضل من الآخر؛ فلكل عمل مختلف. تجد السبب في أحدهما وتأخذ الحكم من الآخر.

حين يكون LCP سيئا، أين ذهب الوقت

«LCP سيئ» عرَض لا تشخيص. وقد قسّم غوغل نفسه LCP إلى أربعة أجزاء، وهذا التقسيم هو ما ينقل العمل من التخمين إلى القراءة.

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

وينشر غوغل توزيعا تقريبيا لهذه الأربعة: الزمن حتى أول بايت نحو ٤٠% من LCP، وتأخير بدء التحميل دون ١٠%، ومدة تحميل المورد نحو ٤٠%، وتأخير رسم العنصر دون ١٠%. ويضيف غوغل فورا أن هذه التقسيمات إرشادات لا قواعد صارمة، ويوصي صراحة بعدم تحويل هذه النسب إلى أرقام مطلقة.

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

يتكون LCP من أربعة أجزاء، اثنان منها يلتهمان معظمه

الحصة التقريبية لكل جزء من LCP، بحسب وثائق غوغل
  1. نحو ٤٠%
  2. دون ١٠%
  3. نحو ٤٠%
  4. دون ١٠%
  • الزمن حتى أول بايت نحو ٤٠%
  • تأخير بدء تحميل المورد دون ١٠%
  • مدة تحميل المورد نحو ٤٠%
  • تأخير رسم العنصر دون ١٠%

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

من أين يتعطل INP وCLS عادة

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

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

والآن القاعدة التي لا يكاد يكتبها درس، وبدونها ستقرأ CLS خطأ: الانزياحات التي تقع خلال ٥٠٠ ميلي ثانية من إدخال المستخدم تُعلَّم، فيمكن استبعادها من الحساب. أي أنك حين تضغط زر القائمة بنفسك فتنفتح القائمة، لا يُضاف ذلك الانزياح إلى CLS لديك. وهذا مقصود: فالمتصفح يفرق بين «قفزت الصفحة تحت يدي» و«أنا من تسبب بذلك». ومن يجهل هذا يبلّغ عن الأكورديون والقائمة عنده كمشكلة CLS، فيصرف وقته في المكان الخطأ.

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

ليست كل الانزياحات محسوبة عليك

ورقة CLSما الذي يُحسب

يُضاف إلى CLS لديك

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

لا يُحسب

  • فتح القائمة بعد أن ضغط المستخدم الزر
  • انفتاح أكورديون الأسئلة بنقر المستخدم نفسه
  • أي انزياح خلال ٥٠٠ ميلي ثانية من إدخال المستخدم

لا يُفهم العمود الأسفل دون قاعدة الـ ٥٠٠ ميلي ثانية. وجهلها هو ما يجعل المرء يبلّغ عن قائمته هو كمشكلة CLS.

ما الذي لا تخبرك به هذه الأرقام الثلاثة

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

وثمة أمران لا تراهما هذه الأرقام أصلا. الأول سرعة ما يأتي بعد تحميل الصفحة: فـ Core Web Vitals يركز على الزيارة، ومع أن INP يرصد عمر الصفحة كله فإنه لا يقول شيئا عن المدة التي يستغرقها إرسال نموذجك. والثاني تجربة المستخدمين الذين ليسوا في تلك المجموعة لأي سبب.

فترتيب العمل الصحيح إذن: انظر أولا هل الصفحة التي تريد تسريعها تهم أحدا أصلا، ثم انتقل إلى هذه الأرقام الثلاثة. والدرس التالي في هذا المسار يبين بأي أداة تُنتَج وكيف يُقرأ التقرير؛ وقائمة الدروس كاملة على صفحة هذا المسار.

المسار السريع مع الذكاء الاصطناعي

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

  1. سلّم أداة تعمل على المصادر صفحات وثائق غوغل المذكورة في مصادر آخر هذا الدرس: صفحة Web Vitals وصفحات LCP وINP وCLS المخصصة. فإن كانت أداتك تقبل الروابط فالعناوين تكفي، وإلا فاحفظ نص الصفحة وارفعه.
  2. ضع أرقامك الثلاثة إلى جانبها، من البيانات الميدانية لا من تشغيل اختبار. وإن لم تكن لديك بيانات ميدانية فاكتب ذلك بالضبط واطلب من النموذج أن يحمل هذا النقص في جوابه لا أن يستنتج نتيجة ميدانية من رقم مخبري.
  3. أعطها الأمر أدناه. وقاعدته المهمة أن كل جملة يجب أن تعود إلى مصدر رفعته أنت، وأن كل ما ليس في المصادر يجب إعلانه مجهولا صراحة. ولا يحتاج هذا نموذجا غاليا؛ فما تريده اقتباس دقيق لا حكم، ويكفي نموذج سريع رخيص من رتبة Gemini Flash. ويُحفظ الاختيار الحالي لكل رتبة في مرجع الذكاء الاصطناعي عندنا.
  4. اختبر الجواب بفحص بسيط: اسأل النموذج ما عتبة INP الجيدة ومن أين جاءت. فإن قال غير ٢٠٠ ميلي ثانية، أو عجز عن ردّ الجملة إلى مصدر، فالمصادر لم تُحمّل كما يجب وبقية الجواب غير جدير بالثقة أيضا.

وصفة جاهزة للنسخ

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

أرقامي (بيانات ميدانية، الصدك ٧٥):
LCP = {رقم أو «لا بيانات ميدانية لدي»}
INP = {رقم أو «لا بيانات ميدانية لدي»}
CLS = {رقم أو «لا بيانات ميدانية لدي»}
الجهاز: {هاتف | سطح مكتب | كلاهما}

اكتب خمسة أشياء:
١. لكل من المؤشرات الثلاثة، اقتبس عتبة «الجيد» من المصدر وقل من أي صفحة جاءت.
٢. قل أي أرقامي الثلاثة راسب، وبكم يبعد عن العتبة.
٣. لكل مؤشر راسب، اذكر الأسباب المحتملة التي سماها المصدر نفسه، ولا تضف سببا من عندك.
٤. إن كان أحد أرقامي «لا بيانات ميدانية لدي» فلا تكتب أن المؤشر سليم؛ بل اكتب أنه لا حكم ممكن عليه وما الذي يلزم ليصير ممكنا.
٥. وفي الآخر اكتب أي جمل جوابك لم تستطع ردها إلى مصدر.

قواعد: لا تكتب عتبة من الذاكرة أبدا. وحيث يحمل المصدر قيدا مثل «إرشادات لا قواعد صارمة» فاحمل ذلك القيد إلى جوابك. ولا تحول أي نسبة إلى ثوان. وإن لاحظت أن لديك معلومات أقدم عن مؤشر FID فنحّها واقتبس من المصدر وحده.

قبل أن تثق بالناتج: هذا يجعل الجواب قابلا للتتبع، لا صحيحا بالضرورة. وأمران يبقيان عليك. الأول أن يكون المصدر الذي ترفعه صفحة اليوم لا نسخة حفظتها قبل ثلاث سنوات؛ فصفحة INP حُدّثت في سبتمبر ٢٠٢٥، وهذا نفسه دليل على أن هذه الصفحات تتحرك. والثاني أن الأسباب التي يستخرجها النموذج من المصدر قائمة احتمالات لا تشخيص لموقعك؛ فالتشخيص يأتي من قياس الصفحة، وهذا بالضبط موضوع الدرس التالي في هذا المسار.

الذكاء الاصطناعي في هذا العمل

موقفنا هنا أشد من بقية الدروس: لأرقام Core Web Vitals، لا تشغّل نموذجا لغويا أبدا دون مصدر أمامه. والسبب ليس ذوقا بل تاريخا. فقد استُبدل المؤشر الأوسط في هذه العائلة، وتحركت العتبات، والنص الذي دُرّبت عليه هذه النماذج كرر الأرقام القديمة سنوات. وفي هذا الموضوع يعطيك النموذج إجماع الإنترنت، والإجماع هنا قديم. أما النموذج نفسه ومعه مصدر أمامه فأداة جيدة.

أدوات تساعد فعلا

  • NotebookLM هذه هي الأداة الصحيحة لهذا العمل، لأنها تبني الجواب من مصدر قدمته أنت وتُظهر الإحالة. حمّل صفحات web.dev واسأل سؤال العتبات من داخل المصدر. تعمل على حساب غوغل، ويقول دليل غوغل نفسه إنها تعمل حيث يعمل تطبيق Gemini؛ وإيران ليست في قائمة الدول المدعومة لتطبيقات Gemini.
  • Gemini مفيد حين يكون لديك تقرير ميداني طويل وتريد قراءة جداول كبيرة. أما سؤال العتبات فلا تتكئ عليه فيه دون مصدر. وتقول صفحة غوغل نفسها إن تطبيق Gemini على الويب يعمل في أكثر من ٢٣٠ دولة وإقليما، وإيران ليست في تلك القائمة.
  • ChatGPT القاعدة نفسها: يعمل جيدا مع مصدر مرفوع، ويكرر الأرقام القديمة بدونه. ولا ندّعي شيئا عن الوصول من إيران، لأن صفحة الدول المدعومة لدى OpenAI، كسائر ذلك النطاق، تعيد ٤٠٣ لهذا الخادم، ونحن لا نكتب ادعاء بلا سند.

اين ينقلب ضدك

الخطر الأساسي هنا شيء محدد وله اسم: يعطيك النموذج عتبة لم تعد صحيحة، وبالنبرة الواثقة نفسها التي كان سيعطي بها الصحيحة. كان FID سنوات هو المؤشر الأوسط في هذه العائلة، وصفحة غوغل نفسها تقول إن INP خلفه. وما زال النص التعليمي على الإنترنت مليئا برقم ١٠٠ ميلي ثانية وباسم FID، والنموذج الذي يجيب بلا مصدر ينقل من ذلك النص بالضبط. وعمليا يعني هذا أنك قد تقضي شهرا في تحسين شيء لم يعد يُحسب. وتسمي وثائق Anthropic نفسها هذا النمط، أي أن يقول النموذج بثقة ما لا سند له، هلوسة. أما الخطر الثاني فأهدأ: يأخذ النموذج رقمك المخبري ويصدر حكما عن الحالة الميدانية. وموقفنا بسيط: مصدر مرفوع أو صمت. فلهذه الأرقام الثلاثة، الجواب الذي لا يُرد إلى صفحة الوثائق ليس جوابا.

المصادر: web.dev: Interaction to Next Paint, the successor to FID Anthropic: reduce hallucinations Google: where Gemini Apps are available

حدود هذه النصيحة

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

من عملنا نحن

يمكن استهداف المؤشرات الثلاثة دون شراء أي إضافة، إن كنت مستعدا لدفع ثمن ما. قسنا الصفحة الأولى لهذا الموقع في ٨ سبتمبر ٢٠٢٦، والقرارات الثلاثة كلها ظاهرة في مصدر الصفحة. فلأجل LCP، أكبر عنصر في صفحتنا الأولى نص عمدا لا صورة: إذ يحمل المستند كله صفر وسم img، لأن كل ما يشبه الإنفوغرافيك في هذا الموقع مرسوم بـ HTML وCSS. ولأجل INP، لم يبق في ملف الأنماط الرئيسي إلا حركة واحدة هي دوارة الانتظار، ولا transition فيه أصلا؛ ويحمل head صفر سكربت، وسكربتات الصفحة السبعة كلها تجلس في آخر المستند، أولها يبدأ بعد ٩٦ بالمئة منه. ولأجل CLS، قاعدتنا المكتوبة أن كل صورة توضع داخل المتن يجب أن تحمل width وheight صريحين. أما الثمن الذي دفعناه فعلا: هذه القرارات تقيّد شكل الموقع، وتجريد الحركة يأخذ شيئا من الصفحة. قبلنا بذلك لأننا نعرف المقايضة، ومغزى الدرس أن تستطيع أنت الحكم على المقايضة نفسها لا أن تأخذها منا. ويمكنك التحقق من كل هذا الآن بعرض مصدر الصفحة الأولى.

اسئلة متابعة حقيقية

هل الدرجة الخضراء في أداة الاختبار تعني نجاح Core Web Vitals لدي؟

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

لماذا قسم البيانات الميدانية في تقريري فارغ؟

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

هل INP هو FID باسم جديد؟

لا. تقول صفحة غوغل نفسها إن INP هو المؤشر الخلف لـ FID، لكن ما يقيسه مختلف: كان FID يرى تأخير الإدخال في أول تفاعل فقط، بينما يرصد INP كل التفاعلات طوال الزيارة ويعد حتى الرسم التالي. فلا العتبة القديمة ولا الرقم القديم ينفع الآن.

واصل التعلم