تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

أجزاء الصورة الخاصة بمقياس "سرعة عرض أكبر محتوى مرئي" (LCP) ووقت استجابة الطلب (RTT) متوفّران الآن في CrUX

Barry Pollard

Johannes Henkel

تاريخ النشر: 11 شباط (فبراير) 2025

يتضمّن إصدار شباط (فبراير) 2025 من تقرير تجربة المستخدم في Chrome (CrUX) عددًا من المقاييس الجديدة (والمعدَّلة) المشوّقة:

أجزاء الصورة الفرعية وأنواع الموارد المتعلّقة بمقياس سرعة عرض أكبر محتوى مرئي (LCP)
تفاصيل مدة إرسال البيانات واستقبالها على الشبكة
إزالة سمة "نوع الاتصال الفعّال" (ECT)

يقدّم كلّ منهما إحصاءات أكبر حول مقاييس أداء مصادر الزيارات وعناوين URL المتاحة في CrUX، وسنوضّح في هذه المشاركة سبب ذلك.

معلومات تشخيص LCP

لقد طرحنا في الأصل مفهوم الأجزاء الفرعية لمقياس LCP في حدث Google I/O لعام 2022 كأسلوب فعّال لتقسيم وقت LCP للصفحات التي تتضمّن مقاييس LCP للصور إلى مكوّنات أصغر لضمان تركيز جهودك على تحسين الأسباب الصحيحة لارتفاع مقياس LCP.

أظهر تحليل بيانات مختبر HTTP Archive في هذه المحادثة أنّ وقت تنزيل الصور كان غالبًا هو الجزء الأصغر من وقت LCP. كانت الكثير من أدوات المختبر (بما في ذلك أداة Lighthouse من Google) تركّز بشكلٍ متكرّر على تقديم نصائح لتحسين أشكال الصور وحجمها من أجل تقليل أوقات التنزيل وتحسين الأداء. على الرغم من أنّ التحليل كان صحيحًا، إلا أنّه أظهر أنّه قد تم التركيز بشكل كبير على النصيحة وأنّ المشكلة الأكبر كانت في التأخيرات قبل أن يعثر المتصفّح على الصورة ويبدأ تنزيلها.

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

الأجزاء الفرعية لصورة مقياس "سرعة عرض أكبر محتوى مرئي" (LCP)

من خلال هذا الإصدار، يمكن لمالكي المواقع الإلكترونية التحقّق من مواقعهم الإلكترونية بحثًا عن الأجزاء الفرعية لمقياس LCP للصور، على مستوى المصدر أو عنوان URL.

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

تمت إضافة هذه البيانات إلى CrUX API وCrUX History API اعتبارًا من شباط (فبراير) 2025 (ملاحظة: لا يشمل ذلك BigQuery). تتضمّن CrUX History API بيانات أسبوعَين عند الإطلاق، وسيتمّ توسيع نطاق هذه البيانات بمرور الوقت ليشمل السجلّ الكامل الذي يمتدّ على 25 أسبوعًا. تتيح واجهات برمجة التطبيقات البيانات على أنّها الشريحة المئوية الخامسة والسبعون لكل جزء فرعي يتم التعبير عنها بالملي ثانية.

على سبيل المثال، للحصول على الأجزاء الفرعية لصورة LCP https://web.dev/ لمرّات مشاهدة الصفحة PHONE، يمكنك استخدام الأمر curl التالي (مع استبدال API_KEY بـ مفتاحك الخاص):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": [
              "largest_contentful_paint_image_time_to_first_byte",
              "largest_contentful_paint_image_resource_load_delay",
              "largest_contentful_paint_image_resource_load_duration",
              "largest_contentful_paint_image_element_render_delay"]}'

وستتلقّى ردًا على النحو التالي:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_image_element_render_delay": {
        "percentiles": {
          "p75": 2088
        }
      },
      "largest_contentful_paint_image_resource_load_delay": {
        "percentiles": {
          "p75": 828
        }
      },
      "largest_contentful_paint_image_resource_load_duration": {
        "percentiles": {
          "p75": 417
        }
      },
      "largest_contentful_paint_image_time_to_first_byte": {
        "percentiles": {
          "p75": 2385
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

لقد عدّلنا أداة CrUX Vis لتضمين هذه البيانات ونتوقّع أن تعرض أيضًا هذه البيانات القيّمة أدوات خارجية أخرى تستخدم واجهات برمجة تطبيقات CrUX:

رسم بياني لأجزاء الصورة في مقياس LCP في أداة العروض المرئية في CrUX يعرض نقطتَي بيانات للأجزاء الأربعة — الأجزاء الفرعية لصورة LCP في أداة العروض المرئية في CrUX

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

تشير القيم العالية في كل جزء فرعي إلى مشاكل مختلفة:

يشير ارتفاع وقت وصول أول بايت (TTFB) عادةً إلى مشاكل في الخادم أو الشبكة أو إعادة التوجيه، كما هو موضّح في مقالة تحسين وقت وصول أول بايت.
يشير ارتفاع تأخُّر تحميل الموارد إلى أنّ المتصفّح اكتشف صورة LCP في وقت متأخر، على سبيل المثال، صورة LCP تم إدراجها من خلال JavaScript على جانب العميل ويستغرق تشغيلها بعض الوقت.
إذا كانت مدة تحميل الموارد طويلة، عليك النظر في تقليل حجم تنزيل الصور.
يحدث تأخُّر كبير في عرض العناصر عندما تكون الصورة متاحة (ربما من خلال <link rel=preload> ولكن لم يتم استخدامها لفترة طويلة، وغالبًا ما يكون ذلك بسبب الحاجة إلى JavaScript من جهة العميل لعرض الصورة.

نأمل أن يساعد إتاحة هذه البيانات في CrUX على مستوى المصدر وعنوان URL (وفقًا لمعايير الأهلية المعتادة) في تسهيل تحسين المواقع الإلكترونية لمقياس LCP.

أنواع موارد LCP

بما أنّه من الأفضل عرض الأجزاء الفرعية لمقاييس LCP للصور، تحدّ CrUX من هذه البيانات لتقتصر على الصفحات التي تحتوي على صور. لذلك، من المهم معرفة عدد عمليات LCP التي تتضمن صورًا مقارنةً بعمليات LCP التي تتضمّن نصًا (مثل <h1> العناوين والفقرات الطويلة).

بالإضافة إلى الأجزاء الفرعية لصورة LCP، تتضمّن واجهات برمجة التطبيقات في CrUX الآن أيضًا تفاصيل عن الموارد التي تعرض تقسيم عمليات تحميل صفحات LCP بين النصوص والصور.

على سبيل المثال، للحصول على أنواع موارد LCP لموقع https://web.dev/ لـ PHONE مشاهدة صفحة، يمكنك استخدام الأمر curl التالي (مرة أخرى، استبدِل API_KEY بـ مفتاحك الخاص):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["largest_contentful_paint_resource_type"]}'

وستتلقّى ردًا على النحو التالي:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_resource_type": {
        "fractions": {
          "image": 0.0155,
          "text": 0.9845
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

تم أيضًا تعديل "البيانات المرئية في CrUX" لعرض هذه البيانات:

رسم بياني لأنواع موارد LCP في أداة العروض المرئية في CrUX يعرض نقطتَي بيانات لنوعَي الموارد — أنواع موارد LCP في "البيانات المرئية في CrUX"

في الصفحة الرئيسية لموقع web.dev، على سبيل المثال، نرى أنّ% 98.5 من عمليات سرعة عرض أكبر محتوى مرئي كانت في الواقع عمليات سرعة عرض أكبر محتوى مرئي نصي، لذا تكون الأجزاء الفرعية لسرعة عرض أكبر محتوى مرئي من الصور أقل فائدة لهذه الصفحة. في هذه الحالة، يمكننا استخدام مقياسَي TTFB وFCP الأصليَين كبيانات تشخيصية أفضل.

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

أنواع موارد مقياس LCP هي أداة تشخيصية أخرى مفيدة لفهم مقياس LCP وتحسينه، لا سيما لمعرفة مدى فائدة الأجزاء الفرعية لصورة مقياس LCP.

معلومات تشخيص وقت استجابة الإرسال

لقد وسّعنا أيضًا نطاق مقياس RTT الذي تم تقديمه لأول مرة في آب (أغسطس) 2024.

تصنيفات RTT الثلاثية

أضفنا ثلاث فئات إلى واجهات برمجة تطبيقات CrUX تعرض ثلاث مجموعات من كثافة RTT:

وقت استجابة الشبكة	البدء	إنهاء
منخفض	0 مللي ثانية	‫< 75 مللي ثانية
الوسيط	75 مللي ثانية	‫< 275 مللي ثانية
عالية	275 مللي ثانية	∞

وتوفّر هذه الحِزم معلومات أكثر من فئات ECT السابقة التي كانت تتضمّن كل ما تقلّ مدته عن 270 ملي ثانية في الفئة 4g. ومع التطورات في تكنولوجيا الشبكات منذ إطلاق هذه الفئات، سجّلت معظم المواقع الإلكترونية معظم زياراتها في هذه الفئة، ما جعل هذا التصنيف أقل فائدة.

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

تتوفّر هذه الحِزم في واجهات برمجة تطبيقات CrUX، على سبيل المثال web.dev لـ PHONE مرّات الاطّلاع على الصفحة (مرة أخرى، استبدِل API_KEY بـ مفتاحك الخاص):

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["round_trip_time"]}'

ما يؤدي إلى عرض النتيجة التالية:

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "round_trip_time": {
        "histogram": [
          {
            "start": 0,
            "end": 75,
            "density": 0.1524
          },
          {
            "start": 75,
            "end": 275,
            "density": 0.6641
          },
          {
            "start": 275,
            "density": 0.1835
          }
        ],
        "percentiles": {
          "p75": 230
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

تظهر الحِزم في CrUX Vis عند اختيار التوزيعات:

يعرض الرسم البياني لمدّة استجابة الطلب في CrUX Vis سلسلة بيانات كاملة لبيانات مدّة استجابة الطلب وتفاصيل التوزيع لآخر نقطتَي بيانات. — بيانات وقت استجابة الطلب في أداة العروض المرئية في CrUX

وقت استجابة الطلب في BigQuery

بالإضافة إلى توسيع نطاق مقياس RTT في واجهات برمجة التطبيقات في CrUX ليشمل الحِزم الثلاثية، وفّرنا أيضًا البيانات في مجموعة بيانات BigQuery الشهرية، بما في ذلك مخطّط بياني هرمي كامل في حِزم مدتها 25 ملي ثانية في الجداول الأوّلية والحِزم الثلاثية وقيم p75 في الجداول المحسّنة.

يتيح ذلك فهمًا أعمق لتوزيع البيانات خارج الحِزم الثلاث المتوفّرة في واجهات برمجة تطبيقات CrUX. ويسمح لنا ذلك أيضًا بإعادة إنشاء تفاصيل ECT التي تمت إزالتها من CrUX اعتبارًا من هذا الشهر (مزيد من المعلومات حول ذلك لاحقًا)، مع تغيير طفيف في الحدّ الأدنى الذي يبلغ 275 ملي ثانية لـ 4g بدلاً من الحدّ الأدنى السابق الذي يبلغ 270 ملي ثانية. تبقى تفاصيل وقت الاستجابة للطلبات (التي يتم الحصول عليها الآن من بيانات وقت استجابة الطلب) متاحة في جداول CrUX في BigQuery حتى تتمكّن أدوات مثل لوحة بيانات CrUX من مواصلة عرض هذه التفاصيل.

تتضمّن مجموعة بيانات BigQuery أيضًا بيانات حسب البلد (على النحو المحدّد في ISO 3166-1). يتيح ذلك إجراء تحليل أعمق يمكن أن يكون مفيدًا لشرح سبب سوء مقاييس الأداء لدى بعض المستخدمين. على سبيل المثال، يمكننا الاطّلاع على بيانات مستخدمي هواتف Google من خلال الاطّلاع على بيانات https://www.google.com:

SELECT
  `chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
  least(500, p75_rtt) AS capped_p75_rtt,
  p75_rtt
FROM
  `chrome-ux-report.materialized.country_summary`
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202501 AND
  device = 'phone'
ORDER BY
  p75_rtt DESC,
  country_code

بعد ذلك، نعرض البيانات على خريطة جغرافية:

عرض وقت استجابة الطلب حسب البلد مع معظم البلدان بدرجات مختلفة من اللون الأخضر، باستثناء منطقة جنوب الصحراء الكبرى وأجزاء من الشرق الأوسط وآسيا الوسطى والصين باللون الأصفر والبرتقالي والأحمر — الشريحة المئوية الخامسة والسبعون لمقياس RTT للهاتف حسب البلد في `https://www.google.com`
(بيانات المصدر مع الرسم البياني التفاعلي).

يمكننا أن نرى أنّه في حين أنّ معظم أنحاء العالم (لا سيما "العالم الغربي") تحقّق أوقات استجابة جيدة جدًا، تواجه أفريقيا جنوب الصحراء الكبرى وأجزاء من الشرق الأوسط وأجزاء من آسيا صعوبة أكبر. في الواقع، تمّ ضبط الحدّ الأقصى للرسم البياني على 500 ملي ثانية لوقت استجابة الطلب، لأنّ استخدام البيانات الكاملة قد أدى إلى تشويه الألوان، لا سيما مع إريتريا التي تبلغ النسبة المئوية للحدّ الأدنى من الأداء فيها 3,850 ملي ثانية.

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

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

إزالة سمة ECT

التغيير النهائي في إصدار شباط (فبراير) 2025 هو إيقاف سمة "نوع الاتصال الفعّال" (ECT) نهائيًا من BigQuery (سبق أن أزلنا RTT من واجهات برمجة التطبيقات اعتبارًا من أيلول (سبتمبر) 2024 عندما طرحنا مقياس RTT كبديل لها).

كما ذكرنا سابقًا في هذه المشاركة، يسمح مقياس RTT بعرض أكثر دقة لتفاصيل الاتصال لزوّار الموقع الإلكتروني. يمكنك أيضًا إعادة إنشاء حِزم ECT من هذه الرسوم البيانية للشرائح. (من الناحية الفنية، يجب أن يكون وقت الاستجابة للشبكة (ECT) عبارة عن مزيج من وقت استجابة الشبكة (RTT) وسرعة التحميل، ولكن لم يستخدم Chrome سوى وقت استجابة الشبكة (RTT)).

يتمثل الاختلاف المهم في أنّ ECT كانت سمة في CrUX، ما يعني أنّه يمكن تقسيم المقاييس الأخرى حسب ECT. ووقت الاستجابة هو مقياس CrUX وليس سمة، لذا لا يمكن عرض LCP حسب وقت الاستجابة على سبيل المثال، ولكن يمكن فقط عرض أوقات الاستجابة حسب السمات الأخرى (نوع الجهاز والبلد).

قد يبدو ذلك أكثر تقييدًا، ولكنّ الانتقال من السمة إلى المقياس يفتح في الواقع المزيد من البيانات في CrUX. ويرجع ذلك إلى أنّ CrUX لديها حدود دنيا معيّنة قبل أن نتمكّن من عرض البيانات. سبق أن جعلنا السمات اختيارية في عام 2022، ما يعني أنّنا أزلنا ECT أو الجهاز عند الضرورة لإعداد التقارير على مستوى أعلى، ولكنّ المقاييس التي لم تكن متوفّرة في معظم عمليات تحميل الصفحات (مدى استجابة الصفحة لتفاعلات المستخدم (INP) وأنواع التنقّل المختلفة والآن الأجزاء الفرعية لصورة LCP) كانت غالبًا غير متاحة للمصادر في BigQuery.

من خلال تقليل عدد السمات، تصبح البيانات أقل تقسيمًا، وبالتالي يزداد عدد مصادر البيانات التي تستوفي الحد الأدنى من المتطلبات. في كانون الثاني (يناير)، أبلغنا عن INP بنسبة% 68.1 من مصادر الزيارات، في حين أنّنا أبلغنا عن INP بنسبة% 64.5 فقط من مصادر الزيارات في مجموعة بيانات كانون الأول (ديسمبر). تنطبق الآلية أيضًا على أنواع التنقّل وأجزاء LCP وأنواع الموارد في هذا الإصدار، وتستفيد جميعها من إزالة سمة ECT. في واجهات برمجة التطبيقات في CrUX، بدأ تطبيق التغطية المتزايدة اعتبارًا من أوائل شباط (فبراير).

ستظل أعمدة ECT في BigQuery للحفاظ على اتساقها مع مجموعات البيانات السابقة، وستظل بيانات ECT في العروض المحسّنة متاحة، ولكن استنادًا إلى معلومات RTT (مع اختلاف 5 مللي ثانية لكل من 3g و4g كما هو موضّح سابقًا) بالإضافة إلى RTT p75 وثلاث الحِزم الجديدة.

الخاتمة

توفّر إضافة المزيد من المقاييس إلى مجموعة بيانات CrUX العامة لمالكي المواقع الإلكترونية والباحثين الكثير من المعلومات للمساعدة في تشخيص مشاكل الأداء وحلّها في نهاية المطاف.

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

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