อัปเกรด Astro 6 → 7 บนบล็อกตัวจริง: วัดผลก่อน-หลัง แล้วมันคุ้มไหม?
เคยมั้ย? รถใช้ดีอยู่แล้ว วันดีคืนดีมีคนมาบอกว่า “เปลี่ยนเครื่องใหม่สิ แรงขึ้นเยอะ” — ใจนึงก็อยากได้ อีกใจก็กลัวเปลี่ยนแล้วพังกลางทาง 😅 การอัปเกรด framework ก็ฟีลเดียวกันเป๊ะ
บล็อกที่น้อง ๆ กำลังอ่านอยู่นี่แหละ เดิมรันบน Astro 6 มาตลอด พอ Astro 7 ออก (มิถุนายน 2026) ผมเลยถือโอกาส “เปลี่ยนเครื่อง” จริง ๆ บนของจริง แล้วจับเวลา-ชั่งน้ำหนักก่อนและหลังมาให้ดูกันแบบไม่มโน
สิ่งที่จะได้จากบทความนี้
- Astro 7 เปลี่ยนอะไรใต้ฝากระโปรงบ้าง (และทำไมมันสำคัญ)
- ขั้นตอนอัปเกรดจริงที่เราทำ — อะไรพัง อะไรรอด
- ตัวเลข ก่อน vs หลัง ของบล็อกนี้ (build time, ขนาด bundle)
- สรุปแบบตรง ๆ ว่า งานแบบไหนควรเปลี่ยน แบบไหนยังไม่ต้องรีบ
Astro 7 มีอะไรใหม่ (เล่าแบบเข้าใจง่าย)
ก่อนจะลงมือ เรามาเข้าใจ “ทำไม” กันก่อน เพราะถ้าไม่รู้ว่ามันดีขึ้นตรงไหน เราจะวัดผลผิดจุด
- Compiler เขียนใหม่ด้วย Rust — ของเดิม compiler ที่แปลงไฟล์
.astroเป็น HTML/JS เขียนด้วย Go คราวนี้ย้ายมาเป็น Rust ทั้งหมด เป้าหมายคือเร็วขึ้นและ error message อ่านง่ายขึ้น - Rolldown แทน Rollup + esbuild — ตัวรวมไฟล์ (bundler) เปลี่ยนมาใช้ Rolldown ที่เขียนด้วย Rust ตัวเดียวจบ เคลมว่าเร็วกว่า Rollup แบบ 10–30 เท่าในงานใหญ่ ๆ คิดซะว่าเปลี่ยนจากสายพานลำเลียงเก่าเป็นสายพานความเร็วสูง
- Vite 8 — เครื่องมือ dev/build เบื้องหลังขยับเมเจอร์ ได้ของใหม่ของ Vite มาเต็ม ๆ
- Markdown engine ตัวใหม่ (Sätteri) — pipeline remark/rehype แบบเดิมไม่ได้เปิดมาให้ by default แล้ว ตรงนี้คือจุดที่ต้องระวังที่สุดถ้าโปรเจกต์เราพึ่ง plugin markdown เยอะ
- Route caching + Streaming เป็น default — ควบคุม cache ราย response ด้วย
Astro.cacheได้เลย และ rendering แบบ streaming กลายเป็นค่ามาตรฐาน - โหมดช่วย AI agent —
astro devรู้ตัวว่าอยู่ในสภาพแวดล้อม AI coding แล้วรันเป็น background process ให้เอง มีastro dev stop/status/logs - Astro DB ถูกถอด — คำสั่งกลุ่ม
astro db,astro loginฯลฯ หายไป (ถ้าไม่ได้ใช้ ก็ไม่กระทบ)
สรุปคือ Astro 7 เน้น “เร็วขึ้นตอน build + DX ดีขึ้น” มากกว่าจะเปลี่ยนวิธีเขียนของเรา
อัปเกรดจริง: เราทำอะไรบ้าง
ของจริงไม่ต้องดราม่า แค่ขยับเวอร์ชัน dependency หลักให้ตรงกับ Astro 7:
# bump astro + integrations ที่ผูกกับ core
pnpm add astro@^7.0.3 @astrojs/mdx@^7.0.0 @astrojs/sitemap@^3.7.3 sharp@^0.35.2
pnpm add -D @astrojs/check@^0.9.9
# แล้วลอง build
pnpm run buildส่วนที่เปลี่ยนใน package.json มีแค่นี้:
- "astro": "^6.1.1",
+ "astro": "^7.0.3",
- "@astrojs/mdx": "^5.0.3",
+ "@astrojs/mdx": "^7.0.0",
- "@astrojs/sitemap": "3.7.2",
+ "@astrojs/sitemap": "3.7.3",
- "sharp": "^0.34.5",
+ "sharp": "^0.35.2",อะไรพัง อะไรรอด
ลุ้นที่สุดคือเรื่อง markdown engine ใหม่ เพราะบล็อกเราใช้ Shiki ไฮไลต์โค้ด (ผ่าน markdown.shikiConfig ใน astro.config.mjs) แต่ผลคือ…
- ✅ Shiki ยังทำงานปกติ — โค้ดทุกบล็อกยังมี syntax highlighting (
class="astro-code github-dark"ยังอยู่ครบ) - ✅ RSS / Sitemap ออกครบ — feed ยังมี 34 รายการ,
sitemap-index.xmlสร้างปกติ - ✅
astro checkผ่าน 0 error (เหลือแค่ hint เล็ก ๆ เรื่องis:inline) - ✅ Mermaid diagram ไม่กระทบ — ของเรา pre-render เป็น SVG ไว้แล้ว ไม่ได้ render ฝั่ง client ตอน build เลยไม่มีอะไรให้พัง
มีจุดเดียวที่ต้องจำให้ขึ้นใจ:
Astro 7 ต้องการ Node 18.17 ขึ้นไป ถ้าเครื่อง/เซิร์ฟเวอร์ยังเป็น Node เก่า (เช่น 16) จะ build/preview ไม่ผ่าน — แต่ถ้า deploy เป็น static (build ที่เครื่องเรา แล้วส่ง
dist/ขึ้น nginx) เซิร์ฟเวอร์ปลายทางไม่ต้องมี Node เลย
ผลทดสอบจริง (ก่อน vs หลัง)
วัดบนโค้ดชุดเดียวกันเป๊ะ ๆ (เครื่อง macOS, Node 26.4.0, pnpm 10.17.0) ต่างกันแค่เวอร์ชัน Astro:
| ตัวชี้วัด | Astro 6.1.1 | Astro 7.0.3 | ผลต่าง |
|---|---|---|---|
| Build (cold) | 2.06s | 1.64s | −20% |
| Build (warm) | 1.99s | 1.53s | −23% |
ขนาด dist/ รวม |
18 MB | 18 MB | เท่าเดิม |
Assets _astro/ |
1.2 MB | 1.2 MB | เท่าเดิม |
| จำนวนหน้า | 122 | 122 | เท่าเดิม |
| CSS รวม | 72.9 KB | 69.6 KB | −4.6% |
| JS รวม | 21.0 KB | 22.7 KB | +8% (เพิ่ม 1 chunk) |
| HTML รวม | 13.27 MB | 13.13 MB | −1.1% |
อยากวัดเองก็ทำได้ ไม่มีอะไรลับ:
# วัดเวลา build แบบ cold (ล้าง cache ก่อน)
rm -rf dist node_modules/.vite .astro/data-store.json
time pnpm run build
# ขนาด output + จำนวนหน้า
du -sh dist
find dist -name '*.html' | wc -l
find dist -name '*.css' -exec cat {} + | wc -c # ขนาด CSS รวม (bytes)อ่านตัวเลขยังไงให้ไม่หลงทาง
- Build เร็วขึ้นจริง ~20% — สม่ำเสมอทั้ง cold/warm นี่คือของแถมจาก Rust compiler + Rolldown
- Output เกือบเท่าเดิม — เพราะบล็อกนี้เป็น static ขนาดเล็ก งานหนักจริง ๆ ของ Rolldown จะโชว์พลังตอนโปรเจกต์ ใหญ่ (component เยอะ, bundle หนัก) ของเล็กแบบนี้กำไรเลยมาในรูป “เวลา build” มากกว่า “ขนาดไฟล์”
- JS โตขึ้นนิดเดียว (+1.7 KB) — เป็นเรื่องการแบ่ง chunk ของ bundler ใหม่ ไม่กระทบ runtime ที่คนอ่านสัมผัสได้
- Core Web Vitals แทบไม่ขยับ — เพราะ HTML ที่ส่งออกแทบจะเหมือนเดิม (static-first ของ Astro ยังเป็นพระเอก) Lighthouse ยังวิ่งใกล้ 100 เหมือนเดิม จุดที่เปลี่ยนชัดคือ ตอนเราพัฒนา ไม่ใช่ตอนผู้ใช้เปิดเว็บ
แล้วตกลง “ควรเปลี่ยนไหม”?
คำตอบสั้น ๆ: เปลี่ยนเถอะ ถ้าผ่านเงื่อนไข Node — แต่ขอแบ่งตามชนิดงาน
ควรเปลี่ยนเลย
- โปรเจกต์ Astro ขนาดใหญ่ ที่ build นาน — Rolldown จะคืนเวลาให้เห็น ๆ
- ทีมที่รัน CI/CD บ่อย ๆ — build เร็วขึ้น 20% = pipeline ถูกลง รอน้อยลง
- เริ่มโปรเจกต์ใหม่ปี 2026 — ไม่มีเหตุผลให้เริ่มที่ของเก่า
เปลี่ยนได้ แต่ทดสอบก่อน
- โปรเจกต์ที่พึ่ง remark/rehype plugin เยอะ — ต้องเช็คให้ชัดว่า engine markdown ใหม่ (Sätteri) รองรับ หรือต้องสลับโหมด
- ใช้ integration นอกกระแส — รอเวอร์ชันที่รองรับ Astro 7 ก่อน
ยังไม่ต้องรีบ
- เซิร์ฟเวอร์ยังติด Node < 18.17 และอัป Node ไม่ได้ง่าย ๆ (เช่นเครื่องที่รันบริการอื่นร่วมอยู่) — ทางออกคือ deploy แบบ static (build ที่อื่น ส่งแต่
dist/) - ใช้ Astro DB อยู่ — อันนี้ถูกถอด ต้องวางแผนย้ายก่อน
สรุป (Recap)
- Astro 7 = Rust compiler + Rolldown + Vite 8 เน้นเร็วขึ้นตอน build และ DX
- อัปเกรดบล็อกนี้ ลื่นมาก — Shiki, RSS, sitemap, MDX ผ่านหมด,
astro check0 error - วัดจริง: build เร็วขึ้น ~20%, output เกือบเท่าเดิม (เพราะเว็บเล็ก)
- กับดักเดียวคือ Node 18.17+ — เลี่ยงได้ด้วยการ deploy เป็น static
ของดีที่ “เปลี่ยนเครื่องแล้วไม่พังกลางทาง” แบบนี้ หาไม่ค่อยได้นะ 🌱
อ่านต่อ
- ทำไม Astro ถึงเร็วมาก? — ปูพื้น Islands Architecture ก่อนไปต่อ