หน้านี้ได้รับการแปลโดย Cloud Translation API

ตอนนี้ส่วนย่อยของรูปภาพ LCP และ RTT พร้อมใช้งานใน CrUX แล้ว

Barry Pollard

Johannes Henkel

เผยแพร่: 11 กุมภาพันธ์ 2025

รายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ฉบับเดือนกุมภาพันธ์ 2025 ประกอบด้วยเมตริกใหม่ (และที่เปลี่ยนแปลง) ที่น่าสนใจหลายรายการ ดังนี้

ชิ้นส่วนย่อยของรูปภาพและประเภททรัพยากร Largest Contentful Paint (LCP)
รายละเอียดระยะเวลารับส่งข้อมูล (RTT)
การนํามิติข้อมูลประเภทการเชื่อมต่อที่มีผล (ECT) ออก

ข้อมูลเหล่านี้จะให้ข้อมูลเชิงลึกที่มากขึ้นเกี่ยวกับเมตริกประสิทธิภาพของต้นทางและ URL ที่มีอยู่ใน CrUX และเราจะอธิบายเหตุผลโดยละเอียดในโพสต์นี้

ข้อมูลการวินิจฉัย LCP

ก่อนหน้านี้เราได้แนะนำแนวคิดเกี่ยวกับส่วนย่อยของ LCP ใน Google I/O 2022 เป็นเทคนิคที่มีประสิทธิภาพในการแจกแจงเวลา LCP สำหรับหน้าเว็บที่มี LCP ของรูปภาพออกเป็นคอมโพเนนต์ย่อยๆ เพื่อให้คุณมุ่งเน้นที่การเพิ่มประสิทธิภาพสาเหตุที่ถูกต้องของ LCP ที่สูง

การวิเคราะห์ข้อมูลห้องทดลองของ HTTP Archive ในการบรรยายครั้งนั้นแสดงให้เห็นว่าเวลาในการดาวน์โหลดรูปภาพมักเป็นส่วนที่น้อยที่สุดของเวลา LCP เครื่องมือทดสอบจำนวนมาก (รวมถึง Lighthouse ของ Google เอง) มักเน้นที่คำแนะนำในการเพิ่มประสิทธิภาพรูปแบบและขนาดรูปภาพเพื่อลดเวลาในการดาวน์โหลดและปรับปรุงประสิทธิภาพ แม้ว่าจะยังคงถูกต้อง แต่การวิเคราะห์แสดงให้เห็นว่าอาจมีการเน้นคำแนะนำมากเกินไป และปัญหาที่ใหญ่กว่าคือความล่าช้าก่อนที่เบราว์เซอร์จะพบรูปภาพและเริ่มดาวน์โหลด

แม้ว่าการวิเคราะห์ข้อมูลในการทดสอบจะมีประโยชน์ แต่การใช้งานเว็บในชีวิตจริงมักจะแตกต่างกันไป ดังนั้นความสามารถในการดูข้อมูลย่อยเหล่านี้สำหรับข้อมูลภาคสนามจึงมีความสําคัญ โพสต์ที่เผยแพร่เมื่อปีที่แล้วยืนยันความเข้าใจผิดที่พบบ่อยเกี่ยวกับวิธีเพิ่มประสิทธิภาพ LCP ด้วยข้อมูลภาคสนาม

ชิ้นส่วนย่อยของรูปภาพ LCP

ในการเผยแพร่ครั้งนี้ เจ้าของเว็บไซต์จะตรวจสอบเว็บไซต์ของตนเองเพื่อหา LCP ของรูปภาพในส่วนย่อยได้ที่ระดับต้นทางหรือระดับ URL

ส่วนย่อยใช้ได้กับรูปภาพเท่านั้น และจะไม่รวมรูปภาพเฟรมแรกของวิดีโอ (ซึ่งมีความซับซ้อนกว่าเล็กน้อยเนื่องจากเราไม่สามารถวัดเวลาการดาวน์โหลดทั้งหมดได้) นอกจากนี้ ระบบจะไม่รวมข้อมูลของส่วนย่อยของข้อความด้วย เนื่องจากข้อมูลดังกล่าวมีประโยชน์น้อยกว่าและอาจทำให้ตัวเลข LCP ของรูปภาพบิดเบือน สําหรับเว็บไซต์ที่ประกอบด้วย LCP ที่เป็นข้อความส่วนใหญ่ เมตริก TTFB โดยรวมและ FCP โดยรวมจะเป็นรายละเอียดที่มีประโยชน์ แต่โปรดทราบว่าเมตริกเหล่านี้จะแสดงข้อมูล LCP ทั้งหมด ไม่ใช่เฉพาะ LCP ที่เป็นข้อความ สุดท้าย ระบบจะรวบรวมข้อมูลส่วนย่อยของรูปภาพเมื่อโหลดหน้าเว็บทั้งหน้าเท่านั้น ซึ่งแตกต่างจากเมตริก LCP ที่รวบรวมข้อมูลในการไปยังหน้าก่อนหน้าและหน้าถัดไป รวมถึงหน้าที่แสดงผลล่วงหน้าด้วย

ข้อมูลนี้เพิ่มลงใน CrUX API และ CrUX History API ตั้งแต่เดือนกุมภาพันธ์ 2025 (หมายเหตุ: ไม่ใช่ BigQuery) CrUX History API มีข้อมูล 2 สัปดาห์เมื่อเปิดตัว และจะเพิ่มขึ้นเป็นประวัติ 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 ให้รวมข้อมูลนี้ไว้ด้วย และคาดว่าเครื่องมืออื่นๆ ของบุคคลที่สามที่ใช้ CrUX API จะแสดงข้อมูลอันมีค่านี้ด้วย

กราฟส่วนย่อยของรูปภาพ LCP ใน CrUX Vis ที่แสดงจุดข้อมูล 2 จุดสำหรับส่วนย่อย 4 ส่วน — ส่วนย่อยของรูปภาพ LCP ในการแสดงภาพ CrUX

ในตัวอย่างนี้ เราเห็นว่าระยะเวลาในการโหลดทรัพยากรเป็นองค์ประกอบที่เล็กที่สุดสําหรับเว็บไซต์สื่อยอดนิยม โอกาสที่แท้จริงในการปรับปรุงเว็บไซต์นี้อยู่ที่ TTFB และความล่าช้าในการโหลดทรัพยากร โดยมีโอกาสน้อยลงในความล่าช้าในการแสดงผลองค์ประกอบ

ค่าที่สูงในแต่ละส่วนย่อยบ่งบอกถึงปัญหาที่แตกต่างกัน ดังนี้

Time To First Byte (TTFB) ที่สูงมักบ่งบอกถึงปัญหาเกี่ยวกับเซิร์ฟเวอร์ เครือข่าย หรือการเปลี่ยนเส้นทาง ตามที่อธิบายไว้ในเพิ่มประสิทธิภาพ TTFB
เวลาในการตอบสนองของการโหลดทรัพยากรสูงบ่งชี้ว่าเบราว์เซอร์ค้นพบรูปภาพ LCP ช้า เช่น รูปภาพ LCP ที่ JavaScript ฝั่งไคลเอ็นต์แทรกเข้ามาซึ่งใช้เวลาสักครู่จึงจะทํางาน
ระยะเวลาในการโหลดทรัพยากรสูงเป็นกรณีที่คุณควรพิจารณาลดขนาดการดาวน์โหลดรูปภาพ
เวลาในการแสดงผลองค์ประกอบล่าช้าสูงคือเมื่อรูปภาพพร้อมใช้งาน (อาจผ่าน <link rel=preload> แต่ไม่ได้ใช้งานเป็นเวลานาน ซึ่งมักเกิดจากต้องใช้ JavaScript ฝั่งไคลเอ็นต์เพื่อแสดงรูปภาพ

ประเด็นสําคัญ: เนื่องจากข้อมูลนี้แสดงข้อมูลรวมจากการดูหน้าเว็บหลายหน้า ระบบจึงแสดงข้อมูลย่อยของรูปภาพเป็นเปอร์เซ็นไทล์ที่ 75 ดังนั้นผลรวมของข้อมูลย่อยจึงไม่ควรเท่ากับ LCP ทั้งหมดที่ 75 ควรใช้ส่วนย่อยของรูปภาพ LCP เพื่อบ่งบอกความสำคัญของส่วนย่อยแบบสัมพัทธ์แทนการแจกแจงค่า LCP ของเปอร์เซ็นต์ไทล์ 75 ที่แน่นอน

เราหวังว่าการทำให้ข้อมูลนี้พร้อมใช้งานใน CrUX ทั้งในระดับต้นทางและระดับ URL (ขึ้นอยู่กับเกณฑ์การมีสิทธิ์ตามปกติ) จะช่วยให้เว็บไซต์เพิ่มประสิทธิภาพเมตริก LCP ได้ง่ายขึ้น

ประเภททรัพยากร LCP

เนื่องจากส่วนย่อยเหมาะสําหรับดู LCP ของรูปภาพ CrUX จึงจํากัดข้อมูลนี้ไว้สําหรับหน้าที่มีรูปภาพเท่านั้น ดังนั้น คุณจึงควรทำความเข้าใจว่า LCP ของคุณมีจำนวนเท่าใดที่เป็น LCP รูปภาพเมื่อเทียบกับ LCP ข้อความ (เช่น <h1> บรรทัดแรกและย่อหน้ายาว)

นอกจากข้อมูลย่อยของรูปภาพ LCP แล้ว ตอนนี้ CrUX API ยังมีรายละเอียดทรัพยากรที่แสดงการแยกการโหลดหน้า 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 ที่แสดงจุดข้อมูล 2 จุดสําหรับทรัพยากร 2 ประเภท — ประเภททรัพยากร LCP ใน CrUX Vis

ตัวอย่างเช่น สําหรับหน้าแรกของ web.dev เราพบว่า LCP 98.5% เป็น LCP ที่เป็นข้อความ ดังนั้นส่วนย่อยของรูปภาพ LCP จึงมีประโยชน์น้อยสําหรับหน้านี้ ในกรณีนี้ เราสามารถใช้เมตริก TTFB และ FCP เดิมเป็นรายละเอียดการวินิจฉัยที่อาจดีกว่า

สำคัญ: ประเภททรัพยากร LCP จะรวมวิดีโอไว้ในเศษส่วนของรูปภาพ เนื่องจากเฟรมแรกของวิดีโอคือสิ่งที่ระบบนับสำหรับ LCP (รวมถึงสำหรับภาพเคลื่อนไหว) อย่างไรก็ตาม ส่วนย่อยของรูปภาพ LCP มีไว้สำหรับองค์ประกอบรูปภาพจริงเท่านั้น เนื่องจากเวลาในการดาวน์โหลดทรัพยากรนั้นคํานวณได้ยากกว่าสําหรับวิดีโอสตรีมมิง จึงไม่ได้รวมอยู่ในตอนนี้ ด้วยเหตุเดียวกัน ระบบจะรวบรวมประเภททรัพยากรเฉพาะเมื่อมีการโหลดหน้าเว็บทั้งหมดเท่านั้น ซึ่งแตกต่างจากเมตริก LCP ที่รวบรวมจากการไปยังหน้าเว็บก่อนหน้าและหน้าเว็บที่แสดงผลล่วงหน้าด้วย

ประเภททรัพยากร LCP เป็นเครื่องมือการวินิจฉัยที่มีประโยชน์อีกอย่างหนึ่งสําหรับทําความเข้าใจและปรับปรุง LCP โดยเฉพาะสําหรับการดูว่าชิ้นส่วนย่อยของรูปภาพ LCP มีประโยชน์เพียงใด

ข้อมูลการวินิจฉัย RTT

นอกจากนี้ เรายังได้ขยายเมตริก RTT ที่เปิดตัวครั้งแรกในเดือนสิงหาคม 2024 ด้วย

กล่อง 3 ช่องของ RTT

เราได้เพิ่มกลุ่ม 3 กลุ่มลงใน CrUX API ซึ่งแสดงความหนาแน่นของ RTT 3 กลุ่ม ได้แก่

เวลาในการตอบสนองของเครือข่าย	เริ่ม	สิ้นสุด
ต่ำ	0 มิลลิวินาที	< 75 มิลลิวินาที
ปานกลาง	75 มิลลิวินาที	< 275 มิลลิวินาที
สูง	275 มิลลิวินาที	∞

ข้อมูลในกล่องเหล่านี้ให้ข้อมูลมากกว่าหมวดหมู่ ECT ก่อนหน้า ซึ่งรวมทุกอย่างที่น้อยกว่า 270 มิลลิวินาทีไว้ในหมวดหมู่ 4g เทคโนโลยีเครือข่ายที่ก้าวหน้าขึ้นนับตั้งแต่เปิดตัวหมวดหมู่เหล่านั้น ทำให้เว็บไซต์ส่วนใหญ่มีการเข้าชมส่วนใหญ่ในหมวดหมู่นั้นๆ การจัดหมวดหมู่นี้จึงมีประโยชน์น้อยลง

ด้วยเหตุนี้ เราจึงขอแนะนำให้ใช้ป้ายกํากับการกระจาย ต่ำ ปานกลาง และสูง แทนป้ายกํากับดี ต้องปรับปรุง และแย่ เมตริกเหล่านี้ไม่ใช่เมตริกที่เจ้าของเว็บไซต์ปรับปรุงได้โดยตรง จึงถือเป็นเมตริกการวินิจฉัยเพื่อทําความเข้าใจเมตริกอื่นๆ และสาเหตุที่อาจแตกต่างไปจากสิ่งที่คาดไว้ เมตริกเหล่านี้ยังช่วยอธิบายสาเหตุที่เมตริกอื่นๆ เปลี่ยนแปลงเมื่อเวลาผ่านไป แม้ว่าเว็บไซต์จะไม่มีการเปลี่ยนแปลงก็ตาม หากเมตริกเหล่านี้แสดงการเปลี่ยนแปลงฐานผู้ใช้

ข้อมูลเหล่านี้มีอยู่ใน CrUX API เช่น 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 ทั้งหมดและรายละเอียดการแจกแจงสำหรับจุดข้อมูล 2 รายการล่าสุด — ข้อมูล RTT ใน CrUX Vis.

RTT ใน BigQuery

นอกจากการขยายเมตริก RTT ใน CrUX API ให้รวมกลุ่ม 3 ช่องแล้ว เรายังทำให้ข้อมูลพร้อมใช้งานในชุดข้อมูล BigQuery รายเดือน รวมถึงฮิสโตแกรมแบบเต็มในบัคเก็ต 25 มิลลิวินาทีในตารางดิบ และกลุ่ม 3 ช่องและค่า p75 ในตารางที่แสดงผลแล้ว

วิธีนี้ช่วยให้เข้าใจการกระจายข้อมูลได้ลึกซึ้งยิ่งขึ้นนอกเหนือจากการเก็บข้อมูล 3 ประเภทที่มีใน CrUX API นอกจากนี้ เรายังสร้างรายละเอียด ECT ขึ้นมาใหม่ได้อีกด้วย ซึ่งถูกนําออกจาก CrUX ตั้งแต่เดือนนี้ (โปรดดูรายละเอียดเพิ่มเติมในภายหลัง) โดยจะมีการเปลี่ยนแปลงเล็กน้อยตรงเกณฑ์ 275 มิลลิวินาทีสําหรับ 4g แทนเกณฑ์ 270 มิลลิวินาทีก่อนหน้านี้ รายละเอียด ECT (ซึ่งตอนนี้มาจากข้อมูล RTT) จะยังคงอยู่ในตารางที่แสดงผลของ 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 ตามประเทศ โดยประเทศส่วนใหญ่เป็นสีเขียวหลายเฉด ยกเว้นพื้นที่แอฟริกาใต้ตอนล่าง บางพื้นที่ของตะวันออกกลางและเอเชียกลาง และจีนที่เป็นสีเหลือง สีส้ม และสีแดง — RTT ทางโทรศัพท์ตามเปอร์เซ็นไทล์ที่ 75 แยกตามประเทศสำหรับ `https://www.google.com`
(ข้อมูลแหล่งที่มาที่มีแผนภูมิแบบอินเทอร์แอกทีฟ)

เราพบว่าแม้ว่าพื้นที่ส่วนใหญ่ของโลก (โดยเฉพาะ "โลกตะวันตก") จะมี RTT ที่ดีมากๆ แต่พื้นที่ในแอฟริกาใต้ซาฮารา บางส่วนของตะวันออกกลาง และบางส่วนของเอเชียกลับมีปัญหามากกว่า จริงๆ แล้วกราฟมีขีดจำกัดที่ RTT 500 มิลลิวินาที เนื่องจากการใช้ข้อมูลทั้งหมดทำให้สีบิดเบือน โดยเฉพาะเมื่อเอธิโอเปียอยู่ที่เปอร์เซ็นต์ไทล์ที่ 75 ของ 3,850 มิลลิวินาที

ซึ่งจะมีประโยชน์เมื่อรูปแบบการเข้าชมมีการเปลี่ยนแปลงด้วย ตัวอย่างเช่น ผู้ใช้จากประเทศเหล่านี้ที่มี RTT สูงกว่าอาจมีสัดส่วนมากกว่า ซึ่งอาจอธิบายสถิติ Core Web Vitals ที่แย่ลงได้ แม้ว่าเว็บไซต์จะไม่มีการทําการเปลี่ยนแปลงใดๆ ก็ตาม

แม้ว่าเว็บไซต์จะปรับปรุง RTT โดยตรงไม่ได้ แต่การทำให้ข้อมูลนี้พร้อมใช้งานสำหรับผู้เข้าชมเว็บไซต์จะช่วยให้เข้าใจผู้ใช้เว็บไซต์ทั่วโลกได้ดียิ่งขึ้น นอกจากนี้ ยังเปิดโอกาสให้วิเคราะห์ได้อีกมากมายในอนาคต และเราหวังว่านักวิจัยจะค้นพบข้อมูลเชิงลึกที่น่าสนใจจากชุดข้อมูลนี้

การนำมิติข้อมูล ECT ออก

การเปลี่ยนแปลงสุดท้ายในรุ่นเดือนกุมภาพันธ์ 2025 คือการเลิกใช้งานมิติข้อมูลประเภทการเชื่อมต่อที่มีประสิทธิภาพ (ECT) จาก BigQuery (เราได้นํา RTT ออกจาก API ตั้งแต่เดือนกันยายน 2024 แล้วเมื่อเราเปิดตัวเมตริก RTT เข้ามาแทนที่)

ดังที่ได้กล่าวไว้ก่อนหน้านี้ในโพสต์นี้ เมตริก RTT ช่วยให้คุณเห็นรายละเอียดการเชื่อมต่อของผู้เข้าชมเว็บไซต์ได้ละเอียดยิ่งขึ้น คุณยังสร้างที่เก็บข้อมูล ECT อีกครั้งจากฮิสโตแกรมเหล่านั้นได้ด้วย (ในทางเทคนิคแล้ว ECT ควรเป็นค่ารวมของ RTT และความเร็วในการรับข้อมูล แต่Chrome ใช้เฉพาะ RTT เท่านั้น)

ความแตกต่างที่สําคัญคือ ECT เป็นมิติข้อมูล CrUX ซึ่งหมายความว่าเมตริกอื่นๆ สามารถแบ่งกลุ่มตาม ECT ได้ RTT คือเมตริก CrUX ไม่ใช่มิติข้อมูล คุณจึงไม่สามารถดู LCP ตาม RTT ได้ แต่จะดู RTT ตามมิติข้อมูลอื่นๆ (ประเภทอุปกรณ์และประเทศ) ได้เท่านั้น

ฟังดูจํากัดมากขึ้น แต่การเปลี่ยนจากมิติข้อมูลเป็นเมตริกจะปลดล็อกข้อมูลใน CrUX ได้มากขึ้น เนื่องจาก CrUX มีเกณฑ์ขั้นต่ำบางอย่างที่เราจะต้องปฏิบัติตามก่อนจึงจะแสดงข้อมูลได้ เราได้ทำให้มิติข้อมูลเป็นตัวเลือกในปี 2022 แล้ว ซึ่งหมายความว่าเราได้นํา ECT หรืออุปกรณ์ออกเมื่อจําเป็นต้องรายงานในระดับที่สูงขึ้น แต่เมตริกที่ไม่ได้อยู่ในการโหลดหน้าเว็บส่วนใหญ่ (การโต้ตอบกับการแสดงผลภาพถัดไป (INP) ประเภทการนําทางต่างๆ และตอนนี้คือส่วนย่อยของรูปภาพ LCP) มักไม่พร้อมใช้งานสําหรับต้นทางใน BigQuery

การลดจํานวนมิติข้อมูลจะทําให้ข้อมูลมีการแบ่งกลุ่มน้อยลง ดังนั้นจํานวนต้นทางที่เป็นไปตามข้อกําหนดขั้นต่ำเหล่านี้จึงเพิ่มขึ้น ในเดือนมกราคม เรารายงาน INP สำหรับต้นทาง 68.1% ส่วนสำหรับชุดข้อมูลเดือนธันวาคม เรารายงาน INP สำหรับต้นทางเพียง 64.5% กลไกนี้มีผลกับประเภทการนําทาง ส่วนย่อยของ LCP และประเภททรัพยากรในรุ่นนี้ด้วย ซึ่งทั้งหมดนี้จะได้รับประโยชน์จากการนํามิติข้อมูล ECT ออก ใน CrUX API การครอบคลุมที่เพิ่มขึ้นมีผลตั้งแต่ต้นเดือนกุมภาพันธ์

คอลัมน์ ECT จะยังคงอยู่ใน BigQuery เพื่อให้สอดคล้องกับชุดข้อมูลก่อนหน้า และข้อมูล ECT ในมุมมองที่แสดงผลจริงจะยังคงใช้งานได้ แต่จะอิงตามข้อมูล RTT (โดยมีความคลาดเคลื่อน 5 มิลลิวินาทีสําหรับ 3g และ 4g ตามที่ระบุไว้ก่อนหน้านี้) นอกเหนือจาก RTT p75 และ 3 กล่องใหม่

บทสรุป

การเพิ่มเมตริกอื่นๆ ลงในชุดข้อมูล CrUX สาธารณะจะช่วยให้เจ้าของเว็บไซต์และนักวิจัยมีข้อมูลมากขึ้นในการวินิจฉัยและแก้ไขปัญหาด้านประสิทธิภาพได้ในที่สุด

CrUX เป็นชุดข้อมูลสาธารณะที่มีข้อจํากัดบางอย่างเกี่ยวกับระดับรายละเอียดที่เราสามารถแสดงได้ เช่น ตัวเลือกองค์ประกอบแต่ละรายการจะแสดงใน CrUX ไม่ได้ เราขอแนะนําอย่างยิ่งให้เจ้าของเว็บไซต์ที่ต้องการรายละเอียดระดับนี้ใช้โซลูชัน RUM ซึ่งจะไม่มีข้อจํากัดมากนัก

อย่างไรก็ตาม ข้อมูลรวมในระดับที่สูงขึ้น เช่น ข้อมูลที่แสดงรายละเอียดไว้ในโพสต์นี้ จะช่วยปิดช่องว่างระหว่างการทราบว่าคุณมีปัญหากับสาเหตุของปัญหา เราหวังว่าข้อมูลเพิ่มเติมนี้จะเป็นประโยชน์ โปรดแจ้งให้เราทราบในกลุ่มสนทนาหากมีความคิดเห็นหรือข้อสงสัย