คำแนะนำยอดนิยมจาก Core Web Vitals ปี 2023

ชุดแนวทางปฏิบัติแนะนำที่ทีม 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 โดยยึดตามการวิเคราะห์สถานะของเว็บอย่างระมัดระวัง

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

• เพิ่มประสิทธิภาพ LCP
• เพิ่มประสิทธิภาพ CLS
• เพิ่มประสิทธิภาพ FID
• เพิ่มประสิทธิภาพ INP

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

รูปภาพโดย Devin Avery