สรุปสั้น ๆ (TL;DR)
- Cloudflare เปิดตัว BEACON เมื่อ 28 กันยายน 2569 ชุดข้อมูลสาธารณะของ LCP, CLS และ INP จากผู้ใช้จริงแบบไม่ระบุตัวตน จากเว็บไซต์ใหญ่สุด 10,000 แห่งในเครือข่าย อัปเดตทุกวันใน BigQuery
- ข้อมูลตัดโดเมนและพาธ URL และทิ้งกลุ่มที่มีจุดข้อมูลน้อยกว่า 5 จุด จึงค้นหาเว็บไซต์รายเดียวไม่ได้
- ใน 46 ประเทศที่ WebKit มีทราฟฟิกเกิน 10% ตามหลัง Blink ตั้งแต่ 10% ขึ้นไป ในกัมพูชา WebKit มี 17.5% ของเพจวิว และ LCP แย่กว่า 50%
- แลนดิ้งเพจมี LCP ที่ P75 เท่ากับ 2,681 ms Cloudflare ระบุว่าการค้นพบทรัพยากร LCP และปลดบล็อกการเรนเดอร์สำคัญกว่าเวลาดาวน์โหลด
Cloudflare เปิดตัว BEACON ชุดข้อมูลสาธารณะของการวัดความเร็วจากผู้ใช้จริงแบบไม่ระบุตัวตน จากเว็บไซต์ใหญ่สุด 10,000 แห่งในเครือข่ายของบริษัท ประกาศเมื่อวันที่ 28 กันยายน 2569 ในบล็อกโพสต์ของ Ryan Townsend และ Nic Jansma ข้อมูลครอบคลุม Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) และ Interaction to Next Paint (INP) อัปเดตทุกวันใน Google BigQuery ทำให้นักการตลาดมีเกณฑ์เทียบ Core Web Vitals ที่ไม่ได้มาจากข้อมูล CrUX ของ Google เอง
BEACON คืออะไรและสร้างอย่างไร
BEACON ย่อมาจาก Browser Experience Across Cloudflare's Observed Network Cloudflare อธิบายว่าเป็นบันทึกประสิทธิภาพนับพันล้านรายการต่อวันจากผู้เข้าชมจริง ดึงจากเว็บไซต์ใหญ่สุด 10,000 แห่งในเครือข่าย ข้อมูลเปิดให้ใช้ใน Google BigQuery ภายใต้โปรเจกต์ cf-open-web-performance และ Cloudflare ระบุว่าอัปเดตทุกวัน ข้อมูลเป็นไปตามมาตรฐานชุมชนของ RUM Archive และตามคำบอกเล่าของ Cloudflare ขยายขอบเขตของ RUM Archive ขึ้น 100 เท่า โพสต์ไม่ให้ตัวเลขจำนวนบันทึกที่แน่นอน นอกจากคำว่า "billions"
เมตริกทั้งสามคือ LCP, CLS และ INP เผยแพร่เป็นฮิสโตแกรมเต็ม ผู้อ่านจึงคำนวณเปอร์เซ็นไทล์ใดก็ได้ ไม่ต้องพึ่งค่าเฉลี่ยค่าเดียว ในการวิเคราะห์ของโพสต์เองมีการกล่าวถึง P50, P75, P90 และ P95
เพื่อให้กลุ่มตัวอย่างสมดุล Cloudflare ระบุว่าปรับทุกเว็บไซต์ให้เท่ากับปริมาณทราฟฟิกของเว็บไซต์อันดับที่ 10,000 เพื่อไม่ให้เว็บไซต์ที่คนเข้ามากที่สุดครอบงำตัวเลข จากนั้นจัดกลุ่มบันทึกตามประเทศ ระบบปฏิบัติการ เบราว์เซอร์ และโปรโตคอลการเชื่อมต่อ
การทำให้ไม่ระบุตัวตน ทำไมจึงค้นเว็บไซต์ของตัวเองไม่ได้
ชื่อโดเมนและพาธ URL ถูกตัดออกจากชุดข้อมูล และกลุ่มที่มีจุดข้อมูลน้อยกว่าห้าจุดจะถูกทิ้ง ผลที่ได้เหมาะกับเกณฑ์เทียบระดับอุตสาหกรรมและตลาด แต่ใช้ตรวจคู่แข่งรายใดรายหนึ่งตามชื่อไม่ได้ ใครที่หวังจะเจอตารางจัดอันดับรายเว็บไซต์จะไม่พบที่นี่ ข้อมูลตอบคำถามประเภทว่าเบราว์เซอร์ ประเทศ หรือหมวดอุตสาหกรรมหนึ่งๆ ทำผลงานอย่างไร และไม่สามารถระบุเว็บไซต์เดี่ยวได้
ชุดข้อมูลนี้ไม่ได้มาแทนการวัดเว็บไซต์ของคุณเอง ข้อมูลภาคสนามของหน้าเว็บของคุณยังต้องมาจากการติดตามผู้ใช้จริงของคุณเอง จาก Search Console หรือจากแหล่งอื่นที่ผูกกับโดเมนของคุณ
ผลการวิเคราะห์หลักในโพสต์
Cloudflare รายงานผลหลายข้อจากข้อมูลนี้ ตารางด้านล่างรวมข้อที่มีตัวเลขเฉพาะ
| ข้อค้นพบ | ตัวเลขที่ Cloudflare รายงาน |
|---|---|
| ประเทศที่ WebKit (iOS) ตามหลังเบราว์เซอร์ Blink ตั้งแต่ 10% ขึ้นไปใน LCP และ/หรือ INP ในกลุ่มประเทศที่ WebKit มีทราฟฟิกเกิน 10% | 46 ประเทศ |
| กัมพูชา สัดส่วน WebKit ในจำนวนเพจวิว และช่องว่าง LCP เทียบกับ Blink | 17.5% ของเพจวิว LCP แย่กว่า 50% |
| แอปหน้าเดียว การนำทางแบบ hard ที่ P75 | 1,421 มิลลิวินาที |
| แอปหน้าเดียว การนำทางแบบ soft ที่ P75 | 582 มิลลิวินาที |
| แลนดิ้งเพจ (hard navigation) LCP ที่ P75 | 2,681 มิลลิวินาที |
| แลนดิ้งเพจ (hard navigation) LCP ที่ P95 | 8,940 มิลลิวินาที |
ผลเรื่องเบราว์เซอร์น่าสนใจที่สุด WebKit ซึ่งเป็นเอนจินของเบราว์เซอร์บน iOS ถูกอธิบายว่าดีที่สุดโดยรวม แต่ใน 46 ประเทศที่ WebKit มีทราฟฟิกเกิน 10% กลับตามหลังเบราว์เซอร์ Blink อย่างน้อย 10% ใน LCP, INP หรือทั้งสองอย่าง ตัวอย่างเดียวที่ยกมาคือกัมพูชา ที่ WebKit มี 17.5% ของเพจวิว และ LCP แย่กว่า Blink 50% ข้อความที่อ่านไม่ได้ระบุรายชื่ออีก 45 ประเทศ
หมวดอุตสาหกรรม
ตามหมวดอุตสาหกรรม Cloudflare รายงานว่า Government and Politics, Health และ Safe for Kids ทำผลงานดีที่สุด ส่วน Ads, Religion และ Weather แย่ที่สุด ข้อความที่อ่านไม่ได้เผยแพร่ตัวเลขเบื้องหลังลำดับนี้ในรูปที่อ้างถึงได้ ดังนั้นข้อเท็จจริงมีเพียงลำดับเท่านั้น ควรถือเป็นทิศทาง ไม่ใช่เกณฑ์ที่ต้องทำให้ได้
เวลา LCP หมดไปกับอะไร
ส่วนที่นำไปใช้ได้จริงส่วนหนึ่งแยก LCP เป็นส่วนย่อย และให้สามค่าต่อแต่ละส่วน คือ good, needs improvement และ poor ตัวเลขด้านล่างรายงานตามที่ปรากฏในโพสต์
| ส่วนย่อยของ LCP | Good / needs improvement / poor |
|---|---|
| Document TTFB | 598 ms / 1,015 ms / 1,891 ms |
| Load delay | 76 ms / 1,049 ms / 1,485 ms |
| Render delay | 157 ms / 437 ms / 2,002 ms |
โพสต์ยังระบุส่วนย่อยที่สี่คือ load duration ด้วยค่า 119, 199 และ 119 ms ค่า poor เท่ากับค่า good ซึ่งดูไม่สอดคล้อง จึงไม่ใส่ในตาราง แทนที่จะทวนตัวเลขที่ตรวจสอบไม่ได้ ข้อสรุปของ Cloudflare ระบุไว้ตรงๆ ว่าการดาวน์โหลดทรัพยากรมีส่วนต่อความล่าช้าในการโหลดที่ผู้ใช้รับรู้น้อยที่สุด ขณะที่การค้นพบองค์ประกอบ LCP และการปลดบล็อกการเรนเดอร์มีส่วนมากกว่า
สำหรับเจ้าของเว็บไซต์ นี่ชี้ว่างานควรเน้นที่เบราว์เซอร์พบรูปหรือบล็อกข้อความหลักเร็วแค่ไหน และอะไรขวางไม่ให้เพนต์ การบีบอัดไฟล์ที่เบราว์เซอร์พบช้าช่วยได้น้อยกว่าการทำให้พบเร็วขึ้น นี่เป็นการตีความข้อสรุปของ Cloudflare โพสต์นำเสนอเป็นข้อค้นพบจากชุดข้อมูล ไม่ใช่คำสั่งสำหรับเว็บไซต์ใดโดยเฉพาะ
เวลา INP หมดไปกับอะไร
INP แยกเป็นสามส่วนย่อยด้วยวิธีเดียวกัน
| ส่วนย่อยของ INP | Good / needs improvement / poor |
|---|---|
| Input delay | 18 ms / 32 ms / 84 ms |
| Processing time | 55 ms / 112 ms / 284 ms |
| Presentation delay | 56 ms / 111 ms / 217 ms |
Cloudflare ระบุว่าสำหรับการโต้ตอบที่ช้าที่สุด การรัน JavaScript เป็นตัวหลัก และเวลาในการแสดงผล ซึ่งรวมงานอย่างการคำนวณเลย์เอาต์ใหม่ ก็มีนัยสำคัญด้วย ในทางปฏิบัติโพสต์ชี้ไปที่การลดสคริปต์ที่ทำงานเมื่อแตะหรือคลิก และจำกัดงานเลย์เอาต์ที่ตามมา
แอปหน้าเดียวและแลนดิ้งเพจ
Cloudflare เทียบ hard navigation ที่โหลดทั้งหน้า กับ soft navigation ในแอปหน้าเดียวที่สร้างด้วยเฟรมเวิร์กอย่าง React, Vue, Angular และ Svelte soft navigation เรนเดอร์เร็วกว่าสองถึงสามเท่าในทุกเปอร์เซ็นไทล์ที่รายงาน
| เปอร์เซ็นไทล์ | Hard navigation | Soft navigation |
|---|---|---|
| P50 | 791 ms | 274 ms |
| P75 | 1,421 ms | 582 ms |
| P90 | 2,636 ms | 1,169 ms |
| P95 | 4,122 ms | 1,816 ms |
แลนดิ้งเพจช้ากว่าตัวเลข hard navigation ทั่วไป สำหรับ hard navigation ไปยังแลนดิ้งเพจ โพสต์รายงาน P50 ที่ 1,370 ms, P75 ที่ 2,681 ms, P90 ที่ 5,397 ms และ P95 ที่ 8,940 ms โพสต์ยังระบุว่า Google Chrome เพิ่มการรองรับ Soft Navigations API ซึ่งช่วยให้วัดแอปหน้าเดียวได้แม่นยำ
ความมั่งคั่ง แบนด์วิดท์ และช่องว่างของอุปกรณ์
Cloudflare นำ BEACON ไปรวมกับตัวเลข GDP ต่อหัวของธนาคารโลก และรายงานความสัมพันธ์ระหว่างสภาพเศรษฐกิจของประเทศกับประสิทธิภาพเว็บ ระบุว่าแบนด์วิดท์ของยุโรปสูงกว่าทวีปอื่นอย่างเห็นได้ชัด และแอฟริกามีขนาดการถ่ายโอนข้อมูลเล็กกว่า ซึ่ง Cloudflare อ่านว่าเป็นการปรับเนื้อหาให้เข้ากับเครือข่ายที่จำกัด การเปิดตัวนี้วางกรอบรอบช่องว่างระหว่างนักพัฒนาที่ใช้แล็ปท็อปเร็วกับผู้ใช้ที่ใช้โทรศัพท์รุ่นเก่าราคาประหยัด
โพสต์ยังกล่าวถึงส่วน Web Performance ใหม่บน Cloudflare Radar ที่เชื่อมกับ Internet Quality Index และบอกว่าเมตริกส่วนย่อยของ LCP และ INP จะมาถึงแดชบอร์ด RUM ของ Cloudflare ในอีกไม่กี่สัปดาห์ รวมทั้งอ้างถึง Smart Hints และ Zaraz ว่าเป็นเครื่องมือของ Cloudflare ที่เกี่ยวกับการค้นพบทรัพยากรและสคริปต์บุคคลที่สาม สิ่งเหล่านี้เป็นผลิตภัณฑ์ของ Cloudflare การตัดสินใจใช้จึงควรอิงการทดสอบกับหน้าเว็บของคุณเอง
สิ่งที่แหล่งข่าวไม่ได้บอก
- จำนวนบันทึกที่แน่นอน โพสต์บอกเพียง "billions" และไม่ให้ยอดรวม
- ตัวเลขเฉพาะประเทศไทย กัมพูชาเป็นประเทศเดียวในเอเชียตะวันออกเฉียงใต้ที่โพสต์เอ่ยถึงในข้อความที่อ่าน
- อีก 45 ประเทศที่พบช่องว่างของ WebKit นอกเหนือจากตัวอย่างกัมพูชา
- กลุ่มตัวอย่างเป็นตัวแทนของเว็บไซต์ขนาดเล็กหรือไม่ เพราะสร้างจากเว็บไซต์ใหญ่สุด 10,000 แห่งในเครือข่ายเดียวและปรับให้เท่ากับอันดับที่ 10,000
- ความเชื่อมโยงระหว่างตัวเลขใน BEACON กับอันดับบน Google โพสต์พูดถึงการวัดและเกณฑ์เทียบเท่านั้น
ความหมายต่อนักการตลาดไทย
โพสต์ไม่มีตัวเลขของไทย ส่วนนี้จึงเป็นการให้เหตุผล ผู้ชมชาวไทยมักเข้าถึงผ่านโทรศัพท์ และสัดส่วน iPhone ต่างกันไปตามแคมเปญ ข้อค้นพบเรื่อง WebKit จึงเป็นเหตุผลให้ทดสอบหน้าเว็บบน Safari ของ iOS แทนที่จะสมมติว่าผลบน Chrome ใช้แทนกันได้ แลนดิ้งเพจที่ใช้กับโฆษณา Google Adsและทราฟฟิกแคมเปญเป็นจุดเริ่มที่สมเหตุสมผล ข้อค้นพบว่าการค้นพบทรัพยากรและตัวบล็อกการเรนเดอร์สำคัญกว่าขนาดไฟล์ยังชี้ให้ดูประเด็นSEO เชิงเทคนิค เช่นวิธีที่หน้าเว็บร้องขอรูป hero และฟอนต์ ก่อนจะไปดูการบีบอัดไฟล์
ชุดข้อมูลนี้ให้เกณฑ์เทียบ ไม่ใช่สัญญาณจัดอันดับ ช่วยให้ทีมถามได้ว่า LCP ของตนใกล้ค่าทั่วไปของตลาดหรืออุตสาหกรรมเดียวกันหรือไม่ และเป็นการเทียบอิสระควบคู่กับข้อมูล CrUX ของ Google
สิ่งที่ควรตรวจบนเว็บไซต์ของคุณ
- วัด LCP, INP และ CLS ภาคสนามแยกบน Safari ของ iOS และ Chrome ของ Android ไม่ใช่เฉพาะเดสก์ท็อป
- แยก LCP เป็นส่วนย่อยทั้งสี่ แล้วดูว่าส่วนใดใหญ่สุดในแลนดิ้งเพจของคุณ แก้ส่วนที่ใหญ่สุดก่อน
- ตรวจว่ารูปหรือข้อความ LCP ถูกพบได้เร็วแค่ไหนใน HTML และอะไรบล็อกการเรนเดอร์ก่อนหน้านั้น
- สำหรับการโต้ตอบที่ช้า ดู JavaScript ที่ทำงานหลังการแตะหรือคลิก และงานเลย์เอาต์ที่ตามมา
- ถ้าใช้แอปหน้าเดียว ให้วัด soft navigation ด้วย ไม่ใช่เฉพาะการโหลดครั้งแรก
- เทียบผลของคุณกับเปอร์เซ็นไทล์ใน BEACON ของประเทศหรือหมวดอุตสาหกรรมที่เกี่ยวข้อง โดยจำไว้ว่าระบุเว็บไซต์รายเดียวในนั้นไม่ได้
คำถามที่พบบ่อยเกี่ยวกับ Cloudflare BEACON
Cloudflare BEACON คืออะไร
BEACON เป็นชุดข้อมูลสาธารณะแบบไม่ระบุตัวตนของการวัด LCP, CLS และ INP จากผู้ใช้จริงบนเว็บไซต์ใหญ่สุด 10,000 แห่งในเครือข่ายของ Cloudflare โฮสต์ใน Google BigQuery ภายใต้โปรเจกต์ cf-open-web-performance และอัปเดตทุกวัน
ค้นหาเว็บไซต์ของฉันหรือของคู่แข่งใน BEACON ได้หรือไม่
ไม่ได้ Cloudflare ตัดชื่อโดเมนและพาธ URL ออก และทิ้งกลุ่มที่มีจุดข้อมูลน้อยกว่าห้าจุด ข้อมูลจัดกลุ่มตามประเทศ ระบบปฏิบัติการ เบราว์เซอร์ และโปรโตคอล จึงรองรับการเทียบเกณฑ์ ไม่รองรับการค้นหารายเว็บไซต์
ตามข้อมูล iOS เร็วกว่าหรือช้ากว่า Chrome
ขึ้นกับตลาด WebKit ถูกอธิบายว่าดีที่สุดโดยรวม แต่ใน 46 ประเทศที่มีทราฟฟิกเกิน 10% ตามหลังเบราว์เซอร์ Blink อย่างน้อย 10% ใน LCP และ/หรือ INP ในกัมพูชา LCP ของ WebKit แย่กว่า Blink 50%
Cloudflare บอกว่าเวลา LCP หมดไปกับอะไร
ส่วนใหญ่หมดไปกับการค้นพบทรัพยากร LCP และการปลดบล็อกการเรนเดอร์ ไม่ใช่การดาวน์โหลด Cloudflare ระบุว่าการดาวน์โหลดทรัพยากรมีส่วนต่อความล่าช้าที่รับรู้น้อยที่สุด การค้นพบให้เร็วขึ้นและลดตัวบล็อกการเรนเดอร์จึงสำคัญกว่า
สรุป
BEACON เป็นเกณฑ์เทียบสาธารณะใหม่ และผลที่ใช้ได้มากที่สุดคือการแยกส่วนย่อยของ LCP และ INP ช่องว่างระหว่าง soft กับ hard navigation และตัวเลขแลนดิ้งเพจที่ช้า ข้อมูลนี้ไม่แสดงว่าเว็บไซต์ของคุณทำผลงานอย่างไร ข้อมูลภาคสนามของคุณเองจึงยังเป็นจุดเริ่มต้น
