ทรัพยากรที่เร็วที่สุดและได้รับการเพิ่มประสิทธิภาพมากที่สุดคือทรัพยากรที่ไม่ได้ส่ง คุณควรนำทรัพยากรที่ไม่จำเป็นออกจากแอปพลิเคชัน แนวทางปฏิบัติที่ดีคือการตั้งคำถามและกลับมาทบทวนสมมติฐานทั้งโดยนัยและโดยชัดแจ้งกับทีมเป็นระยะๆ ลองดูตัวอย่างต่อไปนี้
- คุณรวมทรัพยากร X ไว้ในหน้าเว็บเสมอ แต่ค่าใช้จ่ายในการดาวน์โหลดและแสดงทรัพยากรดังกล่าวชดเชยคุณค่าที่มอบให้แก่ผู้ใช้หรือไม่ คุณวัดผลและพิสูจน์คุณค่าของแคมเปญได้ไหม
- ทรัพยากร (โดยเฉพาะอย่างยิ่งหากเป็นทรัพยากรของบุคคลที่สาม) มีประสิทธิภาพที่สม่ำเสมอหรือไม่ ทรัพยากรนี้อยู่ในเส้นทางวิกฤตหรือจำเป็นต้องอยู่หรือไม่ หากทรัพยากรอยู่ในเส้นทางที่สำคัญ ทรัพยากรดังกล่าวอาจเป็นจุดเดียวของความล้มเหลวสำหรับเว็บไซต์หรือไม่ กล่าวคือ หากทรัพยากรไม่พร้อมใช้งาน จะส่งผลต่อประสิทธิภาพและประสบการณ์ของผู้ใช้ในหน้าเว็บหรือไม่
- ทรัพยากรนี้จำเป็นต้องมีหรือมี SLA ไหม ทรัพยากรนี้เป็นไปตามแนวทางปฏิบัติแนะนำด้านประสิทธิภาพหรือไม่ เช่น การบีบอัด การแคช และอื่นๆ
บ่อยครั้งที่หน้าเว็บมีทรัพยากรที่ไม่จำเป็น หรือแย่กว่านั้นคือขัดขวางประสิทธิภาพของหน้าเว็บโดยไม่ได้มอบคุณค่าให้แก่ผู้เข้าชมหรือเว็บไซต์ที่โฮสต์ทรัพยากรเหล่านั้นมากนัก ซึ่งมีผลกับทรัพยากรและวิดเจ็ตของบุคคลที่หนึ่งและบุคคลที่สามอย่างเท่าเทียมกัน ดังนี้
- เว็บไซต์ A ตัดสินใจแสดงภาพสไลด์บนหน้าแรกเพื่อให้ผู้เข้าชมดูตัวอย่างรูปภาพหลายรูปได้ด้วยการคลิกอย่างรวดเร็ว ระบบจะโหลดรูปภาพทั้งหมดเมื่อโหลดหน้าเว็บ และผู้ใช้จะเลื่อนดูรูปภาพได้
- คำถาม: คุณเคยวัดจำนวนผู้ใช้ที่ดูรูปภาพหลายรูปในภาพสไลด์ไหม คุณอาจมีค่าใช้จ่ายสูงจากการดาวน์โหลดทรัพยากรที่ผู้เข้าชมส่วนใหญ่ไม่เคยดู
- เว็บไซต์ B ตัดสินใจติดตั้งวิดเจ็ตของบุคคลที่สามเพื่อแสดงเนื้อหาที่เกี่ยวข้อง ปรับปรุงการมีส่วนร่วมทางโซเชียล หรือให้บริการอื่นๆ
- คำถาม: คุณได้ติดตามจำนวนผู้เข้าชมที่ใช้วิดเจ็ตหรือคลิกผ่านเนื้อหาที่วิดเจ็ตแสดงหรือไม่ การมีส่วนร่วมที่วิดเจ็ตนี้สร้างขึ้นเพียงพอที่จะพิสูจน์ค่าใช้จ่ายในการดำเนินการหรือไม่ นอกจากนี้ คุณสามารถใช้กลยุทธ์การโหลดเพื่อให้แน่ใจว่าระบบจะไม่โหลดสคริปต์จนกว่าจะจำเป็นได้หรือไม่
การพิจารณาว่าจะกำจัดการดาวน์โหลดที่ไม่จำเป็นออกหรือไม่นั้นมักต้องใช้การคิดและการวัดผลอย่างรอบคอบ เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด ให้ตรวจสอบและทบทวนคำถามเหล่านี้เป็นระยะๆ สำหรับเนื้อหาทุกรายการในหน้าเว็บ
ผลกระทบต่อ Core Web Vitals
Google ได้เปิดตัวโครงการริเริ่ม Core Web Vitals เพื่อให้ชุดเมตริกที่สะท้อนถึงสิ่งที่ผู้ใช้พบเจอขณะใช้เว็บ แม้ว่าจะมีกลยุทธ์การเพิ่มประสิทธิภาพมากมายสำหรับ Core Web Vitals แต่การตั้งคำถามว่าจะโหลดทรัพยากรหนึ่งๆ ในหน้าเว็บหรือไม่นั้นอาจช่วยให้คุณปรับปรุงเมตริกเหล่านี้ในเว็บไซต์ได้ ด้านล่างนี้คือตัวอย่างบางส่วนที่จัดกลุ่มตาม Core Web Vital แต่ละรายการซึ่งควรค่าแก่การพิจารณา แม้ว่านี่จะไม่ใช่รายการตัวอย่างทั้งหมด (ซึ่งมีอยู่มากมาย) แต่การอ่านตัวอย่างเหล่านี้อาจช่วยให้คุณได้ข้อคิด
Largest Contentful Paint (LCP)
Largest Contentful Paint (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 ของหน้าเว็บต้องมีการดำเนินการบางอย่างเพื่อให้เลย์เอาต์ของหน้าเว็บมีความเสถียรเพียงพอ การตั้งคำถามว่าคุณต้องการทรัพยากรที่เฉพาะเจาะจงหรือไม่ ไม่เพียงแต่จะช่วยเร่งการโหลดหน้าเว็บเท่านั้น แต่ยังช่วยลดความพยายามในการทำความเข้าใจที่จำเป็นต่อการรักษาความเสถียรของเลย์เอาต์ด้วย ซึ่งไม่เพียงแต่จะช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่น่าพึงพอใจมากขึ้นเท่านั้น แต่ยังช่วยให้นักพัฒนาซอฟต์แวร์ได้รับประสบการณ์การใช้งานที่น่าพึงพอใจมากขึ้นด้วย เนื่องจากคุณจะมีเวลามากขึ้นในการบรรลุเป้าหมายอื่นๆ ในโปรเจ็กต์
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) วัดการตอบสนองต่ออินพุตของผู้ใช้ตลอดอายุการใช้งานของหน้าเว็บ INP ของหน้าเว็บอาจได้รับอิทธิพลอย่างมากจาก JavaScript ที่โหลด เนื่องจาก JavaScript เป็นสิ่งที่ขับเคลื่อนการโต้ตอบส่วนใหญ่ที่ผู้ใช้ได้รับจากเว็บ โดยเฉพาะอย่างยิ่ง จำนวนทรัพยากรสคริปต์ที่ดาวน์โหลดระหว่างการโหลดหน้าเว็บอาจทำให้เกิดงานที่อาจมีค่าใช้จ่ายสูงซึ่งเกี่ยวข้องกับการประเมินและการคอมไพล์สคริปต์ ยิ่งคุณโหลด JavaScript น้อยลงในระหว่างการเริ่มต้น เบราว์เซอร์ก็ยิ่งทำงานน้อยลงในจุดสำคัญของประสบการณ์การใช้งานหน้าเว็บ ซึ่งผู้ใช้อาจพยายามโต้ตอบกับหน้าเว็บ
แม้ว่าจะมีกลยุทธ์ในการลดขนาดของทรัพยากร JavaScript ที่ดาวน์โหลดระหว่างการเริ่มต้นระบบ เช่น การแยกโค้ดและการทรีเชคกิ้ง แต่ก็ควรตรวจสอบแพ็กเกจที่คุณใช้ในโปรเจ็กต์เพื่อดูว่าจำเป็นหรือไม่ ตัวอย่างเช่น lodash มีเมธอดมากมายที่ยังคงมีประโยชน์ในปัจจุบัน แต่มาพร้อมกับเมธอดที่เบราว์เซอร์มีให้โดยค่าเริ่มต้น เช่น ฟังก์ชันเฉพาะ Array สำหรับการแมป การลด และการกรอง รวมถึงอื่นๆ อีกมากมาย
การเพิ่มประสิทธิภาพแบบต่อเนื่องยังเป็นแนวทางที่มีประโยชน์สำหรับ JavaScript เนื่องจากช่วยให้คุณมอบประสบการณ์การใช้งานพื้นฐาน (แต่ยังคงใช้งานได้) แก่ผู้ใช้ ซึ่งคุณสามารถเพิ่มประสบการณ์การใช้งานสำหรับผู้ใช้ที่มีอุปกรณ์ที่มีประสิทธิภาพมากขึ้นและการเชื่อมต่อเครือข่ายที่เร็วขึ้นได้ ไม่ว่าคุณจะยึดหลักการเพิ่มประสิทธิภาพแบบต่อเนื่องหรือไม่ ประเด็นก็ยังคงเหมือนเดิม นั่นคือทรัพยากร JavaScript ทุกรายการที่คุณหลีกเลี่ยงการดาวน์โหลดได้จะส่งผลให้เกิดประสบการณ์ที่ตอบสนองต่อการโต้ตอบของผู้ใช้ได้เร็วขึ้น ซึ่งเป็นแง่มุมที่สำคัญของประสิทธิภาพเว็บ
บทสรุป
การตรวจสอบเว็บไซต์เพื่อหาการดาวน์โหลดที่ไม่จำเป็นอาจเป็นเพียงแง่มุมหนึ่งของการมอบประสบการณ์การใช้งานที่รวดเร็วแก่ผู้ใช้ แต่ก็เป็นแง่มุมที่มีแนวโน้มจะส่งผลกระทบสูง กล่าวโดยสรุปคือ
- จัดทำรายการเนื้อหาของคุณเองและเนื้อหาของบุคคลที่สามในหน้าเว็บ
- วัดประสิทธิภาพของเนื้อหาแต่ละรายการ ทั้งมูลค่าและประสิทธิภาพทางเทคนิค
- พิจารณาว่าแหล่งข้อมูลให้คุณค่าเพียงพอหรือไม่
- ทำความเข้าใจผลกระทบของการดาวน์โหลดที่ไม่จำเป็นต่อ Core Web Vitals และเมตริกที่สนับสนุน
การเพิ่มประสิทธิภาพเนื้อหาด้วยวิธีนี้ไม่เพียงช่วยปรับปรุงประสิทธิภาพโดยรวมเท่านั้น แต่ยังช่วยดูแลไม่ให้แบนด์วิดท์ของผู้ใช้สูญเปล่า รวมถึงอาจปรับปรุงเมตริกที่เน้นผู้ใช้เป็นศูนย์กลางและมอบประสบการณ์ของผู้ใช้ที่ดียิ่งขึ้นด้วย