โหลดเนื้อหาที่สำคัญไว้ล่วงหน้าเพื่อปรับปรุงความเร็วในการโหลด

เมื่อคุณเปิดหน้าเว็บ เบราว์เซอร์จะขอเอกสาร HTML จากเซิร์ฟเวอร์ แยกวิเคราะห์เนื้อหา และส่งคําขอแยกต่างหากสําหรับทรัพยากรที่อ้างอิง ในฐานะนักพัฒนาซอฟต์แวร์ คุณทราบอยู่แล้วว่าหน้าเว็บต้องใช้ทรัพยากรใดบ้างและทรัพยากรใดสำคัญที่สุด คุณสามารถใช้ความรู้ดังกล่าวเพื่อขอทรัพยากรสําคัญล่วงหน้าและเร่งกระบวนการโหลดได้ โพสต์นี้อธิบายวิธีดำเนินการดังกล่าวด้วย <link rel="preload">

วิธีการทำงานของการโหลดล่วงหน้า

การโหลดล่วงหน้าเหมาะสําหรับทรัพยากรที่เบราว์เซอร์มักจะค้นพบช้า

ภาพหน้าจอของแผงเครือข่ายในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ในตัวอย่างนี้ มีการกําหนดแบบอักษร Pacifico ในสไตล์ชีตด้วยกฎ @font-face เบราว์เซอร์จะโหลดไฟล์แบบอักษรหลังจากที่ดาวน์โหลดและแยกวิเคราะห์สไตล์ชีตเสร็จแล้วเท่านั้น

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

ภาพหน้าจอของแผงเครือข่ายใน Chrome DevTools หลังจากใช้การโหลดล่วงหน้า
ในตัวอย่างนี้ ระบบจะโหลดแบบอักษร Pacifico ไว้ล่วงหน้า ดังนั้นการดาวน์โหลดจึงเกิดขึ้นควบคู่ไปกับสไตล์ชีต

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

การตรวจสอบคําขอคีย์ที่โหลดล่วงหน้าของ Lighthouse

คุณสามารถโหลดทรัพยากรล่วงหน้าได้โดยเพิ่มแท็ก <link> ที่มี rel="preload" ลงในส่วนหัวของเอกสาร HTML

<link rel="preload" as="script" href="critical.js">

เบราว์เซอร์จะแคชทรัพยากรที่โหลดไว้ล่วงหน้าเพื่อให้พร้อมใช้งานทันทีเมื่อต้องการ (จะไม่เรียกใช้สคริปต์หรือใช้สไตล์ชีต)

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

การโหลดล่วงหน้าที่ไม่ได้ใช้จะทริกเกอร์คำเตือนคอนโซลใน Chrome โดยจะเกิดขึ้นประมาณ 3 วินาทีหลังจากเหตุการณ์ load

คำเตือนของคอนโซลเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เกี่ยวกับทรัพยากรที่โหลดไว้ล่วงหน้าแต่ไม่ได้ใช้งาน

กรณีการใช้งาน

โหลดทรัพยากรที่กําหนดไว้ใน CSS ล่วงหน้า

ระบบจะไม่ค้นพบแบบอักษรที่กําหนดด้วยกฎ @font-face หรือรูปภาพพื้นหลังที่กําหนดไว้ในไฟล์ CSS จนกว่าเบราว์เซอร์จะดาวน์โหลดและแยกวิเคราะห์ไฟล์ CSS เหล่านั้น การโหลดทรัพยากรเหล่านี้ล่วงหน้าช่วยให้มั่นใจได้ว่าระบบจะดึงข้อมูลทรัพยากรดังกล่าวก่อนที่จะดาวน์โหลดไฟล์ CSS

โหลดไฟล์ CSS ล่วงหน้า

หากใช้แนวทาง CSS ที่สําคัญ ให้แยก CSS ออกเป็น 2 ส่วน CSS ที่สําคัญที่จําเป็นสําหรับการแสดงผลเนื้อหาครึ่งหน้าบนจะแทรกอยู่ใน <head> ของเอกสาร และ CSS ที่ไม่สําคัญมักจะโหลดแบบ Lazy ด้วย JavaScript การรอให้ JavaScript ทำงานก่อนที่จะโหลด CSS ที่ไม่สำคัญอาจทําให้การแสดงผลล่าช้าเมื่อผู้ใช้เลื่อนดู ดังนั้นคุณควรใช้ <link rel="preload"> เพื่อเริ่มการดาวน์โหลดให้เร็วขึ้น

โหลดไฟล์ JavaScript ล่วงหน้า

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

วิธีใช้ rel=preload

วิธีที่ง่ายที่สุดในการใช้งาน preload คือการเพิ่มแท็ก <link> ลงใน <head> ของเอกสาร ดังนี้

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

การให้แอตทริบิวต์ as จะช่วยให้เบราว์เซอร์กำหนดลำดับความสำคัญของทรัพยากรที่ดึงข้อมูลล่วงหน้าตามประเภทของทรัพยากร ตั้งค่าส่วนหัวที่เหมาะสม และระบุว่ามีทรัพยากรนั้นอยู่ในแคชอยู่แล้วหรือไม่ ค่าที่ยอมรับสำหรับแอตทริบิวต์นี้ ได้แก่ script, style, font, image และอื่นๆ

ระบบจะโหลดทรัพยากรบางประเภท เช่น แบบอักษร ในโหมดไม่ระบุตัวตน สำหรับรายการเหล่านี้ คุณต้องตั้งค่าแอตทริบิวต์ crossorigin ด้วย preload

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

องค์ประกอบ <link> ยังยอมรับแอตทริบิวต์ type ที่มีประเภท MIME ของทรัพยากรที่ลิงก์ด้วย เบราว์เซอร์จะใช้ค่าของแอตทริบิวต์ type เพื่อให้แน่ใจว่าระบบจะโหลดทรัพยากรล่วงหน้าเฉพาะในกรณีที่รองรับประเภทไฟล์ของทรัพยากรนั้นๆ หากเบราว์เซอร์ไม่รองรับประเภททรัพยากรที่ระบุ เบราว์เซอร์จะไม่สนใจ <link rel="preload">

นอกจากนี้ คุณยังโหลดทรัพยากรประเภทใดก็ได้ล่วงหน้าผ่านLinkส่วนหัว HTTP ดังนี้

Link: </css/style.css>; rel="preload"; as="style"

ข้อดีของการระบุ preload ในส่วนหัว HTTP คือเบราว์เซอร์ไม่จําเป็นต้องแยกวิเคราะห์เอกสารเพื่อค้นหา ซึ่งอาจช่วยปรับปรุงได้เล็กน้อยในบางกรณี

โหลดโมดูล JavaScript ล่วงหน้าด้วย webpack

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

import(_/* webpackPreload: true */_ "CriticalChunk")

หากคุณใช้ Webpack เวอร์ชันเก่า ให้ใช้ปลั๊กอินของบุคคลที่สาม เช่น preload-webpack-plugin

ผลกระทบของการโหลดล่วงหน้าต่อ Core Web Vitals

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

Largest Contentful Paint (LCP)

การโหลดล่วงหน้าส่งผลอย่างมากต่อ Largest Contentful Paint (LCP) ในส่วนของแบบอักษรและรูปภาพ เนื่องจากทั้งรูปภาพและโหนดข้อความอาจเป็นผู้สมัคร LCP ได้ รูปภาพหลักและข้อความจำนวนมากที่แสดงผลโดยใช้แบบอักษรเว็บจะได้รับประโยชน์อย่างมากจากคำแนะนำการโหลดล่วงหน้าที่วางไว้อย่างเหมาะสม และควรใช้เมื่อมีโอกาสที่จะแสดงเนื้อหาสำคัญเหล่านี้ต่อผู้ใช้ได้เร็วขึ้น

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

แต่ให้เน้นที่เนื้อหาที่มีคุณค่าสูงเพียงไม่กี่รายการที่คุณรู้ว่าจะได้ประโยชน์จากการโหลดล่วงหน้าในตำแหน่งที่เหมาะสม เมื่อโหลดแบบอักษรล่วงหน้า โปรดตรวจสอบว่าคุณแสดงแบบอักษรในรูปแบบ WOFF 2.0 เพื่อลดเวลาในการโหลดทรัพยากรให้มากที่สุด เนื่องจาก WOFF 2.0 มีการรองรับเบราว์เซอร์ที่ยอดเยี่ยม การใช้รูปแบบเก่า เช่น WOFF 1.0 หรือ TrueType (TTF) จะทําให้ LCP ล่าช้าหาก LCP ที่เป็นไปได้คือโหนดข้อความ

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

Cumulative Layout Shift (CLS)

การจัดวางที่เลื่อนสะสม (CLS) เป็นเมตริกที่สําคัญอย่างยิ่งเมื่อพูดถึงเว็บฟอนต์ และ CLS มีการโต้ตอบที่สําคัญกับเว็บฟอนต์ที่ใช้font-displayพร็อพเพอร์ตี้ CSS เพื่อจัดการวิธีโหลดแบบอักษร ลองใช้กลยุทธ์ต่อไปนี้เพื่อลดการเปลี่ยนแปลงเลย์เอาต์ที่เกี่ยวข้องกับแบบอักษรเว็บ

  1. โหลดแบบอักษรไว้ล่วงหน้าขณะใช้ค่าเริ่มต้น block สำหรับ font-display การรักษาสมดุลเป็นเรื่องละเอียดอ่อน การบล็อกการแสดงแบบอักษรโดยไม่มีแบบอักษรสำรองอาจถือเป็นปัญหาด้านประสบการณ์ของผู้ใช้ ในทางหนึ่ง การใช้ font-display: block; ในการโหลดแบบอักษรจะช่วยขจัดการเปลี่ยนแปลงเลย์เอาต์ที่เกี่ยวข้องกับแบบอักษรบนเว็บ ในทางกลับกัน คุณยังคงต้องโหลดแบบอักษรเว็บเหล่านั้นโดยเร็วที่สุดหากแบบอักษรเหล่านั้นมีความสำคัญต่อประสบการณ์ของผู้ใช้ การรวมการโหลดล่วงหน้าเข้ากับ font-display: block; อาจเป็นการประนีประนอมที่เรายอมรับได้
  2. โหลดแบบอักษรล่วงหน้าขณะใช้ค่า fallback สำหรับ font-display fallback เป็นค่ากลางระหว่าง swap กับ block เนื่องจากมีระยะเวลาการบล็อกสั้นมาก
  3. ใช้ค่า optional สำหรับ font-display โดยไม่ต้องมีการโหลดล่วงหน้า หากแบบอักษรเว็บไม่สำคัญต่อประสบการณ์ของผู้ใช้ แต่ยังคงใช้เพื่อแสดงผลข้อความในหน้าเว็บจำนวนมาก ให้พิจารณาใช้ค่า optional ในกรณีที่ไม่เหมาะสม optional จะแสดงข้อความในหน้าเว็บด้วยแบบอักษรสำรองขณะที่โหลดแบบอักษรในเบื้องหลังสำหรับการนําทางครั้งถัดไป ผลลัพธ์สุทธิในเงื่อนไขเหล่านี้คือ CLS ที่ดีขึ้น เนื่องจากแบบอักษรของระบบจะแสดงผลทันที ขณะที่การโหลดหน้าเว็บครั้งต่อๆ ไปจะโหลดแบบอักษรทันทีโดยไม่มีการเปลี่ยนแปลงเลย์เอาต์

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

การโต้ตอบกับ Next Paint (INP)

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

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

บทสรุป

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