เว็บล่มวันโปรโมชั่นใหญ่ เพราะ hosting ไม่พอ: อ่านใบเสนอราคาโฮสติ้งยังไงก่อนเซ็น

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

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

ทดสอบเว็บตัวเองตอนนี้เลย ใช้เวลาไม่ถึง 3 นาที

ก่อนจะพูดเรื่องเทคนิค ลองเปิดเว็บ pagespeed.web.dev แล้ววางลิงก์เว็บไซต์ตัวเองดูครับ เครื่องมือนี้ของ Google ให้ผลสองชุดที่คนส่วนใหญ่ไม่ทันสังเกตว่าต่างกัน ชุดแรกคือคะแนนห้องแล็บ ซึ่งเป็นการจำลองโหลดเว็บครั้งเดียวในสภาพแวดล้อมควบคุม กับอีกชุดคือข้อมูลประสบการณ์จริงของผู้ใช้ ซึ่งเก็บมาจากคนที่เคยเข้าเว็บนั้นจริงในช่วง 28 วันที่ผ่านมา สองชุดนี้ไม่จำเป็นต้องตรงกัน และโฮสติ้งเป็นส่วนหนึ่งของสาเหตุที่ทำให้ต่างกัน แม้จะไม่ใช่สาเหตุเดียวก็ตาม

บทความนี้จะไม่พูดซ้ำเรื่องพื้นฐานที่เราเคยเขียนไว้แล้วนะครับ ถ้ายังไม่รู้ว่า hosting คืออะไร shared กับ cloud ต่างกันตรงไหน อ่านได้ในบทความ เลือก Web Hosting อย่างไรให้เว็บไซต์ธุรกิจโหลดไวและติดอันดับ SEO ส่วนเรื่องโดเมนที่มักถูกเข้าใจปนกับ hosting อ่านแยกได้ในบทความ Domain Name คืออะไร ที่นี่ผมจะพาดูเฉพาะเรื่องที่ยังไม่มีใครเขียนถึง คือมันพังตอนไหน และควรถามอะไรก่อนเซ็นสัญญา

สิ่งที่พังจริงเวลาโฮสติ้งไม่พอ

แบบที่หนึ่ง เว็บล่มไปเลย

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

แบบที่สอง ไม่ล่มแต่ช้าจนลูกค้าปิดหนี

แบบนี้อันตรายกว่าที่คิดครับ เพราะเจ้าของเว็บจะไม่เห็น error อะไรเลย เว็บยังเปิดได้ปกติ แค่โหลดช้าลงกว่าเดิมมากในช่วงที่คนเข้าเยอะ ลูกค้าที่กดเข้ามาจากโฆษณาหรือจากโพสต์ที่แชร์กันมา ถ้ารอนานเกินไปก็ปิดหน้าจอไปเงียบๆ โดยเจ้าของเว็บไม่มีทางรู้เลยว่าเสียลูกค้าไปกี่คนในวันนั้น เพราะไม่มี error ให้เห็น มีแค่ยอดขายที่น้อยกว่าที่ควรจะเป็น

ตัวอย่างที่ผมอยากเล่าตรงๆ คือเว็บของเราเอง TumWebSME ที่ผ่านมาเราทุ่มปรับปรุงประสิทธิภาพเว็บอย่างหนัก จนคะแนนห้องแล็บ (Lighthouse) บนมือถือของหน้าแรก หน้า /system หน้า /package และหน้า /blog ขยับจาก 51, 52, 62, 66 คะแนน ขึ้นไปอยู่ที่ 88, 88, 95, 95 คะแนนตามลำดับ แต่พอเช็กข้อมูลประสบการณ์จริงของผู้ใช้ในวันเดียวกันคือ 16 กันยายน 2569 กลับพบว่า LCP ยังอยู่ที่ 3,780 มิลลิวินาที ขณะที่เกณฑ์ "ดี" ที่ Google กำหนดไว้ใน web.dev/articles/lcp อยู่ที่ไม่เกิน 2,500 มิลลิวินาที ส่วน INP อยู่ที่ 534 มิลลิวินาที เทียบกับเกณฑ์ดีที่ web.dev/articles/inp กำหนดไว้ไม่เกิน 200 มิลลิวินาที มีแค่ CLS ตัวเดียวที่ผ่านเป๊ะที่ 0.00 ผมเล่าแบบนี้ไม่ใช่เพื่อทำให้ตัวเองดูแย่ แต่อยากให้เห็นว่าคะแนนห้องแล็บที่สวยกับตัวเลขที่ลูกค้าจริงเจอ เป็นคนละเรื่องกันได้ขนาดนี้ แม้จะเป็นเว็บที่มีคนดูแลอยู่ทุกสัปดาห์ก็ตาม

ทำไมราคาโฮสติ้งหรือ VPS เทียบกันตรงๆ ไม่ได้

ลองดูตัวเลขจริงที่ผมไปเช็กมาวันนี้ วันที่ 16 กันยายน 2569 ครับ ผู้ให้บริการโฮสติ้งไทยรายหนึ่งชื่อ ThaiDNS ตั้งราคาแพ็กเกจ Shared Hosting เริ่มต้น พื้นที่ 2GB เซิร์ฟเวอร์ฝั่งเอเชีย ไว้ที่ 500 บาทต่อปี ส่วนแพ็กเกจ VPS ของผู้ให้บริการเดียวกันเริ่มต้นที่ 250 บาทต่อเดือน หรือราว 3,000 บาทต่อปี ต่างกัน 6 เท่าทั้งที่เป็นผู้ให้บริการรายเดียวกัน ตามหน้าราคาที่ thaidns.co.th/pricing.html และหน้าแพ็กเกจ hosting ของผู้ให้บริการรายนี้ระบุไว้ว่าราคาที่แสดงทั้งหมดยังไม่รวมภาษีมูลค่าเพิ่ม 7%

ทีนี้ลองไปดู DigitalOcean ผู้ให้บริการ cloud compute ระดับโลกครับ Droplet ซึ่งเป็นชื่อเรียก VPS ของเขา รุ่นเล็กที่สุดเริ่มต้นแค่ 4 ดอลลาร์สหรัฐต่อเดือน ตามหน้าราคา digitalocean.com/pricing/droplets คำนวณคร่าวๆ ที่ประมาณ 35 บาทต่อดอลลาร์เพื่อให้เห็นภาพเท่านั้น ไม่ใช่อัตราแลกเปลี่ยนจริงหรือราคาที่รวมค่าธรรมเนียมบัตร จะอยู่ราว 140 บาทต่อเดือน ต่ำกว่าราคาเริ่มต้นของ VPS ThaiDNS ที่ 250 บาทต่อเดือน (ยังไม่รวม VAT 7%) แต่สองตัวเลขนี้คิดฐานภาษีคนละแบบ จึงเทียบได้แค่คร่าวๆ และไม่ได้แปลว่า DigitalOcean ถูกกว่าหรือแย่กว่า ThaiDNS ครับ มันคือคนละของกัน Droplet ราคา 4 ดอลลาร์ให้แค่เครื่องเซิร์ฟเวอร์เปล่า ไม่มีทีมงานคนไทยคอยดูแล ไม่มีระบบ backup อัตโนมัติมาให้ในราคานั้น ถ้าเซิร์ฟเวอร์มีปัญหาตอนตีสองต้องแก้เองหรือจ้างคนที่รู้เรื่องเซิร์ฟเวอร์มาดูแลให้ ขณะที่ราคา VPS ของผู้ให้บริการไทยมักรวมทีมซัพพอร์ตและการดูแลเบื้องต้นเข้าไปแล้ว

ราคาที่ต่างกันขนาดนี้ไม่ได้มาจากใครโกงใครครับ แค่เป็นสินค้าคนละแบบที่บังเอิญเรียกชื่อคล้ายกัน ใบเสนอราคาสองใบที่เขียนคำว่า hosting หรือ VPS เหมือนกัน จึงอาจต่างราคากันหลายเท่าโดยไม่มีใครผิดเลย ตัวเลขบนหน้าใบเสนอราคาไม่เคยบอกว่าข้างในมีอะไรบ้าง ต้องถามเอง

อ่านใบเสนอราคายังไงก่อนเซ็น

คำถามที่ผมแนะนำให้ถามทุกครั้งก่อนตัดสินใจ ไม่ว่าจะเป็นโฮสติ้งเจ้าไหนหรือจ้างทีมทำเว็บที่ไหนก็ตาม รวมถึงเราด้วย:

• Uptime ที่รับปากมา เป็นตัวเลขเขียนไว้เป็นลายลักษณ์อักษรไหม หรือเป็นแค่คำพูดว่า "เสถียรแน่นอนครับ"

• ถ้าเว็บล่มจริง มีการชดเชยยังไง เขียนไว้ในสัญญาหรือเปล่า

• Backup ทำถี่แค่ไหน เก็บย้อนหลังกี่วัน และกู้คืนเองได้ทันทีไหมหรือต้องรอทีมงาน

• ทีมซัพพอร์ตติดต่อได้ถึงกี่โมง ถ้าเว็บล่มตอนตีสองจะมีใครรับสาย

• ราคาปีแรกกับราคาต่ออายุปีถัดไปเท่ากันไหม

ข้อสุดท้ายสำคัญกว่าที่คิดครับ เพราะราคาที่ใช้ดึงดูดให้สมัคร มักเป็นราคาปีแรกเท่านั้น

ส่วนตัวเลข uptime เองก็มีความหมายที่คนขายไม่ค่อยอธิบายให้ฟังตรงๆ ลองคำนวณง่ายๆ ดูครับ ใน 1 เดือนมีประมาณ 43,200 นาที ถ้ารับปาก uptime 99% แปลว่ายอมให้เว็บล่มได้ราว 7 ชั่วโมงเศษต่อเดือน ถ้ารับปาก 99.9% เหลือแค่ราว 43 นาทีต่อเดือน และถ้ารับปาก 99.99% เหลือแค่ราว 4 นาทีต่อเดือนเท่านั้น ทศนิยมที่เพิ่มมาทีละหลักของตัวเลขนี้จึงมีความหมายมากกว่าที่คิด

เว็บที่ไม่เคยล่ม กับเว็บที่ผ่านการทดสอบวันหนักสุดแล้ว เป็นคนละเรื่องกัน

ผมเข้าใจนะครับ ถ้าเว็บที่ใช้อยู่ตอนนี้ไม่เคยล่มเลยมาหลายปี ก็คงรู้สึกว่าโฮสติ้งที่ใช้อยู่ดีพออยู่แล้ว ผมไม่เถียงเลยครับ มันอาจจะดีจริงก็ได้ แต่เหมือนเบรกเกอร์ในร้านเพื่อนผมที่เล่าไปตอนต้น "ไม่เคยตัด" กับ "รับน้ำหนักได้ทุกสถานการณ์" เป็นคนละเรื่องกัน ถ้าเว็บไม่เคยเจอวันที่คนเข้าพร้อมกันเยอะขนาดนั้น ก็ยังไม่รู้จริงว่าจะรับไหวหรือไม่ อย่างที่เล่าไปข้างต้นว่าเว็บของเราเองก็ยังมีตัวเลขที่ไม่ผ่านเกณฑ์ของ Google อยู่ แม้จะปรับปรุงมาต่อเนื่อง นี่คือเหตุผลที่การเช็กข้อมูลจริงเป็นระยะสำคัญกว่าการเชื่อว่าไม่เคยมีปัญหาแปลว่าปลอดภัยแล้ว

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

สิ่งที่ควรมีอย่างน้อย ไม่ต้องถึงระดับองค์กรใหญ่

ธุรกิจ SME ไม่จำเป็นต้องมีโครงสร้างระดับที่รองรับคนเข้าพร้อมกันเป็นแสนแบบองค์กรใหญ่ครับ มีสามอย่างนี้ก็เพียงพอสำหรับกรณีส่วนใหญ่ โครงสร้างที่ขยายกำลังได้เองเมื่อทราฟฟิกพุ่ง โดยไม่ต้องมีใครนั่งเฝ้าคอยเพิ่มทรัพยากรเอง ระบบ backup อัตโนมัติที่ระบุรอบเวลาและระยะเก็บย้อนหลังไว้เป็นลายลักษณ์อักษร และช่องทางติดต่อจริงเวลาเกิดปัญหาที่เคยทดสอบแล้วว่าใช้งานได้จริง ไม่ใช่แค่เบอร์ในสัญญาที่ไม่เคยโทรไปสักครั้ง การลงทุนกับโครงสร้างที่ดีตั้งแต่ต้น เป็นส่วนหนึ่งของภาพรวมต้นทุนการมีเว็บเป็นของตัวเอง ที่เราเคยคำนวณจุดคุ้มทุนเทียบกับค่าธรรมเนียมแพลตฟอร์มไว้ใน บทความจุดคุ้มทุนของการมีเว็บเป็นของตัวเอง

แพ็กเกจของเราเองเริ่มต้นที่ 79,000 บาท จ่ายครั้งเดียว ใช้ custom code วางอยู่บนโครงสร้าง cloud ที่ขยายกำลังได้เอง ถ้าอยากดูรายละเอียดว่าแต่ละแพ็กเกจครอบคลุมเรื่องพวกนี้ยังไงบ้าง ดูได้ที่ หน้าแพ็กเกจ ของเราครับ

แผน 30 วัน เช็กโฮสติ้งของธุรกิจตัวเอง

• วันที่ 1-3: ทดสอบเว็บตัวเองที่ pagespeed.web.dev เก็บภาพหน้าจอทั้งคะแนนห้องแล็บและข้อมูลประสบการณ์จริงไว้เป็น baseline

• วันที่ 4-7: หยิบสัญญาหรือใบเสนอราคาโฮสติ้งปัจจุบันมาเช็กกับ 5 คำถามด้านบน อะไรที่ไม่มีคำตอบชัดเจน ส่งอีเมลถามผู้ให้บริการตรงๆ

• วันที่ 8-14: ถ้ามีแผนจัดโปรโมชั่นหรือลงโฆษณาชุดใหญ่เร็วๆ นี้ แจ้งทีมที่ดูแลเว็บหรือโฮสติ้งล่วงหน้า และเฝ้าดูว่าเว็บตอบสนองยังไงในวันจริง

• วันที่ 15-21: ถ้า backup ไม่ใช่ระบบอัตโนมัติที่เขียนไว้ชัดเจน ให้ export ข้อมูลเว็บหรือเนื้อหาสำคัญเก็บไว้เองอีกชุดหนึ่ง

• วันที่ 22-30: ทดสอบเว็บซ้ำอีกครั้งที่ pagespeed.web.dev เทียบกับ baseline วันแรก

วัดผลต่อเนื่องยังไงหลังจากนี้

กลับมาเช็ก pagespeed.web.dev เดือนละครั้งก็พอครับ สิ่งที่ควรดูไม่ใช่แค่คะแนนห้องแล็บที่เพิ่มขึ้น แต่คือแนวโน้มของข้อมูลประสบการณ์จริงว่าขยับเข้าใกล้เกณฑ์ "ดี" หรือไม่ ถ้าตัวเลขค้างหรือแย่ลงทั้งที่ไม่ได้แก้อะไรฝั่งเว็บเลย นั่นอาจเป็นสัญญาณที่ควรกลับไปคุยกับผู้ให้บริการโฮสติ้ง

สายไฟหลังผนังไม่เคยทำให้ร้านขายดีขึ้น แต่วันที่มันมีปัญหา มันคือสิ่งเดียวที่ทุกคนจะจำได้

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

ช่องทางการติดตาม TumWebSME

ติดตามสาระความรู้เรื่องการทำเว็บไซต์และการตลาดออนไลน์ได้ที่:

• Facebook: TumWebSME รับทำเว็บไซต์ธุรกิจ

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

ติดต่องานและสอบถามบริการ

• 088-983-9386 (คุณพลอย)

• 099-856-3198 (คุณแสนนาน)