CrUX API ให้สิทธิ์เข้าถึงเวลาในการตอบสนองต่ำสำหรับข้อมูลประสบการณ์ของผู้ใช้จริงที่รวบรวมไว้ที่ระดับรายละเอียดหน้าเว็บและต้นทาง
กรณีการใช้งานทั่วไป
CrUX API ช่วยให้ค้นหาเมตริกประสบการณ์ของผู้ใช้สำหรับ URI ที่เจาะจงได้ เช่น "รับเมตริกสำหรับต้นทางของ https://example.com
"
คีย์ API ของ CrUX
การใช้ CrUX API จำเป็นต้องมีคีย์ Google Cloud API ที่จัดสรรสำหรับการใช้งาน Chrome UX Report API
การรับและใช้คีย์ API
ซื้อกุญแจหรือสร้างบัญชีในหน้าข้อมูลเข้าสู่ระบบ
หลังจากมีคีย์ API แล้ว แอปพลิเคชันจะเพิ่มพารามิเตอร์การค้นหาต่อท้ายได้
key=yourAPIKey
ไปยัง URL คำขอทั้งหมด
คีย์ API ปลอดภัยสำหรับการฝังใน URL ผลิตภัณฑ์ดังกล่าวไม่จำเป็นต้องมีการเข้ารหัส
โมเดลข้อมูล
ส่วนนี้จะแสดงรายละเอียดโครงสร้างของข้อมูลในคำขอและการตอบกลับ
บันทึก
ข้อมูลแยกต่างหากเกี่ยวกับหน้าเว็บหรือเว็บไซต์ ระเบียนสามารถมีข้อมูลที่เฉพาะเจาะจงสำหรับตัวระบุ และสำหรับชุดค่าผสมของมิติข้อมูลที่เฉพาะเจาะจง ระเบียนหนึ่งจะมีข้อมูลสำหรับเมตริกอย่างน้อย 1 รายการ
รหัสระบุ
ตัวระบุจะระบุระเบียนที่ควรค้นหา ใน CrUX ตัวระบุเหล่านี้คือหน้าเว็บและเว็บไซต์
Origin
เมื่อตัวระบุเป็นต้นทาง ข้อมูลทั้งหมดที่แสดงสำหรับทุกหน้าในต้นทางนั้นจะรวมเข้าด้วยกัน ตัวอย่างเช่น สมมติว่าต้นทาง http://www.example.com
มีหน้าเว็บตามที่ Sitemap วาง ดังนี้
http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html
ซึ่งหมายความว่า เมื่อสืบค้นข้อมูลรายงาน UX ของ Chrome โดยตั้งค่าต้นทางเป็น http://www.example.com
ระบบจะแสดงผลข้อมูลของ http://www.example.com/
, http://www.example.com/foo.html
และ http://www.example.com/bar.html
แบบรวมเข้าด้วยกัน เนื่องจากหน้าเว็บทั้งหมดอยู่ภายใต้ต้นทางดังกล่าว
URL
เมื่อตัวระบุเป็น URL ระบบจะแสดงเฉพาะข้อมูลของ URL นั้นๆ ตรวจสอบ Sitemap ต้นทาง http://www.example.com
อีกครั้ง:
http://www.example.com/
http://www.example.com/foo.html
http://www.example.com/bar.html
หากกำหนดตัวระบุเป็น URL ที่มีค่า http://www.example.com/foo.html
ระบบจะแสดงผลเฉพาะข้อมูลของหน้านั้นเท่านั้น
ขนาด
มิติข้อมูลจะระบุกลุ่มข้อมูลที่เฉพาะเจาะจงซึ่งมีการรวบรวมระเบียนไว้ เช่น รูปแบบของอุปกรณ์ PHONE
บ่งชี้ว่าระเบียนมีข้อมูลเกี่ยวกับการโหลดที่เกิดขึ้นในอุปกรณ์เคลื่อนที่ มิติข้อมูลแต่ละรายการจะมีค่าจํานวนหนึ่ง และหากไม่ได้ระบุมิติข้อมูลนั้น หมายความว่าระบบจะรวบรวมมิติข้อมูลจากค่าทั้งหมดโดยนัย เช่น การไม่ระบุรูปแบบของอุปกรณ์หมายความว่าระเบียนมีข้อมูลเกี่ยวกับโหลดที่เกิดขึ้นในรูปแบบของอุปกรณ์ใดๆ
รูปแบบของอุปกรณ์
คลาสอุปกรณ์ที่ผู้ใช้ปลายทางใช้นำทางไปยังหน้าเว็บ นี่คือคลาสทั่วไปของอุปกรณ์ที่แบ่งออกเป็น PHONE
, TABLET
และ DESKTOP
ประเภทการเชื่อมต่อที่มีประสิทธิภาพ
ประเภทการเชื่อมต่อที่มีประสิทธิภาพคือคุณภาพการเชื่อมต่อโดยประมาณของอุปกรณ์เมื่อไปยังหน้าเว็บ นี่คือชั้นเรียนทั่วไปที่แบ่งออกเป็น offline
, slow-2G
, 2G
, 3G
และ 4G
เมตริก
เรารายงานเมตริกว่าเป็นการรวมสถิติ ในฮิสโตแกรม เปอร์เซ็นไทล์ และเศษส่วน
ค่าจุดทศนิยมจะปัดเศษเป็นทศนิยม 4 ตำแหน่ง (โปรดทราบว่าเมตริก cumulative_layout_shift
มีการเข้ารหัส 2 เท่าเป็นสตริง ดังนั้นจะไม่ถือว่าเป็นจำนวนทศนิยมและจะรายงานเป็นทศนิยม 2 ตำแหน่งภายในสตริง)
ฮิสโตแกรม
เมื่อเมตริกแสดงในฮิสโตแกรม เราจะแสดงเปอร์เซ็นต์ของการโหลดหน้าเว็บใน สำหรับเมตริกนั้น
ฮิสโตแกรม 3 bin สำหรับตัวอย่างเมตริกมีลักษณะดังนี้
{
"histogram": [
{
"start": 0,
"end": 1000,
"density": 0.3818
},
{
"start": 1000,
"end": 3000,
"density": 0.4991
},
{
"start": 3000,
"density": 0.1192
}
]
}
ข้อมูลนี้บ่งชี้ว่ามีการวัดตัวอย่างเมตริกในการโหลดหน้าเว็บ 38.18% ระหว่าง 0 ถึง 1,000 มิลลิวินาที หน่วยของเมตริกไม่ได้อยู่ในฮิสโตแกรมนี้ ในกรณีนี้ เราจะถือว่าเป็นมิลลิวินาที
นอกจากนี้ การโหลดหน้าเว็บ 49.91% มีเมตริกมีค่าระหว่าง 1,000-3,000 มิลลิวินาที และ 11.92% มีค่ามากกว่า 3,000 มิลลิวินาที
เปอร์เซ็นไทล์
เมตริกยังอาจมีเปอร์เซ็นไทล์ที่อาจมีประโยชน์สําหรับการวิเคราะห์เพิ่มเติม เราจะรายงานค่าเมตริกเฉพาะเจาะจงที่เปอร์เซ็นไทล์ที่ระบุสำหรับเมตริกนั้น โดยจะอิงตามชุดข้อมูลทั้งหมดที่มีอยู่ ไม่ใช่ข้อมูลที่เก็บรวมล่าสุด จึงไม่จำเป็นต้องตรงกับเปอร์เซ็นไทล์ที่ประมาณตาม ฮิสโตแกรมแบบไบนารีสุดท้าย
{
"percentiles": {
"p75": 2063
}
}
ในตัวอย่างนี้ มีการวัดการโหลดหน้าเว็บอย่างน้อย 75% ด้วยค่าเมตริก <= 2063
เศษส่วน
เศษส่วนหมายถึงเปอร์เซ็นต์ของการโหลดหน้าเว็บที่สามารถติดป้ายกำกับได้ในวิธีที่เฉพาะเจาะจง ในกรณีนี้ ค่าเมตริกคือป้ายกำกับเหล่านี้
เช่น เมตริก form_factors
ประกอบด้วยออบเจ็กต์ fractions
ที่แสดงรายละเอียดของรูปแบบ (หรืออุปกรณ์) ที่แอปพลิเคชันการค้นหาที่ระบุครอบคลุม
"form_factors": {
"fractions": {
"desktop": 0.0377,
"tablet": 0.0288,
"phone": 0.9335
}
}
ในกรณีนี้ มีการวัดการโหลดหน้าเว็บ 3.77% บนเดสก์ท็อป, 2.88% บนแท็บเล็ต และ 93.35% บนโทรศัพท์ ทำให้ยอดรวมทั้งหมดเป็น 100%
ประเภทค่าเมตริก
ชื่อเมตริก CrUX API | ประเภทข้อมูล | หน่วยเมตริก | การรวมข้อมูลทางสถิติ | เอกสารประกอบ |
---|---|---|---|---|
cumulative_layout_shift |
ทศนิยม 2 หลักเข้ารหัสคู่เป็นสตริง | ไม่มีหน่วย | ฮิสโตแกรมที่มีถัง 3 ใบ เปอร์เซ็นไทล์ที่มี p75 | cls |
first_contentful_paint |
int | มิลลิวินาที | ฮิสโตแกรมที่มีถัง 3 ใบ เปอร์เซ็นไทล์ที่มี p75 | fcp |
interaction_to_next_paint |
int | มิลลิวินาที | ฮิสโตแกรมที่มีถัง 3 ใบ เปอร์เซ็นไทล์ที่มี p75 | inp |
largest_contentful_paint |
int | มิลลิวินาที | ฮิสโตแกรมที่มีถัง 3 ใบ เปอร์เซ็นไทล์ที่มี p75 | lcp |
experimental_time_to_first_byte |
int | มิลลิวินาที | ฮิสโตแกรมที่มีถัง 3 ใบ เปอร์เซ็นไทล์ที่มี p75 | ttfb |
form_factors |
ทศนิยม 4 ตำแหน่ง | เปอร์เซ็นต์ | การแมปจากรูปแบบของอุปกรณ์ไปยังเศษส่วน | รูปแบบของอุปกรณ์ |
navigation_types |
ทศนิยม 4 ตำแหน่ง | เปอร์เซ็นต์ | การแมปจากประเภทการนำทางเป็นเศษส่วน | ประเภทการนำทาง |
round_trip_time |
int | มิลลิวินาที | เปอร์เซ็นไทล์ที่มี p75 | rtt |
การแมปชื่อเมตริก BigQuery
ชื่อเมตริก CrUX API | ชื่อเมตริก BigQuery |
---|---|
cumulative_layout_shift |
layout_instability.cumulative_layout_shift |
first_contentful_paint |
first_contentful_paint |
interaction_to_next_paint |
interaction_to_next_paint |
largest_contentful_paint |
largest_contentful_paint |
experimental_time_to_first_byte |
experimental.time_to_first_byte |
navigation_types |
navigation_types |
form_factors |
ไม่มี |
round_trip_time |
ไม่มี |
ระยะเวลาการรวบรวม
ในเดือนตุลาคม 2022 CrUX API มีออบเจ็กต์ collectionPeriod
ที่มีช่อง firstDate
และ endDate
ที่แทนวันที่เริ่มต้นและวันที่สิ้นสุดของหน้าต่างการรวม เช่น
"collectionPeriod": {
"firstDate": {
"year": 2022,
"month": 9,
"day": 12
},
"lastDate": {
"year": 2022,
"month": 10,
"day": 9
}
}
วิธีนี้ช่วยให้เข้าใจข้อมูลได้ดีขึ้นและทราบว่าข้อมูลได้รับการอัปเดตสำหรับวันนั้นแล้วหรือยัง หรือแสดงข้อมูลเดียวกันกับเมื่อวาน
โปรดทราบว่า CrUX API จะช้ากว่าวันนี้ประมาณ 2 วัน เนื่องจากต้องรอข้อมูลที่เสร็จสมบูรณ์ของวันนั้น และต้องใช้เวลาในการประมวลผลสักพักก่อนที่จะพร้อมใช้งานใน API เขตเวลาที่ใช้คือเวลามาตรฐานแปซิฟิก (PST) ซึ่งไม่มีการเปลี่ยนแปลงสำหรับการออมแสง
ตัวอย่างคำค้นหา
ระบบจะส่งการค้นหาเป็นออบเจ็กต์ JSON โดยใช้คำขอ POST ไปยัง https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=[YOUR_API_KEY]"
พร้อมข้อมูลการค้นหาเป็นออบเจ็กต์ JSON ในส่วนเนื้อหาของ POST:
{
"origin": "https://example.com",
"formFactor": "PHONE",
"metrics": [
"largest_contentful_paint",
"experimental_time_to_first_byte"
]
}
ตัวอย่างเช่น โค้ดนี้สามารถเรียกใช้จาก curl
ด้วยบรรทัดคำสั่งต่อไปนี้ (แทนที่ API_KEY
ด้วยคีย์ของคุณ)
curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{"formFactor":"PHONE","origin":"https://www.example.com","metrics":["largest_contentful_paint", "experimental_time_to_first_byte"]}'
ข้อมูลระดับหน้าเว็บพร้อมใช้งานผ่าน API โดยการส่งพร็อพเพอร์ตี้ url
ในการค้นหาแทน origin
{
"url": "https://example.com/page",
"formFactor": "PHONE",
"metrics": [
"largest_contentful_paint",
"experimental_time_to_first_byte"
]
}
หากไม่ได้ตั้งค่าพร็อพเพอร์ตี้ metrics
ระบบจะแสดงผลเมตริกที่ใช้ได้ทั้งหมด
cumulative_layout_shift
first_contentful_paint
interaction_to_next_paint
largest_contentful_paint
experimental_time_to_first_byte
navigation_types
form_factors
(รายงานเฉพาะในกรณีที่ไม่ได้ระบุformFactor
ในคำขอ)
หากไม่ได้ระบุค่า formFactor
ระบบจะรวมค่าดังกล่าวในรูปแบบของอุปกรณ์ทั้งหมด
ดูตัวอย่างการค้นหาเพิ่มเติมที่หัวข้อการใช้ Chrome UX Report API
Data Pipeline
ชุดข้อมูล CrUX ได้รับการประมวลผลผ่านไปป์ไลน์เพื่อรวม รวบรวม และกรองข้อมูลก่อนที่จะพร้อมใช้งานโดยใช้ API
รายได้เฉลี่ยต่อเนื่อง
ข้อมูลในรายงาน UX ของ Chrome คือรายได้เฉลี่ยต่อเนื่องในช่วง 28 วันของเมตริกรวม ซึ่งหมายความว่าข้อมูลที่แสดงในรายงาน UX ของ Chrome ในช่วงเวลาหนึ่งนั้นเป็นข้อมูลสำหรับ 28 วันที่ผ่านมาซึ่งรวบรวมไว้ด้วยกัน
ซึ่งคล้ายกับวิธีที่ชุดข้อมูล CrUX ใน BigQuery รวบรวมรายงานรายเดือน
อัปเดตรายวัน
ข้อมูลจะอัปเดตทุกวันประมาณ 04:00 น. UTC ไม่มีข้อตกลงระดับการให้บริการสำหรับเวลาการอัปเดต ระบบจะดำเนินการอย่างเต็มความสามารถทุกวัน
สคีมา
มีปลายทางเดียวสำหรับ CrUX API ซึ่งยอมรับคำขอ HTTP POST
API จะแสดงผล record
ซึ่งมี metrics
อย่างน้อย 1 รายการที่สอดคล้องกับข้อมูลประสิทธิภาพเกี่ยวกับต้นทางหรือหน้าเว็บที่ขอ
คำขอ HTTP
POST https://chromeuxreport.googleapis.com/v1/records:queryRecord
URL ใช้ไวยากรณ์การแปลง gRPC
เนื้อหาของคำขอ
เนื้อหาของคำขอควรมีข้อมูลที่มีโครงสร้างต่อไปนี้
{
"effectiveConnectionType": string,
"formFactor": enum (FormFactor),
"metrics": [
string
],
// Union field url_pattern can be only one of the following:
"origin": string,
"url": string
// End of list of possible types for union field url_pattern.
}
ช่อง | |
---|---|
effectiveConnectionType |
ประเภทการเชื่อมต่อที่มีประสิทธิภาพคือมิติข้อมูลการค้นหาที่ระบุคลาสเครือข่ายที่มีประสิทธิภาพซึ่งควรมีข้อมูลของระเบียน ช่องนี้ใช้ค่า หมายเหตุ: หากไม่ได้ระบุประเภทการเชื่อมต่อที่มีประสิทธิภาพ ระบบจะแสดงระเบียนพิเศษที่มีข้อมูลที่รวบรวมจากประเภทการเชื่อมต่อที่มีประสิทธิภาพทั้งหมด |
formFactor |
รูปแบบของอุปกรณ์คือมิติข้อมูลการค้นหาที่ระบุคลาสอุปกรณ์ที่ควรมีข้อมูลของระเบียน ช่องนี้ใช้ค่า หมายเหตุ: หากไม่ได้ระบุรูปแบบของอุปกรณ์ไว้ ระบบจะส่งระเบียนพิเศษที่มีข้อมูลรวมในรูปแบบของอุปกรณ์ทั้งหมด |
metrics[] |
เมตริกที่ควรรวมอยู่ในคำตอบ หากไม่ได้ระบุ ระบบจะแสดงผลเมตริกที่พบ ค่าที่อนุญาต: |
ช่องการรวม url_ url_pattern คือตัวระบุหลักสำหรับการค้นหาระเบียน ซึ่งสามารถเป็นได้อย่างใดอย่างหนึ่งต่อไปนี้เท่านั้น |
|
origin |
"ต้นทาง" ตัวอย่าง: |
url |
ตัวอย่าง: |
เช่น หากต้องการขอค่า Contentful Paint ที่ใหญ่ที่สุดในเดสก์ท็อปสำหรับหน้าแรกของเอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ Chrome ให้ทำดังนี้
{
"url": "https://developer.chrome.com/docs/",
"formFactor": "DESKTOP",
"metrics": [
"largest_contentful_paint"
]
}
เนื้อหาการตอบกลับ
คำขอที่สำเร็จจะแสดงการตอบกลับที่มีออบเจ็กต์ record
และ urlNormalizationDetails
ในโครงสร้างต่อไปนี้
{
"record": {
"key": {
object (Key)
},
"metrics": [
string: {
object (Metric)
}
]
},
"urlNormalizationDetails": {
object (UrlNormalization)
}
}
ตัวอย่างเช่น การตอบกลับเนื้อหาคำขอในคำขอก่อนหน้าอาจเป็นดังนี้
{
"record": {
"key": {
"formFactor": "DESKTOP",
"url": "https://developer.chrome.com/docs/"
},
"metrics": {
"largest_contentful_paint": {
"histogram": [
{
"start": 0,
"end": 2500,
"density": 0.9815
},
{
"start": 2500,
"end": 4000,
"density": 0.0108
},
{
"start": 4000,
"density": 0.0077
}
],
"percentiles": {
"p75": 651
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2022,
"month": 9,
"day": 12
},
"lastDate": {
"year": 2022,
"month": 10,
"day": 9
}
}
}
}
คีย์
Key
จะกำหนดมิติข้อมูลทั้งหมดที่ระบุว่าระเบียนนี้ไม่ซ้ำกัน
{
"effectiveConnectionType": string,
"formFactor": enum (FormFactor),
// Union field url_pattern can be only one of the following:
"origin": string,
"url": string
// End of list of possible types for union field url_pattern.
}
ช่อง | |
---|---|
formFactor |
รูปแบบของอุปกรณ์คือคลาสอุปกรณ์ที่ผู้ใช้ทุกคนใช้ในการเข้าถึงเว็บไซต์สำหรับระเบียนนี้ หากไม่ได้ระบุรูปแบบของอุปกรณ์ ระบบจะแสดงผลข้อมูลที่รวบรวมในรูปแบบของอุปกรณ์ทั้งหมด |
effectiveConnectionType |
ประเภทการเชื่อมต่อที่มีประสิทธิภาพคือคลาสการเชื่อมต่อทั่วไปที่ผู้ใช้ทั้งหมดพบสำหรับระเบียนนี้ ช่องนี้ใช้ค่า ["offline", "slow-2G", "2G", "3G", "4G"] ตามที่ระบุไว้ใน https://wicg.github.io/netinfo/#effective-connection-types หากไม่ได้ระบุประเภทการเชื่อมต่อที่มีประสิทธิภาพ ระบบจะแสดงข้อมูลที่รวบรวมจากการเชื่อมต่อที่มีประสิทธิภาพทุกประเภท |
ช่องการรวม url_ รูปแบบ URL คือ URL ที่ใช้กับระเบียน url_ ต้องเป็นค่าใดค่าหนึ่งต่อไปนี้ |
|
origin |
หมายเหตุ: เมื่อระบุ |
url |
หมายเหตุ: เมื่อระบุ |
เมตริก
metric
คือชุดข้อมูลประสบการณ์ของผู้ใช้ที่รวบรวมไว้สำหรับเมตริกประสิทธิภาพของเว็บหนึ่งๆ เช่น First Contentful Paint
อาจมีฮิสโตแกรมสรุปการใช้งาน Chrome ในชีวิตจริงเป็นชุดของ bins
ข้อมูลเปอร์เซ็นไทล์ที่เจาะจง
(เช่น p75) หรือมีเศษส่วนที่ติดป้ายกำกับ
{
"histogram": [
{
object (Bin)
}
],
"percentiles": {
object (Percentiles)
}
}
หรือ
{
"fractions": {
object (Fractions)
}
}
ช่อง | |
---|---|
histogram[] |
ฮิสโตแกรมของประสบการณ์ของผู้ใช้สำหรับเมตริก ฮิสโตแกรมจะมี Bin อย่างน้อย 1 ตัว และความหนาแน่นของ Bin ทั้งหมดจะรวมกันได้ ~1 |
percentiles |
เปอร์เซ็นไทล์ที่เป็นประโยชน์โดยทั่วไปของเมตริก ประเภทค่าของเปอร์เซ็นต์ิลจะเหมือนกับประเภทค่าที่ระบุสำหรับกล่องฮิสโตแกรม |
fractions |
วัตถุนี้มีเศษส่วนที่มีป้ายกำกับ ซึ่งจะรวมกันได้ประมาณ 1 รายการ เศษส่วนจะปัดเศษเป็นทศนิยม 4 ตำแหน่ง |
ถัง
bin
คือส่วนของข้อมูลที่ครอบคลุมตั้งแต่จุดเริ่มต้นถึงจุดสิ้นสุด หรือหากไม่มีจุดสิ้นสุดจากจุดเริ่มต้นไปจนถึงอนันต์ที่เป็นบวก
ค่าเริ่มต้นและสิ้นสุดของ Bin จะอยู่ในประเภทค่าของเมตริกที่แสดง ตัวอย่างเช่น First Contentful Paint จะวัดเป็นหน่วยมิลลิวินาทีและแสดงเป็น Int ดังนั้น Bin เมตริกก็จะใช้ int32s สำหรับประเภทเริ่มต้นและสิ้นสุด อย่างไรก็ตาม การเปลี่ยนเลย์เอาต์สะสมจะวัดเป็นทศนิยมแบบไม่เป็นหน่วยและแสดงเป็นทศนิยมที่เข้ารหัสเป็นสตริง ดังนั้นถังเมตริกจะใช้สตริงสำหรับประเภทค่าแทน
{
"start": value,
"end": value,
"density": number
}
ช่อง | |
---|---|
start |
Start คือจุดเริ่มต้นของ Bin ข้อมูล |
end |
End คือจุดสิ้นสุดของที่เก็บข้อมูล ถ้าไม่มีการเติมค่า end จะหมายถึง Bin ก็ไม่มีจุดสิ้นสุดและใช้ได้ตั้งแต่จุดเริ่มต้นจนถึง +inf |
density |
สัดส่วนของผู้ใช้ที่พบค่าของ Bin นี้สำหรับเมตริกที่ระบุ ระบบจะปัดเศษความหนาแน่นเป็นทศนิยม 4 ตำแหน่ง |
เปอร์เซ็นต์ไทล์
Percentiles
มีค่าสังเคราะห์ของเมตริกที่เปอร์เซ็นไทล์ทางสถิติที่ระบุ ระบบจะใช้ค่าเหล่านี้สำหรับการประมาณค่าของเมตริกตามเปอร์เซ็นต์ของผู้ใช้จากจำนวนผู้ใช้ทั้งหมด
{
"P75": value
}
ช่อง | |
---|---|
p75 |
75% ของการโหลดหน้าเว็บพบเมตริกที่ระบุเท่ากับหรือน้อยกว่าค่านี้ |
เศษส่วน
Fractions
มีเศษส่วนที่มีป้ายกำกับซึ่งรวมกันแล้วประมาณ 1 แต่ละป้ายกำกับจะอธิบาย
ในรูปแบบใดรูปแบบหนึ่ง ดังนั้นเมตริกที่แสดงในลักษณะนี้จะมองว่าเป็น
จะให้ค่าที่แตกต่างกันแทนค่าตัวเลข และเศษส่วนจะแสดง
ความถี่ในการวัดค่าเฉพาะหนึ่งๆ
{
"label_1": fraction,
"label_2": fraction,
...
"label_n": fraction
}
fraction
แต่ละรายการเป็นตัวเลข ซึ่งคล้ายกับค่าความหนาแน่นในถังฮิสโตแกรม
0.0 <= value <= 1.0
และเพิ่มได้ประมาณ 1.0
UrlNormalization
ออบเจ็กต์ที่แสดงถึงการดำเนินการแปลง URL ให้เป็นมาตรฐานซึ่งมีโอกาสสูงขึ้นในการค้นหาที่ประสบความสำเร็จ นี่เป็นการเปลี่ยนแปลงอัตโนมัติง่ายๆ ที่เกิดขึ้นเมื่อค้นหา url_pattern
ที่ระบุ เป็นที่ทราบว่าล้มเหลว ระบบจะไม่จัดการการดำเนินการที่ซับซ้อน เช่น การติดตามการเปลี่ยนเส้นทาง
{
"originalUrl": string,
"normalizedUrl": string
}
ช่อง | |
---|---|
originalUrl |
URL เดิมที่ขอก่อนการดำเนินการทำให้เป็นมาตรฐาน |
normalizedUrl |
URL หลังจากการดำเนินการทำให้เป็นมาตรฐาน นี่คือ URL ประสบการณ์ของผู้ใช้ที่ถูกต้องซึ่งสามารถค้นหาได้อย่างสมเหตุสมผล |
ขีดจำกัดอัตรา
CrUX API จำกัดการค้นหาไว้ที่ 150 ครั้งต่อนาทีต่อโปรเจ็กต์ Google Cloud ซึ่งให้บริการโดยไม่มีค่าใช้จ่าย คุณดูขีดจำกัดนี้และการใช้งานปัจจุบันได้ใน Google Cloud Console โควต้าขนาดใหญ่นี้ควรเพียงพอสำหรับ Use Case ส่วนใหญ่ และคุณไม่สามารถชำระเงินเพิ่มโควต้าได้