ทรัพยากรที่เร็วที่สุดและเพิ่มประสิทธิภาพได้ดีที่สุดคือทรัพยากรที่ไม่ได้ส่ง คุณควรนำทรัพยากรที่ไม่จำเป็นออกจากแอปพลิเคชัน คุณควรตั้งคำถามและตรวจสอบสมมติฐานทั้งโดยนัยและโดยชัดแจ้งกับทีมเป็นระยะๆ ลองดูตัวอย่างต่อไปนี้
- คุณใส่ทรัพยากร X ไว้ในหน้าเว็บเสมอ แต่ค่าใช้จ่ายในการดาวน์โหลดและแสดงทรัพยากรนั้นคุ้มค่ากับคุณค่าที่มอบให้แก่ผู้ใช้หรือไม่ คุณวัดและพิสูจน์คุณค่าของเนื้อหาได้ไหม
- ทรัพยากร (โดยเฉพาะในกรณีที่เป็นทรัพยากรของบุคคลที่สาม) ให้ประสิทธิภาพที่สอดคล้องกันหรือไม่ ทรัพยากรนี้อยู่ในเส้นทางที่สำคัญหรือจำเป็นต้องอยู่ในเส้นทางดังกล่าว หากทรัพยากรอยู่ในเส้นทางที่สำคัญ ทรัพยากรดังกล่าวอาจเป็นจุดที่ทำให้เกิดข้อผิดพลาดเพียงจุดเดียวของเว็บไซต์ได้ไหม กล่าวคือ หากทรัพยากรไม่พร้อมใช้งาน ประสิทธิภาพและประสบการณ์ของผู้ใช้หน้าเว็บจะได้รับผลกระทบหรือไม่
- ทรัพยากรนี้ต้องมีหรือมี SLA ไหม แหล่งข้อมูลนี้เป็นไปตามแนวทางปฏิบัติแนะนำด้านประสิทธิภาพ เช่น การบีบอัด แคช และอื่นๆ หรือไม่
หน้าเว็บมักมีทรัพยากรที่ไม่จำเป็น หรือแย่กว่านั้นคือขัดขวางประสิทธิภาพของหน้าเว็บโดยไม่ให้คุณค่าแก่ผู้เข้าชมหรือเว็บไซต์ที่โฮสต์หน้าเว็บนั้น นโยบายนี้มีผลบังคับใช้กับทรัพยากรและวิดเจ็ตของบุคคลที่หนึ่งและบุคคลที่สามอย่างเท่าเทียมกัน ดังนี้
- เว็บไซต์ ก ตัดสินใจแสดงภาพสไลด์ในหน้าแรกเพื่อให้ผู้เข้าชมดูตัวอย่างรูปภาพหลายรูปได้ด้วยการคลิกเพียงไม่กี่ครั้ง ระบบจะโหลดรูปภาพทั้งหมดเมื่อโหลดหน้าเว็บ และผู้ใช้เลื่อนดูรูปภาพ
- คําถาม: คุณได้วัดจํานวนผู้ใช้ที่ดูรูปภาพหลายรูปในภาพสไลด์แล้วหรือยัง คุณอาจต้องเสียค่าใช้จ่ายสูงจากการดาวน์โหลดทรัพยากรที่ผู้เข้าชมส่วนใหญ่ไม่เคยดู
- เว็บไซต์ ข. ตัดสินใจติดตั้งวิดเจ็ตของบุคคลที่สามเพื่อแสดงเนื้อหาที่เกี่ยวข้อง ปรับปรุงการมีส่วนร่วมทางโซเชียล หรือให้บริการอื่นๆ
- คําถาม: คุณได้ติดตามจํานวนผู้เข้าชมที่ใช้วิดเจ็ตหรือคลิกผ่านเนื้อหาที่วิดเจ็ตให้ไว้หรือไม่ การมีส่วนร่วมที่วิดเจ็ตนี้สร้างขึ้นเพียงพอที่จะชดเชยค่าใช้จ่ายเพิ่มเติมหรือไม่ นอกจากนี้ คุณใช้กลยุทธ์การโหลดเพื่อให้มั่นใจว่าสคริปต์จะไม่โหลดจนกว่าจะจําเป็นได้ไหม
การพิจารณาว่าจะยกเลิกการดาวน์โหลดที่ไม่จำเป็นหรือไม่นั้นมักต้องใช้การคิดและวัดผลอย่างรอบคอบ ตรวจสอบและกลับไปดูคำถามเหล่านี้เป็นระยะๆ สําหรับชิ้นงานทุกรายการในหน้าเว็บเพื่อให้ได้ผลลัพธ์ที่ดีที่สุด
ผลกระทบต่อ Core Web Vitals
Google ได้เปิดตัวโครงการริเริ่ม Core Web Vitals เพื่อมอบชุดเมตริกที่แสดงถึงสิ่งที่ผู้ใช้ได้รับขณะใช้เว็บ แม้ว่าจะมีกลยุทธ์การเพิ่มประสิทธิภาพสําหรับ Core Web Vitals อยู่หลายกลยุทธ์ แต่การถามว่าควรโหลดทรัพยากรหนึ่งๆ ในหน้าเว็บหรือไม่อาจช่วยชี้แนะแนวทางในการปรับปรุงเมตริกเหล่านี้ในเว็บไซต์ ด้านล่างนี้คือตัวอย่างบางส่วนที่จัดกลุ่มตาม Core Web Vitals แต่ละรายการที่ควรพิจารณา แม้ว่ารายการนี้จะเป็นตัวอย่างเพียงบางส่วน (และยังมีอีกมากมาย) การอ่านตัวอย่างเหล่านี้อาจช่วยให้คุณมีแนวคิดใหม่ๆ
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) จะวัดเมื่อโหลดเนื้อหาที่ใหญ่ที่สุด (เช่น รูปภาพหลักหรือบรรทัดแรก) ซึ่งถือเป็นเมตริกการรับรู้ที่สําคัญซึ่งทําให้ผู้ใช้รู้สึกว่าเว็บไซต์โหลดเร็ว
โดยทั่วไป การดาวน์โหลดทรัพยากรน้อยลงหมายความว่าแบนด์วิดท์ที่ผู้ใช้มีจะได้รับการแบ่งสรรให้กับทรัพยากรน้อยลง และอาจส่งผลให้ LCP ดีขึ้น ตัวอย่างคลาสสิกคือ Lazy Loading ซึ่งจะไม่ดาวน์โหลดรูปภาพที่อยู่นอกวิวพอร์ตระหว่างการโหลดหน้าเว็บจนกว่าเบราว์เซอร์จะพิจารณาว่าผู้ใช้มีแนวโน้มที่จะเห็นรูปภาพเหล่านั้นมากกว่า หากคุณมีแกลเลอรีภาพขนาดย่อขนาดใหญ่ เช่น 50 ภาพ การโหลดแบบเลื่อนเวลาในการโหลดรูปภาพทั้งหมดยกเว้น 10 รูปแรกหมายความว่าเบราว์เซอร์จะใช้ประโยชน์จากแบนด์วิดท์ที่มีอยู่ได้อย่างมีประสิทธิภาพมากขึ้น และรูปภาพแรกๆ ที่ผู้ใช้จะเห็นจะโหลดได้เร็วขึ้น
อย่างไรก็ตาม ไม่ได้หมายความว่าจะต้องโหลดรูปภาพน้อยลง เบราว์เซอร์มีรูปแบบการจัดลําดับความสําคัญภายในซึ่งกําหนดปริมาณแบนด์วิดท์ที่ทรัพยากรแต่ละรายการควรได้รับ อย่างไรก็ตาม แม้จะมีทรัพยากรทั้งหมดนี้ โดยเฉพาะทรัพยากรที่ดาวน์โหลดโดยมีลําดับความสําคัญสูง แต่ก็อาจทำให้ทรัพยากรที่ต้องพึ่งพาขององค์ประกอบ LCP ที่เป็นไปได้ขาดหายไป โดยเฉพาะอย่างยิ่งเมื่อใช้การเชื่อมต่อเครือข่ายที่ช้า ทรัพยากรที่ขึ้นต่อกันนั้นอาจเป็นไฟล์รูปภาพที่แสดงองค์ประกอบ LCP ของหน้าเว็บ หรืออาจเป็นทรัพยากรแบบเว็บฟอนต์ที่เบราว์เซอร์ต้องใช้เพื่อแสดงผลโหนดข้อความที่อาจกำหนดให้เป็นองค์ประกอบ LCP ของหน้าเว็บ
หากเว็บไซต์มีข้อความมาก องค์ประกอบ LCP ของหน้าเว็บอาจเป็นโหนดข้อความ แม้ว่าจะมีกลยุทธ์การเพิ่มประสิทธิภาพและการโหลดแบบอักษรที่ดีมากมาย แต่คุณอาจต้องพิจารณาว่าแบบอักษรของระบบเพียงพอต่อความต้องการของเว็บไซต์หรือไม่ เพื่อให้องค์ประกอบ LCP ซึ่งเป็นโหนดข้อความโหลดได้โดยไม่ต้องใช้ทรัพยากรแบบอักษรบนเว็บ และแสดงผลเกือบจะทันทีเมื่อ CSS และ HTML มาจากเซิร์ฟเวอร์
Cumulative Layout Shift (CLS)
ทรัพยากรทุกรายการที่คุณโหลดมีแนวโน้มที่จะส่งผลต่อการเปลี่ยนเลย์เอาต์สะสม (CLS) ของหน้าเว็บ โดยเฉพาะหากยังไม่ได้ดาวน์โหลดเสร็จสิ้นเมื่อถึงเวลาแสดงผลครั้งแรก สำหรับรูปภาพ หลีกเลี่ยง CLS ที่เกี่ยวข้องกับแนวทางปฏิบัติ เช่น การตั้งค่าขนาดที่ชัดเจน สําหรับแบบอักษร การจัดการการโหลดแบบอักษรและการจับคู่แบบอักษรสำรองที่เป็นไปได้จะช่วยลดการเปลี่ยนแปลงในช่วงระยะเวลาการแลกเปลี่ยนของแบบอักษรบนเว็บ สําหรับ JavaScript อาจเป็นการจัดการวิธีที่สคริปต์นั้นจัดการ DOM เพื่อลดการเปลี่ยนแปลงเลย์เอาต์ให้เหลือในปริมาณที่ยอมรับได้
ทรัพยากรทุกรายการที่ส่งผลต่อ CLS ของหน้าเว็บจะต้องได้รับการแก้ไขเพื่อให้เลย์เอาต์หน้าเว็บมีความเสถียรเพียงพอ การถามตัวเองว่าต้องการทรัพยากรที่เฉพาะเจาะจงหรือไม่ ไม่เพียงแต่จะเพิ่มความเร็วในการโหลดหน้าเว็บเท่านั้น แต่ยังช่วยลดความพยายามในการรับรู้ที่จำเป็นเพื่อรักษาความเสถียรของเลย์เอาต์ด้วย ซึ่งไม่เพียงทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ราบรื่นขึ้นเท่านั้น แต่ยังทำให้นักพัฒนาแอปได้รับประสบการณ์การใช้งานที่ราบรื่นขึ้นด้วย เนื่องจากคุณจะมีเวลามากขึ้นในการบรรลุเป้าหมายอื่นๆ ในโปรเจ็กต์
การโต้ตอบกับ Next Paint (INP)
Interaction to Next Paint (INP) จะวัดการตอบสนองต่ออินพุตของผู้ใช้ตลอดอายุของหน้าเว็บ INP ของหน้าเว็บอาจได้รับอิทธิพลอย่างมากจาก JavaScript ที่โหลด เนื่องจาก JavaScript เป็นปัจจัยที่ขับเคลื่อนการโต้ตอบส่วนใหญ่ที่ผู้ใช้พบในเว็บ โดยเฉพาะอย่างยิ่ง ปริมาณทรัพยากรสคริปต์ที่ดาวน์โหลดระหว่างการโหลดหน้าเว็บอาจทําให้เกิดงานที่อาจมีค่าใช้จ่ายสูงซึ่งเกี่ยวข้องกับการประเมินและการคอมไพล์สคริปต์ ยิ่งคุณโหลด JavaScript น้อยลงในระหว่างการเริ่มต้น เบราว์เซอร์ก็ยิ่งต้องทํางานน้อยลง ณ จุดสําคัญในประสบการณ์การใช้งานหน้าเว็บที่ผู้ใช้อาจพยายามโต้ตอบกับหน้าเว็บ
แม้ว่าจะมีกลยุทธ์ในการลดขนาดของทรัพยากร JavaScript ที่ดาวน์โหลดระหว่างการเริ่มต้น เช่น การแยกโค้ดและการแยกไฟล์ที่ไม่จำเป็นออก แต่คุณก็ควรตรวจสอบแพ็กเกจที่ใช้ในโปรเจ็กต์เพื่อดูว่าแพ็กเกจเหล่านั้นจำเป็นหรือไม่ ตัวอย่างเช่น lodash มีเมธอดมากมายที่ยังคงมีประโยชน์ในปัจจุบัน แต่มาพร้อมกับเมธอดที่เบราว์เซอร์มีให้ใช้งานอยู่แล้ว เช่น ฟังก์ชันเฉพาะ Array สำหรับการแมป การลด และการกรอง รวมถึงอื่นๆ อีกมากมาย
การปรับปรุงแบบเป็นขั้นเป็นตอนยังเป็นแนวทางที่มีประโยชน์สําหรับ JavaScript เนื่องจากช่วยให้คุณแสดงประสบการณ์การใช้งานพื้นฐาน (แต่ยังคงใช้งานได้) สําหรับผู้ใช้ ซึ่งคุณสามารถเพิ่มประสบการณ์การใช้งานให้กับผู้ใช้ที่มีอุปกรณ์ที่มีประสิทธิภาพมากขึ้นและการเชื่อมต่อเครือข่ายที่เร็วขึ้น ไม่ว่าคุณจะยึดตามหลักการของการปรับปรุงแบบเป็นขั้นเป็นตอนหรือไม่ ประเด็นสำคัญคือทรัพยากร JavaScript ทั้งหมดที่คุณหลีกเลี่ยงการดาวน์โหลดได้จะส่งผลให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ตอบสนองเร็วขึ้น ซึ่งถือเป็นแง่มุมที่สําคัญของประสิทธิภาพเว็บ
บทสรุป
การตรวจสอบเว็บไซต์เพื่อหาการดาวน์โหลดที่ไม่จำเป็นอาจเป็นเพียงแง่มุมหนึ่งของการส่งมอบประสบการณ์การใช้งานที่รวดเร็วให้แก่ผู้ใช้ แต่แง่มุมนี้มีโอกาสที่จะสร้างผลกระทบอย่างมาก กล่าวโดยสรุปคือ
- ตรวจสอบเนื้อหาของคุณเองและเนื้อหาของบุคคลที่สามในหน้าเว็บ
- วัดประสิทธิภาพของชิ้นงานแต่ละรายการ ได้แก่ มูลค่าและประสิทธิภาพทางเทคนิค
- พิจารณาว่าทรัพยากรให้คุณค่าที่เพียงพอหรือไม่
- ทําความเข้าใจผลกระทบของการดาวน์โหลดที่ไม่จําเป็นต่อ Core Web Vitals และเมตริกสนับสนุน
การเพิ่มประสิทธิภาพเนื้อหาด้วยวิธีนี้ไม่เพียงช่วยปรับปรุงประสิทธิภาพโดยรวมเท่านั้น แต่ยังช่วยไม่ให้เกิดการใช้แบนด์วิดท์ของผู้ใช้โดยไม่จำเป็น รวมถึงอาจช่วยปรับปรุงเมตริกที่เน้นผู้ใช้เป็นหลักและมอบประสบการณ์การใช้งานที่ดีขึ้นให้แก่ผู้ใช้ด้วย