ประเภทการนำทางพร้อมใช้งานแล้วใน CrUX

Barry Pollard

Johannes Henkel

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

การไปยังส่วนต่างๆ ประเภทต่างๆ ส่งผลให้เมตริกประสิทธิภาพแตกต่างกัน ดังนั้นเมื่อดูประสิทธิภาพของเว็บไซต์ คุณควรทำความเข้าใจความถี่สัมพัทธ์ของประเภทต่างๆ เหล่านี้ ตัวอย่างเช่น เมื่อการนำทางใช้การย้อนกลับ (bfcache) ซึ่งมักจะทำให้การนำทางเกือบจะทันทีซึ่งจะแสดงในเมตริก LCP และ FCP จำนวนน้อยมาก รวมถึงทำให้เมตริก CLS และ INP ลดลง

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

เมตริก navigation_types มีอยู่ใน CrUX API รายวัน, CrUX History API (โดยมีประวัติ 3 สัปดาห์ในเบื้องต้นและจะเพิ่มการครอบคลุมแบบรายสัปดาห์ตลอด 6 เดือนถัดไป), ชุดข้อมูล CrUX BigQuery ล่าสุด และแดชบอร์ด CrUX การมีประวัติดังกล่าวยังช่วยให้เจ้าของเว็บไซต์ดูการเปลี่ยนแปลงของการใช้งานประเภทการนำทางเมื่อเวลาผ่านไปได้ด้วย วิธีนี้ทำให้ติดตามการปรับปรุงได้ (เช่น นำการบล็อก bfcache ออก) นอกจากนี้ยังช่วยอธิบายการเปลี่ยนแปลงของเมตริกต่างๆ แม้ว่าจะไม่ได้ทำการเปลี่ยนแปลงในเว็บไซต์ก็ตาม

ประเภทการนำทางที่มีให้บริการใน CrUX มีอะไรบ้าง

CrUX จำแนกประเภทการนำทางต่อไปนี้ในตารางต่อไปนี้

ในบางกรณี การโหลดหน้าเว็บอาจเป็นการผสมการนำทางประเภทต่างๆ ไว้ด้วยกัน ในกรณีนี้ CrUX จะรายงานการจับคู่แรกตามลำดับกลับของตารางก่อนหน้า (จากล่างขึ้นบน)

ข้อจำกัดของประเภทการนำทางใน CrUX

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

นอกจากนี้ CrUX ไม่สามารถระบุรายละเอียดของเมตริกอื่นๆ ตามประเภทการไปยังส่วนต่างๆ ได้ เนื่องจากจะทำให้จำนวนต้นทางและ URL ที่มีอยู่ใน CrUX ลดลงอีก

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

RUM ยังให้รายละเอียดเพิ่มเติมเกี่ยวกับปัญหาด้านประสิทธิภาพที่เฉพาะเจาะจงได้ ตัวอย่างเช่น แม้ว่า CrUX อาจบอกเป็นนัยว่าการปรับปรุงการมีสิทธิ์ของ bfcache คุ้มค่ากว่า แต่ bfcache notRestoredReasons API สามารถบอกเหตุผลที่ทำให้การโหลดหน้าเว็บหนึ่งๆ แสดงจาก bfcache ไม่ได้

ประเภทการนำทางใน CrUX API

หากต้องการดูประเภทการนำทางใน API ให้รวมเมตริก navigation_types ในคำขอ หรือไม่ตั้งค่าเมตริกเพื่อให้ระบบรวมเมตริกทั้งหมดไว้ด้วย

export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{"origin": "https://example.com", metrics: ["navigation_types"]}'

เราอธิบายรูปแบบคำขอโดยละเอียดในเอกสารประกอบของ API รวมถึงคำอธิบายเกี่ยวกับวิธีรับคีย์ API และคู่มือ API ซึ่งจะแสดงผลออบเจ็กต์แบบนี้

{
  "record": {
    "key": {  "origin": "https://example.com" },
    "metrics": {
      "navigation_types": {
        "fractions": {
          "navigate": 0.5335,
          "navigate_cache": 0.2646,
          "reload": 0.0885,
          "restore": 0.0023,
          "back_forward": 0.0403,
          "back_forward_cache": 0.0677,
          "prerender": 0.0031
        }
      }
    },
    "collectionPeriod": {
      "firstDate": { "year": 2024, "month": 3, "day": 6 },
      "lastDate": { "year": 2024, "month": 4, "day": 2 }
    }
  }
}

ในการตอบสนอง CrUX จะรายงานเมตริก navigation_types เป็นออบเจ็กต์ที่มีเศษส่วนของการโหลดหน้าเว็บสำหรับการนำทางแต่ละประเภท แต่ละเศษส่วนคือค่าระหว่าง 0.0 (ระบุ 0% ของการโหลดหน้าเว็บ) ถึง 1.0 (ระบุการโหลดหน้าเว็บ 100%) สำหรับคีย์ที่ระบุ

ดูจากคำตอบนี้ว่าในระยะเวลาการรวบรวมข้อมูลตั้งแต่วันที่ 6 มีนาคม 2024 จนถึงวันที่ 2 เมษายน 2024 - 6.77% ของการนำทาง (การโหลดหน้าเว็บ) แสดงจาก bfcache ของเบราว์เซอร์ ในทำนองเดียวกัน เศษส่วนอื่นๆ บางส่วนสามารถช่วยระบุโอกาสในการเพิ่มประสิทธิภาพการโหลดหน้าเว็บ โปรดทราบว่าสำหรับคีย์หนึ่งๆ (รวมถึง URL หรือต้นทางและรูปแบบของอุปกรณ์รวมกัน) เศษส่วน navigation_types จะรวมกันได้ประมาณ 1.0

ประเภทการนำทางใน CrUX History API

CrUX History API สามารถระบุอนุกรมเวลาสำหรับประเภทการนำทางที่มีจุดข้อมูลสูงสุด 25 จุดต่อเศษส่วน ซึ่งช่วยให้แสดงภาพเศษส่วนเหล่านี้ได้เมื่อเวลาผ่านไป หากต้องการเปลี่ยนคำขอจาก CrUX API เป็น CrUX History API ให้เรียกใช้กับปลายทาง queryHistoryRecord แทน queryRecord ตัวอย่างเช่น Colab ประวัติ CrUX จะพล็อตเมตริก navigation_types เป็นแท่งซ้อนกัน ดังนี้

วันที่

ในภาพหน้าจอก่อนหน้า การเก็บประวัติจะมีระยะเวลาการรวบรวม 3 ช่วงเท่านั้น (แต่ละครั้งห่างกัน 28 วัน และห่างกัน 7 วัน) เมื่อป้อนข้อมูลครบถ้วนแล้ว ค่านี้จะมีผลครอบคลุมทั้ง 25 ช่วงการรวบรวมข้อมูล การแสดงภาพประวัตินี้ช่วยให้ยืนยันได้ว่าการเพิ่มประสิทธิภาพมีผลแล้วหรือเกิดการถดถอย โดยเฉพาะอย่างยิ่งสำหรับการกำหนดค่าแคช HTTP ซึ่งเป็นการเพิ่มประสิทธิภาพหน้าเว็บสำหรับ bfcache และการแสดงผลล่วงหน้า

ประเภทการนำทางใน CrUX BigQuery

ขณะนี้ตาราง CrUX BigQuery มีระเบียน navigation_type ที่สร้างขึ้นจากแต่ละประเภท ขณะที่มุมมองสรุปที่เป็นรูปธรรมจะมีคอลัมน์ navigation_types_* หลายคอลัมน์ โดย 1 คอลัมน์สำหรับแต่ละประเภท

ตารางโดยละเอียด

สคีมาตารางโดยละเอียดใน CrUX BigQuery แสดงฮิสโตแกรมโดยละเอียดสำหรับเมตริกประสิทธิภาพเว็บ ซึ่งทำให้เราแสดงในตัวอย่างการวิเคราะห์นี้ว่าประเภทการนำทางต่างๆ อาจสัมพันธ์กับประสิทธิภาพการโหลดทันทีหรือที่ดีอย่างไร

ในตัวอย่างนี้ เราดูที่เศษส่วน back_forward_cache และความสัมพันธ์กับความถี่ที่หน้าเว็บโหลดทันที (instant_lcp_density คือ LCP <= 200 มิลลิวินาที) และความถี่ในการมองเห็น LCP ที่ดี (good_lcp_density หมายถึง LCP <= 2, 500 มิลลิวินาที) เราสังเกตเห็นความสัมพันธ์ทางสถิติที่ชัดเจนระหว่าง back_forward_cache กับ instant_lcp_density (สตริง=0.87) ซึ่งแสดงในพล็อตต่อไปนี้ และมีความสัมพันธ์ปานกลางระหว่าง back_forward_cache กับ good_lcp_density (สตริง=0.29)

วันที่

Colab สำหรับการวิเคราะห์นี้ได้รับการแสดงความคิดเห็นเป็นอย่างดี ในที่นี้ เราจะพูดถึงเฉพาะการค้นหาที่ดึงเศษส่วน Navigation_types สำหรับต้นทางยอดนิยม 10, 000 รายการจากตารางโดยละเอียดใน CrUX BigQuery

• เราเข้าถึงตาราง all.202403 ที่นี่ (ดูวลี FROM) และกรอง form_factor สำหรับ phone แล้วเลือกต้นทางที่มีอันดับความนิยม <= 10,000 สำหรับต้นทางยอดนิยม 10,000 อันดับแรก (ดูประโยค WHERE)
• เมื่อค้นหาเมตริก navigation_types ใน BigQuery คุณต้องหารด้วยผลรวมของ navigation_types บางส่วน เนื่องจากจะบวกกันตามต้นทางเท่านั้น ไม่ใช่ตามชุดค่าผสม (ต้นทางและรูปแบบ)
• ต้นทางบางแห่งอาจไม่มี navigation_types จึงควรใช้ SAVE_DIVIDE

WITH tmp AS (
  SELECT
    origin,
    SUM(navigation_types.navigate.fraction) AS navigate,
    SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
    SUM(navigation_types.reload.fraction) AS reload,
    SUM(navigation_types.restore AS restore,
    SUM(navigation_types.back_forward.fraction) AS back_forward,
    SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
    SUM(navigation_types.prerender.fraction) AS prerender,
    SUM(navigation_types.navigate.fraction
      + navigation_types.navigate_cache.fraction
      + navigation_types.reload.fraction
      + navigation_types.restore.fraction
      + navigation_types.back_forward.fraction
      + navigation_types.back_forward_cache.fraction
      + navigation_types.prerender.fraction) AS total
  FROM
    `chrome-ux-report.all.202403`
  WHERE
    experimental.popularity.rank <= 10000 AND
    form_factor.name = 'phone'
  GROUP BY
    origin
)

SELECT
  origin,
  ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
  ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
  ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
  ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
  ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
  ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
  ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
  tmp

ตารางที่เป็นรูปธรรม

หากข้อมูลสรุปเพียงพอแล้ว การค้นหาตารางที่เป็นรูปธรรมแทนมักจะรวดเร็วกว่า (และถูกกว่า) ตัวอย่างเช่น คำค้นหาต่อไปนี้จะดึงข้อมูล navigation_types ที่ใช้ได้จากตาราง chrome-ux-report.materialized.device_summary ตารางนี้มีการคีย์ตามเดือน ต้นทาง และประเภทอุปกรณ์

SELECT
  yyyymm,
  device,
  navigation_types_navigate,
  navigation_types_navigate_cache,
  navigation_types_reload,
  navigation_types_restore,
  navigation_types_back_forward,
  navigation_types_back_forward_cache,
  navigation_types_prerender
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://example.com' AND
  navigation_types_navigate IS NOT NULL
ORDER BY
  yyyymm DESC,
  device DESC

โปรดทราบว่าเศษส่วนเหล่านี้จะรวมกันเป็น 1.0 ต่อแถวไม่ได้ ดังนั้นจึงต้องหารแต่ละเศษส่วนด้วยผลรวมของผลลัพธ์ที่จะใช้ตีความคำค้นหา

สาเหตุก็คือเศษ navigation_type ใน chrome-ux-report.materialized.device_summary เช่น ความหนาแน่นของฮิสโตแกรม ได้รวมกันได้ 1.0 ต่อต้นทาง แทนที่จะเป็น 1.0 ต่อต้นทาง ไม่ใช่ต่อต้นทางและอุปกรณ์ต่อวัน วิธีนี้ช่วยให้คุณดูการกระจายของประเภทการนำทางในอุปกรณ์ต่างๆ ได้ดังนี้

SELECT
  device,
  navigation_types_back_forward
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

ในผลการค้นหานี้ เศษส่วนจะแสดงเปอร์เซ็นต์การโหลดหน้าเว็บสำหรับต้นทาง https://www.google.com นั่นคือ 6.63% ของการโหลดหน้าเว็บเหล่านี้มีประเภทการนำทาง back_forward บนโทรศัพท์ เดสก์ท็อป 1.79% และแท็บเล็ต 0.09%

เปอร์เซ็นต์ back_forward ที่สูงกว่าอย่างมากใน phone ชี้ให้เห็นว่าเราสามารถลองเพิ่มประสิทธิภาพการโหลดหน้าเว็บเหล่านี้เพื่อให้แสดงจาก bfcache ได้

อย่างไรก็ตาม ควรคำนึงถึงสัดส่วนของการโหลดหน้าเว็บที่ bfcache แสดงไปแล้ว ซึ่งก็คืออัตรา Hit ของ bfcache คำค้นหาต่อไปนี้ชี้ให้เห็นว่าต้นทางนี้อาจได้รับการเพิ่มประสิทธิภาพอย่างเหมาะสม เนื่องจาก อัตรา Hit 60% สำหรับโทรศัพท์และเดสก์ท็อป

SELECT
  device,
  navigation_types_back_forward_cache /
    (navigation_types_back_forward + navigation_types_back_forward_cache)
    AS back_forward_cache_hit_rate
FROM
  chrome-ux-report.materialized.device_summary
WHERE
  origin = 'https://www.google.com' AND
  yyyymm = 202403

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

ประเภทการนำทางในแดชบอร์ด CrUX

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

วันที่

นอกจากนี้ คุณยังจะเห็นได้ว่าเราได้ไฮไลต์ประเภทการนำทางที่เร็วกว่า ที่สถานที่ต่างๆ ควรค้นหาเพื่อเพิ่มประสิทธิภาพที่ด้านบนของหน้านี้

บทสรุป

เราหวังว่ารายละเอียดประเภทการนำทางใน CrUX จะมีประโยชน์สำหรับคุณ ซึ่งจะช่วยให้คุณเข้าใจและเพิ่มประสิทธิภาพเว็บไซต์ได้ ด้วยการใช้การแคช HTTP, bfcache และการแสดงผลล่วงหน้าอย่างมีประสิทธิภาพ ทำให้เว็บไซต์สามารถโหลดหน้าเว็บได้เร็วกว่าการโหลดหน้าเว็บที่ต้องกลับไปยังเซิร์ฟเวอร์

นอกจากนี้ เรายังยินดีที่จะให้บริการข้อมูลในทุกจุดเข้าใช้งาน CrUX เพื่อให้ผู้ใช้ใช้ข้อมูลได้ตามต้องการและดูรายละเอียดประเภทตาม URL สำหรับการแสดงข้อมูลใน CrUX API

เราอยากทราบความคิดเห็นเกี่ยวกับการเพิ่มเติมของ CrUX นี้บนโซเชียลมีเดียหรือในกลุ่มสนทนา CrUX