بخش های فرعی تصویر LCP و RTT اکنون در CrUX موجود است

بری پولارد
یوهانس هنکل
Johannes Henkel
X GitHub Mastodon

تاریخ انتشار: 11 فوریه 2025

انتشار فوریه 2025 گزارش تجربه کاربر Chrome (CrUX) شامل تعدادی معیارهای جدید (و تغییر یافته!) هیجان انگیز است:

هر یک از اینها بینش بیشتری را در مورد معیارهای عملکرد مبدا و URL های موجود در CrUX ارائه می دهد و در این پست به تفصیل دلیل آن را توضیح خواهیم داد.

اطلاعات تشخیصی LCP

ما در اصل مفهوم زیربخش‌های LCP را در Google I/O 2022 به‌عنوان تکنیکی مؤثر برای تقسیم زمان LCP برای صفحات دارای LCP تصویر به اجزای کوچک‌تر معرفی کردیم تا اطمینان حاصل کنیم که تلاش‌های خود را صرف بهینه‌سازی علت(های) صحیح LCP بالا می‌کنید.

تجزیه و تحلیل داده‌های آزمایشگاه بایگانی HTTP در آن سخنرانی نشان داد که زمان دانلود تصویر اغلب کوچک‌ترین بخش زمان LCP است. بسیاری از ابزارهای آزمایشگاهی (از جمله فانوس دریایی خود گوگل) اغلب بر توصیه هایی برای بهینه سازی فرمت و اندازه تصویر برای کاهش زمان دانلود و بهبود عملکرد متمرکز شده اند. در حالی که هنوز درست است، تجزیه و تحلیل نشان داد که ممکن است توصیه بیش از حد مورد تاکید قرار گرفته باشد و مشکل بزرگتر در تاخیرهای قبل از یافتن تصویر توسط مرورگر و شروع دانلود بود.

در حالی که تجزیه و تحلیل داده‌های آزمایشگاهی می‌تواند مفید باشد، نحوه استفاده از وب در زندگی واقعی اغلب می‌تواند متفاوت باشد، بنابراین دیدن این بخش‌ها برای داده‌های میدانی بسیار مهم است. پستی که سال گذشته منتشر شد، این تصور غلط رایج در مورد چگونگی بهینه‌سازی LCP با داده‌های میدانی را تأیید کرد.

زیربخش های تصویر LCP

با این نسخه، صاحبان سایت ممکن است سایت های خود را برای قسمت های فرعی برای LCP تصویر، در سطح مبدا یا URL بررسی کنند.

بخش‌های فرعی فقط برای تصاویر در دسترس هستند و این شامل اولین تصاویر فریم ویدیو نمی‌شود (که کمی پیچیده‌تر هستند زیرا نمی‌توانیم زمان دانلود کامل را اندازه‌گیری کنیم). بخش‌های فرعی متن نیز گنجانده نشده‌اند، زیرا کاربرد کمتری دارند و اعداد LCPهای تصویر را تحریف می‌کنند. برای سایت‌هایی که عمدتاً از LCPهای متنی ساخته شده‌اند، معیارهای کلی TTFB و FCP کلی، تفکیک‌های مفیدی هستند - اگرچه توجه داشته باشید که آنها در همه LCPها هستند و مختص LCPهای متنی نیستند. در نهایت، بخش‌های فرعی تصویر فقط در بارگذاری‌های کامل صفحه جمع‌آوری می‌شوند - بر خلاف معیار LCP که در پیمایش‌های رو به جلو و صفحات از پیش اجرا شده نیز جمع‌آوری می‌شود.

این داده ها از فوریه 2025 به CrUX API و CrUX History API اضافه شده است (توجه داشته باشید: BigQuery نیست). CrUX History API دارای دو هفته داده در زمان راه اندازی است و به مرور زمان به تاریخچه کامل 25 هفته ای افزایش می یابد. APIها داده ها را به عنوان صدک 75 هر فرعی که در میلی ثانیه بیان می شود در دسترس قرار می دهند.

به عنوان مثال، برای دریافت زیربخش های تصویر 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 را به‌روزرسانی کرده‌ایم تا این داده‌ها را شامل شود و انتظار داریم ابزارهای شخص ثالثی که از APIهای CrUX استفاده می‌کنند نیز این داده‌های ارزشمند را افشا کنند:

نمودار زیربخش های تصویر LCP در CrUX Vis که دو نقطه داده را برای چهار زیربخش نشان می دهد
زیربخش های تصویر LCP در CrUX Vis.

در این مثال، می‌توانیم ببینیم که برای یک سایت رسانه محبوب، مدت زمان بارگذاری منبع کوچک‌ترین مؤلفه است. فرصت های واقعی برای بهبود این سایت در TTFB و تاخیر بارگذاری منبع با فرصت کمتری در تاخیر رندر عنصر نهفته است.

مقادیر بالا در هر بخش نشان دهنده مسائل مختلف است:

  • High Time to First Byte (TTFB) معمولاً به مشکلات سرور، شبکه یا تغییر مسیر همانطور که در Optimize TTFB توضیح داده شده است اشاره می کند.
  • تأخیر زیاد بار منبع نشان می‌دهد که تصویر LCP دیر کشف شده است - برای مثال، یک تصویر LCP که توسط جاوا اسکریپت سمت کلاینت تزریق می‌شود و اجرای آن مدتی طول می‌کشد.
  • مدت زمان بارگذاری منابع بالا جایی است که باید به کاهش اندازه دانلود تصویر نگاه کنید.
  • تأخیر رندر بالای عنصر زمانی است که تصویر در دسترس است (شاید از طریق <link rel=preload> اما برای مدت طولانی استفاده نشده است - اغلب به دلیل نیاز به جاوا اسکریپت سمت کلاینت برای نشان دادن تصویر.

امیدواریم در دسترس قرار دادن این داده‌ها در CrUX در سطح مبدا و URL (با توجه به معیارهای واجد شرایط بودن معمول ) به بهینه‌سازی معیار LCP برای سایت‌ها کمک کند.

انواع منابع LCP

از آنجایی که بخش‌های فرعی به بهترین وجه برای LCPهای تصویر مشاهده می‌شوند، CrUX این داده‌ها را فقط به صفحات دارای تصاویر محدود می‌کند. بنابراین، مهم است که بدانید چه تعداد از LCPهای شما LCPهای تصویری هستند در مقابل LCPهای متنی (مانند سرفصل های <h1> و پاراگراف های طولانی، برای مثال).

علاوه بر بخش های فرعی تصویر LCP، API های 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 Vis نیز برای نمایش این داده ها به روز شده است:

نمودار انواع منابع LCP در CrUX Vis که دو نقطه داده را برای دو نوع منبع نشان می دهد.
انواع منابع LCP در CrUX Vis

برای مثال برای صفحه اصلی web.dev، می‌توانیم ببینیم که 98.5٪ از LCPها در واقع LCPهای متنی بودند، بنابراین زیربخش‌های تصویر LCP برای این صفحه کمتر مفید هستند. در آن صورت، می‌توانیم از معیارهای اصلی TTFB و FCP به عنوان یک شکست تشخیصی بالقوه بهتر استفاده کنیم.

انواع منابع LCP یکی دیگر از ابزارهای تشخیصی مفید برای درک و بهبود LCP است، به ویژه برای دانستن اینکه زیربخش های تصویر LCP چقدر مفید هستند.

اطلاعات تشخیصی RTT

ما همچنین معیار RTT را که برای اولین بار در آگوست 2024 معرفی شد، گسترش دادیم.

سطل های سه گانه RTT

ما سه‌بین‌ها را به APIهای CrUX اضافه کرده‌ایم که سه گروه‌بندی از چگالی RTT را نشان می‌دهند:

تأخیر شبکه شروع کنید پایان
کم 0 میلی ثانیه < 75 میلی ثانیه
متوسط 75 میلی ثانیه < 275 میلی ثانیه
بالا 275 میلی ثانیه ∞

این سطل‌ها نسبت به دسته‌های قبلی ECT که هر چیزی کمتر از 270 میلی‌ثانیه را در دسته 4g شامل می‌شد، آموزنده‌تر هستند. با پیشرفت‌های فناوری شبکه از زمان راه‌اندازی آن‌ها، اکثر سایت‌ها بیشتر ترافیک خود را در آن دسته دیدند که این دسته‌بندی را کمتر مفید کرده است.

به همین دلیل است که پیشنهاد می‌کنیم از برچسب‌های توزیع کم ، متوسط ​​و زیاد به جای برچسب‌های خوب ، نیاز به بهبود و ضعیف استفاده کنید. آنها معیارهایی نیستند که مالک سایت بتواند مستقیماً خودش آن را بهبود بخشد، و بنابراین معیارهای تشخیصی برای درک سایر معیارها و اینکه چرا ممکن است متفاوت از حد انتظار باشند، هستند. آنها همچنین می توانند توضیح دهند که چرا معیارهای دیگر در طول زمان حرکت می کنند، علیرغم اینکه سایت تغییر نمی کند اگر تغییری در پایگاه کاربر نشان دهد.

این سطل‌ها در APIهای 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 نشان داده می‌شوند:

نمودار RTT در CrUX Vis یک سری داده کامل از داده های RTT و تجزیه توزیع برای دو نقطه داده آخر
داده های RTT در CrUX Vis.

RTT در BigQuery

علاوه بر گسترش معیار RTT در APIهای CrUX برای شامل سه‌بین‌ها، داده‌ها را نیز در مجموعه داده ماهانه BigQuery شامل یک هیستوگرام کامل در سطل‌های 25 میلی‌ثانیه‌ای در جداول خام و سه‌بین‌ها و مقادیر p75 در جداول تحقق‌یافته در دسترس قرار داده‌ایم.

این اجازه می دهد تا درک عمیق تری از توزیع داده ها فراتر از tri-bin های موجود در API های CrUX داشته باشید. همچنین به ما امکان می‌دهد تا شکست ECT را که از این ماه از CrUX حذف شده است (در ادامه در مورد آن بیشتر توضیح دهیم) دوباره ایجاد کنیم - با تغییر جزئی آستانه 275 میلی‌ثانیه برای 4g به جای آستانه 270 میلی‌ثانیه قبلی. تفکیک‌های ECT (اکنون از داده‌های RTT تهیه می‌شوند) همچنان در جداول CrUX BigQuery موجود هستند، بنابراین ابزارهایی مانند داشبورد CrUX می‌توانند به نمایش این تفکیک ادامه دهند.

مجموعه داده BigQuery همچنین شامل داده ها بر اساس کشور است (همانطور که توسط ISO 3166-1 تعریف شده است). این امکان تحلیل عمیق‌تری را فراهم می‌کند که می‌تواند برای توضیح اینکه چرا معیارهای عملکرد برای برخی از کاربران بدتر هستند مفید باشد. برای مثال، می‌توانیم با نگاه کردن به داده‌های https://www.google.com به داده‌های کاربران Google Phone نگاه کنیم:

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 بر اساس کشور با اکثر کشورها در سایه های مختلف سبز، به جز کشورهای جنوب صحرا، بخش هایی از خاورمیانه و آسیای مرکزی، و چین در رنگ های زرد، نارنجی و قرمز.
صدک 75 تلفن RTT بر اساس کشور برای https://www.google.com
( داده منبع با نمودار تعاملی ).

ما می‌توانیم ببینیم که، در حالی که بیشتر نقاط جهان (به ویژه «جهان غربی») دارای RTTهای بسیار خوبی هستند، کشورهای جنوب صحرای آفریقا، بخش‌هایی از خاورمیانه و بخش‌هایی از آسیا بیشتر با مشکل مواجه هستند. در واقع نمودار روی 500 میلی‌ثانیه RTT محدود شده است، زیرا استفاده از داده‌های کامل رنگ‌ها را منحرف می‌کند - به‌ویژه با اریتره در صدک 75 3850 میلی‌ثانیه!

این همچنین می تواند زمانی که الگوهای ترافیک تغییر می کند مفید باشد. به عنوان مثال، نسبت بیشتری از کاربران از کشورهایی با RTT بالاتر ممکن است آمار بدتر Core Web Vitals را با وجود اینکه سایت چیزی تغییر نمی‌دهد توضیح دهند.

در حالی که سایت‌ها نمی‌توانند مستقیماً RTT را بهبود بخشند، اما در دسترس قرار دادن این داده‌ها توسط بازدیدکنندگان سایت به درک بهتر کاربران سایت شما در سراسر جهان کمک می‌کند. همچنین فرصت های زیادی برای تجزیه و تحلیل در آینده ایجاد می کند و امیدواریم محققان بینش های جالبی از این مجموعه داده پیدا کنند.

حذف بعد ECT

آخرین تغییر در نسخه فوریه 2025 بازنشستگی بعد نوع اتصال مؤثر (ECT) از BigQuery است (ما قبلاً RTT را از سپتامبر 2024 از APIها حذف کرده بودیم که در آن زمان معیار RTT را به عنوان جایگزین آن معرفی کردیم).

همانطور که قبلاً در این پست ذکر شد، معیار RTT اجازه می دهد تا دید دقیق تری از جزئیات اتصال بازدیدکنندگان یک سایت داشته باشید. حتی می توانید سطل های ECT را از آن هیستوگرام ها بازسازی کنید. (از نظر فنی، ECT باید ترکیبی از RTT و سرعت پایین لینک باشد ، اما کروم تا کنون فقط از RTT استفاده کرده است .)

یک تفاوت مهم این است که ECT یک بعد CrUX بود - به این معنی که سایر معیارها می توانند توسط ECT تقسیم شوند. RTT یک متریک CrUX به جای یک بعد است، بنابراین برای مثال نمی توان LCP را با RTT مشاهده کرد، بلکه فقط می توان RTT ها را با ابعاد دیگر (نوع دستگاه و کشور) مشاهده کرد.

این ممکن است محدودتر به نظر برسد، اما حرکت از بعد به متریک در واقع داده های بیشتری را در CrUX باز می کند. این به این دلیل است که CrUX قبل از اینکه بتوانیم داده ها را نشان دهیم، حداقل آستانه های مشخصی دارد. ما قبلاً ابعاد را در سال 2022 اختیاری کردیم به این معنی که ECT یا دستگاه را در صورت لزوم برای گزارش در سطح بالاتر حذف کردیم، اما معیارهایی که در بیشتر بارگیری‌های صفحه ( Interaction to Next Paint (INP) ، انواع مختلف پیمایش، و اکنون زیربخش‌های تصویر LCP) نبودند، اغلب برای مبدا در BigQuery در دسترس نبودند.

با کاهش تعداد ابعاد، داده ها کمتر تقسیم بندی می شوند، بنابراین تعداد مبداهایی که این حداقل نیازها را برآورده می کنند افزایش می یابد. در ژانویه، INP را برای 68.1٪ از مبدا گزارش می کنیم، در حالی که برای مجموعه داده دسامبر، ما INP را فقط برای 64.5٪ از مبدا گزارش می کنیم. این مکانیسم همچنین برای انواع ناوبری، بخش‌های فرعی LCP و انواع منابع در این نسخه اعمال می‌شود - همه آنها از حذف بعد ECT سود می‌برند. در CrUX APIها، افزایش پوشش از ابتدای فوریه اعمال شده است.

ستون‌های ECT برای سازگاری با مجموعه‌های داده قبلی در BigQuery باقی می‌مانند و داده‌های ECT در نماهای تحقق‌یافته در دسترس باقی می‌مانند، اما بر اساس اطلاعات RTT (با اختلاف 5 میلی‌ثانیه برای 3g و 4g همانطور که قبلا ذکر شد) علاوه بر RTT p75 و tri-bin‌های جدید.

نتیجه گیری

افزودن معیارهای بیشتر به مجموعه داده عمومی CrUX به صاحبان سایت و محققان اطلاعات بیشتری برای کمک به تشخیص و در نهایت رفع مشکلات عملکرد می دهد.

به عنوان یک مجموعه داده عمومی، CrUX دارای محدودیت‌های خاصی برای سطح جزئیاتی است که می‌توانیم نشان دهیم – برای مثال، انتخابگرهای عنصر منفرد هرگز نمی‌توانند در CrUX نشان داده شوند. به صاحبان سایت هایی که به دنبال این سطح از جزئیات هستند، اکیداً توصیه می شود که یک راه حل RUM را پیاده سازی کنند، که آنقدرها هم محدود نخواهد بود.

با این حال، داده‌های جمع‌آوری‌شده سطح بالاتر مانند آنچه که در این پست توضیح داده شده است، می‌تواند به پر کردن شکاف بین دانستن اینکه مشکل دارید و چرایی مشکل وجود دارد، کمک کند. امیدواریم این داده های اضافی مفید واقع شوند. اگر بازخورد یا سوالی دارید در گروه بحث با ما در میان بگذارید !