ชุดแนวทางปฏิบัติแนะนำที่ทีม Chrome DevRel เชื่อว่าเป็นวิธีที่มีประสิทธิภาพมากที่สุดในการปรับปรุงประสิทธิภาพ Core Web Vitals ในปี 2023
ตลอดหลายปีที่ผ่านมา Google ให้คำแนะนำหลายอย่างแก่นักพัฒนาเว็บเกี่ยวกับวิธีเพิ่มประสิทธิภาพ
แม้ว่าคำแนะนำเหล่านี้แต่ละรายการอาจช่วยปรับปรุงประสิทธิภาพสำหรับหลายๆ เว็บไซต์ได้ แต่คำแนะนำที่ครบถ้วนมีอยู่มากมายจนนับไม่ถ้วน และในความเป็นจริงแล้ว ไม่มีทางใดที่บุคคลหรือเว็บไซต์ใดจะทำตามคำแนะนำเหล่านี้ได้ทั้งหมด
หากประสิทธิภาพเว็บเป็นงานประจำวันของคุณ คงไม่มีอะไรชัดเจนว่าคำแนะนำใดจะมีผลดีมากที่สุดกับเว็บไซต์ของคุณ ตัวอย่างเช่น คุณอาจได้อ่านมาว่าการใช้ CSS ที่สำคัญช่วยปรับปรุงประสิทธิภาพในการโหลดได้ และคุณอาจได้ยินมาว่าการปรับแต่งรูปภาพเป็นสิ่งสำคัญ แต่ถ้าคุณไม่มีเวลาทำงานทั้ง 2 อย่าง คุณจะตัดสินใจเลือกฝ่ายไหนอย่างไร
ในทีม Chrome เราได้ใช้เวลาในช่วงปีที่ผ่านมาเพื่อตอบคำถามนี้ คำแนะนำที่สำคัญที่สุดที่เราสามารถมอบให้นักพัฒนาซอฟต์แวร์เพื่อช่วยปรับปรุงประสิทธิภาพสำหรับผู้ใช้ของตนมีอะไรบ้าง
เพื่อที่จะตอบคำถามนี้ได้อย่างเพียงพอ เราต้องพิจารณาทั้งข้อดีทางเทคนิคของคำแนะนำหนึ่งๆ เท่านั้น แต่ยังรวมถึงปัจจัยของมนุษย์และองค์กรที่มีอิทธิพลต่อความเป็นไปได้ที่นักพัฒนาแอปจะสามารถนำคำแนะนำเหล่านี้ไปใช้ได้จริง กล่าวอีกนัยหนึ่งคือ คำแนะนำบางรายการอาจมีผลกระทบอย่างมากในเชิงทฤษฎี แต่ในความเป็นจริงแล้ว มีเว็บไซต์ที่มีเวลาหรือทรัพยากรในการดำเนินการเพียงไม่กี่แห่ง ในทำนองเดียวกัน คำแนะนำบางรายการมีความสำคัญ แต่เว็บไซต์ส่วนใหญ่ก็ทำตามแนวทางปฏิบัติเหล่านี้อยู่แล้ว
สรุปคือ เราต้องการให้รายการคำแนะนำด้านประสิทธิภาพเว็บยอดนิยมมุ่งเน้นเรื่องต่อไปนี้
- คำแนะนำที่เราเชื่อว่าจะมีผลกระทบมากที่สุดในชีวิตจริง
- คำแนะนำที่มีความเกี่ยวข้องและใช้ได้กับเว็บไซต์ส่วนใหญ่
- คำแนะนำที่นำไปใช้ได้จริงเพื่อให้นักพัฒนาซอฟต์แวร์ส่วนใหญ่นำไปใช้ได้
ในปีที่ผ่านมา เราใช้เวลานานในการตรวจสอบคำแนะนำด้านประสิทธิภาพที่เราให้ไว้ทั้งหมด และประเมินคำแนะนำเหล่านั้น (ทั้งในเชิงคุณภาพและเชิงปริมาณ) กับเกณฑ์ 3 ข้อข้างต้น
โพสต์นี้สรุปคำแนะนำยอดนิยมของเราในการปรับปรุงประสิทธิภาพของเมตริก Core Web Vitals แต่ละรายการ หากคุณเพิ่งเริ่มใช้ประสิทธิภาพเว็บ หรือคุณกำลังพยายามตัดสินใจว่าอะไรจะให้ผลตอบแทนที่คุ้มค่ามากที่สุดสำหรับเงินที่ลงทุนไปได้ เราคิดว่าคำแนะนำเหล่านี้เป็นที่ที่ดีที่สุดสำหรับการเริ่มต้น
Largest Contentful Paint (LCP)
คำแนะนำชุดแรกของเรามีไว้สำหรับ Largest Contentful Paint (LCP) ซึ่งเป็นตัวชี้วัดประสิทธิภาพการโหลด จากเมตริก Core Web Vitals ทั้ง 3 รายการ จำนวน LCP คือรายการที่มีจำนวนเว็บไซต์มากที่สุด โดยมีเพียงประมาณครึ่งหนึ่งของเว็บไซต์ทั้งหมดบนเว็บในปัจจุบันที่มีคุณสมบัติตรงตามเกณฑ์ที่แนะนำ ดังนั้นมาเริ่มกันเลย
ตรวจสอบว่าค้นพบทรัพยากร LCP ได้จากซอร์ส HTML
จากข้อมูลของเว็บ Almanac ปี 2022 โดยที่เก็บถาวรของ HTTP พบว่าหน้าเว็บบนอุปกรณ์เคลื่อนที่ 72% มีรูปภาพเป็นองค์ประกอบ LCP ซึ่งหมายความว่าเว็บไซต์ส่วนใหญ่ที่ต้องการเพิ่มประสิทธิภาพ LCP จะต้องตรวจสอบว่ารูปภาพเหล่านั้นโหลดได้อย่างรวดเร็ว
สิ่งที่นักพัฒนาซอฟต์แวร์จำนวนมากอาจไม่ชัดเจนคือเวลาที่ใช้ในการโหลดรูปภาพเป็นเพียงส่วนหนึ่งของความท้าทายเท่านั้น ส่วนที่สำคัญอีกอย่างคือเวลาก่อนที่รูปภาพจะเริ่มโหลด และข้อมูลที่เก็บถาวรของ HTTP บ่งบอกว่าเป็นจุดที่ทำให้เว็บไซต์จํานวนมากเกิดขึ้นพร้อมกัน
ที่จริงแล้ว หน้าที่มีองค์ประกอบ 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 ซึ่งจะสั่งให้เบราว์เซอร์โหลดสคริปต์ก่อน แทนที่จะรอให้สคริปต์ทำงานเสร็จ
จากข้อมูลของ Web Almanac หน้าเว็บที่มีสิทธิ์มีเพียง 0.03% เท่านั้นที่ใช้ประโยชน์จาก API ใหม่นี้ ซึ่งหมายความว่าเว็บไซต์ส่วนใหญ่มีโอกาสมากมายที่จะปรับปรุง LCP โดยแทบไม่ต้องทำงานเลย แม้ว่าปัจจุบันแอตทริบิวต์ fetchpriority
จะรองรับเฉพาะในเบราว์เซอร์แบบ Chromium เท่านั้น แต่ API นี้เป็นการเพิ่มประสิทธิภาพแบบต่อเนื่องที่เบราว์เซอร์อื่นๆ ไม่สนใจ จึงขอแนะนำอย่างยิ่งให้นักพัฒนาแอปใช้ 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 ได้เช่นกัน แม้แต่เนื้อหาที่สร้างขึ้นแบบไดนามิก
จากข้อมูลของ Web Almanac คำขอเอกสาร HTML เพียง 29% ที่มาจาก CDN เท่านั้น ซึ่งหมายความว่าเว็บไซต์จะมีโอกาสจำนวนมากที่จะอ้างสิทธิ์การประหยัดค่าใช้จ่ายเพิ่มเติม
เคล็ดลับบางส่วนสำหรับการกำหนดค่า CDN มีดังนี้
- ลองเพิ่มระยะเวลาที่ระบบจะแคชเนื้อหาไว้ (เช่น การที่เนื้อหาสดใหม่อยู่เสมอเป็นเรื่องจำเป็นไหม หรืออาจไม่มีอัปเดต 2-3 นาที)
- ลองแคชเนื้อหาไปเรื่อยๆ แล้วล้างแคชหากคุณทำการอัปเดต
- สำรวจว่าคุณจะย้ายตรรกะแบบไดนามิกที่กำลังทำงานอยู่ในเซิร์ฟเวอร์ต้นทางไปยัง EDGE (ฟีเจอร์ของ CDN สมัยใหม่ส่วนใหญ่) ได้หรือไม่
โดยทั่วไปแล้ว เมื่อใดก็ตามที่คุณแสดงเนื้อหาได้โดยตรงจาก Edge (เพื่อหลีกเลี่ยงการเดินทางไปยังเซิร์ฟเวอร์ต้นทาง) ก็จะมีประสิทธิภาพสูงสุด และแม้กระทั่งในกรณีที่คุณต้องต้องเดินทางกลับไปหาเซิร์ฟเวอร์ต้นทาง แต่ CDN ก็จะได้รับการปรับให้ทำงานได้เร็วกว่านั้นมาก ดังนั้นคุณจะได้รับประโยชน์ทั้ง 2 อย่าง
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 จะช่วยปรับปรุง Core Web Vitals อื่นๆ ด้วย เป็นหนึ่งในการนำทางทันทีจำนวนหนึ่งที่ช่วยปรับปรุงการนำทางหน้าเว็บได้อย่างมาก
หลีกเลี่ยงภาพเคลื่อนไหว/การเปลี่ยนภาพที่ใช้คุณสมบัติ CSS ที่ทำให้เกิดเลย์เอาต์
แหล่งที่มาโดยทั่วไปอีกประการของการเปลี่ยนเลย์เอาต์คือเมื่อองค์ประกอบเคลื่อนไหว เช่น แบนเนอร์คุกกี้หรือแบนเนอร์การแจ้งเตือนแบบอื่นๆ ที่เลื่อนเข้ามาจากด้านบนหรือด้านล่างมักจะเป็นแบนเนอร์ที่ให้ CLS ด้วย ซึ่งเป็นปัญหาอย่างยิ่งเมื่อแบนเนอร์เหล่านี้ผลักดันเนื้อหาอื่นๆ ออกไป แต่แม้ว่าจะไม่ได้ทำ การสร้างภาพเคลื่อนไหวก็ยังคงส่งผลกระทบต่อ CLS ได้
แม้ว่าข้อมูลที่เก็บถาวรของ HTTP จะไม่สามารถเชื่อมโยงภาพเคลื่อนไหวกับการเปลี่ยนเลย์เอาต์ได้สรุป แต่ข้อมูลแสดงให้เห็นว่าหน้าที่เคลื่อนไหวคุณสมบัติ CSS ที่อาจส่งผลต่อเลย์เอาต์มีแนวโน้มน้อยกว่า 15% ที่จะมี CLS ในระดับ "ดี" เมื่อเทียบกับหน้าเว็บโดยรวม ที่พักบางแห่งมีความเชื่อมโยงกับ CLS ที่แย่กว่ารายการอื่นๆ เช่น หน้าที่สร้างภาพเคลื่อนไหว margin
หรือความกว้าง border
มี CLS เป็น "แย่" ในอัตราที่เกือบ 2 เท่าของดูว่าหน้าเว็บโดยรวมจะได้รับการประเมินว่าแย่
กรณีนี้อาจไม่น่าแปลกใจ เพราะเมื่อใดก็ตามที่คุณเปลี่ยนหรือทำให้พร็อพเพอร์ตี้ CSS ใดก็ตามที่ทำให้เกิดเลย์เอาต์เคลื่อนไหว จะทำให้เลย์เอาต์เกิดการเปลี่ยนแปลง และหากการเปลี่ยนเลย์เอาต์ไม่อยู่ในช่วง 500 มิลลิวินาทีของการโต้ตอบของผู้ใช้ ก็จะส่งผลต่อ CLS ด้วย
สิ่งที่น่าแปลกใจสำหรับนักพัฒนาแอปบางรายคือ กรณีนี้เกิดขึ้นจริงแม้จะมีการนำองค์ประกอบออกนอกโฟลว์เอกสารปกติก็ตาม เช่น องค์ประกอบที่อยู่ในตําแหน่งที่แน่นอนซึ่งทําให้ top
หรือ left
เคลื่อนไหวทําให้เลย์เอาต์เกิดการเปลี่ยนแปลง แม้ว่าจะไม่มีการดันเนื้อหาอื่นๆ ไปรอบๆ ก็ตาม อย่างไรก็ตาม หากคุณเลือกภาพเคลื่อนไหว transform:translateX()
หรือ transform:translateY()
แทนการทำให้ top
หรือ left
เคลื่อนไหว ก็จะไม่ทำให้เบราว์เซอร์อัปเดตเลย์เอาต์ของหน้าเว็บ ดังนั้นจึงไม่สร้างการเปลี่ยนแปลงใดๆ ของเลย์เอาต์
การเลือกใช้ภาพเคลื่อนไหวของคุณสมบัติ CSS ที่สามารถอัปเดตบนเทรด Compositor ของเบราว์เซอร์เป็นแนวทางปฏิบัติแนะนำด้านประสิทธิภาพมาอย่างยาวนาน เนื่องจากการย้ายที่ทำงานไปยัง GPU และอยู่นอกเทรดหลัก และนอกจากจะเป็นแนวทางปฏิบัติแนะนำด้านประสิทธิภาพโดยทั่วไปแล้ว ยังช่วยเพิ่ม CLS ได้อีกด้วย
ตามกฎทั่วไป ห้ามสร้างภาพเคลื่อนไหวหรือเปลี่ยนพร็อพเพอร์ตี้ CSS ใดๆ ที่กำหนดให้เบราว์เซอร์อัปเดตเลย์เอาต์หน้าเว็บ เว้นแต่คุณจะทำเพื่อตอบสนองต่อการแตะหรือการกดแป้นของผู้ใช้ (แต่ไม่ใช่ hover
) และหากเป็นไปได้ ให้เลือกใช้การเปลี่ยนและภาพเคลื่อนไหวโดยใช้พร็อพเพอร์ตี้ transform
ของ CSS
การตรวจสอบ Lighthouse คือการหลีกเลี่ยงภาพเคลื่อนไหวที่ไม่ได้ทำการ Composite จะเตือนเมื่อหน้าเว็บเคลื่อนไหวพร็อพเพอร์ตี้ CSS ที่อาจทำงานช้า
First Input Delay (FID)
คำแนะนำชุดล่าสุดของเรามีไว้สำหรับ First Input Delay (FID) ซึ่งเป็นการวัดการตอบสนองของหน้าเว็บต่อการโต้ตอบของผู้ใช้ แม้ว่าปัจจุบันเว็บไซต์ส่วนใหญ่บนเว็บจะได้รับคะแนนดีมากใน FID แต่เราก็บันทึกจุดบกพร่องของเมตริก FID ไว้ในอดีต และเราเชื่อว่าเว็บไซต์ยังมีโอกาสอีกมากมายในการปรับปรุงการตอบสนองโดยรวมต่อการโต้ตอบของผู้ใช้
เมตริก Interaction to Next Paint (INP) ใหม่ของเราอาจแทนที่ FID และคำแนะนำทั้งหมดด้านล่างใช้ได้กับทั้ง FID และ INP เนื่องจากเว็บไซต์บน INP นั้นมีประสิทธิภาพแย่กว่า FID โดยเฉพาะบนอุปกรณ์เคลื่อนที่ เราจึงขอแนะนำให้นักพัฒนาซอฟต์แวร์พิจารณาคำแนะนำด้านการตอบสนองเหล่านี้อย่างจริงจัง แม้ว่าจะมี FID ที่ "ดี" ก็ตาม
หลีกเลี่ยงหรือแบ่งงานที่ยาว
Tasks เป็นงานที่แยกเป็นส่วนๆ ซึ่งเบราว์เซอร์ทำ งานประกอบด้วยการแสดงผล การจัดวาง การแยกวิเคราะห์ การคอมไพล์ และการเรียกใช้สคริปต์ เมื่องานกลายเป็นงานที่ใช้เวลานาน กล่าวคือ 50 มิลลิวินาทีขึ้นไป งานจะบล็อกเทรดหลักไม่ให้ตอบสนองต่ออินพุตของผู้ใช้อย่างรวดเร็ว
ตาม Web Almanac มีหลักฐานมากมายที่ชี้ให้เห็นว่านักพัฒนาซอฟต์แวร์ควรทำสิ่งต่างๆ ให้มากขึ้นเพื่อหลีกเลี่ยงหรือแบ่งงานที่ใช้เวลานาน แม้ว่าการแบ่งงานที่ใช้เวลานานอาจไม่ใช่เรื่องง่ายเท่าคำแนะนำอื่นๆ ในบทความนี้ แต่ก็ใช้ความพยายามน้อยกว่าเทคนิคอื่นๆ ที่ไม่ได้นำเสนอในบทความนี้
แม้ว่าคุณควรพยายามทำงานให้น้อยที่สุดเท่าที่จะเป็นไปได้ใน JavaScript แต่คุณก็ช่วยเทรดหลักได้พอสมควรโดยแบ่งงานที่มีขนาดยาวออกเป็นงานเล็กๆ โดยการให้ผลตอบแทนไปยังเทรดหลักบ่อยๆ เพื่อให้การแสดงผลการอัปเดตและการโต้ตอบอื่นๆ ของผู้ใช้เกิดขึ้นเร็วขึ้น
อีกทางเลือกหนึ่งคือลองใช้ API เช่น isInputPending
และ Scheduler API isInputPending
คือฟังก์ชันที่แสดงผลค่าบูลีนที่ระบุว่าอินพุตของผู้ใช้รอดำเนินการอยู่หรือไม่ หากแสดงค่า true
คุณสามารถกลับไปยังเทรดหลักเพื่อจัดการข้อมูลที่ผู้ใช้รอดําเนินการได้
Scheduler API เป็นวิธีขั้นสูงกว่าซึ่งจะช่วยให้คุณกำหนดเวลางานตามระบบลำดับความสำคัญโดยพิจารณาว่างานที่ทำอยู่เป็นผู้ใช้ที่มองเห็นหรืออยู่เบื้องหลังหรือไม่
การแบ่งงานที่ใช้เวลานานๆ จะเป็นการเปิดโอกาสให้เบราว์เซอร์สามารถรองรับงานสำคัญที่ผู้ใช้มองเห็น เช่น การจัดการกับการโต้ตอบและการอัปเดตการแสดงผลที่เกิดขึ้น
หลีกเลี่ยง JavaScript ที่ไม่จำเป็น
ก็ไม่ต้องสงสัยเลยว่าเว็บไซต์ต่างๆ ส่ง JavaScript กันมากกว่าที่เคย และแนวโน้มนี้จะไม่มีการเปลี่ยนแปลงใดๆ ในไม่ช้า การส่ง JavaScript มากเกินไปจะเป็นการสร้างสภาพแวดล้อมที่งานต่างๆ ต้องแย่งความสนใจของเทรดหลัก ซึ่งส่งผลต่อการตอบสนองของเว็บไซต์ได้อย่างแน่นอน โดยเฉพาะอย่างยิ่งในช่วงเริ่มต้นช่วงสำคัญดังกล่าว
อย่างไรก็ตาม เรื่องนี้ไม่ใช่ปัญหาที่แก้ไม่ได้ คุณมีตัวเลือกดังนี้
- ใช้เครื่องมือการครอบคลุมใน Chrome DevTools เพื่อค้นหาโค้ดที่ไม่ได้ใช้ในทรัพยากรของเว็บไซต์ การลดขนาดของทรัพยากรที่คุณต้องการในช่วงเริ่มต้นช่วยให้คุณมั่นใจได้ว่าเว็บไซต์ของคุณจะใช้เวลาน้อยลงในการแยกวิเคราะห์และคอมไพล์โค้ด ซึ่งจะทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานเริ่มต้นที่ราบรื่นยิ่งขึ้น
- บางครั้งโค้ดที่ไม่มีการใช้งานที่คุณพบจากการใช้เครื่องมือการครอบคลุมจะมีข้อความเป็น "unused" เนื่องจากโค้ดดังกล่าวไม่ได้เรียกใช้ระหว่างการเริ่มต้น แต่ยังคงจำเป็นสำหรับบางฟังก์ชันในอนาคต ซึ่งจะเป็นโค้ดที่จะย้ายไปยัง Bundle แยกต่างหากได้ผ่านการแยกโค้ด
- หากคุณใช้เครื่องจัดการแท็ก อย่าลืมตรวจสอบแท็กเป็นระยะๆ เพื่อให้มั่นใจว่าแท็กได้รับการเพิ่มประสิทธิภาพแล้ว หรือแม้ว่าจะยังมีการใช้งานอยู่ก็ตาม คุณสามารถล้างแท็กเก่าที่มีโค้ดที่ไม่ได้ใช้งานออกเพื่อทำให้ JavaScript ของเครื่องจัดการแท็กมีขนาดเล็กลงและมีประสิทธิภาพมากขึ้น
หลีกเลี่ยงการอัปเดตการแสดงภาพขนาดใหญ่
JavaScript ไม่ใช่ปัจจัยเดียวที่อาจส่งผลต่อการตอบสนองของเว็บไซต์ได้ การแสดงภาพอาจเป็นงานที่มีราคาสูงโดยตัวมันเอง และเมื่อมีการอัปเดตการแสดงผลจำนวนมาก ก็อาจรบกวนความสามารถของเว็บไซต์ในการตอบสนองต่อข้อมูลจากผู้ใช้
การเพิ่มประสิทธิภาพการแสดงผลไม่ใช่กระบวนการที่ตรงไปตรงมา และมักจะขึ้นอยู่กับสิ่งที่คุณพยายามทำให้สำเร็จ อย่างไรก็ตาม มีบางสิ่งที่คุณทำได้เพื่อให้มั่นใจว่าการอัปเดตการแสดงผลของคุณสมเหตุสมผล และไม่แบ่งเป็นงานยาวๆ ดังนี้
- หลีกเลี่ยงการใช้
requestAnimationFrame()
สำหรับการทำงานที่ไม่มีภาพ ระบบจะจัดการการเรียกrequestAnimationFrame()
ในช่วงการแสดงผลของลูปเหตุการณ์ และเมื่อมีการทำงานมากเกินไปในขั้นตอนนี้ การอัปเดตการแสดงผลจึงอาจล่าช้า งานใดก็ตามที่คุณทำด้วยrequestAnimationFrame()
จะสงวนไว้สำหรับงานที่เกี่ยวข้องกับการอัปเดตการแสดงผลเท่านั้น - ทำให้ DOM มีขนาดเล็ก ขนาด DOM และความเข้มของงานเลย์เอาต์จะสัมพันธ์กัน เมื่อตัวแสดงผลต้องอัปเดตเลย์เอาต์สำหรับ DOM ที่มีขนาดใหญ่มาก งานที่ต้องทำในการคำนวณเลย์เอาต์ใหม่อาจเพิ่มขึ้นเป็นจำนวนมาก
- ใช้การกักเก็บ CSS การควบคุม CSS อาศัยพร็อพเพอร์ตี้
contain
ของ CSS ซึ่งให้คำแนะนำแก่เบราว์เซอร์เกี่ยวกับวิธีทำงานเลย์เอาต์สำหรับคอนเทนเนอร์ที่มีการตั้งค่าพร็อพเพอร์ตี้contain
ซึ่งรวมถึงการแยกขอบเขตของเลย์เอาต์และการแสดงผลไปยังรูทที่เฉพาะเจาะจงใน DOM ด้วย ในบางครั้ง กระบวนการดังกล่าวอาจทำได้ยาก แต่ด้วยการแยกพื้นที่ที่มีเลย์เอาต์ที่ซับซ้อน เพื่อช่วยลดภาระของการออกแบบและแสดงผลโดยไม่จำเป็น
บทสรุป
การปรับปรุงประสิทธิภาพของหน้าเว็บอาจดูเป็นงานที่ท้าทาย โดยเฉพาะอย่างยิ่งเนื่องจากมีคำแนะนำมากมายในเว็บที่ต้องพิจารณา อย่างไรก็ตาม การให้ความสำคัญกับคำแนะนำเหล่านี้จะช่วยให้คุณจัดการกับปัญหาได้อย่างตรงจุดและวัตถุประสงค์ และหวังว่าจะสร้างความเปลี่ยนแปลงให้กับ Core Web Vitals ของเว็บไซต์ได้
แม้ว่าคำแนะนำที่ระบุไว้ในที่นี้ไม่ได้ครอบคลุมทั้งหมด แต่เราก็เชื่อว่าคำแนะนำเหล่านี้จะเป็นวิธีที่มีประสิทธิภาพมากที่สุดที่เว็บไซต์จะปรับปรุงประสิทธิภาพ Core Web Vitals ได้ในปี 2023 โดยยึดตามการวิเคราะห์สถานะของเว็บอย่างระมัดระวัง
หากคุณต้องการใช้งานเพิ่มเติมจากคำแนะนำที่ระบุไว้ที่นี่ โปรดดูข้อมูลเพิ่มเติมต่อไปนี้ในคู่มือการเพิ่มประสิทธิภาพ
ขอเฉลิมฉลองปีใหม่และให้ทุกคนท่องเว็บได้เร็วขึ้น! ขอให้เว็บไซต์ของคุณโหลดเร็วสำหรับผู้ใช้ในทุกด้านที่สำคัญที่สุด
รูปภาพโดย Devin Avery