Vercel หรือ Cloudflare Pages: ความเร็วสูสี แต่บิลโตคนละทาง

สำหรับเว็บที่ส่งไฟล์สแตติกเป็นหลัก Cloudflare Pages คุมต้นทุนเมื่อทราฟฟิกเพิ่มได้ง่ายกว่า เพราะคำขอไฟล์สแตติกไม่ถูกคิดตามจำนวนครั้ง ส่วน Vercel นับทั้งข้อมูลที่ส่งและคำขอผ่าน CDN โดย ตารางราคาของ Vercel ระบุว่า Hobby รวม Fast Data Transfer 100 GB และคำขอ CDN 1 ล้านครั้ง พร้อมโควตาการเรียกฟังก์ชัน 1 ล้านครั้งต่อเดือน

เมื่อเว็บต้องเรียกโค้ดฝั่งเซิร์ฟเวอร์ คำตอบอาจเปลี่ยนไปตามจำนวนครั้งและงานที่โค้ดทำ กติกาของ Cloudflare Pages ระบุว่าคำขอไฟล์สแตติกที่ไม่เรียก Functions ฟรีและไม่จำกัด แต่ Pages Functions ใช้โควตาร่วมกับ Workers Free ซึ่งมีเพดานรวม 100,000 คำขอต่อวัน ผลวัดความเร็วที่มีอยู่แสดงเพียงว่าเว็บไซต์บางเป้าหมายตอบสนองใกล้กันจากจุดทดสอบหนึ่งแห่ง จึงยังใช้เลือกผู้ชนะสำหรับผู้ใช้ในไทยไม่ได้

หนึ่งครั้งที่เปิดหน้าเว็บ กลายเป็นต้นทุนอย่างไร

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

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

ฝั่ง Cloudflare Pages ต้องแยกเส้นทางที่ส่งไฟล์สแตติกออกจากเส้นทางที่เรียก Functions ให้ชัด การมีไฟล์ JavaScript ในหน้าเว็บไม่ได้ทำให้ทุกคำขอเป็นคำขอฟังก์ชัน แต่การกำหนดให้ Function รับคำขอของทุกหน้าจะเปลี่ยนยอดที่ใช้โควตาทันที เว็บสองแห่งที่แสดงผลเหมือนกันจึงอาจมีต้นทุนคนละแบบเพียงเพราะกำหนดเส้นทางการทำงานต่างกัน

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

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

ฟังก์ชันเพิ่มตัวนับอีกชุด

Cloudflare คิด Pages Functions ตามกติกา Workers ซึ่งนับคำขอและเวลา CPU แยกกัน ตารางราคา Workers ระบุว่าแผนฟรีให้เวลา CPU สูงสุด 10 มิลลิวินาทีต่อการเรียก ส่วน Workers Paid มีค่าขั้นต่ำ 5 ดอลลาร์สหรัฐต่อเดือน รวม 10 ล้านคำขอและเวลา CPU 30 ล้านมิลลิวินาทีต่อเดือน ก่อนคิดส่วนเกินตามแต่ละรายการ แผนนี้ไม่มีค่าถ่ายโอนข้อมูลออกเพิ่มเติมสำหรับ Workers

โควตารายวันของ Workers Free เป็นยอดร่วมของบัญชี ไม่ใช่โควตาใหม่สำหรับแต่ละโครงการ หากบัญชีเดียวกันมี Worker ที่รับคำขออยู่แล้ว Pages Functions จะใช้พื้นที่ที่เหลือจากเพดานเดียวกัน อีกทั้งเพดานรีเซ็ตตามเวลา UTC ไม่ใช่เมื่อครบยี่สิบสี่ชั่วโมงนับจากช่วงที่เว็บเริ่มมีผู้ชมมาก สำหรับเว็บในไทย การดูเฉพาะยอดเฉลี่ยรายเดือนจึงอาจซ่อนวันที่คำขอหนาแน่นผิดปกติ

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

Vercel มีตัวนับสำหรับฟังก์ชันมากกว่าจำนวนครั้งที่เรียกด้วย ทั้ง Active CPU หน่วยความจำที่จัดสรร และข้อมูลระหว่าง CDN กับฟังก์ชันมีผลต่อการใช้งาน การรอ I/O อาจหยุดการนับ Active CPU แต่หน่วยความจำของอินสแตนซ์ยังถูกจัดสรรอยู่ ความต่างนี้ทำให้ค่าเฉลี่ยเวลาเรียก API เพียงค่าเดียวบอกต้นทุนไม่ได้ การแยก ต้นทุนของ Workers และ Functions ตามลักษณะงานช่วยอธิบายกรณีที่จำนวนคำขอใกล้กันแต่ค่าใช้จ่ายต่างกัน

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

ผล TTFB ที่ดูใกล้กัน มีขอบเขตแค่ไหน

การวัดของ StackVerified เมื่อ 29 สิงหาคม 2026 ส่งคำขอ HTTPS ต่อเนื่อง 8 ครั้งต่อเป้าหมายจากอินเทอร์เน็ตบ้านในสหรัฐฯ หนึ่งจุด ทุกคำขอที่นำมารายงานเป็น cache HIT ค่ามัธยฐาน TTFB ของ vercel.com และ nextjs.org อยู่ที่ 108 และ 110 มิลลิวินาที ส่วน developers.cloudflare.com และ pages.cloudflare.com อยู่ที่ 111 และ 205 มิลลิวินาทีตามลำดับ

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

TTFB วัดช่วงตั้งแต่เริ่มคำขอจนได้รับไบต์แรก จึงสะท้อนทั้งเส้นทางเครือข่าย การเชื่อมต่อ สถานะแคช และการทำงานก่อนตอบกลับ การได้ cache HIT บอกว่าตัวอย่างนั้นไม่ได้วัดเวลาสร้างหน้าใหม่ด้วยฟังก์ชัน หากเว็บจริงต้องสร้าง HTML ตามผู้ใช้หรืออ่านฐานข้อมูล ผลวัดไฟล์ที่อยู่ในแคชจะตอบคำถามเรื่องความหน่วงของเส้นทางนั้นไม่ได้

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

เครื่องคำนวณสามสถานการณ์

แบบจำลองอย่างง่ายเริ่มจากสามผลคูณ: จำนวนการเปิดหน้า × คำขอเครือข่ายต่อหน้า, จำนวนการเปิดหน้า × ข้อมูลที่ส่งต่อหน้า และจำนวนการเปิดหน้า × สัดส่วนที่เรียกฟังก์ชัน × จำนวนครั้งที่เรียกต่อหน้า จากนั้นแยกยอดรายวันออกจากยอดรายเดือน เพราะ Pages Functions บนแผนฟรีมีเพดานรายวัน ส่วนตัวนับหลักของ Vercel ใช้โควตาตามรอบบัญชี ตัวอย่างต่อไปเป็นสมมติฐานเพื่อหาจุดที่คำตอบเปลี่ยน ไม่ใช่ราคาที่เสนอให้โครงการใด

เว็บสแตติกที่มีผู้ชมสม่ำเสมอ

สมมติว่าเว็บมีการเปิดหน้า 400,000 ครั้งต่อเดือน แต่ละครั้งสร้างคำขอเครือข่ายเฉลี่ย 4 รายการและส่งข้อมูลรวม 300 KB หลังบีบอัด ผลคือประมาณ 1.6 ล้านคำขอและข้อมูล 120 GB ต่อเดือน ตัวเลขทั้งสองเกินปริมาณที่รวมใน Vercel Hobby ตามสมมติฐานนี้ หากทุกคำขอบน Pages ส่งไฟล์สแตติกโดยไม่เรียก Functions ก็ไม่มีค่าคำขอไฟล์สแตติกตามยอดดังกล่าว

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

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

เว็บที่เรียกฟังก์ชันบางหน้า

สมมติว่ามีการเปิดหน้า 40,000 ครั้งต่อวัน และ 10% ของการเปิดหน้าเรียกฟังก์ชันหนึ่งครั้ง จะเกิด 4,000 คำขอฟังก์ชันต่อวัน หรือราว 120,000 ครั้งในเดือนสมมติที่มี 30 วัน หากใช้ CPU เฉลี่ย 5 มิลลิวินาทีต่อครั้ง ยอด CPU จะอยู่ราว 600,000 มิลลิวินาทีต่อเดือน ภายใต้สมมติฐานว่าไม่มี Workers อื่นใช้โควตาร่วม ยอดคำขอรายวันยังต่ำกว่าเพดาน Workers Free

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

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

วันที่ทราฟฟิกจากไทยพุ่ง

สมมติว่าเว็บได้รับการเปิดหน้า 600,000 ครั้งในวันเดียว และส่งข้อมูลเฉลี่ย 250 KB ต่อครั้ง จะมีข้อมูลส่งออกประมาณ 150 GB ในวันนั้น หากข้อมูลทั้งหมดผ่าน Vercel ตัวเลขนี้สูงกว่าโควตา Fast Data Transfer ของ Hobby แม้วันอื่นของเดือนจะเงียบมาก สำหรับ Pages ที่ตอบเป็นไฟล์สแตติกทั้งหมด จำนวนคำขอไฟล์ที่เพิ่มขึ้นไม่เปลี่ยนค่าคำขอไฟล์สแตติก

การเพิ่มฟังก์ชันเพียงบางส่วนทำให้ภาพเปลี่ยน หาก 5% ของการเปิดหน้าเรียกฟังก์ชันหนึ่งครั้ง จะได้ 30,000 คำขอในวันพุ่งสูง ซึ่งยังอยู่ใต้เพดานรายวันของ Workers Free เมื่อไม่มีงานอื่นใช้โควตา แต่ถ้าสัดส่วนเพิ่มเป็น 25% จะกลายเป็น 150,000 คำขอและเกินเพดานนั้น ความต่างนี้เกิดจากเส้นทางคำขอ ไม่ได้เกิดจากจำนวนผู้ชมที่เปลี่ยนไป

สำหรับวันที่มีแคมเปญหรือข่าวทำให้ยอดเข้าชมกระจุกตัว ยอดเฉลี่ยรายเดือนจึงใช้แทนยอดสูงสุดรายวันไม่ได้ ฝั่ง Vercel ต้องดูว่าการใช้ข้อมูลและคำขอจะไปถึงเพดานหรือทำให้เกิดค่าใช้จ่ายเพิ่ม ส่วนฝั่ง Pages ต้องดูจำนวนคำขอที่เรียก Functions ภายในวันเดียวกัน การคาดว่าทราฟฟิกจะโตมากจึงยังไม่พอ ต้องรู้ว่าทราฟฟิกนั้นขอไฟล์หรือเรียกโค้ด

วัดจากไทยด้วยงานที่เว็บทำจริง

การทดสอบความเร็วที่ตอบโจทย์ควรใช้แอปและไฟล์ชุดเดียวกันบนทั้งสองแพลตฟอร์ม กำหนดขนาดคำตอบและเงื่อนไขแคชให้เทียบกันได้ แล้วส่งคำขอจากเครือข่ายที่ใกล้กับผู้ใช้เป้าหมายในไทย แยกผล HTML กับไฟล์สแตติกออกจาก API และแยก cache HIT ออกจาก cache MISS การปะปนผลเหล่านี้ทำให้ค่ากลางดูดีหรือแย่เพราะชนิดงานมากกว่าตัวบริการ

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

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

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

คำตอบขึ้นอยู่กับรูปแบบเว็บ

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

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

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

อ่านเพิ่มเติม:

• Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว
• AWS Lambda หรือ Cloudflare Workers: งานรอ I/O คิดเงินคนละนาฬิกา
• Cloudflare R2 หรือ Amazon S3: egress ฟรีแลกกับอัปโหลดที่ช้ากว่า