การวัดประสิทธิภาพ: Lighthouse และ Core Web Vitals

Lighthouse เป็นเครื่องมือมาตรฐานสำหรับวัดประสิทธิภาพเว็บ ให้เรียกใช้ใน Chrome DevTools (แท็บ Lighthouse) หรือผ่าน CLI (npx lighthouse https://yoursite.com) เมื่อประเมินสถาปัตยกรรมแบบไอส์แลนด์ ให้เรียกใช้ Lighthouse กับหน้าเว็บตัวแทนก่อนและหลังการย้ายระบบ เพื่อวัดผลลัพธ์ที่เพิ่มขึ้นอย่างเป็นกลาง

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

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

เวลาที่บล็อกทั้งหมดใช้วัดระยะเวลาที่เธรดหลักถูก JavaScript บล็อกโดยงานที่ใช้เวลานานกว่า 50 มิลลิวินาที การทำไฮเดรตแอป SPA ของรีแอกต์ขนาดใหญ่อาจทำให้ TBT สูงถึงหลายร้อยมิลลิวินาที สถาปัตยกรรมแบบเกาะช่วยลด TBT ได้อย่างมาก เพราะปริมาณ JavaScript ที่ทำงานแปรผันตามจำนวนเกาะ ไม่ใช่ตามขนาดของหน้า

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

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

ตัวอย่างการเปรียบเทียบทั่วไปสำหรับหน้าบล็อกคือ แอป SPA ของรีแอกต์แบบเต็มรูปแบบอาจได้คะแนน 45-65 บนไลท์เฮาส์สำหรับมือถือ (TBT: 800 มิลลิวินาที, LCP: 3.2 วินาที) ส่วนเนื้อหาเดียวกันที่สร้างเป็นเว็บไซต์แอสโตรซึ่งมีเกาะรีแอกต์หนึ่งเกาะอาจได้คะแนน 90-98 (TBT: 80 มิลลิวินาที, LCP: 1.1 วินาที) ผลลัพธ์ที่ดีขึ้นจะเห็นได้ชัดเจนที่สุดในหน้าที่มีเนื้อหาจำนวนมากและมีการโต้ตอบจำกัด

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

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

กูเกิลใช้ตัวชี้วัดเว็บหลัก (LCP, INP, CLS) เป็นสัญญาณจัดอันดับ การปรับปรุงตัวชี้วัดเหล่านี้ด้วยสถาปัตยกรรมแบบเกาะจึงส่งผลดีโดยตรงต่ออันดับการค้นหา เว็บไซต์ที่ปรับปรุงคะแนนไลท์เฮาส์บนมือถือจาก 55 เป็น 92 ด้วยการนำสถาปัตยกรรมแบบเกาะมาใช้ จะได้รับทั้งประโยชน์ด้านประสบการณ์ผู้ใช้และการปรับแต่งเว็บไซต์เพื่อการค้นหาไปพร้อมกัน

ทีมที่ย้ายจากแอป SPA ของรีแอกต์บน Next.js ไปใช้แอสโตรสำหรับเว็บไซต์การตลาดและเอกสารประกอบรายงานผลลัพธ์ที่สอดคล้องกัน ได้แก่ ข้อมูล JavaScript ที่ส่งไปยังไคลเอนต์ลดลง 70-90% คะแนนประสิทธิภาพบนมือถือเพิ่มขึ้น 20-40 คะแนน และค่าโฮสต์เซิร์ฟเวอร์ลดลง เพราะให้บริการไฟล์คงที่จาก CDN โดยไม่ต้องมีต้นทุนการเรนเดอร์ฝั่งเซิร์ฟเวอร์ในแต่ละคำขอ

เหตุใดสถาปัตยกรรมแบบเกาะจึงช่วยลดเวลาที่บล็อกทั้งหมด (TBT) ได้อย่างมาก

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