เสิร์ฟ Static Files และตั้ง Cache ด้วย Nginx ให้เว็บโหลดเร็วขึ้น

ภาพรวม

เว็บที่โหลดรูป ไฟล์ CSS และ JavaScript เร็วขึ้นได้มาก

ไม่ใช่เพราะไฟล์เล็กลงอย่างเดียว แต่เพราะคนเสิร์ฟไฟล์ “เหมาะกับงาน” มากกว่า ⚡

Nginx เหมาะกับการเสิร์ฟ Static File โดยตรงมากกว่าโยนให้ backend app ทำทุกอย่างเอง 🚀

เหตุผลสำคัญอยู่ที่สถาปัตยกรรมการทำงาน

backend หลายตัวต้องเปิด process หรือ thread มารอรับ request พอรูปเยอะ ไฟล์เยอะ request พร้อมกันมากๆ ทรัพยากรจะถูกใช้ไปกับงานง่ายๆ ที่ไม่ควรหนักขนาดนั้น 😵‍💫

แต่ Nginx ออกแบบมาให้รับ connection จำนวนมากได้ดีมาก ใช้แนว event-driven ทำให้กินหน่วยความจำน้อย และจัดการงานซ้ำๆ ได้คล่องกว่า 🧠

พูดง่ายๆ ให้ backend ไปทำ business logic ให้ Nginx ไปส่งไฟล์ แต่ละตัวทำงานที่ตัวเองถนัดที่สุด 🔧

ตัวอย่างที่เห็นผลชัดมาก

ถ้า browser ขอไฟล์เหล่านี้พร้อมกัน logo.png app.css main.js banner.webp font.woff2

ถ้าทุกไฟล์วิ่งเข้า backend ก่อน backend ต้องรับ request ตรวจ route เปิดไฟล์ อ่านไฟล์ ส่ง response ทำซ้ำหลายรอบ 📦

แม้บาง framework จะทำได้ไม่ยาก แต่ก็เสีย overhead โดยไม่จำเป็น ทั้ง CPU, RAM และเวลาตอบสนอง

ฝั่ง Nginx ทำงานแนวนี้ได้เบากว่า เพราะมันเน้น serving file โดยตรงจาก disk หรือ cache ได้มีประสิทธิภาพกว่า 💨

จุดที่หลายคนไม่ทันสังเกตคือ backend หนึ่ง request ไม่ได้แปลว่ามีแค่ “ส่งไฟล์” บางระบบยังมี middleware ติดมาด้วย เช็ก auth เขียน log แปลง header ผ่าน framework stack หลายชั้น 🪜

สุดท้ายไฟล์รูป 120KB กลายเป็น request ที่แพงเกินเหตุ

อีกเรื่องที่ Nginx เด่นมากคือการตั้ง cache header เช่น Cache-Control, ETag, Expires ทำให้ browser เก็บไฟล์ไว้และไม่ต้องโหลดใหม่ทุกครั้ง 🧩

ผลที่ได้ไม่ใช่แค่เร็วขึ้น แต่ลดจำนวน request ที่วิ่งถึงระบบจริงด้วย

ยิ่งถ้าไฟล์เป็น asset ที่เปลี่ยนชื่อแบบมี hash เช่น app.a84f2.js ยิ่งตั้ง cache ยาวๆ ได้สบาย ทั้งเร็วและประหยัดทราฟฟิก 📉

Nginx ยังทำ gzip และ brotli ได้ดีในหลายระบบ หมายถึงไฟล์ text อย่าง CSS, JS, JSON ส่งได้เล็กลงอีก โหลดไวขึ้นแบบเห็นผลจริง 📦✨

อีกมุมที่สำคัญมากคือ backend ที่ไม่ต้องเสียแรงเสิร์ฟ static file จะเหลือพลังไปตอบ API หรือประมวลผล logic สำคัญได้เต็มขึ้น

เท่ากับว่าเราไม่ได้แค่ทำหน้าเว็บเร็วขึ้น แต่ทำให้ทั้งระบบนิ่งขึ้นตอนทราฟฟิกพุ่งด้วย 📈

ถ้าเว็บมีผู้ใช้พร้อมกันเยอะๆ ความต่างจะยิ่งชัด เพราะ request ไฟล์ static มักมีจำนวนมากกว่า request API หลักหลายเท่า

หลักการง่ายมาก งานซ้ำ งานเบา งานจำนวนมาก โยนให้ตัวที่ถนัดเรื่องนี้จัดการ

ตัวอย่าง config แนวคิดที่ใช้กันบ่อย ให้ Nginx เสิร์ฟ /assets/ ส่วน /api/ ค่อย proxy ไป backend แบบนี้ backend ไม่ต้องแบกทั้งโลก 🌍

หลายทีมเริ่มจากปรับแค่นี้ ค่า response time ลดลงทันที และ server รับคนพร้อมกันได้มากขึ้นโดยไม่ต้องเพิ่มเครื่อง 💡

เรื่องที่น่าสนใจอีกอย่าง บางครั้งคนคิดว่า backend ก็อ่านไฟล์จาก disk ได้เหมือนกัน ทำไมจะช้ากว่า

คำตอบคือไม่ได้วัดแค่ “อ่านไฟล์ได้ไหม” แต่วัดทั้งเส้นทางของ request ตั้งแต่รับ connection ไปจนปิด response Nginx ลดภาระส่วนเกินระหว่างทางได้เก่งกว่า 🔍

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

สรุปแบบสั้นที่สุด Nginx เร็วกว่าในการเสิร์ฟ static file เพราะมันถูกสร้างมาเพื่อรับ request จำนวนมาก ส่งไฟล์ได้เบา ตั้ง cache ได้ดี ลด overhead จาก framework และคืนทรัพยากรให้ backend ไปทำงานที่มีมูลค่ามากกว่า ✅

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

เรื่องเล็กอย่างการย้าย static file มาไว้หลัง Nginx บางทีให้ผลลัพธ์ใหญ่กว่าการรีไรต์โค้ดทั้งก้อนอีก 🔥

แนวทางนำไปใช้

• นำแนวคิดจากโพสต์นี้ไปทดลองกับงานจริงของคุณ
• แยกเป็นขั้นตอนเล็ก ๆ แล้วทำทีละส่วน
• บันทึกผลลัพธ์และสิ่งที่เรียนรู้เพื่อต่อยอด

สรุป

แยกงานส่งรูป CSS JavaScript และฟอนต์ออกจาก backend พร้อมตั้ง Cache-Control, ETag และ compression เพื่อลด request และคืนทรัพยากรให้ business logic