เจ้าของร้านขายของฝากแห่งหนึ่งในตัวเมืองโทรมาหาเราตอนสี่ทุ่มครึ่ง เสียงตื่นตระหนกมาก “พี่ครับ เว็บผมล่ม ขึ้นว่า Bandwidth Limit Exceeded วันนี้เพิ่งลงโฆษณาไป ยอดกำลังมาเลย”
พอเข้าไปดูหลังบ้าน ปรากฏว่าโฮสต์ให้แบนด์วิดท์มา 10 GB ต่อเดือน แต่หน้าแรกของเว็บมีรูปสินค้า 24 รูป ขนาดไฟล์ละ 3-4 MB ที่อัปโหลดตรงจากกล้องมือถือโดยไม่ย่อเลย นั่นแปลว่าคนเข้าเว็บแค่ประมาณ 130 คนก็กินโควตาทั้งเดือนหมดแล้ว เงินค่าโฆษณาที่จ่ายไปกลายเป็นการพาคนไปเจอหน้าจอสีขาวที่เขียนว่าเว็บใช้งานไม่ได้
เรื่องนี้เกิดขึ้นบ่อยกว่าที่คิด และต้นตอเกือบทั้งหมดมาจากการที่เจ้าของเว็บไม่เคยเข้าใจว่า bandwidth คือ อะไรกันแน่ บทความนี้จะอธิบายให้จบในที่เดียว ตั้งแต่นิยาม การคำนวณจริงด้วยสูตรง่าย ๆ ไปจนถึงความจริงเบื้องหลังคำว่า “unlimited” ที่โฮสต์ไทยชอบใช้กัน
Bandwidth คือ อะไรกันแน่
Bandwidth (แบนด์วิดท์) คือ ปริมาณข้อมูลสูงสุดที่สามารถส่งผ่านช่องทางการเชื่อมต่อได้ในหน่วยเวลาหนึ่ง ถ้าพูดในบริบทของเว็บโฮสติ้ง มันหมายถึงปริมาณข้อมูลทั้งหมดที่เซิร์ฟเวอร์ของคุณส่งออกไปให้ผู้เข้าชมภายในหนึ่งเดือน
เปรียบเทียบง่าย ๆ ให้เห็นภาพ ลองนึกถึงท่อประปาที่ต่อเข้าบ้าน
- ขนาดท่อ = bandwidth ทางเทคนิค (ส่งข้อมูลได้กี่ Mbps ในหนึ่งวินาที)
- ปริมาณน้ำที่ใช้ทั้งเดือน = data transfer หรือโควตาแบนด์วิดท์ที่โฮสต์คิดเงิน
- ความเร็วที่น้ำไหลมาถึงก๊อก = latency กับ throughput ซึ่งเป็นคนละเรื่อง
ตรงนี้คือจุดที่คนสับสนมากที่สุด เพราะในวงการโฮสติ้ง คำว่า bandwidth ถูกใช้แทน “data transfer ต่อเดือน” จนกลายเป็นมาตรฐานไปแล้ว เวลาแพ็กเกจโฮสต์เขียนว่า “Bandwidth 100 GB” เขาไม่ได้หมายถึงความกว้างของท่อ แต่หมายถึงว่าเดือนหนึ่งคุณดึงข้อมูลออกจากเซิร์ฟเวอร์ได้ 100 GB
หน่วยที่ต้องแยกให้ออก
ระวังเรื่องหน่วยให้ดี เพราะมันหลอกตาได้ง่ายมาก
- bit (b) กับ Byte (B) ต่างกัน 8 เท่า — 1 Byte = 8 bits
- ความเร็วเน็ตบ้านที่โฆษณาว่า 500 Mbps คือ 500 megabits ต่อวินาที ซึ่งเท่ากับประมาณ 62.5 MB ต่อวินาทีเท่านั้น
- โควตาโฮสติ้งใช้หน่วย GB (gigabytes) เสมอ
เวลาอ่านสเปกอะไรก็ตาม ให้ดูว่าตัว B ใหญ่หรือเล็ก เพราะความต่าง 8 เท่าทำให้ตัดสินใจผิดได้จริง ๆ
Bandwidth ต่างจาก Speed, Latency, Throughput อย่างไร
นี่คือคำถามที่เราเจอบ่อยที่สุดเวลาคุยกับลูกค้า เพราะสี่คำนี้ถูกใช้ปนกันจนมั่วไปหมด ทั้งที่มันวัดคนละอย่างและแก้ปัญหาคนละแบบ
| คำศัพท์ | วัดอะไร | หน่วย | เปรียบเทียบกับถนน | ถ้ามีปัญหาจะรู้สึกยังไง |
|---|---|---|---|---|
| Bandwidth | ความจุสูงสุดของช่องทาง / โควตาข้อมูลต่อเดือน | Mbps หรือ GB/เดือน | จำนวนเลนบนถนน | เว็บล่ม ขึ้น 509 Bandwidth Limit Exceeded |
| Throughput | ปริมาณข้อมูลที่ส่งได้จริง ณ ขณะนั้น | Mbps | รถที่วิ่งผ่านได้จริงในชั่วโมงเร่งด่วน | ดาวน์โหลดช้ากว่าที่ควร แม้ท่อใหญ่ |
| Latency | เวลาที่ข้อมูลเดินทางไปกลับ | มิลลิวินาที (ms) | ระยะทางจากบ้านถึงที่ทำงาน | กดแล้วค้างแวบหนึ่งก่อนอะไรจะเกิดขึ้น |
| Speed (ที่ผู้ใช้รู้สึก) | ผลรวมของทุกอย่างข้างบน + การประมวลผลฝั่ง browser | วินาที | เวลาที่ใช้เดินทางถึงจริง | หน้าเว็บโหลดนาน |
ประเด็นสำคัญคือ การเพิ่ม bandwidth ไม่ได้ทำให้เว็บเร็วขึ้นเสมอไป ถ้าเว็บคุณช้าเพราะเซิร์ฟเวอร์อยู่ที่สหรัฐฯ แต่คนดูอยู่หาดใหญ่ ปัญหาคือ latency ไม่ใช่ bandwidth การอัปเกรดแพ็กเกจเป็น 500 GB ก็ไม่ช่วยอะไร สิ่งที่ช่วยคือย้ายเซิร์ฟเวอร์มาสิงคโปร์หรือไทย หรือใช้ CDN
ในทางกลับกัน ถ้าเว็บคุณช้าเพราะหน้าเดียวมีขนาด 12 MB การเพิ่ม bandwidth ก็ไม่ช่วยเช่นกัน เพราะปัญหาคือขนาดหน้าเว็บที่ใหญ่เกินไป ถ้าอยากเข้าใจเรื่องเวลาตอบสนองของเซิร์ฟเวอร์ลึกกว่านี้ แนะนำอ่าน คู่มือ TTFB และการปรับ server response เพิ่มเติม
ทำไมเจ้าของเว็บปี 2026 ต้องสนใจเรื่องนี้
หลายคนคิดว่ายุคนี้แบนด์วิดท์ถูกจนไม่ต้องคิดแล้ว ซึ่งจริงแค่ครึ่งเดียว ราคาต่อ GB ถูกลงมากก็จริง แต่ขนาดหน้าเว็บโตเร็วกว่าราคาที่ลดลงเสียอีก
จากที่เราสังเกตจากงานลูกค้าและข้อมูลสาธารณะในตลาด ตัวเลขโดยประมาณปี 2026 เป็นแบบนี้
- ขนาดหน้าเว็บเฉลี่ยบนเดสก์ท็อปอยู่ราว ~2.5-3 MB ต่อหน้า เพิ่มขึ้นเกือบเท่าตัวจากเมื่อห้าปีก่อน
- ประมาณ ~55-65% ของขนาดหน้าเว็บทั่วไปมาจากรูปภาพและวิดีโอ
- เว็บ WordPress ที่ติดตั้งปลั๊กอินเยอะ ๆ โดยไม่ optimize มักมีหน้าแรกขนาด ~4-6 MB
- เว็บที่ผ่านการ optimize จริงจัง ทำได้ที่ ~600 KB - 1.2 MB ต่อหน้า
ความต่างระหว่าง 5 MB กับ 800 KB คือ 6 เท่า แปลว่าโฮสต์แพ็กเกจเดียวกันจะรับคนได้ต่างกัน 6 เท่า และค่าโฆษณาที่คุณจ่ายก็จะให้ผลลัพธ์ต่างกัน 6 เท่าในแง่ของคนที่รอโหลดจนจบจริง ๆ
นี่ยังไม่นับว่า bot และ crawler กินแบนด์วิดท์ด้วย ปี 2026 นอกจาก Googlebot แล้วยังมี AI crawler อีกเป็นสิบตัวที่วิ่งเก็บข้อมูลเว็บคุณ บางเว็บที่เราตรวจสอบพบว่าทราฟฟิกจาก bot กินไป ~25-40% ของแบนด์วิดท์ทั้งหมด โดยที่เจ้าของเว็บไม่รู้ตัว
สูตรคำนวณ Bandwidth ที่เว็บคุณใช้จริง
สูตรพื้นฐานง่ายมาก จำแค่บรรทัดเดียว
Bandwidth ต่อเดือน = ขนาดหน้าเว็บเฉลี่ย × จำนวน Pageviews ต่อเดือน × Safety Margin
ขยายความแต่ละตัวแปร
1. ขนาดหน้าเว็บเฉลี่ย (Average Page Size) วัดได้จาก Chrome DevTools แท็บ Network โหลดหน้าเว็บแบบล้างแคช แล้วดูตัวเลข “transferred” ด้านล่าง ทำสัก 5-6 หน้าที่คนเข้าบ่อยแล้วหาค่าเฉลี่ย หรือใช้ PageSpeed Insights ก็บอกขนาด payload รวมให้เหมือนกัน
2. Pageviews ต่อเดือน ดูจาก Google Analytics 4 ที่รายงาน Pages and screens ใช้ตัวเลข views ไม่ใช่ users เพราะคนหนึ่งคนเปิดหลายหน้า
3. Safety Margin คูณเพิ่ม 1.5-2 เท่าเสมอ เผื่อสำหรับ bot traffic, การอัปโหลดไฟล์เข้าหลังบ้าน, ระบบ backup ที่ดึงไฟล์ออก, อีเมลที่ใช้โดเมนเดียวกัน และเดือนที่ยอดพุ่งผิดปกติ
สูตรเต็มที่เราใช้จริงกับลูกค้า:
Bandwidth (GB/เดือน) = (ขนาดหน้าเฉลี่ยเป็น MB × Pageviews) ÷ 1024 × 1.7ตัวเลข 1.7 คือ margin ที่เราพบว่าใกล้เคียงความจริงที่สุดสำหรับเว็บ SME ทั่วไป ถ้าเว็บมีไฟล์ให้ดาวน์โหลดหรือมีวิดีโอ ให้ขยับเป็น 2.5 ขึ้นไป
ตัวอย่างคำนวณจริง 3 เคส
ทฤษฎีอย่างเดียวไม่พอ มาดูเคสที่เจอจริงในงานลูกค้าภาคใต้กัน
เคส 1: เว็บบริษัท 5 หน้า (Corporate Site)
โรงงานแปรรูปยางพาราแห่งหนึ่งใน จ.สุราษฎร์ธานี ทำเว็บ 5 หน้า: หน้าแรก, เกี่ยวกับเรา, สินค้า, ผลงาน, ติดต่อ
- ขนาดหน้าเฉลี่ย: 1.2 MB (มีภาพโรงงานพอสมควร แต่ย่อมาแล้ว)
- Pageviews: 3,000 ต่อเดือน
- คำนวณ: (1.2 × 3,000) ÷ 1024 × 1.7 = ~6 GB ต่อเดือน
สรุป: แพ็กเกจโฮสต์ถูกสุดที่ให้ 10-20 GB ก็เหลือเฟือ ไม่ต้องจ่ายแพง เว็บลักษณะนี้แทบไม่มีทางชนเพดาน ยกเว้นจะทำแคมเปญโฆษณาใหญ่
เคส 2: บล็อกคอนเทนต์ที่โตแล้ว
เว็บรีวิวที่พักและร้านอาหารในกระบี่ มีบทความ 180 ชิ้น รูปเยอะเพราะเป็นเนื้อหาท่องเที่ยว
- ขนาดหน้าเฉลี่ย: 2.4 MB (รูปเยอะ ยังไม่ได้ทำ WebP)
- Pageviews: 45,000 ต่อเดือน
- คำนวณ: (2.4 × 45,000) ÷ 1024 × 1.7 = ~179 GB ต่อเดือน
สรุป: ตัวเลขกระโดดทันที และนี่คือจุดที่เว็บส่วนใหญ่เริ่มมีปัญหา ถ้าเว็บนี้แปลงรูปเป็น WebP ทั้งหมด ขนาดหน้าจะลดเหลือราว 1.1 MB ทำให้แบนด์วิดท์ที่ต้องใช้เหลือแค่ ~82 GB ประหยัดไปกว่าครึ่งโดยที่คุณภาพภาพแทบไม่ต่าง
เคส 3: ร้านค้าออนไลน์
ร้านขายผ้าบาติกและของฝากจากปัตตานี มีสินค้า 400 SKU แต่ละหน้าสินค้ามีรูป 6-8 รูป
- ขนาดหน้าเฉลี่ย: 3.1 MB
- Pageviews: 90,000 ต่อเดือน (คนดูหลายหน้าก่อนตัดสินใจซื้อ)
- Margin สูงกว่าปกติเพราะมีการอัปโหลดรูปสินค้าใหม่ตลอด: ใช้ 2.2
- คำนวณ: (3.1 × 90,000) ÷ 1024 × 2.2 = ~599 GB ต่อเดือน
สรุป: ระดับนี้ต้องใช้ VPS หรือ Cloud hosting แล้ว และควรต่อ CDN ตั้งแต่วันแรก เพราะ CDN จะรับภาระรูปภาพไปเกือบ 70% ทำให้ต้นทางเหลือแค่ ~180 GB
ตารางเทียบสรุป 3 เคส
| ประเภทเว็บ | ขนาดหน้าเฉลี่ย | Pageviews/เดือน | Bandwidth ที่ต้องการ | ประเภทโฮสต์ที่เหมาะ |
|---|---|---|---|---|
| เว็บบริษัท 5 หน้า | 1.2 MB | 3,000 | ~6 GB | Shared hosting ราคาถูก |
| บล็อกคอนเทนต์ | 2.4 MB | 45,000 | ~179 GB | Shared ระดับกลาง / Cloud |
| ร้านค้าออนไลน์ | 3.1 MB | 90,000 | ~599 GB | VPS / Cloud + CDN |
ความจริงเรื่อง “Unlimited Bandwidth” ของโฮสต์ไทย
เข้าเว็บโฮสต์ไทยสิบเจ้า แปดเจ้าจะเขียนว่า “Unlimited Bandwidth” หรือ “แบนด์วิดท์ไม่จำกัด” ตัวใหญ่ ๆ บนหน้าแรก คำถามคือมันจริงไหม
คำตอบสั้น ๆ คือ ไม่จริงในทางเทคนิค แต่ก็ไม่ใช่การหลอกลวงเสียทีเดียว มันคือโมเดลธุรกิจที่เรียกว่า overselling ซึ่งตั้งอยู่บนสมมติฐานว่าลูกค้าส่วนใหญ่ใช้ทรัพยากรน้อยมาก
เซิร์ฟเวอร์หนึ่งเครื่องมีสาย network จำกัดชัดเจน พูดง่าย ๆ คือ “ไม่จำกัด” เป็นไปไม่ได้ทางฟิสิกส์ สิ่งที่โฮสต์ทำจริงคือย้ายเพดานไปซ่อนไว้ที่อื่นแทน
เพดานที่ซ่อนอยู่จริง ๆ
เวลาเจอคำว่า unlimited ให้ไปอ่านสามที่นี้แทน
- Inode limit — จำนวนไฟล์สูงสุดในบัญชี ปกติ 200,000-500,000 ไฟล์ เว็บ WordPress ที่มีปลั๊กอินเยอะแตะเพดานนี้ได้ง่ายกว่าที่คิด
- CPU / Entry Process / I/O limit — ตัวจำกัดที่แท้จริง โฮสต์จะให้ CPU คุณแค่ 1-2 core และจำกัด entry process ไว้ที่ 20-40 พร้อมกัน พอคนเข้าพร้อมกันเยอะ เว็บจะขึ้น error 508 Resource Limit Reached แทนที่จะเป็นเรื่องแบนด์วิดท์
- Fair Use Policy / AUP — ข้อความประมาณว่า “หากใช้ทรัพยากรผิดปกติเมื่อเทียบกับผู้ใช้ทั่วไป ผู้ให้บริการขอสงวนสิทธิ์ในการระงับบริการ” นี่คือประโยคที่ทำให้ unlimited ไม่ unlimited จริง
วิธีอ่านแพ็กเกจโฮสต์ให้เป็น
เวลาเปรียบเทียบโฮสต์ ให้ถามคำถามเหล่านี้แทนที่จะดูแค่ตัวเลขแบนด์วิดท์
- โควตา inode เท่าไหร่
- จำกัด entry process / concurrent connection กี่ตัว
- เซิร์ฟเวอร์ตั้งอยู่ที่ไหน (ไทย / สิงคโปร์ / สหรัฐฯ) — มีผลกับ latency โดยตรง
- มี CDN ให้ในตัวไหม หรือต้องต่อเอง
- ถ้าเกินโควตาแล้วเกิดอะไรขึ้น: ตัดเว็บ, คิดเงินเพิ่ม, หรือลดความเร็ว
- backup ที่ให้มา นับรวมในโควตาพื้นที่และแบนด์วิดท์หรือเปล่า
รายละเอียดเรื่องการเลือกโฮสต์แบบเจาะลึกเราเขียนไว้แล้วใน คู่มือเลือก WordPress Hosting แนะนำให้อ่านคู่กัน
เกิดอะไรขึ้นเมื่อใช้ Bandwidth เกินโควตา
ผลลัพธ์ต่างกันไปตามนโยบายของแต่ละเจ้า และมันสำคัญมากที่คุณต้องรู้ล่วงหน้าว่าโฮสต์ของคุณใช้แบบไหน
แบบที่ 1: ปิดเว็บทันที (Hard Suspend) ผู้เข้าชมจะเห็นหน้า “509 Bandwidth Limit Exceeded” นี่คือกรณีที่แย่ที่สุด เพราะถ้าเกิดตอนกลางเดือน เว็บคุณจะหายไปจากอินเทอร์เน็ตอีกสองสัปดาห์ Googlebot ที่เข้ามาเจอ error ซ้ำ ๆ อาจถอดหน้าเว็บออกจากดัชนีชั่วคราวได้ด้วย
แบบที่ 2: คิดเงินเพิ่มอัตโนมัติ (Overage Billing) โฮสต์จะคิดค่าส่วนเกินเป็น GB ปกติราว 5-30 บาทต่อ GB แล้วแต่เจ้า ข้อดีคือเว็บไม่ล่ม ข้อเสียคือถ้าเจอ bot attack หรือมีคนดึงรูปคุณไปใช้ (hotlink) บิลอาจบานปลายได้แบบไม่รู้ตัว
แบบที่ 3: ลดความเร็ว (Throttling) เว็บยังใช้ได้ แต่ช้าลงอย่างเห็นได้ชัด ผู้ใช้ส่วนใหญ่จะกดออกก่อนโหลดเสร็จ ซึ่งกระทบทั้งยอดขายและสัญญาณ engagement ที่ Google เก็บ
สิ่งที่ควรทำก่อนจะถึงจุดนั้น
- ตั้งการแจ้งเตือนที่ cPanel หรือหลังบ้านโฮสต์เมื่อใช้ถึง 70%
- เปิด hotlink protection เพื่อไม่ให้เว็บอื่นดึงรูปคุณไปใช้แล้วกินแบนด์วิดท์คุณ
- เช็ก raw access log เดือนละครั้งว่ามี bot แปลก ๆ วิ่งหนักผิดปกติไหม
- คุมพวก crawler ที่ไม่จำเป็นผ่านไฟล์ robots.txt ตามที่อธิบายไว้ใน คู่มือ robots.txt
8 วิธีลดการใช้ Bandwidth ที่ได้ผลจริง
เรียงจากที่ให้ผลมากที่สุดลงไป ทำแค่สามข้อแรกก็มักลดได้เกินครึ่งแล้ว
1. บีบอัดและแปลงรูปเป็น WebP หรือ AVIF
นี่คือข้อที่ให้ผลมากที่สุดเสมอ เพราะรูปคือส่วนที่ใหญ่ที่สุดของเว็บเกือบทุกเว็บ
- JPEG คุณภาพ 85 → WebP ลดได้ราว 25-35%
- JPEG → AVIF ลดได้ราว 45-55%
- อย่าอัปโหลดรูปกว้าง 4000px มาแสดงในกรอบ 800px — ย่อก่อนอัปโหลดเสมอ
- ใช้
srcsetเพื่อส่งรูปเล็กให้มือถือ รูปใหญ่ให้เดสก์ท็อป
เรื่องเลือกฟอร์แมตและ trade-off เราเทียบไว้ละเอียดใน WebP vs AVIF ควรใช้อะไรดี
2. เปิด Lazy Loading
รูปที่อยู่ล่างสุดของหน้าจะยังไม่ถูกโหลดจนกว่าผู้ใช้จะเลื่อนลงไปถึง ถ้าคนส่วนใหญ่ดูแค่ครึ่งหน้าบนแล้วออก คุณประหยัดแบนด์วิดท์ไปครึ่งหนึ่งทันที ใน HTML สมัยใหม่ใส่แค่ loading="lazy" ที่แท็ก img ก็พอ แต่อย่าใส่ให้รูปหลักบนสุดของหน้า เพราะจะทำให้ค่า LCP แย่ลง
3. ใช้ CDN
CDN จะกระจายไฟล์ static ของคุณ (รูป, CSS, JS) ไปเก็บไว้ตามเซิร์ฟเวอร์ทั่วโลก คนที่อยู่ภูเก็ตจะดึงรูปจากโหนดในสิงคโปร์แทนที่จะวิ่งข้ามทวีป ได้สองต่อคือ latency ลดลง และแบนด์วิดท์จากเซิร์ฟเวอร์ต้นทางลดลง 60-80% Cloudflare มีแพ็กเกจฟรีที่เพียงพอสำหรับ SME ส่วนใหญ่ ดูวิธีตั้งค่าได้ใน คู่มือ Cloudflare ฉบับสมบูรณ์
4. ตั้งค่า Browser Caching ให้ถูก
กำหนด Cache-Control header ให้ไฟล์ static มีอายุยาว ๆ (เช่น 1 ปี) พร้อมใส่ hash ในชื่อไฟล์เวลาอัปเดต ผลคือคนที่กลับมาเข้าเว็บครั้งที่สองแทบไม่ดาวน์โหลดอะไรใหม่เลย
5. บีบอัดด้วย Gzip หรือ Brotli
ไฟล์ HTML, CSS, JS เป็นข้อความล้วน บีบอัดได้ 70-80% Brotli ให้ผลดีกว่า Gzip อีกราว 15-20% โฮสต์สมัยใหม่เปิดให้อยู่แล้ว แต่ควรเช็กให้แน่ใจ
6. เลิกโฮสต์วิดีโอเอง
วิดีโอ 3 นาทีความละเอียด 1080p มีขนาดราว 100-150 MB ถ้ามีคนดู 500 คนก็กิน 50-75 GB จบเลย ให้อัปขึ้น YouTube หรือ Vimeo แล้ว embed มาแทน ประหยัดแบนด์วิดท์ 100% และได้ระบบ adaptive streaming ฟรี
7. ลดจำนวนปลั๊กอินและสคริปต์ที่ไม่จำเป็น
ปลั๊กอิน WordPress แต่ละตัวมักโหลด CSS และ JS ของตัวเองทุกหน้า แม้หน้านั้นจะไม่ได้ใช้ฟีเจอร์นั้นเลย ลองปิดปลั๊กอินที่ไม่ได้ใช้จริงแล้ววัดขนาดหน้าใหม่ เราเคยลดขนาดหน้าแรกลูกค้าจาก 4.8 MB เหลือ 1.9 MB แค่ด้วยการถอดปลั๊กอิน 11 ตัวที่ไม่มีใครใช้
8. พิจารณาเปลี่ยนไปใช้ Static Site
ถ้าเว็บคุณเป็นเว็บบริษัทหรือบล็อกที่เนื้อหาไม่ได้เปลี่ยนทุกนาที การใช้ static site generator อย่าง Astro จะส่งไฟล์ HTML สำเร็จรูปโดยไม่ต้องประมวลผล PHP หรือคิวรีฐานข้อมูลเลย ขนาดหน้าเล็กลง เร็วขึ้น และโฮสต์ได้ฟรีบนแพลตฟอร์มอย่าง Cloudflare Pages ดูรายละเอียดใน ทำไมเราเลือก Astro สำหรับงาน SEO
Bandwidth กับ Core Web Vitals และ SEO
Google ไม่ได้ใช้ “ปริมาณแบนด์วิดท์ที่คุณใช้ต่อเดือน” เป็นปัจจัยจัดอันดับโดยตรง แต่ทุกอย่างที่ทำให้แบนด์วิดท์คุณบานปลาย ล้วนกระทบตัวชี้วัดที่ Google ใช้จริงทั้งสิ้น
ความเชื่อมโยงที่ชัดเจนที่สุด:
- LCP (Largest Contentful Paint) — องค์ประกอบที่ใหญ่ที่สุดบนหน้าจอมักเป็นรูป hero ยิ่งไฟล์ใหญ่ยิ่งโหลดนาน ยิ่ง LCP แย่ การบีบรูปจึงแก้ทั้งสองปัญหาพร้อมกัน อ่านเทคนิคเจาะลึกได้ที่ คู่มือ optimize LCP
- CLS (Cumulative Layout Shift) — รูปที่โหลดช้าและไม่ได้กำหนด width/height จะทำให้เลย์เอาต์กระตุก
- INP (Interaction to Next Paint) — JavaScript ก้อนใหญ่กินทั้งแบนด์วิดท์และเวลาประมวลผลบนมือถือราคาประหยัด
- Crawl budget — ถ้าเซิร์ฟเวอร์ตอบช้าเพราะรับภาระหนัก Googlebot จะลดความถี่การเก็บข้อมูล ทำให้เนื้อหาใหม่เข้าดัชนีช้าลง
พูดอีกแบบคือ การจัดการแบนด์วิดท์ให้ดี = การทำ Core Web Vitals ให้ผ่านโดยอัตโนมัติ มันคืองานเดียวกันที่ให้ผลตอบแทนสองทาง ทั้งค่าโฮสต์ที่ถูกลงและอันดับที่ดีขึ้น
ข้อผิดพลาดที่พบบ่อยที่สุด
จากการตรวจเว็บลูกค้ามาหลายร้อยเว็บ นี่คือความผิดพลาดที่เจอซ้ำ ๆ
- อัปโหลดรูปจากมือถือหรือกล้องตรง ๆ ไฟล์ 5-8 MB ต่อรูป นี่คือสาเหตุอันดับหนึ่งของทุกปัญหา
- ซื้อแพ็กเกจแพงเกินความจำเป็น เพราะกลัวเว็บล่ม ทั้งที่คำนวณแล้วใช้จริงแค่ 5% ของโควตา
- เชื่อคำว่า unlimited แล้วไม่เคยดูตัวเลขจริง พอเจอ 508 error ก็งงว่าทำไม ทั้งที่บอกว่าไม่จำกัด
- ไม่เปิด hotlink protection ปล่อยให้เว็บอื่นดึงรูปไปใช้ฟรี ๆ โดยคุณจ่ายค่าแบนด์วิดท์แทน
- โฮสต์วิดีโอเอง เพราะคิดว่าดูโปรกว่า embed จาก YouTube
- ลืมนับ bot ปี 2026 crawler เยอะกว่าเดิมมาก ควรเผื่อไว้ในการคำนวณเสมอ
- วัดขนาดหน้าเว็บทั้งที่ browser ยังมีแคช ทำให้ได้ตัวเลขต่ำกว่าความจริงมาก ต้องกด hard reload หรือใช้ incognito
เครื่องมือที่ควรมีติดตัว
- Chrome DevTools (แท็บ Network) — ฟรี แม่นที่สุดสำหรับวัดขนาดหน้าเว็บจริง
- PageSpeed Insights — บอกทั้งขนาด payload และคำแนะนำการลดขนาด
- cPanel Bandwidth / Awstats — ดูการใช้งานจริงย้อนหลังรายเดือน
- Google Analytics 4 — เอาตัวเลข pageviews มาเข้าสูตร
- Squoosh หรือ ImageOptim — ย่อและแปลงรูปก่อนอัปโหลด
- Cloudflare Analytics — บอกว่า CDN ช่วยประหยัดจากต้นทางไปได้เท่าไหร่
ที่ Southern Whale เราไม่ได้แค่บอกลูกค้าว่าต้องซื้อโฮสต์แพ็กเกจไหน แต่เราลงมือวัดขนาดหน้าเว็บจริง คำนวณแบนด์วิดท์ที่ต้องใช้จริง แล้วออกแบบเว็บให้เบาตั้งแต่ต้นเพื่อไม่ให้คุณต้องจ่ายค่าโฮสต์แพงโดยไม่จำเป็น ถ้าคุณกำลังจะทำเว็บใหม่ หรือเว็บเดิมเริ่มมีปัญหาโหลดช้าและชนโควตาบ่อย ๆ ลองคุยกับเราได้ที่ บริการพัฒนาเว็บไซต์ เรายินดีช่วยประเมินให้ก่อนโดยไม่มีค่าใช้จ่าย
คำถามที่พบบ่อย
Bandwidth กับ Data Transfer ต่างกันไหม ในทางเทคนิคต่างกัน bandwidth คือความจุต่อวินาที ส่วน data transfer คือปริมาณสะสมต่อเดือน แต่ในวงการโฮสติ้งใช้แทนกันจนเป็นมาตรฐานแล้ว เวลาอ่านแพ็กเกจให้เข้าใจว่าหมายถึงโควตาต่อเดือน
เพิ่ม Bandwidth แล้วเว็บจะเร็วขึ้นไหม ไม่เสมอไป ถ้าปัญหาคือ latency หรือขนาดไฟล์ใหญ่ การเพิ่มโควตาไม่ช่วยเลย ให้วัดก่อนว่าปัญหาอยู่ตรงไหนด้วย PageSpeed Insights แล้วค่อยแก้ให้ตรงจุด
เว็บเล็ก ๆ ควรซื้อแบนด์วิดท์เท่าไหร่ เว็บบริษัท 5-10 หน้าที่มีคนเข้าไม่เกิน 5,000 pageviews ต่อเดือน ใช้ 10-20 GB ก็พอแล้ว ไม่ต้องซื้อแพ็กเกจ 500 GB
CDN ช่วยลดค่าโฮสต์ได้จริงไหม จริง เพราะไฟล์ static ส่วนใหญ่จะถูกเสิร์ฟจาก CDN แทนเซิร์ฟเวอร์คุณ โดยทั่วไปลดแบนด์วิดท์ต้นทางได้ 60-80% และ Cloudflare แผนฟรีก็ใช้ได้จริงสำหรับ SME
ทำไมแบนด์วิดท์พุ่งขึ้นทั้งที่คนเข้าเท่าเดิม สาเหตุที่พบบ่อยคือ bot ที่วิ่งหนักผิดปกติ, มีคน hotlink รูปคุณ, ระบบ backup อัตโนมัติที่ดึงไฟล์ออกนอกเซิร์ฟเวอร์ หรือมีการอัปโหลดไฟล์ขนาดใหญ่เข้าไปในหน้าใดหน้าหนึ่งโดยไม่ตั้งใจ ให้เริ่มจากดู raw access log
สรุป
Bandwidth คือ ปริมาณข้อมูลที่เว็บของคุณส่งออกไปให้ผู้เข้าชม ไม่ใช่ความเร็ว ไม่ใช่ latency และไม่ใช่สิ่งที่แก้ได้ด้วยการจ่ายเงินเพิ่มเสมอไป
สิ่งที่ควรทำต่อจากนี้มีแค่สามข้อ
- วัด ขนาดหน้าเว็บจริงด้วย DevTools และดึง pageviews จาก GA4
- คำนวณ ด้วยสูตร (ขนาดหน้า × pageviews) ÷ 1024 × 1.7 แล้วเทียบกับโควตาที่มี
- ลด เริ่มจากรูปภาพก่อนเสมอ ตามด้วย lazy load และ CDN
เว็บที่เบาไม่ได้แค่ประหยัดค่าโฮสต์ แต่ยังโหลดเร็วกว่า ผ่าน Core Web Vitals ง่ายกว่า และเปลี่ยนผู้เข้าชมเป็นลูกค้าได้มากกว่า มันคือการลงทุนที่ให้ผลตอบแทนหลายทางพร้อมกัน และเป็นงานที่ทำครั้งเดียวแล้วได้ผลยาว