จาก React SPA สู่ Astro: เมื่อใดและทำไมจึงควรย้าย

เว็บไซต์องค์กรที่สร้างเป็นแอปพลิเคชันหน้าเดียว (SPA) ด้วย React เป็นทางเลือกด้านสถาปัตยกรรมที่สมเหตุสมผลในปี 2018 ขณะนั้น React เป็นเฟรมเวิร์ก frontend ที่ได้รับความนิยมสูงสุด เครื่องมือรวมไฟล์พัฒนาอย่างรวดเร็ว และประสบการณ์ของนักพัฒนาดูได้เปรียบแนวทางเรนเดอร์บนเซิร์ฟเวอร์อย่างมาก หลายปีต่อมา เว็บไซต์เหล่านั้นจำนวนมากกลับทำผลงานได้ไม่ดีในตัวชี้วัดที่ส่งผลต่อธุรกิจจริง ทั้ง Core Web Vitals อันดับการค้นหา และระยะเวลาจนผู้ใช้ที่มีการเชื่อมต่อจำกัดเห็นเนื้อหาที่มีความหมาย

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

เหตุใด React SPA จึงทำงานได้ไม่ดีบนเว็บไซต์องค์กร

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

Core Web Vitals ของ Google ทำให้ความล่าช้าเหล่านี้วัดได้ชัดเจน Largest Contentful Paint วัดเวลาที่องค์ประกอบขนาดใหญ่ที่สุดในส่วนที่มองเห็นถูกเรนเดอร์ สำหรับ React SPA ที่โหลดส่วนหลักของหน้าหรือเนื้อหาที่เห็นโดยไม่ต้องเลื่อน โดยทั่วไปจะเกิดขึ้นหลังจากรัน JavaScript เสร็จแล้ว First Contentful Paint ซึ่งเป็นตัวชี้วัดเสริมและไม่ใช่หนึ่งใน Core Web Vitals ทั้งสาม (LCP, INP และ CLS) ก็ล่าช้าด้วยเหตุผลเดียวกัน ในทางปฏิบัติ React SPA ที่แสดงเนื้อหาการตลาดแบบสแตติกเป็นหลักมักมีค่า LCP อยู่ในระดับ “ต้องปรับปรุง” หรือ “แย่” เพราะเส้นทางการเรนเดอร์ซับซ้อนเกินจำเป็น ไม่ใช่เพราะเนื้อหามีน้ำหนักมาก

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

Astro เปลี่ยนอะไรบ้าง

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

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

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

สถาปัตยกรรม islands ในทางปฏิบัติ

Island ของ Astro คือคอมโพเนนต์ที่ต้องใช้ JavaScript ฝั่งไคลเอนต์ โดยมี HTML แบบสแตติกล้อมรอบ แทนที่จะส่งรันไทม์ React เต็มรูปแบบเพื่อทำ hydration ทั้งหน้า Astro ส่ง JavaScript เฉพาะคอมโพเนนต์ที่ต้องใช้จริง แบบฟอร์มติดต่อเป็น island เมนูนำทางแบบดรอปดาวน์เป็น island ส่วนเนื้อหารอบข้าง ทั้งหัวข้อ ข้อความ รูปภาพ และส่วนท้าย ยังคงเป็น HTML แบบสแตติก

แนวทางนี้กลับสมมติฐานเริ่มต้นของ React SPA ใน React SPA คำถามคือ “ส่วนไหนของหน้านี้ที่เราข้ามการเรนเดอร์ได้” และคำตอบมักเป็นไม่มีเลย เพราะกระบวนการเรนเดอร์ทั้งหมดผ่าน React ส่วน Astro ถามว่า “ส่วนไหนของหน้านี้ที่ต้องใช้ JavaScript จริง ๆ” ซึ่งสำหรับเว็บไซต์องค์กรทั่วไป คำตอบคือเพียงส่วนเล็ก ๆ ของเนื้อหาทั้งหมด

สถาปัตยกรรมนี้รองรับเฟรมเวิร์กสำหรับ islands เช่น React, Preact, Vue, Svelte และ Solid จึงย้ายระบบได้โดยไม่ต้องเขียนคอมโพเนนต์ React เดิมใหม่ องค์ประกอบโต้ตอบที่สร้างด้วย React ยังทำงานเป็น islands ของ Astro ด้วยโค้ดคอมโพเนนต์เดิม ขณะที่โครงสร้างหน้ารอบข้างกลายเป็นสแตติก ความเข้ากันได้นี้ทำให้ย้ายบางส่วนได้ โดยเก็บคอมโพเนนต์ React ที่จัดการการโต้ตอบจริงไว้ และลดภาระจาก SPA เต็มรูปแบบที่เนื้อหาการตลาดรอบข้างเคยต้องแบกรับ

เมื่อใด Astro จึงเหมาะสม

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

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

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

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

ขั้นตอนการย้ายระบบในทางปฏิบัติ

การย้ายจาก React SPA ไป Astro ทั้งระบบควรแบ่งเป็นระยะ แทนการเปลี่ยนทั้งหมดในครั้งเดียว เป้าหมายของแต่ละระยะคือเวอร์ชันที่นำขึ้นใช้งานได้และดีขึ้นจากเวอร์ชันก่อน แทนการเขียนใหม่ยาวนานจนสะสมความเสี่ยง

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

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

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

ระยะที่สี่คือการตรวจสอบผล ควรวัด Core Web Vitals ก่อนและหลังย้ายภายใต้เงื่อนไขที่เทียบกันได้ เช่น จำลองเครือข่ายมือถือและใช้แคชที่ยังไม่มีข้อมูล การย้ายจาก React SPA ที่เรนเดอร์ฝั่งไคลเอนต์ไปยังผลลัพธ์แบบสแตติกของ Astro โดยมีเนื้อหาเทียบเท่ากัน มักทำให้ LCP ดีขึ้นอย่างมาก แต่ขนาดของผลที่ได้ขึ้นอยู่กับสภาพก่อนย้าย จึงควรวัดผลแทนการคาดเดา ส่วนผลต่อ SEO มักต้องใช้เวลาหลายสัปดาห์กว่าจะเห็นในข้อมูลการค้นหา เพราะบอตต้องจัดทำดัชนีหน้าเว็บที่อัปเดตใหม่

ข้อแลกเปลี่ยนที่ควรยอมรับ

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

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

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

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