SCT

กำลังเตรียมประสบการณ์ดิจิทัล

เว็บทั่วโลกเร็วแค่ไหนจริง ๆ: Cloudflare เปิดข้อมูลความเร็วจากผู้ใช้จริงชุด BEACON ให้ใครก็วิเคราะห์ได้ และสิ่งที่ตัวเลขบอกทีมทำเว็บ

ทีมทำเว็บส่วนใหญ่วัดความเร็วจากเครื่องของตัวเองหรือจากเครื่องมือทดสอบ ซึ่งไม่เหมือนสิ่งที่ผู้ใช้จริงเจอบนมือถือและเครือข่ายที่หลากหลาย Cloudflare เปิดข้อมูลชุด BEACON ซึ่งรวบรวมการวัดความเร็วจากผู้ใช้จริงนับพันล้านครั้งต่อวันของเว็บไซต์ 10,000 อันดับแรกบนเครือข่ายของตน ให้ทุกคนวิเคราะห์ได้ผ่าน Google BigQuery ข้อมูลชุดแรกบอกว่าหน้าแรกที่ผู้ใช้เข้ามาถึงช้ากว่าการเปลี่ยนหน้าภายในเว็บหลายเท่า และเบราว์เซอร์บน iPhone ช้ากว่าเบราว์เซอร์ตระกูล Chrome ในหลายสิบประเทศ

ทีมทำเว็บส่วนใหญ่วัดความเร็วจากเครื่องของตัวเองหรือจากเครื่องมือทดสอบ ซึ่งไม่เหมือนสิ่งที่ผู้ใช้จริงเจอบนมือถือและเครือข่ายที่หลากหลาย Cloudflare เปิดข้อมูลชุด BEACON ซึ่งรวบรวมการวัดความเร็วจากผู้ใช้จริงนับพันล้านครั้งต่อวันของเว็บไซต์ 10,000 อันดับแรกบนเครือข่ายของตน ให้ทุกคนวิเคราะห์ได้ผ่าน Google BigQuery ข้อมูลชุดแรกบอกว่าหน้าแรกที่ผู้ใช้เข้ามาถึงช้ากว่าการเปลี่ยนหน้าภายในเว็บหลายเท่า และเบราว์เซอร์บน iPhone ช้ากว่าเบราว์เซอร์ตระกูล Chrome ในหลายสิบประเทศ

BEACON คืออะไร และต่างจากเครื่องมือวัดความเร็วทั่วไปอย่างไร

BEACON ย่อมาจาก Browser Experience Across Cloudflare's Observed Network เป็นข้อมูลแบบ Real User Monitoring หรือการวัดจากเบราว์เซอร์ของผู้ใช้จริง ต่างจากการทดสอบในห้องแล็บที่จำลองเครื่องและเครือข่ายเพียงแบบเดียว ข้อมูลครอบคลุมเว็บไซต์ 10,000 อันดับแรกที่ใช้ Cloudflare ทุกเอนจินเบราว์เซอร์หลัก อัปเดตทุกวัน และเก็บเป็นฮิสโทแกรมเต็มแทนค่าเฉลี่ยตัวเดียว ผู้วิเคราะห์จึงคำนวณเปอร์เซ็นไทล์ที่ต้องการเองได้ เช่น เปอร์เซ็นไทล์ที่ 75 ซึ่ง Google ใช้ตัดสิน Core Web Vitals ข้อมูลอยู่ในโปรเจกต์ BigQuery ชื่อ cf-open-web-performance พร้อมตัวอย่างคำสั่งค้นข้อมูล

วัดอะไรบ้าง

ตัวชี้วัดใน BEACON
ตัวชี้วัดความหมายส่วนย่อยที่แยกให้ดู
LCP (Largest Contentful Paint)เวลาจนเนื้อหาหลักชิ้นใหญ่ที่สุดขึ้นจอเวลารอเซิร์ฟเวอร์ตอบ (TTFB) · รอเริ่มโหลด · เวลาโหลด · รอวาดขึ้นจอ
INP (Interaction to Next Paint)เวลาตั้งแต่ผู้ใช้กดจนหน้าจอตอบสนองรอเริ่มประมวลผล · เวลาประมวลผล · เวลาวาดผลลัพธ์
CLS (Cumulative Layout Shift)ความนิ่งของหน้าจอระหว่างโหลด–

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

สิ่งที่ข้อมูลชุดแรกบอก

LCP ของการเปลี่ยนหน้าแบบ soft และแบบ hard (มิลลิวินาที)
เปอร์เซ็นไทล์Soft navigationHard navigation
P50274791
P755821,421
P901,1692,636
P951,8164,122

Soft navigation คือการเปลี่ยนหน้าภายในเว็บที่ไม่โหลดทั้งหน้าใหม่ เช่นในเว็บแบบแอปหน้าเดียว ส่วน hard navigation คือการโหลดหน้าใหม่ทั้งหมด ข้อมูลพบว่าแบบ soft เร็วกว่า 2-3 เท่าในทุกเปอร์เซ็นไทล์ ที่น่าสนใจที่สุดคือหน้าแรกที่ผู้ใช้เข้ามาถึง (landing page) มี LCP ที่ P75 ถึง 2,681 มิลลิวินาที เกินเกณฑ์ "ดี" ของ Google ที่ 2.5 วินาที และที่ P95 สูงถึง 8,940 มิลลิวินาที ซึ่งหน้าแรกนี้คือหน้าที่คนจากผลค้นหาและโฆษณาเห็นเป็นหน้าแรก

ด้านเบราว์เซอร์ WebKit ซึ่งเป็นเอนจินของ Safari และทุกเบราว์เซอร์บน iPhone ทำได้ดีโดยรวม แต่ช้ากว่าเบราว์เซอร์ตระกูล Blink อย่าง Chrome ราว 10% ใน 46 ประเทศ ตัวอย่างที่ชัดคือกัมพูชาที่ LCP บน WebKit ช้ากว่าราว 50% ส่วนด้านอุตสาหกรรม เว็บภาครัฐ สุขภาพ และเว็บสำหรับเด็กเร็วที่สุด ขณะที่เว็บโฆษณา ศาสนา และพยากรณ์อากาศช้าที่สุด และภาพรวมยืนยันสิ่งที่คาดไว้ว่าพื้นที่ที่แบนด์วิดท์สูงอย่างยุโรปมี LCP เร็วกว่า

หน้าที่ช้า ช้าเพราะอะไร

BEACON แยกเวลา LCP เป็นช่วงย่อยตามกลุ่มหน้าที่ผ่านเกณฑ์ดี ต้องปรับปรุง และแย่ ช่วงที่โตขึ้นมากที่สุดในกลุ่มแย่คือเวลารอเซิร์ฟเวอร์ตอบ (ราว 1.9 วินาที เทียบกับราว 0.6 วินาทีในกลุ่มดี) และเวลารอวาดขึ้นจอ (ราว 2 วินาที เทียบกับราว 0.16 วินาที) ขณะที่เวลาดาวน์โหลดรูปหรือไฟล์หลักเองใช้เพียงราว 0.1-0.2 วินาทีในทุกกลุ่ม ความหมายเชิงปฏิบัติคือหน้าที่ช้ามักช้าเพราะเซิร์ฟเวอร์หรือสคริปต์ที่บล็อกการแสดงผล มากกว่าเพราะรูปใหญ่ ด้าน INP กลุ่มที่แย่ใช้เวลาประมวลผลราว 284 มิลลิวินาที สะท้อนว่า JavaScript ที่หนักคือต้นเหตุหลัก

ทีมทำเว็บไทยใช้ประโยชน์จากข้อมูลนี้อย่างไร

ข้อมูลรวมตามประเทศ จึงดูภาพของผู้ใช้ในไทยแยกได้ ทั้งสัดส่วนเบราว์เซอร์ ความเร็วบน iPhone เทียบกับ Android และความเร็วตามโปรโตคอล ใช้ตั้งเป้าความเร็ว (performance budget) ที่อิงกับผู้ใช้จริงในตลาดเดียวกัน แทนการเทียบกับค่าที่วัดจากเครื่องของทีม และเมื่อต้องจัดลำดับงาน ข้อมูลชี้ชัดว่าหน้าแรกที่คนเข้ามาถึงควรได้รับการปรับก่อน โดยเริ่มจากเวลาตอบของเซิร์ฟเวอร์และการตัดสคริปต์ที่บล็อกการวาดหน้า ส่วนการเปลี่ยนหน้าแบบ soft ช่วยให้เว็บรู้สึกเร็วขึ้นมาก แต่ต้องออกแบบให้ทุกหน้ายังมี URL และ HTML ของตัวเองเพื่อไม่ให้เสียผลค้นหา

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

สรุปสาระสำคัญ

  • BEACON คืออะไร และต่างจากเครื่องมือวัดความเร็วทั่วไปอย่างไร
  • วัดอะไรบ้าง
  • สิ่งที่ข้อมูลชุดแรกบอก
แหล่งอ้างอิงเรียบเรียงจาก Cloudflare Blog — How fast is the web? Explore billions of real-user measurements with BEACON — อ่านบทความต้นฉบับ
ภาพปก: Cloudflare Blog · ลิขสิทธิ์ภาพเป็นของเจ้าของต้นฉบับ ใช้ประกอบการรายงานพร้อมอ้างอิงแหล่งที่มา
มีคำถามเพิ่มเติมเกี่ยวกับบทความนี้? เขียนหาเราได้ที่ info@smart-cyber-tech.com
บริการที่เกี่ยวข้องจากทีมงาน Smart Cyber Tech

บทความอื่นที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

ลดความหน่วง P99 ของ CDN ลง 91% ด้วยการรวมข้อมูลเป็นชิ้นขนาดพอดี: บทเรียนเรื่อง cache จาก Vercel เว็บ

ลดความหน่วง P99 ของ CDN ลง 91% ด้วยการรวมข้อมูลเป็นชิ้นขนาดพอดี: บทเรียนเรื่อง cache จาก Vercel

Vercel เล่าว่าลดเวลาค้นหาข้อมูลเส้นทางของ CDN ในกลุ่มคำขอที่ช้าที่สุด 1 เปอร์เซ็นต์ (P99) จาก 215.8 มิลลิวินาทีเหลือ 19.1 มิลลิวินาทีได้อย่างไร สิ่งที่น่าสนใจคือไม่ได้ใช้เซิร์ฟเวอร์ที่แรงขึ้น แต่เปลี่ยนวิธีจัดเก็บข้อมูลจากอ็อบเจกต์แยกทีละเส้นทางมาเป็นชิ้นข้อมูลขนาดราว 200 KB ที่ค้นหาแบบ binary search ได้ในตัว บทความนี้สรุปปัญหา วิธีแก้ ตัวเลขผลลัพธ์ และบทเรียนที่ทีมพัฒนาเว็บในไทยนำไปใช้กับระบบของตัวเองได้

อ่านบทความ
Cloudflare เขียน module registry ของ Workers ใหม่: ทำไมการเปลี่ยนจากพาธเป็น URL ถึงปลดล็อกความเข้ากันได้กับ Node.js เว็บ

Cloudflare เขียน module registry ของ Workers ใหม่: ทำไมการเปลี่ยนจากพาธเป็น URL ถึงปลดล็อกความเข้ากันได้กับ Node.js

Cloudflare เขียนระบบจัดการโมดูลของ Workers ใหม่ทั้งหมด สาเหตุคือระบบเดิมมองตัวระบุโมดูลเป็นพาธแบบไฟล์ ไม่ใช่ URL ซึ่งทำให้รองรับความสามารถมาตรฐานของ JavaScript สมัยใหม่ไม่ได้ และยังคอมไพล์โค้ดทั้งบันเดิลตั้งแต่ต้นแม้จะไม่ได้ใช้ทุกส่วน ระบบใหม่ใช้ URL เป็นรูปแบบตัวระบุ คอมไพล์เฉพาะโมดูลที่ถูกเรียกจริง และแบ่งปันแคชข้ามอินสแตนซ์ได้ บทความนี้สรุปว่าเปลี่ยนอะไรบ้าง ต้องเปิดแฟล็กอะไร และบทเรียนที่ทีมพัฒนาเว็บนำไปใช้ได้

อ่านบทความ
ทำไมเว็บไซต์ไม่ควรหยุดเปลี่ยนแปลง: เลิกวงจรรื้อใหม่ทุกสามปี เว็บ

ทำไมเว็บไซต์ไม่ควรหยุดเปลี่ยนแปลง: เลิกวงจรรื้อใหม่ทุกสามปี

เว็บไซต์ส่วนใหญ่ดีที่สุดในวันเปิดตัว แล้วค่อย ๆ ถดถอยลงจนถึงวันที่ต้องรื้อใหม่ทั้งหมด บทความนี้เสนอว่าปัญหาไม่ได้อยู่ที่เทคโนโลยี แต่อยู่ที่การไม่มีใครดูแลต่อ พร้อมแนวทางแบ่งงานบำรุงรักษาให้เดินหน้าได้ต่อเนื่อง

อ่านบทความ

ติดต่อเพื่อขอรับคำปรึกษาจากทีมงาน

ตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย

ปรึกษาทีมของเรา