ย้าย Gatsby ไป Astro ใน 9 วันโดยไม่เขียน React ใหม่: บทเรียนจาก Evil Martians
กรณีศึกษาของ Astro เล่าว่า Evil Martians ย้ายเว็บไซต์จาก Gatsby ไป Astro ด้วยวิศวกรคนเดียวในเก้าวัน โดยไม่เขียน React components เดิมใหม่ จุดที่น่าเก็บไปใช้ไม่ใช่ตัวเลขความเร็วอย่างเดียว แต่เป็นการแยก “ย้าย framework” ออกจาก “ปรับสถาปัตยกรรม hydration” ครับ
รอบ cutover แรกเก็บ component เดิมผ่าน React integration ก่อน หน้าแรกจึงลดน้ำหนักจาก 2.1 MB เหลือ 1.8 MB โดยยังไม่ต้องเปิดโครงการ rewrite อีกก้อน หลังระบบใหม่ทำงานแล้วจึงค่อยเลือกจุด hydrate และใช้ islands architecture เต็มขึ้น น้ำหนักหน้าแรกลดต่อถึง 1.1 MB ขณะที่ JavaScript ตอนโหลดลด 61% และคะแนน mobile Lighthouse ขยับจาก 66 เป็น 90
รูปแบบ migration ที่ทำซ้ำได้
- ทำ inventory ของ page templates, data sources, plugins และ React islands
- ย้าย routing กับ content pipeline ก่อน โดยห่อ component เดิมไว้
- ตั้ง visual regression และ URL parity ให้ผ่านก่อน cutover
- วัด JavaScript, page weight และ Core Web Vitals จากหน้าเดียวกัน
- หลัง production นิ่ง ค่อยลบ hydration ที่ไม่จำเป็นทีละ island
ความเร็วเก้าวันไม่ใช่ SLA ที่ทุกทีมควรลอก เว็บไซต์นี้มีเงื่อนไขของตัวเอง และตัวเลขเป็นผลจากกรณีศึกษาเดียว สิ่งที่นำไปใช้ได้กว้างกว่าคือการตั้ง intermediate state ที่ deploy ได้: framework ใหม่ทำงานร่วมกับ UI เดิม แล้ว performance refactor เดินตามหลังด้วยข้อมูลจริง
อย่าลืม dependency ที่ไม่ได้อยู่ใน component เช่น image pipeline, redirects, RSS, canonical URLs, analytics และ preview ของ CMS ส่วนเหล่านี้มักทำให้ migration ที่ดูจบใน local ยังไม่พร้อมรับ traffic
Recap
- แยก framework cutover ออกจาก component rewrite
- วัด URL, visual และ metadata parity ก่อนเปิด traffic
- เก็บ baseline JavaScript และ Lighthouse ด้วยเงื่อนไขเดียวกัน
- ค่อยลด hydration หลังระบบใหม่ผ่าน production smoke test