การแสดงผลที่ขอบเครือข่ายคืออะไรและเหตุใดจึงสำคัญ

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

เครือข่ายส่งมอบเนื้อหา (CDN) จะแคชไฟล์คงที่ เช่น รูปภาพ, CSS และ JavaScript ไว้ที่ตำแหน่งให้บริการ (PoPs) หลายสิบแห่งทั่วโลก แล้วส่งไฟล์จากตำแหน่งที่ใกล้ที่สุด อย่างไรก็ตาม CDN แบบดั้งเดิมไม่สามารถเรียกใช้โค้ดได้ ทำได้เพียงให้บริการเนื้อหาคงที่ที่สร้างไว้ล่วงหน้าเท่านั้น

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

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

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

แอป SSR มาตรฐานที่ให้บริการจาก US-East อาจใช้เวลา 400 มิลลิวินาทีกว่าจะถึงโตเกียว (เครือข่าย 200 มิลลิวินาที + การเรนเดอร์โดยเซิร์ฟเวอร์ 200 มิลลิวินาที) เมื่อใช้การเรนเดอร์ที่ขอบเครือข่าย การเรนเดอร์จะเกิดขึ้นในสิงคโปร์ ทำให้เวลาแฝงของเครือข่ายลดเหลือ 30 มิลลิวินาที และส่ง HTML ได้ภายในเวลาไม่ถึง 100 มิลลิวินาทีโดยรวม ซึ่งทำให้เวลาที่ผู้ใช้รับรู้ว่าหน้าโหลดดีขึ้น 4 เท่า

รันไทม์ที่ขอบเครือข่ายไม่ใช่สภาพแวดล้อม Node.js แบบเต็มรูปแบบ Cloudflare Workers ไม่อนุญาตให้ใช้ส่วนติดต่อการเขียนโปรแกรมหลักของ Node.js เช่น fs, net และ crypto จำกัดเวลา CPU ไว้ที่ 50 มิลลิวินาทีต่อคำขอ (แผนแบบชำระเงินอนุญาตให้ใช้เวลาได้มากกว่านี้) จำกัดหน่วยความจำ และไม่มีสิทธิ์เข้าถึงระบบไฟล์ ข้อจำกัดเหล่านี้ทำให้ต้องออกแบบสถาปัตยกรรมอย่างรอบคอบ

มีหลายแพลตฟอร์มที่ให้บริการรันไทม์ที่ขอบเครือข่าย ได้แก่ Vercel Edge Functions (สร้างบนรูปแบบอินสแตนซ์แยกอิสระของ V8 เดียวกัน), Deno Deploy (ใช้รันไทม์ Deno ที่ขอบเครือข่าย) และ Fastly Compute (ใช้ WebAssembly) แต่ละแพลตฟอร์มมีความเข้ากันได้ของส่วนติดต่อ พื้นที่ครอบคลุมทั่วโลก และรูปแบบราคาแตกต่างกัน

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

ฟังก์ชัน Lambda (และ Cloud Run) จะสร้างคอนเทนเนอร์ ดาวน์โหลดโค้ดของคุณ เริ่มต้นรันไทม์ แล้วจึงเรียกใช้โค้ด ส่งผลให้เกิดการเริ่มทำงานแบบเย็น 100–1000 มิลลิวินาที ส่วน Workers จะนำอินสแตนซ์แยกอิสระของ V8 ที่กำลังทำงานอยู่แล้วกลับมาใช้ใหม่ ทำให้การเริ่มทำงานแบบเย็นแทบมองไม่เห็น โดยใช้เวลาน้อยกว่า 5 มิลลิวินาที

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

เหตุใด Cloudflare Workers จึงมีการเริ่มทำงานแบบเย็นเกือบเป็นศูนย์เมื่อเทียบกับ AWS Lambda

การเรนเดอร์ที่ขอบเครือข่ายจะเรียกใช้ JavaScript ที่ตำแหน่งให้บริการ CDN ทั่วโลก จึงไม่ต้องเดินทางไปกลับถึงต้นทางและช่วยลดเวลาแฝงได้อย่างมาก Cloudflare Workers โดดเด่นด้วยการเริ่มทำงานแบบเย็นระดับไมโครวินาทีที่อาศัยอินสแตนซ์แยกอิสระของ V8 ในสถานที่ต่าง ๆ มากกว่า 300 แห่งทั่วโลก ข้อแลกเปลี่ยนมีอยู่จริง ได้แก่ ไม่มีส่วนติดต่อการเขียนโปรแกรมของ Node.js และมี CPU จำกัด จึงเหมาะที่สุดกับหน้าการตลาดและเนื้อหาที่ปรับให้เหมาะกับผู้ใช้แต่ส่วนใหญ่ยังคงที่ มากกว่าหน้าที่ขับเคลื่อนด้วยฐานข้อมูลอย่างหนัก