Lighthouse เป็นเครื่องมืออัตโนมัติสำหรับปรับปรุงคุณภาพของเว็บไซต์ เพียงคุณใส่ URL แล้วก็จะให้รายการแนะนำวิธีปรับปรุงประสิทธิภาพของหน้าเว็บ ทำให้หน้าเว็บเข้าถึงได้ง่ายขึ้น ปฏิบัติตามแนวทางปฏิบัติแนะนำ และอีกมากมาย คุณสามารถเรียกใช้จากในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เป็นส่วนขยาย Chrome หรือแม้แต่เป็นโมดูลโหนดก็ได้ ซึ่งมีประโยชน์สำหรับการผสานรวมอย่างต่อเนื่อง
ในตอนนี้ Lighthouse ได้ให้คำแนะนำหลายอย่างในการปรับปรุงประสิทธิภาพในการโหลดหน้าเว็บ เช่น การเปิดใช้การบีบอัดข้อความหรือการลดสคริปต์ที่บล็อกการแสดงผล ทีม Lighthouse ยังส่งการตรวจสอบใหม่อย่างต่อเนื่องเพื่อให้คำแนะนำที่มีประโยชน์มากขึ้นในการทำให้เว็บไซต์เร็วขึ้น โพสต์นี้สรุปการตรวจสอบประสิทธิภาพที่มีประโยชน์ซึ่งคุณอาจไม่ทราบมาก่อน อย่างเช่น
- รายละเอียดเกี่ยวกับงานเทรดหลัก
- โหลดคำขอคีย์ล่วงหน้า
- เวลาเปิดเครื่อง JavaScript สูง
- หลีกเลี่ยงการเปลี่ยนเส้นทางหน้าเว็บ
- JavaScript ที่ไม่ได้ใช้
- ใช้นโยบายแคชที่ไม่มีประสิทธิภาพกับเนื้อหาแบบคงที่
- หลีกเลี่ยงการเดินทางไป-กลับที่มีราคาสูงหลายรอบในต้นทางใดก็ได้
- ใช้รูปแบบวิดีโอสำหรับเนื้อหาภาพเคลื่อนไหว
- ข้อความทั้งหมดจะยังมองเห็นได้ในระหว่างการโหลดเว็บฟอนต์
- CSS และ JavaScript ที่ไม่ย่อ
- กฎ CSS ที่ไม่ได้ใช้
รายละเอียดการทำงานเทรดหลัก
หากเคยใช้แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บมาก่อน ก็คงเป็นงานที่น่าเบื่อมากที่จะดูรายละเอียดว่าใช้เวลา CPU ไหนในการโหลดหน้าเว็บ เรายินดีที่จะแจ้งให้ทราบว่าขณะนี้ข้อมูลนี้พร้อมใช้งานได้อย่างสะดวกและง่ายดายแล้วผ่านการตรวจสอบรายละเอียดการทํางานของเทรดหลักใหม่
การวินิจฉัยแบบใหม่นี้จะประเมินจำนวนกิจกรรมและประเภทของกิจกรรมที่เกิดขึ้นระหว่างการโหลดหน้าเว็บ ซึ่งคุณใช้เพื่อจัดการกับปัญหาด้านประสิทธิภาพการโหลดที่เกี่ยวข้องกับเลย์เอาต์ การประเมินสคริปต์ การแยกวิเคราะห์ และกิจกรรมอื่นๆ ได้
โหลดคำขอคีย์ล่วงหน้า
เมื่อเบราว์เซอร์เรียกทรัพยากร เบราว์เซอร์ก็จะค้นหาการอ้างอิงภายในเอกสารและทรัพยากรย่อย การทำเช่นนี้อาจมีประสิทธิภาพไม่ดีในบางครั้งเนื่องจากมีการค้นพบทรัพยากรที่สำคัญบางส่วนมาแทนที่ในกระบวนการโหลดหน้าเว็บ โชคดีที่ rel=preload ช่วยให้นักพัฒนาซอฟต์แวร์สามารถบอกใบ้แก่เบราว์เซอร์ที่เป็นไปตามนโยบายว่าควรดึงข้อมูลทรัพยากรใดโดยเร็วที่สุด การตรวจสอบคำขอคีย์ล่วงหน้าแบบใหม่ช่วยให้นักพัฒนาแอปทราบว่าทรัพยากรใดอาจได้รับประโยชน์จากการโหลดเร็วขึ้นภายในวันที่ rel=preload
คุณจำเป็นต้องทดสอบและเปรียบเทียบการเปลี่ยนแปลงด้านประสิทธิภาพกับ rel=preload เนื่องจากการเปลี่ยนแปลงอาจส่งผลต่อประสิทธิภาพการโหลดในแบบที่คุณคาดไม่ถึง เช่น การโหลดรูปภาพขนาดใหญ่ล่วงหน้าอาจทำให้การแสดงผลเริ่มต้นล่าช้า แต่ข้อดีคือรูปภาพที่โหลดล่วงหน้าจะปรากฏในเลย์เอาต์เร็วขึ้น
ตรวจสอบให้แน่ใจเสมอว่าผลลัพธ์จะดีมาก
เวลาเปิดเครื่อง JavaScript สูง
เมื่อโหลด JavaScript มากเกินไป หน้าเว็บอาจไม่ตอบสนองเมื่อเบราว์เซอร์แยกวิเคราะห์ คอมไพล์ และดำเนินการ สคริปต์และโฆษณาของบุคคลที่สามเป็นแหล่งที่มาเฉพาะของกิจกรรมสคริปต์ที่มากเกินไป ซึ่งอาจทำให้อุปกรณ์ไม่ทำงานได้ การตรวจสอบเวลาในการเปิดเครื่อง JavaScript สูงแบบใหม่จะแสดงระยะเวลาที่ใช้ CPU ในแต่ละหน้าเว็บ รวมถึง URL ของสคริปต์นั้นๆ
เมื่อดำเนินการตรวจสอบนี้ คุณจะเปิดใช้ป้ายของบุคคลที่สามในแผงเครือข่ายและกรองรายการเพื่อระบุทรัพยากรสคริปต์ของบุคคลที่สามได้ด้วย ข้อมูลจากการตรวจสอบนี้จะทำให้คุณพร้อมค้นหาแหล่งที่มาของกิจกรรม JavaScript ที่มากเกินไปซึ่งจะเปลี่ยนหน้าต่างๆ จากไม่เร็วจนช้าๆ ได้ สำหรับสคริปต์เฉพาะสำหรับแอปพลิเคชัน คุณอาจใช้เทคนิคต่างๆ เช่น การแยกโค้ดและการเขย่าต้นไม้เพื่อจำกัดจำนวน JavaScript ในแต่ละหน้าของเว็บไซต์
หลีกเลี่ยงการเปลี่ยนเส้นทางหน้าเว็บ
บางครั้งเมื่อเบราว์เซอร์ขอ URL เซิร์ฟเวอร์อาจตอบกลับด้วยรหัสสถานะระดับ 300 ซึ่งจะทำให้เบราว์เซอร์เปลี่ยนเส้นทางไปยัง URL อื่น แม้ว่าการเปลี่ยนเส้นทางเป็นสิ่งจำเป็นสำหรับ SEO และความสะดวก แต่ก็เพิ่มเวลาในการตอบสนองให้คำขอด้วย โดยเฉพาะอย่างยิ่งหากเปลี่ยนเส้นทางไปยังต้นทางอื่นๆ ซึ่งอาจทำให้การค้นหา DNS และใช้เวลาเจรจาเพิ่มเติมกับการเชื่อมต่อ/TLS
การเปลี่ยนเส้นทางนั้นไม่เป็นที่ต้องการสำหรับหน้า Landing Page ในเว็บไซต์ของคุณ ตอนนี้ Lighthouse ได้มีการตรวจสอบหลีกเลี่ยงการเปลี่ยนเส้นทางหน้าเว็บเพื่อช่วยลดเวลาในการตอบสนองและปรับปรุงประสิทธิภาพการโหลด ซึ่งจะแจ้งให้คุณทราบเมื่อการนำทางทริกเกอร์การเปลี่ยนเส้นทาง
โปรดทราบว่าการตรวจสอบนี้จะทริกเกอร์ใน Lighthouse เวอร์ชันสำหรับ DevTools ได้ยาก เนื่องจากการตรวจสอบนี้จะวิเคราะห์ URL ปัจจุบันในแถบที่อยู่ของหน้าเว็บ ซึ่งจะแสดงความละเอียดของการเปลี่ยนเส้นทางทั้งหมด คุณน่าจะเห็นการตรวจสอบนี้ปรากฏใน Node CLI
JavaScript ที่ไม่ได้ใช้
โค้ดที่ใช้งานไม่ได้อาจเป็นปัญหาร้ายแรงในแอปพลิเคชันที่มี JavaScript จำนวนมาก แม้ว่าวิธีนี้จะไม่ทำให้เกิดต้นทุนในการดําเนินการเนื่องจากไม่เคยเกิดขึ้น แต่ก็จะก่อให้เกิดผลกระทบที่ไม่พึงประสงค์อื่นๆ ด้วย เบราว์เซอร์จะยังคงดาวน์โหลด แยกวิเคราะห์ และคอมไพล์โค้ดที่เสียหายต่อไป ซึ่งมีผลต่อประสิทธิภาพการโหลดและเวลาที่ใช้ในการเปิดเครื่อง JavaScript การตรวจสอบ JavaScript ที่ไม่ได้ใช้นั้นคล้ายกับแผงการครอบคลุมในเครื่องมือสำหรับนักพัฒนาเว็บ โดยจะแสดง JavaScript ที่ดาวน์โหลดโดยหน้าปัจจุบัน แต่ไม่มีการใช้งาน
ด้วยการตรวจสอบนี้ คุณจะระบุโค้ดที่ใช้งานไม่ได้ในแอปพลิเคชันของคุณ และนำออกเพื่อปรับปรุงประสิทธิภาพการโหลดและลดการใช้ทรัพยากรของระบบ เคล็ดลับมือโปร: คุณยังใช้แผงการครอบคลุมโค้ดในเครื่องมือสำหรับนักพัฒนาเว็บของ Chrome เพื่อค้นหาข้อมูลนี้ได้ด้วย
ใช้นโยบายแคชที่ไม่มีประสิทธิภาพกับเนื้อหาคงที่
แม้ว่าคำแนะนำด้านประสิทธิภาพมักมุ่งเน้นที่การเพิ่มความเร็วของเว็บไซต์สำหรับผู้ใช้ครั้งแรก แต่คุณก็ควรใช้การแคชเพื่อปรับปรุงประสิทธิภาพการโหลดสำหรับผู้ใช้ที่กลับมาด้วย การใช้นโยบายแคชที่ไม่มีประสิทธิภาพเกี่ยวกับเนื้อหาแบบคงที่จะตรวจสอบส่วนหัวการแคชสำหรับทรัพยากรเครือข่าย และแจ้งให้คุณทราบหากนโยบายแคชสำหรับทรัพยากรแบบคงที่ต่ำกว่ามาตรฐาน
การตรวจสอบนี้จะช่วยให้คุณค้นหาและแก้ไขปัญหาเกี่ยวกับนโยบายแคชปัจจุบันได้อย่างง่ายดาย การทำเช่นนี้จะช่วยปรับปรุงประสิทธิภาพ สำหรับผู้ใช้ที่กลับมาได้อย่างมาก พวกเขาจะชื่นชอบความเร็วที่เพิ่มขึ้นด้วย!
หลีกเลี่ยงการเดินทางไป-กลับที่มีราคาสูงหลายๆ รอบไปยังต้นทางใดก็ได้
เมื่อเบราว์เซอร์เรียกทรัพยากรจากเซิร์ฟเวอร์ อาจใช้เวลานานในการค้นหา DNS และสร้างการเชื่อมต่อกับเซิร์ฟเวอร์
rel=preconnect ทำให้นักพัฒนาซอฟต์แวร์มาสก์เวลาในการตอบสนองนี้ได้ด้วยการสร้างการเชื่อมต่อกับเซิร์ฟเวอร์อื่นก่อนที่เบราว์เซอร์จะถึงกำหนดส่ง การตรวจสอบหลีกเลี่ยงการเดินทางหลายรอบในต้นทางที่หลากหลายจะช่วยให้คุณค้นพบโอกาสในการใช้ rel=preconnect!
rel=preconnect ใน Lighthouseเมื่อเวลาในการตอบสนองของเนื้อหาแบบข้ามต้นทางลดลง ผู้ใช้จะรู้สึกว่าสิ่งต่างๆ เปลี่ยนไปเร็วขึ้นเล็กน้อย การตรวจสอบ Lighthouse ใหม่นี้จะทำให้คุณได้เรียนรู้ถึงโอกาสใหม่ๆ ในการใช้ rel=preconnect เพื่อทำเช่นนั้น
ใช้รูปแบบวิดีโอสำหรับเนื้อหาภาพเคลื่อนไหว
GIF แบบเคลื่อนไหวใหญ่ ซึ่งมักจะใช้อย่างน้อยหลายร้อยกิโลไบต์ ถ้าไม่มีข้อมูลหลายเมกะไบต์ หากคุณสนใจเรื่องประสิทธิภาพการโหลด ก็ต้องแปลง GIF เหล่านั้นเป็นวิดีโอ โชคดีที่การตรวจสอบการใช้รูปแบบวิดีโอสำหรับเนื้อหาภาพเคลื่อนไหวช่วยได้
หากเว็บไซต์มี GIF ที่มีขนาดเกิน 100 KB การตรวจสอบนี้จะแจ้งว่าไม่เหมาะสมโดยอัตโนมัติและนำคุณไปยังคำแนะนำเกี่ยวกับวิธีแปลงเป็นวิดีโอและฝัง GIF ไว้ เว็บไซต์อย่าง Imgur ปรับปรุงประสิทธิภาพในการโหลดได้อย่างมากด้วยการแปลง GIF เป็นวิดีโอ นอกจากนี้ หากเว็บไซต์ใช้แพ็กเกจโฮสติ้งที่มีแบนด์วิดท์แบบจำกัดปริมาณ การประหยัดค่าใช้จ่ายที่เป็นไปได้เพียงอย่างเดียวก็อาจเพียงพอแล้วที่จะโน้มน้าวคุณ
ข้อความทั้งหมดจะยังมองเห็นได้ในระหว่างการโหลดแบบอักษรบนเว็บ
เมื่อเราโหลดแบบอักษรเว็บสำหรับหน้า เบราว์เซอร์มักจะแสดงข้อความที่มองไม่เห็นจนกว่าแบบอักษรจะโหลด ปรากฏการณ์นี้ที่รู้จักกันในชื่อ Flash of Invisible Text (FOIT)) อาจเหมาะกับคุณมากกว่าในแง่ของการออกแบบ แต่อันที่จริงมันเป็นปัญหาจริงๆ ข้อความที่ถูกบล็อกจากการแสดงผลจะไม่สามารถอ่านได้จนกว่าข้อความดังกล่าวจะแสดงผลและปรากฏให้เห็น ในกรณีที่มีเวลาในการตอบสนองสูงและ/หรือการเชื่อมต่อที่มีแบนด์วิดท์สูง จะหมายความว่าส่วนสำคัญของประสบการณ์ของผู้ใช้ขาดหายไป และยังอาจเป็นปัญหาด้านประสิทธิภาพทางการรับรู้ที่หน้าเว็บไม่แสดงเนื้อหาที่มีความหมายเร็วที่สุดเท่าที่ทำได้ โชคดีที่การตรวจสอบข้อความทั้งหมดยังคงแสดงให้เห็นระหว่างการโหลดแบบอักษรเว็บจะช่วยให้คุณพบโอกาสในการแก้ไขปัญหานี้ในเว็บไซต์
หาก Lighthouse พบแบบอักษรเว็บในแอปพลิเคชันที่ทำให้การแสดงผลข้อความล่าช้า ก็มีวิธีแก้ไขที่เป็นไปได้อยู่ 2-3 ข้อ คุณควบคุมการแสดงข้อความได้ด้วยพร็อพเพอร์ตี้ CSS font-display และ/หรือ Font Loading API
หากต้องการข้อมูลแบบเจาะลึก ลองอ่านคู่มือที่ครอบคลุมสำหรับกลยุทธ์การโหลดแบบอักษร ซึ่งเป็นคู่มือที่ยอดเยี่ยมจาก Zach Leatherman ซึ่งเป็นแหล่งข้อมูลที่ยอดเยี่ยมสำหรับการโหลดแบบอักษรที่เหมาะสม
CSS และ JavaScript ที่ไม่มีความละเอียด
การลดขนาดเป็นเทคนิคที่แนะนำมาเนื่องจากประสิทธิภาพของเว็บเป็นสิ่งสำคัญและด้วยเหตุผลที่ดี เครื่องมือนี้ลดขนาดทรัพยากรแบบข้อความได้อย่างมาก ซึ่งส่งผลดีต่อประสิทธิภาพในการโหลด อย่างไรก็ตาม คุณอาจมองข้ามการเพิ่มประสิทธิภาพนี้ไปได้ง่ายๆ โดยเฉพาะอย่างยิ่งหากกระบวนการสร้างไม่จัดการเรื่องนี้ให้คุณ การตรวจสอบ Minify CSS และ Minify JavaScript จะรวบรวมรายการทรัพยากรที่ยังไม่ถูกย่อซึ่งพบในหน้าปัจจุบัน จากตรงนั้น คุณสามารถลดขนาดไฟล์เหล่านั้นด้วยตนเอง หรือเสริมระบบบิลด์เพื่อสร้างให้คุณ
กฎ CSS ที่ไม่ได้ใช้
เมื่อเว็บไซต์ค่อนข้างยาว แหล่งที่มาของการใช้งานที่เกินความจำเป็นมาในรูปแบบของกฎ CSS ที่ไม่ได้ใช้ ซึ่งไม่จำเป็นต่อการทำงานของเว็บไซต์อีกต่อไป แต่ก็ยังใช้แบนด์วิดท์อยู่ การตรวจสอบกฎ CSS ที่ไม่ได้ใช้จะแสดงทรัพยากร CSS ในหน้าที่มี CSS ที่ไม่ได้ใช้เพื่อความสะดวก
หาก Lighthouse พบ CSS ที่ไม่ได้ใช้ในหน้าเว็บ ก็มีวิธีแก้ไขดังนี้ UnCSS เป็นเครื่องมือหนึ่งที่จะดำเนินการให้คุณโดยอัตโนมัติ (แต่ต้องใช้ด้วยความระมัดระวัง) วิธีการที่ต้องดำเนินการด้วยตนเองมากกว่าจะใช้แผงการครอบคลุมของโค้ดในเครื่องมือสำหรับนักพัฒนาเว็บ แต่อย่าลืมว่า CSS ที่ไม่ได้ใช้ในหน้าหนึ่งอาจจำเป็นในหน้าอื่น อีกวิธีหนึ่งคือการแยก CSS ออกเป็นไฟล์เฉพาะเทมเพลตซึ่งจะโหลดเมื่อจำเป็นเท่านั้น ไม่ว่าคุณจะตัดสินใจทำอะไร Lighthouse จะพร้อมช่วยให้คุณ รู้ว่า CSS ของคุณยากมากหรือไม่
ลองใช้ Lighthouse
หากตื่นเต้นกับการตรวจสอบใหม่เหล่านี้ ก็อัปเดต Lighthouse แล้วลองได้เลย
- ส่วนขยาย Lighthouse ของ Chrome ควรอัปเดตโดยอัตโนมัติ แต่คุณจะอัปเดตด้วยตนเองได้ผ่าน
chrome://extensions - ในเครื่องมือสำหรับนักพัฒนาเว็บ คุณจะเรียกใช้ Lighthouse ในแผงการตรวจสอบได้ Chrome จะอัปเดตเป็นเวอร์ชันใหม่ทุก 6 สัปดาห์โดยประมาณ ดังนั้นการตรวจสอบใหม่ๆ อาจไม่พร้อมใช้งาน หากไม่ต้องการใช้การตรวจสอบล่าสุดที่มีอยู่ คุณจะเรียกใช้โค้ด Chrome ล่าสุดได้โดยดาวน์โหลด Chrome Canary
- สำหรับผู้ใช้โหนด: เรียกใช้
npm update lighthouseหรือnpm update lighthouse -gหากคุณติดตั้ง Lighthouse ทั่วโลก
ขอขอบคุณเป็นพิเศษสำหรับ Kayce Basques, Patrick Hulce, Addy Osmani และ Vinamrata Singal สำหรับความคิดเห็นอันมีค่า ซึ่งช่วยปรับปรุงคุณภาพของบทความนี้ได้เป็นอย่างมาก