ชุดแนวทางปฏิบัติแนะนำที่ทีม Chrome DevRel เชื่อว่าเป็นวิธีที่มีประสิทธิภาพมากที่สุดในการปรับปรุงประสิทธิภาพของ Core Web Vitals ในปี 2023
ตลอดหลายปีที่ผ่านมา พวกเราที่ Google ได้ให้คำแนะนำมากมายแก่นักพัฒนาเว็บเกี่ยวกับวิธีปรับปรุงประสิทธิภาพ
แม้ว่าคำแนะนำแต่ละรายการเหล่านี้อาจช่วยปรับปรุงประสิทธิภาพของเว็บไซต์ต่างๆ ได้ แต่คำแนะนำทั้งชุดมีปริมาณมหาศาลและในความเป็นจริงแล้ว อาจไม่มีวิธีที่บุคคลหรือเว็บไซต์ใดติดตามเว็บไซต์ทั้งหมดได้
หากประสิทธิภาพเว็บไม่ใช่งานประจำวันของคุณ ก็คงไม่แน่ชัดว่าคำแนะนำใดจะมีผลดีต่อเว็บไซต์มากที่สุด ตัวอย่างเช่น คุณอาจได้อ่านมาว่าการใช้ CSS ที่สำคัญจะช่วยปรับปรุงประสิทธิภาพการโหลดได้ และคุณอาจเคยได้ยินมาว่าการเพิ่มประสิทธิภาพรูปภาพเป็นสิ่งสำคัญ แต่หากคุณไม่มีเวลาจัดการกับทั้ง 2 อย่าง คุณจะตัดสินใจเลือกวิธีใดดี
ในปีที่ผ่านมา เราได้ใช้เวลาในปีที่ผ่านมาเพื่อพยายามตอบคำถามนี้: อะไรคือคำแนะนำที่สำคัญที่สุดที่เราสามารถมอบให้แก่นักพัฒนาซอฟต์แวร์เพื่อช่วยให้นักพัฒนาซอฟต์แวร์ปรับปรุงประสิทธิภาพสำหรับผู้ใช้ของตน
ในการตอบคำถามนี้ได้อย่างเพียงพอ เราต้องไม่พิจารณาเฉพาะประโยชน์ทางเทคนิคของคำแนะนำต่างๆ เท่านั้น แต่ยังต้องพิจารณาปัจจัยระหว่างบุคคลและองค์กรที่มีอิทธิพลต่อแนวโน้มที่นักพัฒนาซอฟต์แวร์จะสามารถนำคำแนะนำเหล่านี้ไปใช้ได้จริง กล่าวอีกนัยหนึ่งคือ คำแนะนำบางอย่างอาจมีผลอย่างมากในทางทฤษฎี แต่ในความเป็นจริงแล้วมีเว็บไซต์เพียงไม่กี่แห่งที่มีเวลาหรือทรัพยากรในการนำคำแนะนำเหล่านั้นไปใช้ ในทำนองเดียวกัน คำแนะนำบางอย่างมีความสำคัญ แต่เว็บไซต์ส่วนใหญ่ปฏิบัติตามแนวทางปฏิบัติเหล่านี้อยู่แล้ว
กล่าวโดยสรุปคือ เราต้องการให้รายการคำแนะนำด้านประสิทธิภาพเว็บยอดนิยมของเรามุ่งเน้นไปที่ข้อใดต่อไปนี้
- คำแนะนำที่เราเชื่อว่าจะมีผลกระทบในชีวิตจริงที่ใหญ่ที่สุด
- คำแนะนำที่เกี่ยวข้องและตรงกับเว็บไซต์ส่วนใหญ่
- คำแนะนำที่นำไปใช้ได้จริงสำหรับนักพัฒนาซอฟต์แวร์ส่วนใหญ่
ในปีที่ผ่านมา เราใช้เวลามากมายในการตรวจสอบคำแนะนำด้านประสิทธิภาพทั้งหมดที่เราจัดทำ และประเมินคำแนะนำแต่ละรายการ (ทั้งในเชิงคุณภาพและเชิงปริมาณ) ตามเกณฑ์ทั้ง 3 ข้อข้างต้น
โพสต์นี้สรุปคำแนะนำยอดนิยมในการปรับปรุงประสิทธิภาพของเมตริก Core Web Vitals แต่ละรายการ หากคุณยังใหม่ต่อประสิทธิภาพของเว็บ หรือกำลังตัดสินใจว่าอะไรที่จะช่วยเพิ่มผลตอบแทนให้คุ้มค่าที่สุด เราคิดว่าคำแนะนำเหล่านี้เป็นจุดเริ่มต้นที่ดีที่สุด
Largest Contentful Paint (LCP)
คำแนะนำชุดแรกมีไว้สำหรับ Largest Contentful Paint (LCP) ซึ่งเป็นการวัดประสิทธิภาพการโหลด จากเมตริกของ Core Web Vitals ทั้ง 3 รายการ พบว่า LCP เป็นเมตริกที่เว็บไซต์จำนวนมากประสบปัญหามากที่สุดในปัจจุบัน โดยมีเพียงประมาณครึ่งของเว็บไซต์ทั้งหมดในเว็บที่มีคุณสมบัติตรงตามเกณฑ์ที่แนะนำ เรามาเริ่มกันเลย
ตรวจสอบว่าทรัพยากร LCP ค้นพบได้จากแหล่งที่มา HTML
จากหนังสือสรุปเว็บปี 2022 โดยที่เก็บถาวรของ HTTP พบว่าหน้าเว็บในอุปกรณ์เคลื่อนที่ 72% มีรูปภาพเป็นองค์ประกอบ LCP ซึ่งหมายความว่าเว็บไซต์ส่วนใหญ่จะต้องเพิ่มประสิทธิภาพ LCP จึงต้องตรวจสอบว่ารูปภาพเหล่านั้นโหลดได้อย่างรวดเร็ว
สิ่งที่อาจไม่ชัดเจนสำหรับนักพัฒนาซอฟต์แวร์จำนวนมากคือ เวลาที่ใช้ในการโหลดรูปภาพเป็นเพียงส่วนหนึ่งของความท้าทายเท่านั้น ส่วนที่สำคัญอีกอย่างคือเวลาก่อนที่รูปภาพจะเริ่มโหลด และข้อมูล HTTP Archive บ่งบอกว่าเป็นจุดที่เว็บไซต์จำนวนมากหยุดชะงัก
ในความเป็นจริง หน้าเว็บที่องค์ประกอบ LCP เป็นรูปภาพนั้น 39% ของรูปภาพมี URL แหล่งที่มาที่ค้นพบไม่ได้จากแหล่งที่มาของเอกสาร HTML กล่าวคือ ไม่พบ URL เหล่านั้นในแอตทริบิวต์ HTML มาตรฐาน (เช่น <img src="..."> หรือ <link rel="preload" href="...">) ซึ่งจะช่วยให้เบราว์เซอร์ค้นหา URL ได้อย่างรวดเร็วและเริ่มโหลดได้ทันที
หากหน้าเว็บต้องรอให้ไฟล์ CSS หรือ JavaScript ได้รับการดาวน์โหลด แยกวิเคราะห์ และประมวลผลจนเสร็จสมบูรณ์ก่อน รูปภาพจึงจะเริ่มโหลดได้ อาจช้าเกินไปแล้ว
ตามกฎทั่วไป หากองค์ประกอบ LCP เป็นรูปภาพ URL ของรูปภาพควรค้นพบได้จากแหล่งที่มา HTML เสมอ เคล็ดลับบางอย่างที่จะทำให้การบรรลุเป้าหมายนี้เป็นจริงได้มีดังนี้
โหลดรูปภาพโดยใช้องค์ประกอบ
<img>ที่มีแอตทริบิวต์srcหรือsrcsetอย่าใช้แอตทริบิวต์ที่ไม่ใช่มาตรฐาน เช่นdata-srcที่ต้องใช้ JavaScript ในการแสดงผล เนื่องจากจะช้ากว่าอยู่เสมอ 9% ของหน้าเว็บบดบังรูปภาพ LCP ด้านหลังdata-srcเลือกใช้การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) มากกว่าการแสดงผลฝั่งไคลเอ็นต์ (CSR) เนื่องจาก SSR บ่งบอกว่ามาร์กอัปแบบเต็มหน้า (รวมถึงรูปภาพ) มีอยู่ในซอร์ส HTML โซลูชัน CSR ต้องใช้ JavaScript ในการเรียกใช้ก่อนจึงจะค้นพบรูปภาพได้
หากต้องการอ้างอิงรูปภาพจากไฟล์ CSS หรือ JS ภายนอก คุณจะยังคงใส่รูปภาพดังกล่าวในต้นฉบับ HTML ผ่านแท็ก
<link rel="preload">ได้ โปรดทราบว่าตัวสแกนการโหลดล่วงหน้าของเบราว์เซอร์จะค้นหารูปภาพที่อ้างถึงโดยรูปแบบแทรกในบรรทัดไม่ได้ ดังนั้น แม้ว่าจะพบรูปภาพดังกล่าวในซอร์ส HTML แต่การค้นหารูปภาพอาจยังคงถูกบล็อกขณะโหลดทรัพยากรอื่นๆ ดังนั้นการโหลดล่วงหน้าจะช่วยได้ในกรณีเหล่านี้
Lighthouse จะเปิดตัวการตรวจสอบใหม่ในเวอร์ชัน 10.0 (คาดว่าในเดือนมกราคม 2023) เพื่อช่วยให้คุณเข้าใจว่ารูปภาพ LCP มีปัญหาเกี่ยวกับการค้นพบหรือไม่
การตรวจสอบว่าทรัพยากร LCP ค้นพบได้จากแหล่งที่มา HTML จะนำไปสู่การปรับปรุงที่วัดผลได้ และยังปลดล็อกโอกาสเพิ่มเติมในการจัดลำดับความสำคัญของทรัพยากร ซึ่งถือเป็นคำแนะนำถัดไปของเรา
ตรวจสอบว่าทรัพยากร LCP มีการจัดลำดับความสำคัญ
การตรวจสอบว่าทรัพยากร LCP ค้นพบได้จากแหล่งที่มา HTML เป็นขั้นตอนแรกที่สำคัญในการทำให้ทรัพยากร LCP เริ่มโหลดตั้งแต่เนิ่นๆ ได้ แต่อีกขั้นตอนที่สำคัญคือการตรวจสอบว่าการโหลดทรัพยากรนั้นจัดลำดับความสำคัญและไม่ได้อยู่คิวหลังทรัพยากรอื่นๆ ที่สำคัญน้อยกว่า
ตัวอย่างเช่น แม้ว่ารูปภาพ LCP จะแสดงในซอร์ส HTML โดยใช้แท็ก <img> มาตรฐาน แต่หากหน้าเว็บมีแท็ก <script> 10 แท็กใน <head> ของเอกสารก่อนแท็ก <img> ทรัพยากรรูปภาพอาจใช้เวลาสักพักจะเริ่มโหลด
วิธีที่ง่ายที่สุดในการแก้ไขปัญหานี้คือการให้คำแนะนำแก่เบราว์เซอร์ว่าทรัพยากรใดมีลำดับความสำคัญสูงสุดโดยการตั้งค่าแอตทริบิวต์ fetchpriority="high" ใหม่ในแท็ก <img> หรือ <link> ที่โหลดรูปภาพ LCP ซึ่งจะเป็นการสั่งให้เบราว์เซอร์โหลดได้เร็วขึ้น แทนที่จะต้องรอให้สคริปต์เหล่านั้นดำเนินการเสร็จสมบูรณ์
ตามข้อมูลในเว็บ Almanac มีหน้าเว็บที่มีสิทธิ์เพียง 0.03% เท่านั้นที่ใช้ประโยชน์จาก API ใหม่นี้ ซึ่งหมายความว่าเว็บไซต์ส่วนใหญ่บนเว็บยังมีโอกาสมากมายในการปรับปรุง LCP โดยทำงานเพียงเล็กน้อย แม้ว่าขณะนี้จะรองรับแอตทริบิวต์ fetchpriority เฉพาะในเบราว์เซอร์แบบ Chromium แต่ API นี้เป็นการเพิ่มประสิทธิภาพแบบต่อเนื่องที่เบราว์เซอร์อื่นๆ จะไม่สนใจ ดังนั้นเราจึงแนะนำอย่างยิ่งให้นักพัฒนาซอฟต์แวร์ใช้ตั้งแต่ตอนนี้
สำหรับเบราว์เซอร์ที่ไม่ใช่ Chromium วิธีเดียวที่จะทำให้ทรัพยากร LCP มีลำดับความสำคัญเหนือทรัพยากรอื่นๆ คือการอ้างอิงทรัพยากรดังกล่าวก่อนหน้าในเอกสาร ใช้ตัวอย่างอีกครั้งของเว็บไซต์ที่มีแท็ก <script> จำนวนมากใน <head> ของเอกสาร หากต้องการตรวจสอบว่าทรัพยากร LCP มีความสำคัญก่อนทรัพยากรสคริปต์เหล่านั้น ให้เพิ่มแท็ก <link rel="preload"> ก่อนสคริปต์ทั้งหมด หรือย้ายสคริปต์เหล่านั้นไปอยู่ใต้ <img> ในภายหลังก็ได้<body> แม้จะใช้งานได้แต่ก็ทำงานได้ตามหลักการยศาสตร์น้อยกว่าการใช้ fetchpriority เราจึงหวังว่าเบราว์เซอร์อื่นๆ จะเพิ่มการรองรับได้ในเร็วๆ นี้
ปัจจัยสำคัญอีกประการของการจัดลำดับความสำคัญทรัพยากร LCP คือไม่ต้องดำเนินการใดๆ ที่ทำให้ทรัพยากรดังกล่าวลดลำดับความสำคัญ เช่น การเพิ่มแอตทริบิวต์ loading="lazy" ปัจจุบัน 10% ของหน้าเว็บตั้งค่า loading="lazy" ในรูปภาพ LCP โปรดระมัดระวังโซลูชันการเพิ่มประสิทธิภาพรูปภาพที่มีการใช้ลักษณะการโหลดแบบ Lazy Loading กับรูปภาพทั้งหมดอย่างชัดแจ้ง หากมีวิธีลบล้างลักษณะการทำงานดังกล่าว ให้ใช้แอตทริบิวต์ดังกล่าวสำหรับรูปภาพ LCP หากไม่แน่ใจว่ารูปภาพใดจะเป็น LCP ให้ลองใช้การเรียนรู้ที่สมเหตุสมผลเพื่อเลือกคำที่แนะนำที่สมเหตุสมผล
การเลื่อนทรัพยากรที่ไม่สำคัญเป็นอีกวิธีหนึ่งในการเพิ่มลำดับความสำคัญที่เกี่ยวข้องของทรัพยากร LCP ได้อย่างมีประสิทธิภาพ ตัวอย่างเช่น คุณสามารถเลื่อนสคริปต์ที่ไม่ได้ขับเคลื่อนอินเทอร์เฟซผู้ใช้ (เช่น สคริปต์ข้อมูลวิเคราะห์หรือวิดเจ็ตโซเชียล) ออกไปได้อย่างปลอดภัยจนกว่าเหตุการณ์ load จะเริ่มทํางาน เพื่อให้มั่นใจว่าสคริปต์จะไม่แข่งขันกับทรัพยากรสําคัญอื่นๆ (เช่น ทรัพยากร LCP) สําหรับแบนด์วิดท์เครือข่าย
สรุปก็คือ คุณควรทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อโหลดทรัพยากร LCP ก่อนและมีลำดับความสำคัญสูง
- เพิ่ม
fetchpriority="high"ลงในแท็ก<img>ของรูปภาพ LCP หากโหลดทรัพยากร LCP ผ่านแท็ก<link rel="preload">ก็ไม่ต้องกังวลไป เพราะคุณจะตั้งค่าfetchpriority="high"ในนั้นได้ด้วย - อย่าตั้งค่า
loading="lazy"ในแท็ก<img>ของรูปภาพ LCP การทำเช่นนี้จะลดลำดับความสำคัญของรูปภาพ และหน่วงเวลาเมื่อเริ่มโหลด - เลื่อนทรัพยากรที่ไม่สำคัญออกไปเมื่อเป็นไปได้ ย้ายไปท้ายเอกสาร ใช้การโหลดแบบ Lazy Loading เนทีฟสำหรับรูปภาพหรือ iframe หรือโหลดแบบไม่พร้อมกันผ่าน JavaScript
ใช้ CDN เพื่อเพิ่มประสิทธิภาพ TTFB ของเอกสารและทรัพยากร
คำแนะนำ 2 ข้อก่อนหน้านี้ที่มุ่งเน้นในการทำให้ผู้ชมค้นพบทรัพยากร LCP ตั้งแต่เนิ่นๆ และจัดลำดับความสำคัญเพื่อให้เริ่มโหลดได้ทันที ส่วนสุดท้ายของปริศนานี้คือการตรวจสอบว่าเอกสารฉบับแรกตอบกลับเร็วที่สุดด้วย
เบราว์เซอร์ไม่สามารถเริ่มโหลดทรัพยากรย่อยจนกว่าจะได้รับไบต์แรกของการตอบกลับเอกสาร HTML แรก และยิ่งเกิดขึ้นเร็วเท่าใด อย่างอื่นก็จะเริ่มเร็วขึ้นตามไปด้วย
เวลานี้เรียกว่าเวลาที่เกิดไบต์แรก (TTFB) และวิธีที่ดีที่สุดในการลด TTFB คือข้อใด
- แสดงเนื้อหาของคุณใกล้กับผู้ใช้มากที่สุด
- แคชเนื้อหาดังกล่าวเพื่อให้เนื้อหาที่ขอล่าสุดสามารถแสดงอีกครั้งได้อย่างรวดเร็ว
วิธีที่ดีที่สุดในการทำทั้ง 2 อย่างนี้คือใช้ CDN CDN จะกระจายทรัพยากรของคุณไปยังเซิร์ฟเวอร์ Edge Server ซึ่งกระจายอยู่ทั่วโลก ซึ่งจะจำกัดระยะทางในการเดินสายไฟของผู้ใช้ นอกจากนี้ CDN มักมีการควบคุมการแคชแบบละเอียดซึ่งปรับแต่งและเพิ่มประสิทธิภาพให้เหมาะกับความต้องการของเว็บไซต์ได้
นักพัฒนาซอฟต์แวร์จำนวนมากคุ้นเคยกับการใช้ CDN เพื่อโฮสต์เนื้อหาแบบคงที่ แต่ CDN สามารถแสดงและแคชเอกสาร HTML ได้ด้วย แม้จะเป็นเอกสารที่สร้างขึ้นแบบไดนามิกก็ตาม
ตามข้อมูลในเว็บ Almanac ระบุว่ามีคำขอเอกสาร HTML เพียง 29% จาก CDN ซึ่งหมายความว่าเว็บไซต์มีโอกาสสูงที่จะประหยัดค่าใช้จ่ายได้มากขึ้น
เคล็ดลับบางอย่างในการกำหนดค่า CDN มีดังนี้
- พิจารณาเพิ่มระยะเวลาการแคชเนื้อหา (เช่น จำเป็นไหมที่เนื้อหาจะต้องใหม่เสมอ หรืออาจล้าสมัยไป 2-3 นาที)
- คุณอาจพิจารณาแคชเนื้อหาไปเรื่อยๆ แล้วล้างแคชออกถาวรหากมีการอัปเดต
- ดูว่าคุณสามารถย้ายตรรกะแบบไดนามิกที่ทำงานอยู่ในเซิร์ฟเวอร์ต้นทางไปยัง EDGE (ฟีเจอร์ของ CDN ที่ทันสมัยส่วนใหญ่) ได้หรือไม่
โดยทั่วไปแล้ว เมื่อใดก็ตามที่คุณสามารถแสดงเนื้อหาจาก Edge โดยตรง (โดยไม่ต้องเดินทางไปยังเซิร์ฟเวอร์ต้นทาง) ก็ถือว่ามีประสิทธิภาพดีเยี่ยมแล้ว และแม้กระทั่งในกรณีที่คุณต้องต้องเดินทางกลับไปที่เซิร์ฟเวอร์ต้นทางของคุณ โดยทั่วไปแล้ว CDN จะได้รับการเพิ่มประสิทธิภาพให้ทำงานดังกล่าวได้เร็วกว่ามาก จึงเป็นเรื่องที่เหนือกว่า
Cumulative Layout Shift (CLS)
คำแนะนำชุดถัดไปมีไว้สำหรับ Cumulative Layout Shift (CLS) ซึ่งเป็นการวัดความเสถียรของภาพในหน้าเว็บ แม้ว่า CLS จะเพิ่มขึ้นอย่างมากบนเว็บมาตั้งแต่ปี 2020 แต่เว็บไซต์ประมาณ 1 ใน 4 ที่ยังคงไม่เป็นไปตามเกณฑ์ที่แนะนำ จึงยังคงมีโอกาสสูงที่เว็บไซต์จำนวนมากจะปรับปรุงประสบการณ์ของผู้ใช้ได้
กำหนดขนาดที่อาจไม่เหมาะสมสำหรับเนื้อหาที่โหลดจากหน้าเว็บ
การเปลี่ยนเลย์เอาต์มักเกิดขึ้นเมื่อเนื้อหาที่มีอยู่ย้ายที่หลังจากเนื้อหาอื่นๆ โหลดเสร็จแล้ว ดังนั้น วิธีหลักในการลดปัญหานี้คือการจองพื้นที่ที่จำเป็นล่วงหน้าให้ได้มากที่สุด
วิธีที่ง่ายที่สุดในการแก้ไขการเปลี่ยนเลย์เอาต์ที่เกิดจากรูปภาพที่ไม่มีขนาดคือตั้งค่าแอตทริบิวต์ width และ height อย่างชัดแจ้ง (หรือคุณสมบัติ CSS ที่เทียบเท่า) อย่างไรก็ตาม ที่เก็บถาวรของ HTTP ระบุว่า 72% ของหน้าเว็บมีรูปภาพที่ไม่มีขนาดอย่างน้อย 1 รูป หากไม่มีขนาดที่ชัดเจน เบราว์เซอร์จะตั้งค่าความสูงเริ่มต้นไว้ที่ 0px และอาจทำให้เกิดการเปลี่ยนเลย์เอาต์ที่สังเกตเห็นได้ชัดเจนเมื่อโหลดรูปภาพเสร็จในขั้นสุดท้ายและค้นพบขนาดแล้ว ซึ่งนับเป็นทั้งโอกาสใหญ่สำหรับเว็บไซต์ร่วม และโอกาสดังกล่าวนั้นต้องใช้ความพยายามน้อยกว่าคำแนะนำอื่นๆ ที่แนะนำในบทความนี้เป็นอย่างมาก
นอกจากนี้ รูปภาพไม่ได้เป็นเพียงภาพเดียวที่มีผลต่อ CLS การเปลี่ยนเลย์เอาต์อาจเกิดจากเนื้อหาอื่นๆ ที่ปกติแล้วจะโหลดหลังจากที่หน้าเว็บแสดงผลครั้งแรก ซึ่งรวมถึงโฆษณาของบุคคลที่สามหรือวิดีโอแบบฝัง ซึ่งพร็อพเพอร์ตี้ aspect-ratio จะช่วยจัดการกับเรื่องนี้ได้ นี่เป็นฟีเจอร์ใหม่ของ CSS ที่ช่วยให้นักพัฒนาซอฟต์แวร์สามารถระบุสัดส่วนภาพอย่างชัดเจน รวมถึงองค์ประกอบที่ไม่ใช่รูปภาพได้ ซึ่งจะช่วยให้คุณตั้งค่า width แบบไดนามิกได้ (เช่น ตามขนาดหน้าจอ) และกำหนดให้เบราว์เซอร์คำนวณความสูงที่เหมาะสมโดยอัตโนมัติเช่นเดียวกับการคำนวณสำหรับรูปภาพที่มีขนาด
บางครั้ง เราไม่ทราบขนาดที่แน่นอนของเนื้อหาแบบไดนามิกได้ เนื่องจากเป็นเนื้อหาแบบไดนามิกโดยธรรมชาติ อย่างไรก็ตาม แม้ว่าจะไม่ทราบขนาดที่แน่นอน แต่คุณก็ยังทำตามขั้นตอนเพื่อลดความรุนแรงของการเปลี่ยนเลย์เอาต์ได้ การตั้งค่า min-height ที่เหมาะสมมักจะดีกว่าการอนุญาตให้เบราว์เซอร์ใช้ความสูงเริ่มต้น 0px สำหรับองค์ประกอบว่าง นอกจากนี้ การใช้ min-height ยังเป็นวิธีที่แก้ปัญหาได้ง่าย เนื่องจากยังคงช่วยให้คอนเทนเนอร์เพิ่มตามความสูงของเนื้อหาได้หากจำเป็น เนื่องจากเป็นเพียงการลดปริมาณการเติบโตจากข้อมูลทั้งหมดเป็นระดับที่ยอมรับได้มากขึ้น
ตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้ bfcache
เบราว์เซอร์ใช้กลไกการนำทางที่เรียกว่า back/Forward Cache หรือที่เรียกสั้นๆ ว่า bfcache เพื่อโหลดหน้าในประวัติเบราว์เซอร์ก่อนหน้านี้หรือในภายหลังได้โดยตรงจากสแนปชอตหน่วยความจำ
Bfcache เป็นการเพิ่มประสิทธิภาพการทำงานที่สำคัญในระดับเบราว์เซอร์ และจะลบการเปลี่ยนเลย์เอาต์ระหว่างการโหลดหน้าเว็บอย่างสิ้นเชิง ซึ่งสำหรับหลายๆ เว็บไซต์เป็นจุดที่ CLS ส่วนใหญ่เกิดขึ้น การเปิดตัว bfcache ทำให้เกิดการพัฒนาครั้งใหญ่ที่สุดใน CLS ที่เราเห็นในปี 2022
อย่างไรก็ตาม เว็บไซต์จำนวนมากไม่มีสิทธิ์ใช้งาน bfcache จึงพลาดประสิทธิภาพเว็บฟรีที่จะได้รับสำหรับการนำทางเป็นจำนวนมาก เว้นแต่หน้าเว็บจะโหลดข้อมูลที่ละเอียดอ่อนซึ่งคุณไม่ต้องการให้กู้คืนจากหน่วยความจำ คุณจะต้องตรวจสอบว่าหน้าเว็บมีสิทธิ์
เจ้าของเว็บไซต์ควรตรวจสอบว่าหน้าเว็บของตนเองมีสิทธิ์ใช้ Bfcache หรือไม่และพยายามหาสาเหตุว่าทำไมหน้าเหล่านั้นจึงไม่มีสิทธิ์ Chrome มีผู้ทดสอบ bfcache ใน DevTools อยู่แล้ว และในปีนี้เราวางแผนที่จะปรับปรุงเครื่องมือที่นี่ด้วยการตรวจสอบใหม่ของ Lighthouse ที่ทำการทดสอบที่คล้ายกัน และ API เพื่อวัดเรื่องนี้ในระบบ
แม้ว่าเราจะรวม bfcache ไว้ในส่วน CLS แล้ว แต่จนถึงตอนนี้ bfcache ได้รับประโยชน์สูงสุด แต่โดยทั่วไปแล้ว bfcache จะช่วยปรับปรุง Core Web Vitals อื่นๆ ด้วย ซึ่งเป็นการไปยังส่วนต่างๆ แบบทันทีจำนวนมากที่มีให้ใช้งานเพื่อปรับปรุงการนำทางหน้าเว็บอย่างมาก
หลีกเลี่ยงภาพเคลื่อนไหว/การเปลี่ยนภาพที่ใช้คุณสมบัติ CSS ที่ทำให้เกิดเลย์เอาต์
สาเหตุทั่วไปอีกประการหนึ่งของการเปลี่ยนเลย์เอาต์คือเมื่อองค์ประกอบเคลื่อนไหว เช่น แบนเนอร์คุกกี้หรือแบนเนอร์การแจ้งเตือนอื่นๆ ที่เลื่อนเข้ามาจากด้านบนหรือด้านล่างมักเป็นแบนเนอร์ของ CLS ซึ่งจะเป็นปัญหาอย่างยิ่งเมื่อแบนเนอร์เหล่านี้ผลักเนื้อหาอื่นๆ ออกไป แต่หากไม่เป็นเช่นนั้น การสร้างภาพเคลื่อนไหวก็อาจส่งผลกับ CLS ได้
แม้ว่าข้อมูล HTTP Archive จะไม่สามารถเชื่อมโยงภาพเคลื่อนไหวกับการเปลี่ยนเลย์เอาต์ได้อย่างแท้จริง แต่ข้อมูลก็แสดงให้เห็นว่าหน้าที่ทําให้พร็อพเพอร์ตี้ CSS ใดๆ เคลื่อนไหวซึ่งอาจส่งผลต่อเลย์เอาต์มีแนวโน้มที่จะ "ดี" น้อยลง 15% CLS มากกว่าหน้าเว็บโดยรวม พร็อพเพอร์ตี้บางรายการเชื่อมโยงกับ CLS ที่แย่กว่าพร็อพเพอร์ตี้อื่นๆ ตัวอย่างเช่น หน้าที่เคลื่อนไหวความกว้าง margin หรือ border มี "แย่" CLS มีอัตราการประเมินหน้าเว็บโดยรวมว่าแย่เกือบ 2 เท่า
ซึ่งอาจไม่น่าประหลาดใจเนื่องจากเมื่อใดก็ตามที่คุณเปลี่ยนหรือทำให้พร็อพเพอร์ตี้ CSS ใดก็ตามที่ทำให้เกิดเลย์เอาต์เคลื่อนไหว ก็จะทำให้เกิดการเปลี่ยนแปลงเลย์เอาต์และหากการเปลี่ยนแปลงเลย์เอาต์เหล่านั้นไม่ได้อยู่ภายใน 500 มิลลิวินาทีของการโต้ตอบของผู้ใช้ ก็จะส่งผลต่อ CLS
สิ่งที่นักพัฒนาซอฟต์แวร์บางคนอาจคาดไม่ถึงคือนี่เป็นเรื่องจริงแม้ในกรณีที่องค์ประกอบเกิดขึ้นนอกขั้นตอนของเอกสารปกติ ตัวอย่างเช่น องค์ประกอบที่อยู่ในตำแหน่งสัมบูรณ์ที่เคลื่อนไหว top หรือ left จะทำให้เกิดการเปลี่ยนเลย์เอาต์ แม้ว่าองค์ประกอบดังกล่าวจะไม่ได้ดันเนื้อหาอื่นๆ ไปรอบๆ ก็ตาม อย่างไรก็ตาม หากคุณทำให้ transform:translateX() หรือ transform:translateY() เป็นภาพเคลื่อนไหวแทนการทำให้ top หรือ left เคลื่อนไหว เบราว์เซอร์จะไม่อัปเดตเลย์เอาต์ของหน้า และจะไม่ทำให้เกิดการเปลี่ยนเลย์เอาต์ใดๆ
การเลือกใช้ภาพเคลื่อนไหวของคุณสมบัติ CSS ที่อัปเดตบนเธรดของคอมโพสิตของเบราว์เซอร์ได้นั้นเป็นแนวทางปฏิบัติแนะนำด้านประสิทธิภาพมานานแล้ว เพราะการเคลื่อนไหวนี้จะทำงานไปยัง GPU และหลุดออกจากเทรดหลัก และนอกจากจะเป็นแนวทางปฏิบัติแนะนำเกี่ยวกับประสิทธิภาพทั่วไปแล้ว ยังช่วยปรับปรุง CLS ได้ด้วย
ตามกฎทั่วไปแล้ว ห้ามทำให้พร็อพเพอร์ตี้ CSS เคลื่อนไหวหรือเปลี่ยนแปลงพร็อพเพอร์ตี้ CSS ใดๆ ที่กำหนดให้เบราว์เซอร์อัปเดตเลย์เอาต์หน้าเว็บ เว้นแต่คุณจะดำเนินการตอบสนองต่อการแตะหรือกดแป้นของผู้ใช้ (แต่ไม่ใช่ hover) และหากเป็นไปได้ แนะนำให้ใช้การเปลี่ยนภาพและภาพเคลื่อนไหวโดยใช้พร็อพเพอร์ตี้ CSS transform
การตรวจสอบของ Lighthouse จะหลีกเลี่ยงภาพเคลื่อนไหวที่ไม่ได้ทำการ Composite จะเตือนเมื่อหน้าเว็บเคลื่อนไหวคุณสมบัติ CSS ที่อาจช้า
First Input Delay (FID)
คำแนะนำชุดสุดท้ายของเรามีไว้สำหรับ First Input Delay (FID) ซึ่งเป็นการวัดการตอบสนองของหน้าเว็บต่อการโต้ตอบของผู้ใช้ แม้ว่าปัจจุบันเว็บไซต์ส่วนใหญ่บนเว็บได้คะแนนดีมากใน FID แต่เราได้บันทึกข้อบกพร่องของเมตริก FID ในอดีตและเราเชื่อว่ายังมีโอกาสมากมายที่เว็บไซต์จะปรับปรุงการตอบสนองโดยรวมต่อการโต้ตอบของผู้ใช้
เมตริก Interaction to Next Paint (INP) ใหม่ของเราอาจเป็นตัวต่อจาก FID และคำแนะนำทั้งหมดด้านล่างก็ใช้กับทั้ง FID และ INP ได้อย่างเท่าเทียมกัน เนื่องจากเว็บไซต์มีประสิทธิภาพแย่ INP ต่ำกว่า FID โดยเฉพาะอย่างยิ่งบนอุปกรณ์เคลื่อนที่ เราขอแนะนำให้นักพัฒนาซอฟต์แวร์พิจารณาคำแนะนำด้านการตอบสนองเหล่านี้อย่างจริงจัง แม้จะมี "ดี" ก็ตาม FID
หลีกเลี่ยงหรือแบ่งงานที่ใช้เวลานาน
งานคืองานที่เบราว์เซอร์ทำแยกกัน งานประกอบด้วยการแสดงผล เลย์เอาต์ การแยกวิเคราะห์ รวมถึงการคอมไพล์และการเรียกใช้สคริปต์ เมื่องานกลายเป็นงานที่ใช้เวลานาน ซึ่งก็คือเวลา 50 มิลลิวินาทีขึ้นไป งานจะบล็อกเทรดหลักไม่ให้ตอบสนองต่ออินพุตของผู้ใช้ได้อย่างรวดเร็ว
จากรายงานสรุปเว็บ มีหลักฐานมากมายที่ชี้ให้เห็นว่านักพัฒนาซอฟต์แวร์ยังสามารถทำสิ่งต่างๆ ได้มากขึ้นเพื่อหลีกเลี่ยงหรือหยุดทำงานที่ใช้เวลานาน แม้ว่าการแบ่งงานที่ยาวๆ อาจไม่ใช่เรื่องง่ายเท่ากับคำแนะนำอื่นๆ ในบทความนี้ แต่ก็ใช้ความพยายามน้อยกว่าเทคนิคอื่นๆ ที่ไม่ได้นำเสนอในบทความนี้
แม้ว่าคุณควรพยายามทำงานให้น้อยที่สุดเท่าที่จะเป็นไปได้ใน JavaScript เสมอ แต่คุณก็สามารถช่วยให้เธรดหลักทำงานได้ไม่น้อยโดยแบ่งงานที่ยาวให้เป็นงานเล็กๆ ซึ่งทําได้โดยตอบกลับเทรดหลักบ่อยๆ เพื่อให้การอัปเดตการแสดงผลและการโต้ตอบอื่นๆ ของผู้ใช้เกิดขึ้นเร็วขึ้น
อีกตัวเลือกหนึ่งคือการพิจารณาใช้ API เช่น isInputPending และ Scheduler API isInputPending คือฟังก์ชันที่แสดงผลค่าบูลีนที่ระบุว่าอินพุตของผู้ใช้รอดำเนินการหรือไม่ หากสตริงแสดงผล true คุณสามารถปล่อยให้เทรดหลักจัดการอินพุตของผู้ใช้ที่รอดำเนินการได้
API เครื่องจัดตารางเวลาเป็นวิธีขั้นสูงขึ้น ซึ่งช่วยให้คุณสามารถกำหนดเวลางานตามระบบการจัดลำดับความสำคัญ โดยพิจารณาว่างานที่ทำอยู่โดยผู้ใช้มองเห็นได้หรืออยู่ในเบื้องหลัง
การแบ่งงานที่ใช้เวลานานเป็นการเพิ่มโอกาสให้เบราว์เซอร์ทำงานสำคัญที่ผู้ใช้มองเห็นได้ เช่น การจัดการการโต้ตอบและการอัปเดตการแสดงผลใดๆ ที่เกิดขึ้น
หลีกเลี่ยง JavaScript ที่ไม่จำเป็น
แน่นอนว่าเว็บไซต์มีการจัดส่ง JavaScript มากกว่าที่เคย และเทรนด์จะไม่มีการเปลี่ยนแปลงใดๆ ในเร็วๆ นี้ การส่ง JavaScript มากเกินไปจะเป็นการสร้างสภาพแวดล้อมที่งานต่างๆ แข่งขันกันเพื่อดึงความสนใจของเทรดหลัก ซึ่งจะส่งผลต่อการตอบสนองของเว็บไซต์ได้อย่างแน่นอน โดยเฉพาะในช่วงเริ่มต้นที่สำคัญนี้
อย่างไรก็ตาม นี่ไม่ใช่ปัญหาที่แก้ไม่ได้ คุณจะมีตัวเลือกดังนี้
- ใช้เครื่องมือการครอบคลุมใน Chrome DevTools เพื่อค้นหาโค้ดที่ไม่ได้ใช้ในทรัพยากรของเว็บไซต์ การลดขนาดของทรัพยากรที่ต้องการในช่วงเริ่มต้นทำให้มั่นใจได้ว่าเว็บไซต์จะใช้เวลาน้อยลงในการแยกวิเคราะห์และคอมไพล์โค้ด ซึ่งทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานเบื้องต้นที่ราบรื่นยิ่งขึ้น
- บางครั้งโค้ดที่ไม่ได้ใช้งานซึ่งคุณพบว่าใช้เครื่องมือครอบคลุมจะมีเครื่องหมายว่า "ไม่ได้ใช้" เนื่องจากไม่ได้ดำเนินการในระหว่างการเริ่มต้น แต่ยังคงจำเป็นสำหรับฟังก์ชันบางอย่างในอนาคต นี่คือโค้ดที่คุณสามารถย้ายไปยัง Bundle แยกต่างหากผ่านการแยกโค้ด
- หากคุณใช้เครื่องจัดการแท็ก โปรดตรวจสอบแท็กเป็นระยะๆ เพื่อให้แน่ใจว่ามีการเพิ่มประสิทธิภาพแล้ว หรือแม้ว่าจะยังมีการใช้งานแท็กอยู่ คุณสามารถล้างแท็กเก่าที่มีโค้ดที่ไม่ได้ใช้งานออกเพื่อทำให้ JavaScript ของเครื่องจัดการแท็กมีขนาดเล็กลงและมีประสิทธิภาพมากขึ้น
หลีกเลี่ยงการอัปเดตการแสดงผลขนาดใหญ่
JavaScript ไม่ใช่สิ่งเดียวที่อาจส่งผลกระทบต่อการตอบสนองของเว็บไซต์ การแสดงภาพอาจเป็นงานประเภทหนึ่งที่ใช้ต้นทุนสูงอยู่แล้ว และเมื่อมีการอัปเดตการแสดงผลเป็นจำนวนมาก ก็อาจทำให้เว็บไซต์ตอบสนองต่อข้อมูลจากผู้ใช้ได้
การเพิ่มประสิทธิภาพการแสดงผลไม่ใช่กระบวนการที่ตรงไปตรงมา และมักจะขึ้นอยู่กับสิ่งที่คุณพยายามทำให้สำเร็จ อย่างไรก็ตาม มีบางสิ่งที่คุณทำได้เพื่อให้มั่นใจว่าการอัปเดตการแสดงผลนั้นสมเหตุสมผล และไม่กลายเป็นงานที่ใช้เวลานาน
- หลีกเลี่ยงการใช้
requestAnimationFrame()ในการทำงานที่ไม่มีภาพ ระบบจะจัดการการเรียกrequestAnimationFrame()ในช่วงการแสดงผลของลูปเหตุการณ์ และเมื่อทำงานมากเกินไปในขั้นตอนนี้ การอัปเดตการแสดงผลอาจล่าช้าได้ สิ่งสำคัญคืองานที่ทำด้วยrequestAnimationFrame()สงวนไว้สำหรับงานที่เกี่ยวข้องกับการอัปเดตการแสดงผลเท่านั้น - ทำให้ DOM มีขนาดเล็ก ขนาด DOM และความเข้มข้นของงานเลย์เอาต์จะสัมพันธ์กัน เมื่อโหมดแสดงภาพต้องอัปเดตการจัดวางสำหรับ DOM ที่มีขนาดใหญ่มาก การทำงานที่จำเป็นต้องคำนวณเลย์เอาต์ใหม่อาจเพิ่มขึ้นอย่างมาก
- ใช้การควบคุม CSS การควบคุม CSS ใช้พร็อพเพอร์ตี้ CSS
containซึ่งบอกวิธีการใช้งานเลย์เอาต์สำหรับคอนเทนเนอร์ที่ตั้งค่าพร็อพเพอร์ตี้containไว้ ซึ่งรวมถึงการแยกขอบเขตของเลย์เอาต์และการแสดงผลไปยังรูทที่เฉพาะเจาะจงใน DOM ด้วย กระบวนการนี้ไม่ใช่กระบวนการที่ง่ายเสมอไป แต่ด้วยการแยกพื้นที่ที่มีเลย์เอาต์ที่ซับซ้อน ออกมาเพื่อหลีกเลี่ยงการสร้างเลย์เอาต์และการแสดงภาพที่ไม่จำเป็น
บทสรุป
การปรับปรุงประสิทธิภาพของหน้าเว็บอาจดูเป็นเรื่องที่ยุ่งยาก โดยเฉพาะอย่างยิ่งเมื่อมีคำแนะนำมากมายทั่วทั้งอินเทอร์เน็ตที่ต้องพิจารณา อย่างไรก็ตาม การมุ่งเน้นที่คำแนะนำเหล่านี้จะช่วยให้คุณแก้ไขปัญหาด้วยจุดโฟกัสและวัตถุประสงค์ได้ และหวังว่าจะช่วยเพิ่มประสิทธิภาพในการใช้ Core Web Vitals ของเว็บไซต์ได้
แม้ว่าคำแนะนำที่ระบุไว้ที่นี่ไม่ได้ครอบคลุมทั้งหมด แต่เราเชื่อว่าเมื่อพิจารณาจากการวิเคราะห์สถานะของเว็บอย่างรอบคอบแล้ว คำแนะนำเหล่านี้เป็นวิธีที่มีประสิทธิภาพมากที่สุดซึ่งเว็บไซต์จะปรับปรุงประสิทธิภาพของ Core Web Vitals ในปี 2023
หากคุณต้องการดูมากกว่าคำแนะนำที่ระบุไว้ที่นี่ คุณสามารถดูข้อมูลเพิ่มเติมได้จากคู่มือการเพิ่มประสิทธิภาพเหล่านี้
ปีใหม่แล้ว เว็บที่เร็วขึ้นสำหรับทุกคน! ขอให้เว็บไซต์ของคุณโหลดเร็วสำหรับผู้ใช้ในทุกด้านที่สำคัญที่สุด
รูปภาพโดย Devin Avery