ตั้งแต่ชุดข้อมูลเดือนมีนาคม 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 จะแยกความแตกต่างของประเภทการนําทางต่อไปนี้ในตารางต่อไปนี้
ประเภท | คำอธิบาย |
---|---|
navigate |
การโหลดหน้าเว็บซึ่งไม่จัดอยู่ในหมวดหมู่อื่นๆ |
navigate_cache |
การโหลดหน้าเว็บที่มีบริการทรัพยากรหลัก (เอกสาร HTML หลัก) จากแคช HTTP เว็บไซต์มักจะใช้ประโยชน์จากการแคชสำหรับทรัพยากรย่อย แต่เอกสาร HTML หลักมักจะแคชน้อยกว่ามาก เมื่อมีโอกาส ก็อาจส่งผลให้ประสิทธิภาพดีขึ้นอย่างเห็นได้ชัดจากการสามารถแคชในเครื่องและใน CDN ได้ |
reload |
ผู้ใช้โหลดหน้าเว็บซ้ำ ไม่ว่าจะด้วยการกดปุ่มโหลดซ้ำ หรือกด Enter ในแถบที่อยู่ หรือเลิกทำการปิดแท็บ การโหลดหน้าเว็บซ้ำมักจะทำให้มีการตรวจสอบความถูกต้องอีกครั้งไปยังเซิร์ฟเวอร์เพื่อตรวจสอบว่าหน้าหลักมีการเปลี่ยนแปลงหรือไม่ เปอร์เซ็นต์การโหลดหน้าซ้ำที่สูงอาจบ่งบอกถึงผู้ใช้หงุดหงิด |
restore |
มีการโหลดหน้าซ้ำหลังจากรีสตาร์ทเบราว์เซอร์ หรือแท็บถูกนำออกไปแล้วด้วยเหตุผลด้านหน่วยความจำ สำหรับ Chrome บน Android ระบบจะรายงานเป็น reload แทน |
back_forward |
การนำทางของประวัติ ซึ่งหมายความว่าผู้ใช้เห็นและกลับมาดูหน้าดังกล่าวเมื่อเร็วๆ นี้ การแคชที่ถูกต้องจะทำให้ประสบการณ์เหล่านี้รวดเร็วพอสมควร แต่ก็ยังต้องประมวลผลหน้าเว็บและเรียกใช้ JavaScript ซึ่งทั้ง 2 อย่างนี้ bfcache จะหลีกเลี่ยงไม่ได้ |
back_forward_cache |
การนำทางของประวัติที่ให้บริการจาก bfcache การเพิ่มประสิทธิภาพหน้าเว็บเพื่อใช้ประโยชน์จาก bfcache จะช่วยให้ใช้งานได้เร็วขึ้น เว็บไซต์ควรนำตัวบล็อก bfcache ออกเพื่อปรับปรุงเปอร์เซ็นต์ของการนำทางในหมวดหมู่นี้ |
prerender |
หน้าเว็บแสดงผลล่วงหน้าซึ่งคล้ายกับ bfcache อาจทำให้โหลดหน้าเว็บได้เกือบจะทันที |
ในบางกรณี การโหลดหน้าเว็บอาจรวมการนำทางหลายประเภทเข้าด้วยกัน ในกรณีดังกล่าว 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
device |
navigation_types_back_forward |
---|---|
phone |
0.0663 |
desktop |
0.0179 |
tablet |
0.0009 |
ในผลการค้นหานี้ เศษส่วนแสดงถึงเปอร์เซ็นต์ของการโหลดหน้าเว็บสำหรับต้นทาง 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
device |
back_forward_cache_hit_rate |
---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
ดังนั้นการที่มีอัตรา back_forward
สูงในโทรศัพท์จึงไม่ได้เกิดจากการใช้ bfcache น้อยลง แต่สะท้อนให้เห็นวิธีที่ผู้ใช้ย้อนกลับและไปข้างหน้าในโทรศัพท์มากขึ้น
ประเภทการนําทางในแดชบอร์ด CrUX
วิธีที่ง่ายที่สุดในการดูประเภทการนำทางคือในหน้าแดชบอร์ด CrUX ซึ่งเข้าถึงได้สำหรับต้นทางจากลิงก์นี้ จากภาพหน้าจอต่อไปนี้จะเห็นได้ว่าในช่วงแรกมีข้อมูลของ 1 เดือนเท่านั้นที่จะแสดง แต่เมื่อเวลาผ่านไปประวัติจะเต็มขึ้น คุณจะเห็นการเปลี่ยนแปลงของประเภทในแต่ละเดือน
อย่างที่คุณจะได้เห็นว่าเราได้ไฮไลต์ประเภทการนำทางที่เร็วกว่าที่สถานที่อื่นๆ ควรหาวิธีเพิ่มประสิทธิภาพไว้ที่ด้านบนของหน้านี้ของแดชบอร์ด
บทสรุป
เราหวังว่ารายละเอียดประเภทการนําทางใน CrUX จะมีประโยชน์กับคุณ และช่วยให้คุณเข้าใจและเพิ่มประสิทธิภาพเว็บไซต์ได้ เมื่อตรวจสอบว่าใช้การแคช HTTP, bfcache และการแสดงผลล่วงหน้าอย่างมีประสิทธิภาพ เว็บไซต์จะโหลดหน้าเว็บได้เร็วกว่าการโหลดหน้าเว็บที่ต้องมีการเดินทางกลับไปที่เซิร์ฟเวอร์
เรายังยินดีที่จะทำให้ข้อมูลพร้อมใช้งานในจุดเข้าใช้งาน CrUX ต่างๆ ทั้งหมด เพื่อให้ผู้ใช้สามารถใช้ข้อมูลได้ตามต้องการและดูรายละเอียดของประเภทตาม URL สำหรับข้อมูลที่แสดงใน CrUX API
เราอยากทราบความคิดเห็นเกี่ยวกับการเพิ่มลงใน CrUX นี้ในโซเชียลมีเดียหรือในกลุ่มสนทนา CrUX