คะแนน Lighthouse เป็นสัญญาณเชิงสถาปัตยกรรม ไม่ใช่รายการตรวจสอบการเพิ่มประสิทธิภาพ

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

เมื่อเวลาผ่านไป สมมติฐานนั้นก็เริ่มไม่ตรงกับสิ่งที่ผมเห็นในทางปฏิบัติ

เว็บไซต์ที่ได้คะแนนดีอย่างสม่ำเสมอไม่ใช่เว็บไซต์ที่มีความพยายามในการเพิ่มประสิทธิภาพมากที่สุด แต่เป็นเว็บไซต์ที่เบราว์เซอร์มีงานทำน้อยกว่า

ณ จุดนั้น Lighthouse เลิกให้ความรู้สึกเหมือนเครื่องมือเพิ่มประสิทธิภาพและเริ่มให้ความรู้สึกเหมือนสัญญาณวินิจฉัยสำหรับการเลือกสถาปัตยกรรม

สิ่งที่ Lighthouse วัดจริงๆ

Lighthouse ไม่ได้ประเมินเฟรมเวิร์กหรือเครื่องมือ มันประเมินผลลัพธ์

เนื้อหาที่มีความหมายปรากฏเร็วเพียงใด

JavaScript บล็อกเธรดหลักมากเพียงใด

เลย์เอาต์คงความเสถียรได้ดีเพียงใดในระหว่างการโหลด

โครงสร้างเอกสารเข้าถึงได้และสามารถรวบรวมข้อมูลได้ดีเพียงใด

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

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

JavaScript เป็นแหล่งที่มาหลักของความแปรปรวน

จากการตรวจสอบที่ผมได้ทำและโปรเจกต์ที่ผมได้ทำงานด้วย การทำงานของ JavaScript เป็นแหล่งที่มาทั่วไปที่สุดของการถดถอยของ Lighthouse

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

รันไทม์ของเฟรมเวิร์ก ตรรกะการไฮเดรต กราฟการพึ่งพา และการเริ่มต้นสเตตล้วนใช้เวลาก่อนที่เพจจะพร้อมใช้งาน แม้แต่ฟีเจอร์โต้ตอบขนาดเล็กมักต้องการบันเดิลที่ใหญ่ไม่สมส่วน

สถาปัตยกรรมที่สันนิษฐาน JavaScript ตามค่าเริ่มต้นต้องการความพยายามอย่างต่อเนื่องเพื่อควบคุมประสิทธิภาพ สถาปัตยกรรมที่ถือว่า JavaScript เป็นการเลือกใช้อย่างชัดเจนมักสร้างผลลัพธ์ที่เสถียรกว่า

เอาต์พุตแบบคงที่ลดความไม่แน่นอน

เอาต์พุตที่เรนเดอร์ล่วงหน้าจะลดตัวแปรหลายตัวออกจากสมการประสิทธิภาพ

ไม่มีต้นทุนการเรนเดอร์ฝั่งเซิร์ฟเวอร์ในเวลาขอ

ไม่จำเป็นต้องมีการบูตสแตรปฝั่งไคลเอนต์เพื่อให้เนื้อหาปรากฏ

เบราว์เซอร์ได้รับ HTML ที่สมบูรณ์และคาดเดาได้

จากมุมมองของ Lighthouse สิ่งนี้ปรับปรุงเมตริกต่างๆ เช่น TTFB, LCP และ CLS โดยไม่ต้องทำงานเพิ่มประสิทธิภาพเฉพาะเจาะจง การสร้างแบบคงที่ไม่รับประกันคะแนนที่สมบูรณ์แบบ แต่จะลดช่วงของโหมดความล้มเหลวลงอย่างมาก

กรณีศึกษา

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

ด้วยความอยากรู้ ผมลองวิธีการที่แตกต่างซึ่งสันนิษฐาน HTML แบบคงที่ก่อนและถือว่า JavaScript เป็นข้อยกเว้น ผมเลือก Astro สำหรับการทดลองนี้ เพราะข้อจำกัดเริ่มต้นสอดคล้องกับคำถามที่ผมต้องการทดสอบ

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

ผมได้บันทึกกระบวนการสร้างและการแลกเปลี่ยนทางสถาปัตยกรรมในบันทึกทางเทคนิคแยกต่างหากในขณะที่ทำงานผ่านการทดลองนี้บนบล็อกส่วนตัวที่มีคะแนน Lighthouse สูงสุด

การแลกเปลี่ยนมีความสำคัญ

วิธีการนี้ไม่ได้ดีกว่าในทุกกรณี

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

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

ทำไมคะแนน Lighthouse มักจะเสถียรหรือเปราะบาง

สิ่งที่ Lighthouse แสดงไม่ใช่ความพยายาม แต่เป็นเอนโทรปี

ระบบที่พึ่งพาการคำนวณรันไทม์สะสมความซับซ้อนเมื่อเพิ่มฟีเจอร์ ระบบที่ทำงานมากขึ้นในเวลาสร้างจำกัดความซับซ้อนนั้นตามค่าเริ่มต้น

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

ความคิดปิดท้าย

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

เครื่องมือมาและไป แต่หลักการพื้นฐานยังคงเหมือนเดิม เมื่อประสิทธิภาพเป็นข้อจำกัดเริ่มต้นมากกว่าเป้าหมาย Lighthouse จะหยุดเป็นสิ่งที่คุณไล่ตามและกลายเป็นสิ่งที่คุณสังเกต

การเปลี่ยนแปลงนั้นเกี่ยวกับการเลือกเฟรมเวิร์กที่เหมาะสมน้อยลงและเกี่ยวกับการเลือกว่าความซับซ้อนได้รับอนุญาตให้มีอยู่ที่ใดมากขึ้น