Lighthouse: เพิ่มความเร็วเว็บไซต์

Kayce Basques

Twitter GitHub กลิทช์

Sofia Emelianova

GitHub

เป้าหมายของบทแนะนำ

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

อ่านต่อหรือดูวิดีโอบทแนะนำนี้

วิดีโอนี้สร้างด้วย Chrome 68 รายละเอียดส่วนใหญ่ยังคงเป็นจริงอยู่ แต่บางฟีเจอร์ได้รับการอัปเดต ตัวอย่างเช่น แผงการตรวจสอบเปลี่ยนชื่อเป็น Lighthouse และมีรูปลักษณ์ที่ต่างออกไป แต่ตัวเลือกเดียวกันทั้งหมดจะยังคงใช้ได้อยู่

ข้อกำหนดเบื้องต้น

คุณจะต้องมีประสบการณ์การพัฒนาเว็บขั้นพื้นฐาน ซึ่งคล้ายกับสิ่งที่สอนในชั้นเรียนความรู้เบื้องต้นเกี่ยวกับการพัฒนาเว็บนี้

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

เกริ่นนำ

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

เจ้าเหมียวโทนี

ขั้นตอนที่ 1: ตรวจสอบเว็บไซต์

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

• ซึ่งจะสร้างเกณฑ์พื้นฐานเพื่อให้คุณใช้วัดการเปลี่ยนแปลงที่ตามมา
• และมอบเคล็ดลับที่นำไปใช้ได้จริงว่าการเปลี่ยนแปลงใดจะมีผลกระทบมากที่สุด

ตั้งค่า

ก่อนอื่น คุณต้องตั้งค่าสภาพแวดล้อมการทำงานใหม่สำหรับเว็บไซต์ของ Toy เพื่อให้คุณทำการเปลี่ยนแปลงในภายหลังได้

1. รีมิกซ์โปรเจ็กต์ของเว็บไซต์ใน Glitch โปรเจ็กต์ใหม่จะเปิดขึ้นในแท็บ แท็บนี้จะเรียกว่าแท็บตัวแก้ไข

   

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

2. ที่ด้านล่างของแท็บตัวแก้ไข ให้คลิกแสดงตัวอย่าง > แสดงตัวอย่างในหน้าต่างใหม่ เดโมจะเปิดขึ้นในแท็บใหม่ แท็บนี้จะเรียกว่าแท็บสาธิต อาจใช้เวลาสักพักกว่าเว็บไซต์จะโหลด

   

3. เปิดเครื่องมือสำหรับนักพัฒนาเว็บข้างๆ การสาธิต

   

ประเด็นสำคัญ: ภาพหน้าจอที่เหลือในบทแนะนำนี้ เครื่องมือสำหรับนักพัฒนาเว็บจะแสดงอยู่ในหน้าต่างแยกต่างหาก

สร้างเกณฑ์พื้นฐาน

เกณฑ์พื้นฐานคือบันทึกประสิทธิภาพของเว็บไซต์ก่อนที่คุณจะทำการปรับปรุงประสิทธิภาพใดๆ

1. เปิดแผง Lighthouse อาจซ่อนอยู่หลัง แผงเพิ่มเติม

   หมายเหตุ: แผงนี้ขับเคลื่อนโดย Lighthouse ซึ่งเป็นเครื่องมืออัตโนมัติสำหรับปรับปรุงคุณภาพเว็บแอป

   

2. ปรับการกำหนดค่ารายงาน Lighthouse ให้ตรงกับในภาพหน้าจอ คำอธิบายตัวเลือกต่างๆ มีดังนี้

   • ล้างพื้นที่เก็บข้อมูล การเปิดใช้ช่องทำเครื่องหมายนี้จะล้างพื้นที่เก็บข้อมูลทั้งหมดที่เชื่อมโยงกับหน้านี้ก่อนการตรวจสอบทุกครั้ง เปิดการตั้งค่านี้ไว้หากคุณต้องการตรวจสอบว่าผู้เข้าชมครั้งแรกมีประสบการณ์การใช้งานเว็บไซต์ของคุณอย่างไร ปิดใช้การตั้งค่านี้เมื่อต้องการสัมผัสประสบการณ์การเข้าชมซ้ำ
   • การควบคุมจำลอง (ค่าเริ่มต้น) ตัวเลือกนี้จะจำลองเงื่อนไขทั่วไปของการท่องเว็บในอุปกรณ์เคลื่อนที่ ซึ่งเรียกว่า "จำลอง" เพราะจริงๆ แล้ว Lighthouse ไม่ได้ควบคุมกระบวนการตรวจสอบ แต่เป็นเพียงการคาดคะเนระยะเวลาที่หน้าเว็บใช้ในการโหลดภายใต้สภาวะของอุปกรณ์เคลื่อนที่ ในทางกลับกัน การตั้งค่าการควบคุมเครื่องมือสำหรับนักพัฒนาเว็บ (ขั้นสูง) จะเป็นการควบคุม CPU และเครือข่ายของคุณ โดยมีข้อดีข้อเสียคือกระบวนการตรวจสอบที่ยาวนานขึ้น
   • โหมด > การนำทาง (ค่าเริ่มต้น) โหมดนี้จะวิเคราะห์การโหลดหน้าเว็บ 1 ครั้ง และนั่นคือสิ่งที่เราต้องการในบทแนะนำนี้ ดูข้อมูลเพิ่มเติมได้ที่ทั้ง 3 โหมด
   • อุปกรณ์ > อุปกรณ์เคลื่อนที่ ตัวเลือกอุปกรณ์เคลื่อนที่จะเปลี่ยนสตริง User Agent และจำลองวิวพอร์ตสำหรับอุปกรณ์เคลื่อนที่ ส่วนใหญ่แล้ว ตัวเลือกบนเดสก์ท็อปจะปิดใช้การเปลี่ยนแปลงอุปกรณ์เคลื่อนที่
   • หมวดหมู่ > ประสิทธิภาพ หมวดหมู่ที่เปิดใช้รายการเดียวจะทำให้ Lighthouse สร้างรายงานด้วยชุดการตรวจสอบที่เกี่ยวข้องเท่านั้น คุณสามารถเปิดหมวดหมู่อื่นๆ ไว้ได้หากต้องการดูประเภทของคําแนะนําที่หมวดหมู่นั้นให้ไว้ การปิดใช้หมวดหมู่ที่ไม่เกี่ยวข้องจะช่วยให้กระบวนการตรวจสอบเร็วขึ้นเล็กน้อย

3. คลิกวิเคราะห์การโหลดหน้าเว็บ หลังจากผ่านไป 10-30 วินาที แผง Lighthouse จะแสดงรายงานประสิทธิภาพของเว็บไซต์

   

การจัดการข้อผิดพลาดเกี่ยวกับรายงาน

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

ทำความเข้าใจรายงาน

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

เมตริก

เลื่อนลงไปที่ส่วนเมตริก แล้วคลิกขยายมุมมอง หากต้องการอ่านเอกสารประกอบของเมตริก ให้คลิกดูข้อมูลเพิ่มเติม...

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

ภาพหน้าจอ

ถัดไปจะเป็นคอลเล็กชันภาพหน้าจอที่แสดงให้เห็นว่าหน้าเว็บมีลักษณะอย่างไรเมื่อโหลด

โอกาส

ถัดไปคือส่วนโอกาสที่ให้เคล็ดลับเฉพาะเจาะจงเกี่ยวกับวิธีปรับปรุงประสิทธิภาพการโหลดหน้าเว็บนี้

คลิกที่โอกาสเพื่อดูข้อมูลเพิ่มเติม

คลิกดูข้อมูลเพิ่มเติม... เพื่อดูเอกสารประกอบเกี่ยวกับความสำคัญของโอกาส และคำแนะนำที่เจาะจงเกี่ยวกับวิธีแก้ไข

การวินิจฉัย

ส่วนการวินิจฉัยจะให้ข้อมูลเพิ่มเติมเกี่ยวกับปัจจัยที่มีผลต่อเวลาในการโหลดหน้าเว็บ

การตรวจสอบที่ผ่านแล้ว

ส่วนการตรวจสอบที่ผ่านจะแสดงให้เห็นว่าเว็บไซต์ดำเนินการอะไรอย่างถูกต้อง คลิกเพื่อขยายส่วนนี้

ขั้นตอนที่ 2: การทดสอบ

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

เปิดใช้การบีบอัดข้อความ

รายงานของคุณบอกว่าการเปิดใช้การบีบอัดข้อความเป็นโอกาสสำคัญที่สุดอย่างหนึ่งในการปรับปรุงประสิทธิภาพของหน้าเว็บ

การบีบอัดข้อความคือการที่คุณลดหรือบีบอัดขนาดไฟล์ข้อความก่อนที่จะส่งผ่านเครือข่าย คล้ายๆ กับวิธีใช้ซิปโฟลเดอร์ก่อนส่งอีเมลเพื่อลดขนาด

ก่อนเปิดใช้การบีบอัด คุณสามารถตรวจสอบได้ว่ามีการบีบอัดทรัพยากรข้อความหรือไม่ 2-3 วิธีด้วยตนเอง

เปิดแผงเครือข่าย แล้วเลือก การตั้งค่า > ใช้แถวคำขอขนาดใหญ่

จุดสำคัญ: หากคุณไม่เห็นคอลัมน์ขนาดในตารางคำขอเครือข่าย ให้คลิกขวาที่ส่วนหัวของตารางแล้วเลือกขนาด

แต่ละเซลล์ขนาดจะแสดงค่า 2 ค่า ค่าบนสุดคือขนาดของทรัพยากรที่ดาวน์โหลด ค่าต่ำสุดคือขนาดของทรัพยากรที่ไม่ได้บีบอัด หากทั้ง 2 ค่าเหมือนกัน ระบบจะไม่บีบอัดทรัพยากรเมื่อส่งผ่านเครือข่าย ในตัวอย่างนี้ ค่าสูงสุดและค่าต่ำสุดของ bundle.js คือ 1.4 MB

นอกจากนี้คุณยังตรวจสอบการบีบอัดได้โดยตรวจสอบส่วนหัว HTTP ของทรัพยากร โดยทำดังนี้

1. คลิก bundle.js และเปิดแท็บส่วนหัว

   

2. ค้นหาส่วนหัว content-encoding ในส่วนหัวการตอบกลับ คุณไม่ควรเห็นค่าดังกล่าว ซึ่งหมายความว่าไม่มีการบีบอัด bundle.js เมื่อบีบอัดทรัพยากร ส่วนหัวนี้จะมีการตั้งค่าเป็น gzip, deflate หรือ br ดูคำสั่งสำหรับคำอธิบายเกี่ยวกับค่าเหล่านี้

เพียงพอแล้วสำหรับคำอธิบาย ได้เวลาเปลี่ยนแปลงบางอย่างแล้ว เปิดใช้การบีบอัดข้อความด้วยการเพิ่ม โค้ด 2 บรรทัดดังนี้

1. ในแท็บตัวแก้ไข ให้เปิด server.js แล้วเพิ่มบรรทัด (ไฮไลต์) 2 บรรทัดต่อไปนี้

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. โปรดใส่ app.use(compression()) ก่อน app.use(express.static('build'))

   

   หมายเหตุ: โดยปกติคุณจะต้องติดตั้งแพ็กเกจ compression ผ่าน npm i -S compression แต่ขั้นตอนนี้ได้ดำเนินการเรียบร้อยแล้ว

3. รอให้ Glitch ทำให้บิลด์ใหม่ของเว็บไซต์ใช้งานได้ อีโมจิมีความสุขที่มุมล่างซ้ายแสดงถึงการทำให้ใช้งานได้ที่ประสบความสำเร็จ

ใช้เวิร์กโฟลว์ที่คุณได้เรียนรู้ก่อนหน้านี้เพื่อตรวจสอบด้วยตนเองว่าการบีบอัดทำงานหรือไม่:

1. กลับไปที่แท็บสาธิตแล้วโหลดหน้านี้ซ้ำ

   ตอนนี้คอลัมน์ขนาดควรแสดงค่า 2 ค่าที่แตกต่างกันสำหรับทรัพยากรข้อความ เช่น bundle.js ค่าบนสุดของ 269 KB สำหรับ bundle.js คือขนาดไฟล์ที่ส่งผ่านเครือข่าย และค่าต่ำสุดของ 1.4 MB คือขนาดไฟล์ที่ไม่ได้บีบอัด

   

2. ส่วนส่วนหัวการตอบกลับสำหรับ bundle.js ควรมีส่วนหัว content-encoding: gzip แล้วในตอนนี้

   

เรียกใช้รายงาน Lighthouse ในหน้านี้อีกครั้งเพื่อวัดผลกระทบที่การบีบอัดข้อความมีต่อประสิทธิภาพการโหลดหน้าเว็บ

1. เปิดแผง Lighthouse และคลิก ดำเนินการตรวจสอบ... ในแถบการทำงานที่ด้านบน

   

2. ปล่อยการตั้งค่าไว้เหมือนเดิมและคลิกวิเคราะห์การโหลดหน้าเว็บ

   

ไชโย ดูเหมือนว่าจะมีความคืบหน้านะ คะแนนประสิทธิภาพโดยรวมควรเพิ่มขึ้น ซึ่งหมายความว่าเว็บไซต์จะเริ่มเร็วขึ้น

การบีบอัดข้อความในชีวิตจริง

เซิร์ฟเวอร์ส่วนใหญ่สามารถแก้ไขง่ายๆ แบบนี้สำหรับการเปิดใช้งานการบีบอัด! เพียงค้นหาวิธีกำหนดค่า เซิร์ฟเวอร์ที่คุณใช้ในการบีบอัดข้อความ

ปรับขนาดรูปภาพ

รายงานใหม่ของคุณบอกว่า การปรับขนาดภาพที่เหมาะสมเป็นโอกาสที่สำคัญอีกอย่างหนึ่ง

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

1. ในรายงาน คลิกรูปภาพขนาดที่เหมาะสมเพื่อดูรูปภาพที่ควรปรับขนาด ดูเหมือนว่ารูปภาพทั้ง 4 รูปจะมีขนาดใหญ่กว่าที่จำเป็น

   

2. กลับไปที่แท็บเอดิเตอร์ เปิด src/model.js

3. แทนที่ const dir = 'big' ด้วย const dir = 'small' ไดเรกทอรีนี้มีสำเนาของรูปภาพเดียวกันที่มีการปรับขนาด

4. ตรวจสอบหน้าเว็บอีกครั้งเพื่อดูว่าการเปลี่ยนแปลงนี้ส่งผลต่อประสิทธิภาพการโหลดอย่างไร

   

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

การปรับขนาดรูปภาพในชีวิตจริง

สำหรับแอปขนาดเล็ก การปรับขนาดแบบครั้งเดียวแบบนี้อาจจะดีเพียงพอแล้ว แต่สำหรับแอปขนาดใหญ่ ไม่สามารถปรับขนาดได้ กลยุทธ์บางอย่างในการจัดการรูปภาพในแอปขนาดใหญ่มีดังนี้

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

กำจัดทรัพยากรที่บล็อกการแสดงผล

รายงานล่าสุดของคุณบอกว่าการกำจัดทรัพยากรที่บล็อกการแสดงผลเป็นโอกาสที่ดีที่สุดแล้วในตอนนี้

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

งานแรกก็คือการค้นหาโค้ดที่ไม่จำเป็นต้องเรียกใช้เมื่อโหลดหน้าเว็บ

1. คลิกลบทรัพยากรที่บล็อกการแสดงผลเพื่อดูทรัพยากรที่บล็อกอยู่ ดังนี้ lodash.js และ jquery.js

   

2. กดปุ่มต่อไปนี้เพื่อเปิดเมนูคำสั่ง ทั้งนี้ขึ้นอยู่กับระบบปฏิบัติการของคุณ

   • ใน Mac ให้ Command+Shift+P
   • ใน Windows, Linux หรือ ChromeOS ให้ใช้ Control+Shift+P

3. เริ่มพิมพ์ Coverage แล้วเลือกแสดงการครอบคลุม

   

   แท็บการครอบคลุมจะเปิดขึ้นในลิ้นชัก

   

4. คลิก โหลดซ้ำ แท็บการครอบคลุมจะแสดงภาพรวมของจำนวนการเรียกใช้โค้ดใน bundle.js, jquery.js และ lodash.js ขณะที่กำลังโหลดหน้าเว็บ

   

   ภาพหน้าจอนี้บอกว่าไม่มีการใช้ไฟล์ jQuery และ Lodash ประมาณ 74% และ 30% ตามลำดับ

5. คลิกแถว jquery.js เครื่องมือสำหรับนักพัฒนาเว็บจะเปิดไฟล์ในแผงแหล่งที่มา จะมีการเรียกใช้โค้ดบรรทัดหนึ่งหากมีแถบสีเขียวอยู่ข้างๆ แถบสีแดงถัดจากบรรทัดโค้ดหมายความว่าไม่มีการดำเนินการและไม่จำเป็นเมื่อโหลดหน้าเว็บ

   

6. เลื่อนดูโค้ด jQuery เล็กน้อย บางบรรทัดที่มีข้อความ "เรียกใช้" จริงๆ แล้วเป็นเพียงความคิดเห็น การเรียกใช้โค้ดนี้ผ่านตัวลดขนาดที่ลบความคิดเห็นเป็นอีกวิธีหนึ่งในการลดขนาดไฟล์นี้

กล่าวโดยสรุปคือ เมื่อคุณทำงานกับโค้ดของคุณเอง แท็บการครอบคลุมสามารถช่วยคุณวิเคราะห์โค้ดไปทีละบรรทัด และจัดส่งเฉพาะโค้ดที่จำเป็นสำหรับการโหลดหน้าเว็บเท่านั้น

จำเป็นต้องใช้ไฟล์ jquery.js และ lodash.js เพื่อโหลดหน้าเว็บไหม แท็บคำขอการบล็อกจะแสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อทรัพยากรไม่พร้อมใช้งาน

1. คลิกแท็บ Network แล้วเปิดเมนูคำสั่งอีกครั้ง

2. เริ่มพิมพ์ blocking แล้วเลือกแสดงการบล็อกคำขอ แท็บการบล็อกคำขอจะเปิดขึ้น

   

3. คลิก เพิ่มรูปแบบ พิมพ์ /libs/* ในช่องข้อความ แล้วกด Enter เพื่อยืนยัน

   

4. โหลดหน้าเว็บซ้ำ คำขอ jQuery และ Lodash เป็นสีแดง หมายความว่าคำขอเหล่านั้นถูกบล็อก หน้าเว็บจะยังคงโหลดและโต้ตอบได้ จึงดูเหมือนว่าจะไม่จำเป็นต้องมีทรัพยากรเหล่านี้แล้ว

   

5. คลิก นำรูปแบบทั้งหมดออกเพื่อลบรูปแบบการบล็อก /libs/*

โดยทั่วไปแล้ว แท็บคำขอการบล็อกมีประโยชน์ในการจำลองลักษณะการทำงานของหน้าเว็บเมื่อทรัพยากรที่ระบุไม่พร้อมใช้งาน

ในตอนนี้ ให้นำการอ้างอิงไปยังไฟล์เหล่านี้ออกจากโค้ดและตรวจสอบหน้าเว็บอีกครั้ง:

1. กลับไปที่แท็บเอดิเตอร์ เปิด template.html

2. ลบแท็ก <script> ที่เกี่ยวข้อง

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. รอให้เว็บไซต์สร้างใหม่และทำให้ใช้งานได้อีกครั้ง

4. ตรวจสอบหน้าเว็บอีกครั้งจากแผง Lighthouse คะแนนโดยรวมควรดีขึ้นอีกครั้ง

   

การเพิ่มประสิทธิภาพเส้นทางการแสดงผลวิกฤติในโลกแห่งความเป็นจริง

เส้นทางการแสดงผลวิกฤติหมายถึงโค้ดที่คุณต้องโหลดหน้าเว็บ โดยทั่วไปแล้ว คุณสามารถเร่งการโหลดหน้าเว็บได้โดยจัดส่งโค้ดที่สำคัญเท่านั้นระหว่างการโหลดหน้าเว็บ แล้วก็โหลดแบบ Lazy Loading อื่นๆ

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

ลดการทำงานของเทรดหลัก

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

เทรดหลักเป็นส่วนที่เบราว์เซอร์ทำงานส่วนใหญ่ที่จำเป็นในการแสดงหน้าเว็บ เช่น การแยกวิเคราะห์และเรียกใช้ HTML, CSS และ JavaScript

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

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

1. เปิดประสิทธิภาพ > การตั้งค่าการจับภาพ และตั้งค่าเครือข่ายเป็น 3G ที่ช้าและ CPU เป็นช้าลง 6 เท่า

   

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

2. คลิก โหลดซ้ำ เครื่องมือสำหรับนักพัฒนาเว็บจะโหลดหน้าเว็บซ้ำ จากนั้นสร้างภาพแสดงทุกสิ่งที่ต้องทำเพื่อโหลดหน้า การแสดงภาพนี้จะเรียกว่าtrace

   

การติดตามจะแสดงกิจกรรมตามลำดับเวลา จากซ้ายไปขวา แผนภูมิ FPS, CPU และ NET ที่ด้านบนจะแสดงภาพรวมของเฟรมต่อวินาที กิจกรรม CPU และกิจกรรมเครือข่าย

ผนังสีเหลืองที่คุณเห็นในส่วนภาพรวมหมายความว่า CPU ยุ่งกับกิจกรรมการเขียนสคริปต์อย่างเต็มที่ นี่เป็นข้อบ่งชี้ว่าคุณอาจเพิ่มความเร็วในการโหลดหน้าเว็บได้โดยใช้ JavaScript น้อยลง

ตรวจสอบการติดตามเพื่อหาวิธีลดการทำงานของ JavaScript ดังนี้

1. คลิกส่วนการจับเวลาเพื่อขยาย

   

   มีการวัดระยะเวลาของผู้ใช้จาก React มากมาย ดูเหมือนว่าแอปของธเนศวร์กำลังใช้โหมดการพัฒนาของ React การเปลี่ยนไปใช้โหมดการใช้งานจริงของ React อาจทำให้บรรลุเป้าหมายด้านประสิทธิภาพได้อย่างง่ายดาย

2. คลิกระยะเวลาอีกครั้งเพื่อยุบส่วนนั้น

3. เรียกดูส่วนหลัก ส่วนนี้จะแสดงบันทึกตามลำดับเวลาของกิจกรรมเทรดหลัก จากซ้ายไปขวา แกน Y (บนลงล่าง) แสดงสาเหตุที่เกิดเหตุการณ์

   

   ในตัวอย่างนี้ เหตุการณ์ Evaluate Script ทำให้ฟังก์ชัน (anonymous) ทำงาน ซึ่งทำให้ __webpack__require__ ทำงาน ซึ่งเป็นผลให้ ./src/index.jsx ทำงาน เป็นต้น

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

   

   ในแอปนี้ ดูเหมือนว่าฟังก์ชันที่ชื่อว่า App ทำให้มีการเรียกฟังก์ชัน mineBitcoin เป็นจำนวนมาก ดูเหมือนว่าโทนีใช้อุปกรณ์ของแฟนๆ ในการขุดคริปโตเคอเรนซี...

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

5. เปิดแท็บล่างขึ้นบนที่ด้านล่าง แท็บนี้จะแสดงกิจกรรมที่ใช้เวลามากที่สุด หากไม่เห็นอะไรในส่วนล่างขึ้นบน ให้คลิกป้ายกำกับสำหรับส่วนหลัก

   

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

   คอลัมน์เวลาของตนเองจะแสดงระยะเวลาที่ใช้ไปกับแต่ละกิจกรรมโดยตรง ในกรณีนี้ เวลาที่ใช้เทรดหลักไปประมาณ 82% กับฟังก์ชัน mineBitcoin

เวลาดูว่าการใช้โหมดการใช้งานจริงและการลดกิจกรรม JavaScript จะช่วยให้การโหลดหน้าเว็บเร็วขึ้นไหม เริ่มต้นด้วยโหมดที่ใช้งานจริง

1. เปิด webpack.config.js ในแท็บตัวแก้ไข
2. เปลี่ยน "mode":"development" เป็น "mode":"production"
3. รอให้บิลด์ใหม่ทำให้ใช้งานได้

4. ตรวจสอบหน้านี้อีกครั้ง

   

ลดกิจกรรม JavaScript โดยนำการเรียกไปยัง mineBitcoin ออก

1. เปิด src/App.jsx ในแท็บตัวแก้ไข
2. แสดงความคิดเห็นเกี่ยวกับการเรียกไปยัง this.mineBitcoin(1500) ใน constructor
3. รอให้บิลด์ใหม่ทำให้ใช้งานได้
4. ตรวจสอบหน้านี้อีกครั้ง

แต่คุณยังคงต้องดำเนินการบางอย่าง เช่น ลดเมตริก Largest Contentful Paint และ Cumulative Layout Shift

สำเร็จ: แต่ดูเหมือนว่าการเปลี่ยนแปลงครั้งล่าสุดทำให้ประสิทธิภาพพุ่งสูงขึ้นอย่างมาก

ทำให้การทำงานผ่านชุดข้อความหลักน้อยลงในโลกแห่งความเป็นจริง

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

หากต้องการใช้วิธีที่ให้ความรู้สึกคล้ายกับ console.log() มากกว่า User Timing API จะให้คุณมาร์กอัปช่วงต่างๆ ของวงจรแอปได้ตามต้องการ เพื่อติดตามว่าแต่ละระยะใช้เวลานานเท่าใด

สรุป

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

ขั้นตอนถัดไป

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

• รายงานข้อบกพร่องในเอกสารนี้ในที่เก็บ developer.chrome.com
• รายงานข้อบกพร่องเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บที่ข้อบกพร่อง Chromium
• พูดคุยเรื่องฟีเจอร์และการเปลี่ยนแปลงในรายชื่ออีเมล โปรดอย่าใช้รายชื่ออีเมลเพื่อ ถามคำถามเกี่ยวกับการสนับสนุน โปรดใช้ Stack Overflow แทน
• รับความช่วยเหลือทั่วไปเกี่ยวกับการใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Stack Overflow หากต้องการยื่นคำขอข้อบกพร่อง ให้ใช้ข้อบกพร่องของ Chromium เสมอ
• ทวีตหาเราที่ @ChromeDevTools