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

Barry Pollard

Johannes Henkel

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

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

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

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

CrUX มีการนําทางประเภทใด

CrUX จะแยกความแตกต่างของประเภทการนําทางต่อไปนี้ในตารางต่อไปนี้

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

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

เนื่องจาก CrUX เป็นชุดข้อมูลสาธารณะ ความละเอียดในการรายงานจึงถูกจำกัด สำหรับต้นทางและ URL หลายรายการ เมตริก navigation_types ไม่พร้อมใช้งานเนื่องจากมีการเข้าชมที่มีสิทธิ์ไม่เพียงพอ ดูข้อมูลเพิ่มเติมในระเบียบวิธี 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 ตัวอย่างเช่น CrUX History Colab แสดงเมตริก navigation_types เป็นแท่งซ้อนกัน

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

ประเภทการไปยังส่วนต่างๆ ใน CrUX BigQuery

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

ตารางแบบละเอียด

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

ดังตัวอย่าง เราได้ดูเศษส่วน back_forward_cache และความสัมพันธ์กับความถี่ที่โหลดหน้าเว็บได้ทันที (instant_lcp_density หมายถึง LCP <= 200 มิลลิวินาที) และความถี่ในการเห็น LCP ที่ดี (good_lcp_density หมายถึง LCP <= 2, 500 มิลลิวินาที) เราสังเกตเห็นความสัมพันธ์ทางสถิติที่ชัดเจนระหว่าง back_forward_cache และ instant_lcp_density (INPUT=0.87) ซึ่งแสดงในพล็อตต่อไปนี้ และความสัมพันธ์แบบปานกลางระหว่าง back_forward_cache และ good_lcp_density (Error=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 ส่วนต่อต้นทางและอุปกรณ์ต่อวัน ซึ่งจะช่วยให้คุณดูการกระจายประเภทการนำทางในอุปกรณ์ต่างๆ ได้

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

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

บทสรุป

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

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

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