คุณโหลดเว็บไซต์ของคุณ — มันรวดเร็ว ทีมของคุณในเมืองเดียวกันยืนยัน — รวดเร็ว จากนั้น ผู้ใช้ในเยอรมนีส่งอีเมล: "ไซต์ของคุณใช้เวลาโหลด 12 วินาที" ลูกค้าในสิงคโปร์ทวีต: "การชำระเงินหมดเวลาอยู่เสมอ"
เว็บไซต์ของคุณไม่ได้ช้าทุกที่ มันช้าที่ไหนสักแห่ง — และคุณไม่รู้ว่าที่ไหนหรือทำไม
คุณใช้เวลาหลายเดือนในการเพิ่มประสิทธิภาพเว็บไซต์ของคุณ คะแนนประภาคารอยู่ในระดับสูง Core Web Vitals เป็นสีเขียว กำหนดค่า CDN ของคุณแล้ว SSL ได้รับการตั้งค่าอย่างถูกต้อง
จากนั้นคุณเริ่มได้รับการร้องเรียน ไม่ใช่จากทุกคน — เพียงจากภูมิภาคที่เฉพาะเจาะจง ผู้ใช้ในบราซิลรายงานเวลาในการโหลด 8 วินาที ผู้ใช้ในอินเดียไม่สามารถชำระเงินให้เสร็จสิ้นได้ ผู้ใช้ในออสเตรเลียกล่าวว่าไซต์ "รู้สึกเสีย"
คุณทดสอบจากแล็ปท็อปของคุณ ทุกอย่างใช้งานได้ คุณทำการทดสอบความเร็ว - ผลลัพธ์ดูดี APM ของคุณแสดงเวลาตอบสนองที่ดี แดชบอร์ด CDN ของคุณแสดงการทำงานของ Edge ทั้งหมด
แต่ข้อร้องเรียนยังคงมีมา และคุณไม่มีทางที่จะเห็นว่าผู้ใช้เหล่านั้นกำลังประสบกับอะไรอยู่จริง ๆ
นี่คือความเป็นจริงของการใช้งานเว็บไซต์กับผู้ใช้ต่างประเทศ เว็บไซต์ของคุณอาจช้าในบางประเทศแต่เร็วในบางประเทศ — และหากคุณไม่ได้ติดตามจากประเทศเหล่านั้น คุณจะไม่มีทางรู้ได้จนกว่าจะเสียรายได้
อินเทอร์เน็ตไม่ใช่เครือข่ายเดียว แต่เป็นการรวมระบบอัตโนมัติหลายพันระบบเข้าด้วยกัน ซึ่งแต่ละระบบก็มีลักษณะเฉพาะ ข้อตกลงการเพียร์ และโหมดความล้มเหลวของตัวเอง
ก่อนที่เบราว์เซอร์จะสามารถเชื่อมต่อกับเซิร์ฟเวอร์ของคุณได้ จะต้องแก้ไขชื่อโดเมนของคุณเสียก่อน หากผู้ให้บริการ DNS ของคุณไม่มีโหนดคาสต์ใด ๆ ใกล้กับตำแหน่งของผู้ใช้ การแก้ไข DNS เพียงอย่างเดียวอาจเพิ่ม 200–500 มิลลิวินาทีในการโหลดหน้าเว็บทุกหน้า
ตัวอย่าง: ผู้ใช้ในแอฟริกาใต้ที่สอบถามเซิร์ฟเวอร์ DNS ในยุโรปเพิ่มเวลาไปกลับ 150ms+ ก่อนที่คำขอ HTTP แรกจะเริ่มต้นด้วยซ้ำ
BGP (Border Gateway Protocol) กำหนดวิธีที่แพ็กเก็ตท่องอินเทอร์เน็ต การกำหนดเส้นทางที่ไม่เหมาะสมสามารถส่งการรับส่งข้อมูลบนทางอ้อมที่แปลกประหลาด - แพ็กเก็ตจากบราซิลอาจส่งผ่านไมอามี จากนั้นอัมสเตอร์ดัม ก่อนที่จะถึงเซิร์ฟเวอร์ในลอนดอนของคุณ
ตัวอย่าง: ผู้ใช้ในเซาเปาโลที่เชื่อมต่อกับเซิร์ฟเวอร์สิงคโปร์ของคุณอาจเห็นเวลาแฝง 400ms เนื่องจากการกำหนดเส้นทางผ่านชายฝั่งตะวันตกของสหรัฐอเมริกา แทนที่จะเป็นสายเคเบิลใต้ทะเลโดยตรง
CDN ของคุณอาจมีตำแหน่ง Edge 200 ตำแหน่ง แต่ทั้งหมดไม่เท่ากัน ขอบบางส่วนโอเวอร์โหลด บางส่วนมีแคชเก่า บางส่วนมีปัญหาการเชื่อมต่อกับต้นทางของคุณ หน้าสถานะ CDN ระบุว่า "ใช้งานได้" — แต่ผู้ใช้ของคุณในจาการ์ตาจะพบกับ TTFB 5 วินาที
ตัวอย่าง: CDN edge ในกรุงมะนิลาให้บริการเนื้อหาที่แคชไว้ทันที Edge ในโฮจิมินห์ซิตี้มีแคชที่หายไปและทำให้การดึงข้อมูลต้นกำเนิดช้าทุกครั้ง
ISP บางรายควบคุมการรับส่งข้อมูลไปยังช่วง IP หรือผู้ให้บริการโฮสติ้งบางแห่ง บางแห่งมีจุดเชื่อมต่อที่หนาแน่นในช่วงชั่วโมงเร่งด่วน ผู้ใช้บน ISP รายหนึ่งโหลดไซต์ของคุณใน 1 วินาที ผู้ใช้บน ISP อื่นในเมืองเดียวกันรอ 10 วินาที
ตัวอย่าง: ผู้ใช้ Reliance Jio ในอินเดียพบเวลาในการโหลด 8 วินาที ผู้ใช้ Airtel ในเมืองเดียวกันจะได้รับประสบการณ์ 1.2 วินาที เว็บไซต์เดียวกัน เมืองเดียวกัน ISP ต่างกัน
ความจริงที่น่าหงุดหงิด: ปัญหาทั้งหมดนี้ มองไม่เห็นจากตำแหน่งของคุณ เซิร์ฟเวอร์ของคุณรวดเร็ว รหัสของคุณได้รับการปรับให้เหมาะสม CDN ของคุณได้รับการกำหนดค่าอย่างถูกต้อง แต่ที่ใดที่หนึ่งระหว่างโครงสร้างพื้นฐานของคุณและผู้ใช้บางราย บางสิ่งบางอย่างกำลังเพิ่มไม่กี่วินาทีให้กับทุกคำขอ — และคุณสามารถตรวจจับได้โดยการตรวจสอบจากที่ที่ผู้ใช้เหล่านั้นอยู่จริงๆ เท่านั้น
เครื่องมือตรวจสอบมาตรฐานได้รับการออกแบบมาเพื่อตรวจจับการหยุดทำงาน — ไม่ใช่การลดประสิทธิภาพในระดับภูมิภาค
เครื่องมือตรวจสอบความเร็วเว็บไซต์ส่วนใหญ่จะตรวจสอบจาก 3–10 แห่ง ซึ่งกระจุกตัวอย่างมากในสหรัฐอเมริกาและยุโรปตะวันตก หากผู้ใช้ของคุณอยู่ในเอเชียตะวันออกเฉียงใต้ ละตินอเมริกา ตะวันออกกลาง หรือแอฟริกา แสดงว่าคุณกำลังตาบอด
การเรียกใช้การตรวจสอบสังเคราะห์จากภูมิภาค AWS หรือ GCP ไม่ได้เป็นตัวแทน การเชื่อมต่อจากคลาวด์สู่คลาวด์มักจะดีกว่าเส้นทางเครือข่ายที่อยู่อาศัยหรือองค์กร การตรวจสอบของคุณแสดง 200ms; ผู้ใช้จริงสัมผัสประสบการณ์ 2,000ms
การรู้ว่าเพจ "ช้า" นั้นไม่เพียงพอ มันเป็น DNS หรือไม่? การเชื่อมต่อ TCP? จับมือ TLS? ถึงเวลาที่จะไบต์แรก? ดาวน์โหลดเนื้อหา? หากไม่มีการแจกแจงเวลาแฝง คุณจะไม่สามารถวินิจฉัยได้ว่าปัญหาอยู่ที่เซิร์ฟเวอร์, CDN หรือเส้นทางเครือข่ายของคุณ
เมื่อเกิดปัญหาการกำหนดเส้นทางหรือการสูญหายของแพ็กเก็ตบนเส้นทาง คุณต้องมีข้อมูล Traceroute และ MTR เพื่อระบุตำแหน่งที่แพ็กเก็ตล่าช้าหรือหลุด เครื่องมือตรวจสอบส่วนใหญ่ไม่มีสิ่งนี้ — ดังนั้นคุณจึงไม่สามารถพิสูจน์กับ CDN หรือผู้ให้บริการโฮสติ้งของคุณได้อย่างแน่ชัดว่าปัญหาอยู่ที่ใด
หากคุณตรวจสอบจากสถานที่เพียง 10 แห่ง คุณจะเห็นประสบการณ์ผู้ใช้น้อยกว่า 10% อีก 90% อาจกำลังเผชิญกับความเป็นจริงที่แตกต่างไปจากเดิมอย่างสิ้นเชิง
เว็บไซต์ที่ช้าในบางประเทศไม่ได้เป็นเพียงความไม่สะดวกเล็กๆ น้อยๆ เท่านั้น แต่ยังเป็นปัญหาทางธุรกิจอีกด้วย
ผู้ใช้ที่ประสบปัญหาเวลาในการโหลดช้าจะไม่บ่น — พวกเขาออกไป การหน่วงเวลา 3 วินาทีจะเพิ่มอัตราตีกลับ 32% การหน่วงเวลา 5 วินาทีจะเพิ่มขึ้น 90% ผู้ใช้เหล่านี้ไม่ปรากฏในการวิเคราะห์ของคุณ เนื่องจากพวกเขาโหลดโค้ดติดตามของคุณไม่เสร็จ
หากหน้าชำระเงินของคุณใช้เวลาโหลด 10 วินาทีในเยอรมนี คุณกำลังสูญเสียลูกค้าชาวเยอรมัน หากแบบฟอร์มลงทะเบียนของคุณหมดเวลาในอินเดีย คุณกำลังสูญเสียจำนวนประชากรอินเทอร์เน็ตที่ใหญ่เป็นอันดับสองของโลก สิ่งเหล่านี้ไม่ใช่กรณีขอบ แต่เป็นตลาดทั้งหมดที่คุณเพิกเฉยโดยไม่ตั้งใจ
Google รวบรวมข้อมูลจากหลายตำแหน่งทั่วโลก หาก Googlebot ประสบปัญหาเวลาในการโหลดช้าในบางภูมิภาค Core Web Vitals ของคุณประสบปัญหา งบประมาณในการรวบรวมข้อมูลลดลง และการจัดอันดับลดลง ไม่ใช่ทั่วโลก แต่ในตลาดเฉพาะ คุณเห็นปริมาณการเข้าชมลดลงและไม่รู้ว่าทำไม
คำพูดแพร่กระจาย “บริการนั้นใช้ไม่ได้ในเอเชีย” “ไม่ต้องกังวล มันใช้ไม่ได้จากยุโรป” โพสต์ในฟอรัม ทวีต และความคิดเห็นเกี่ยวกับไซต์ตรวจสอบจะสร้างการรับรู้ที่ยากจะย้อนกลับ โดยเฉพาะอย่างยิ่งเมื่อคุณไม่รู้ด้วยซ้ำว่ามีปัญหาอยู่
การวินิจฉัยปัญหาด้านประสิทธิภาพระดับภูมิภาคจำเป็นต้องมีสามสิ่ง: ความครอบคลุมทั่วโลก ความลึกของการวินิจฉัย และบริบทในอดีต
ไม่ใช่แค่มอนิเตอร์จาก "เอเชีย" — มอนิเตอร์จากโตเกียว สิงคโปร์ มุมไบ จาการ์ตา ซิดนีย์ ไม่ใช่แค่มอนิเตอร์จาก "ยุโรป" — มอนิเตอร์จากแฟรงค์เฟิร์ต ลอนดอน อัมสเตอร์ดัม วอร์ซอ สตอกโฮล์ม สถานที่แต่ละแห่งเผยให้เห็นเส้นทางเครือข่ายที่แตกต่างกันและปัญหาคอขวดที่อาจเกิดขึ้น
จับคู่ตำแหน่งการตรวจสอบของคุณกับตำแหน่งที่ผู้ใช้ของคุณอยู่จริงๆ
วัดแต่ละเฟส: การค้นหา DNS, การจับมือ TCP, การเจรจา TLS, เวลาเป็นไบต์แรก, การถ่ายโอนเนื้อหา เมื่อเพจทำงานช้า คุณจะรู้ได้อย่างแน่ชัดว่าเฟสไหนคือตัวการ และไม่ว่าจะเป็นสิ่งที่คุณสามารถแก้ไขได้หรือเป็นปัญหาเครือข่ายอัปสตรีม
"ช้า" ไม่ชัดเจน "500ms DNS + 200ms TTFB" สามารถใช้งานได้
เมื่อภูมิภาคทำงานช้า Traceroute จะแสดงให้คุณเห็นอย่างชัดเจนว่าฮอปของเครือข่ายใดที่เพิ่มเวลาแฝง การเปรียบเทียบในอดีตจะบอกคุณว่านี่เป็นพฤติกรรมใหม่หรือเป็นเช่นนี้มาตลอด สิ่งเหล่านี้จะช่วยคุณพิจารณาว่าเป็นปัญหาชั่วคราวหรือปัญหาการกำหนดเส้นทางถาวร
ข้อมูล Traceroute เป็นข้อพิสูจน์ของคุณเมื่อส่งต่อไปยังผู้ให้บริการ
วิธีการทีละขั้นตอนในการระบุว่าเหตุใดเว็บไซต์ของคุณจึงช้าในบางประเทศ แต่เร็วในบางประเทศ
ดึงข้อมูลจาก Google Analytics, Cloudflare หรือบันทึกเซิร์ฟเวอร์ของคุณ ระบุประเทศและเมือง 10 อันดับแรกที่ผู้ใช้ของคุณมาจาก นี่คือสถานที่ที่คุณต้องติดตามดู
ใช้บริการตรวจสอบที่ตรวจสอบจากสถานที่มากกว่า 50 แห่ง และกำหนดเวลาต่อเฟส (DNS, TCP, TLS, TTFB) หากไม่มีรายละเอียดนี้ คุณจะรู้ว่าบางสิ่งบางอย่างช้าแต่ไม่รู้ว่าอะไรหรือเพราะเหตุใด
เมื่อคุณระบุภูมิภาคที่ช้า ให้เรียกใช้ Traceroute และ MTR เพื่อดูเส้นทางเครือข่าย มองหาฮ็อปที่มีเวลาแฝงสูง แพ็กเก็ตสูญหาย หรือเส้นทางที่ผิดปกติ ข้อมูลนี้จะบอกคุณว่าปัญหาอยู่ที่ CDN ของคุณ ต้นทาง หรือแกนหลักอินเทอร์เน็ต
ตรวจสอบว่า CDN ของคุณให้บริการเนื้อหาจาก Edge ที่ใกล้ที่สุดจริง ๆ ตรวจสอบอัตราส่วนการเข้าถึงแคชต่อภูมิภาค การขาดแคชหมายถึงการดึงข้อมูลต้นทางที่ช้า Edge บางส่วนอาจมีการกำหนดค่าไม่ถูกต้องหรือโอเวอร์โหลด
หากการแก้ไข DNS ช้าในบางภูมิภาค ผู้ให้บริการ DNS ของคุณอาจไม่มีโหนดการส่งใด ๆ ในบริเวณใกล้เคียง พิจารณาผู้ให้บริการ DNS ที่มีความครอบคลุมทั่วโลกที่ดีกว่า หรือเพิ่มผู้ให้บริการรองสำหรับการสำรอง
เมื่อติดต่อ CDN ผู้ให้บริการโฮสติ้ง หรือบริการ DNS เกี่ยวกับปัญหาระดับภูมิภาค ให้นำข้อมูล Traceroute การแบ่งเวลา และแผนภูมิประวัติมาด้วย "มันช้าในสิงคโปร์" ถูกเมินเฉย "นี่คือ Traceroute 30 วันที่แสดงการกระโดด 400 มิลลิวินาทีที่ขอบของคุณ" ได้รับการแก้ไขแล้ว
กำหนดค่าการแจ้งเตือนสำหรับภูมิภาคเฉพาะที่จะแจ้งให้คุณทราบเมื่อเวลาแฝงเกินเกณฑ์หรือความพร้อมใช้งานลดลง คุณไม่จำเป็นต้องมีการแจ้งเตือนเวลาหยุดทำงานทั่วโลก — คุณต้องมีการแจ้งเตือนการเสื่อมสภาพเฉพาะภูมิภาค
ใช้เวลา 10 นาทีในแต่ละสัปดาห์เพื่อทบทวนแนวโน้มผลการดำเนินงานในระดับภูมิภาค การย่อยสลายที่ช้านั้นมองไม่เห็นในแบบเรียลไทม์แต่จะเห็นได้ชัดในแผนภูมิในอดีต จับปัญหาก่อนที่จะทบต้น
Latency Global ถูกสร้างขึ้นโดยเฉพาะเพื่อแก้ปัญหา "ช้าในบางประเทศ เร็วในบางประเทศ" เราตรวจสอบจาก สถานที่จริงมากกว่า 70 แห่งทั่ว 6 ทวีป — ไม่ใช่แค่ภูมิภาคคลาวด์ แต่ยังเป็นจุดชมวิวเครือข่ายจริงที่สะท้อนถึงประสบการณ์ของผู้ใช้จริง
การตรวจสอบทุกครั้งจะมีการแจกแจงเวลาแฝงแบบเต็ม: DNS, TCP, TLS, TTFB คุณสามารถเรียกใช้ Traceroute และ MTR ตามความต้องการได้จากทุกที่ ข้อมูลประวัติช่วยให้คุณเปรียบเทียบประสิทธิภาพปัจจุบันกับเส้นพื้นฐานได้ และมีค่าใช้จ่าย $5/เดือน ไม่ใช่ $200–$500 ที่การตรวจสอบทั่วโลกขององค์กรมักจะดำเนินการ
การตรวจสอบทั่วโลกมีค่าใช้จ่ายสูงในการใช้งาน — นั่นเป็นเหตุผลว่าทำไมเครื่องมือส่วนใหญ่จึงจำกัดสถานที่ เรารักษาราคาให้ต่ำโดยให้บริการลูกค้าที่ชำระเงิน ไม่ใช่รักษาระดับฟรี
สาเหตุที่พบบ่อยที่สุด ได้แก่: เวลาแฝงในการแก้ไข DNS (ผู้ให้บริการ DNS ของคุณไม่มีเซิร์ฟเวอร์ใกล้กับผู้ใช้เหล่านั้น), การกำหนดเส้นทาง BGP ต่ำกว่ามาตรฐาน (แพ็กเก็ตใช้เส้นทางที่ไม่มีประสิทธิภาพ), ปัญหาประสิทธิภาพ CDN Edge (แคชพลาดหรือ Edge โอเวอร์โหลด) และการควบคุมปริมาณหรือความแออัดของ ISP ระดับภูมิภาค วิธีเดียวที่จะระบุได้ว่าสิ่งใดเป็นสาเหตุของปัญหาเฉพาะของคุณคือการตรวจสอบจากตำแหน่งเหล่านั้นพร้อมรายละเอียดเวลาแฝงที่สมบูรณ์และข้อมูลการติดตาม
การทดสอบครั้งเดียวจะทำให้คุณเห็นภาพรวม แต่ประสิทธิภาพจะแตกต่างกันไปตลอดทั้งวัน คุณต้องมีการตรวจสอบอย่างต่อเนื่องเพื่อตรวจจับปัญหาที่เกิดขึ้นเป็นระยะๆ ระบุรูปแบบ (เช่น การชะลอตัวในช่วงชั่วโมงเร่งด่วนในภูมิภาคใดภูมิภาคหนึ่ง) และสร้างเส้นฐานในอดีต การทดสอบความเร็วฟรีจะไม่ให้รายละเอียดเวลาแฝงหรือข้อมูลการติดตามเพื่อวินิจฉัยสาเหตุที่แท้จริง
"การปฏิบัติงาน" ไม่ได้หมายความว่า "เหมาะสมที่สุด" Edges สามารถทำงานได้แต่: มีอัตราส่วนการเข้าถึงแคชต่ำ (บังคับให้ดึงข้อมูลต้นทาง) มีการโหลดมากเกินไปในช่วงชั่วโมงเร่งด่วน มีเนื้อหาเก่าหรือกำหนดค่าไม่ถูกต้อง หรือมีการเชื่อมต่อที่ไม่ดีกับ ISP บางแห่ง การตรวจสอบอิสระจากภายนอก CDN ของคุณช่วยให้คุณได้รับความจริงโดยที่แดชบอร์ด CDN ไม่แสดง
ดูรายละเอียดเวลาในการตอบสนอง หาก TTFB (Time to First Byte) สูง แต่ DNS/TCP/TLS เป็นเรื่องปกติ แสดงว่าปัญหาอยู่ที่เซิร์ฟเวอร์ต้นทางของคุณ ถ้า DNS หรือ TCP handshake สูง ปัญหาจะเกิดขึ้นก่อนเซิร์ฟเวอร์ของคุณ Traceroute แสดงให้คุณเห็นได้อย่างชัดเจนว่าฮ็อพเครือข่ายใดที่เพิ่มเวลาแฝง — ไม่ว่าจะเป็นผู้ให้บริการโฮสต์ของคุณ เครือข่ายการขนส่งสาธารณะ หรือ ISP
คุณอาจไม่สามารถแก้ไขปัญหาระดับ ISP ได้โดยตรง แต่คุณสามารถ: (1) ตรวจสอบว่าไม่ใช่โครงสร้างพื้นฐานของคุณ (2) บันทึกปัญหาสำหรับลูกค้าที่ได้รับผลกระทบ (3) สำรวจ CDN Edge ทางเลือกที่มีเส้นทางแตกต่างออกไป (4) เพิ่มเซิร์ฟเวอร์ต้นทางในภูมิภาคที่มีปัญหาถาวร หรือ (5) ติดต่อทีมเครือข่ายของผู้ให้บริการโฮสติ้งของคุณพร้อมหลักฐานการติดตามเพื่อสำรวจการเปลี่ยนแปลงแบบเพียร์
สำหรับเว็บไซต์ที่ใช้งานจริงที่มีผู้ใช้ต่างประเทศ ช่วงเวลาตรวจสอบ 1 นาทีถือว่าเหมาะสมที่สุด ซึ่งจะตรวจจับปัญหาที่เกิดขึ้นเป็นระยะๆ และให้ข้อมูลที่เพียงพอสำหรับการวิเคราะห์แนวโน้มที่มีความหมาย หน้าเว็บที่มีความสำคัญน้อยกว่าสามารถยอมรับช่วงเวลา 5 นาทีได้ แต่คุณจะพลาดปัญหาเรื่องระยะเวลาสั้น
หยุดเดาว่าทำไมเว็บไซต์ของคุณจึงช้าในบางประเทศ เพิ่ม URL ของคุณ เลือกสถานที่ตรวจสอบ และดูว่าผู้ใช้ทั่วโลกของคุณได้รับประสบการณ์อะไรบ้าง — ก่อนที่พวกเขาจะส่งอีเมลถึงคุณเกี่ยวกับเรื่องนี้
$5/เดือน • ไม่มีสัญญา • ยกเลิกได้ตลอดเวลา