การกำจัดการดาวน์โหลดที่ไม่จำเป็น

Ilya Grigorik

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

• คุณรวมทรัพยากร 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 ภาพ การโหลดแบบ 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) และ First Input Delay (FID)

การโต้ตอบกับ Next Paint (INP) และ First Input Delay (FID) คือเมตริกที่วัดการตอบสนองต่ออินพุตของผู้ใช้ แม้ว่า INP มีกำหนดจะแทนที่ FID เป็น Core Web Vitals ในเดือนมีนาคม 2024 แต่กลยุทธ์การเพิ่มประสิทธิภาพสำหรับ FID มีแนวโน้มที่จะใช้กับ INP ด้วย นอกจากนี้ โดยทั่วไปแล้ว INP ยังเพิ่มประสิทธิภาพได้ยากกว่า FID เนื่องจากจะติดตามเวลาในการตอบสนองเต็มรูปแบบของการโต้ตอบในหน้าเว็บทั้งหมด ไม่ใช่แค่การหน่วงเวลาอินพุตของการโต้ตอบแรกตามการวัดผล FID

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

แม้ว่าจะมีกลยุทธ์ในการลดขนาดของทรัพยากร JavaScript ที่ดาวน์โหลดระหว่างการเริ่มต้นทำงาน เช่น การแยกโค้ดและการเขย่าแผนผัง แต่ก็ควรตรวจสอบแพ็กเกจที่คุณใช้ในโปรเจ็กต์เพื่อดูว่าจำเป็นต้องใช้หรือไม่ ตัวอย่างเช่น lodash มีวิธีมากมายที่ยังคงเป็นประโยชน์ในปัจจุบัน แต่มาพร้อมกับวิธีการที่เบราว์เซอร์มีให้ตั้งแต่แรก เช่น Array ฟังก์ชันเฉพาะสำหรับการแมป การลด และการกรอง และอื่นๆ อีกมากมาย

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

บทสรุป

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

• จัดเก็บเนื้อหาของคุณเองและเนื้อหาของบุคคลที่สามไว้บนหน้าเว็บ
• วัดประสิทธิภาพของเนื้อหาแต่ละรายการตามมูลค่าและประสิทธิภาพทางเทคนิคของเนื้อหา
• พิจารณาว่าทรัพยากรให้ค่าเพียงพอหรือไม่
• ทำความเข้าใจผลของการดาวน์โหลดที่ไม่จำเป็นใน Core Web Vitals และเมตริกที่รองรับ

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