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