ภาพรวม
ใช้แผง Lighthouse เพื่อเรียกใช้การตรวจสอบที่ครอบคลุมของเว็บไซต์ แผง Lighthouse จะสร้างรายงานที่ให้ข้อมูลเชิงลึกเกี่ยวกับเว็บไซต์ดังต่อไปนี้
- ประสิทธิภาพ
- การช่วยเหลือพิเศษ
- แนวทางปฏิบัติแนะนำ
- SEO
... และเมตริกอื่นๆ อีกมากมาย
บทแนะนำต่อไปนี้จะช่วยคุณเริ่มต้นใช้งาน Lighthouse ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีอื่นๆ ที่ Lighthouse ช่วยปรับปรุงคุณภาพเว็บไซต์ได้ในเอกสาร Lighthouse
เป้าหมายของบทแนะนำ
บทแนะนํานี้จะสอนวิธีใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อค้นหาวิธีทําให้เว็บไซต์โหลดเร็วขึ้น
อ่านต่อ หรือดูวิดีโอบทแนะนำนี้:
ข้อกำหนดเบื้องต้น
คุณควรมีประสบการณ์ด้านการพัฒนาเว็บขั้นพื้นฐาน ซึ่งคล้ายกับที่สอนในชั้นเรียนเบื้องต้นเกี่ยวกับการพัฒนาเว็บนี้
คุณไม่จำเป็นต้องทราบเกี่ยวกับประสิทธิภาพการโหลด
บทนำ
และ Tony จะเป็นผู้ดูแลคุณในวันนี้ Tony มีชื่อเสียงมากในสังคมแมว เขาสร้างเว็บไซต์เพื่อให้แฟนๆ ได้รู้ว่าอาหารโปรดของเขาคืออะไร แฟนๆ ชื่นชอบเว็บไซต์ แต่ Tony ได้ยินการร้องเรียนว่าเว็บไซต์โหลดช้าอยู่ตลอด Tony ขอให้คุณช่วยเพิ่มความเร็วเว็บไซต์
ขั้นตอนที่ 1: ตรวจสอบเว็บไซต์
เมื่อใดก็ตามที่คุณต้องการปรับปรุงประสิทธิภาพการโหลดของเว็บไซต์ ให้เริ่มต้นด้วยการตรวจสอบเสมอ การตรวจสอบมีฟังก์ชันสําคัญ 2 อย่างดังนี้
- ซึ่งจะสร้างเส้นฐานให้คุณวัดการเปลี่ยนแปลงที่ตามมา
- พร้อมด้วยเคล็ดลับที่นำไปใช้ได้จริงเพื่อดูว่าการเปลี่ยนแปลงใดจะส่งผลกระทบมากที่สุด
ตั้งค่า
ก่อนอื่น คุณต้องตั้งค่าสภาพแวดล้อมการทำงานใหม่สำหรับเว็บไซต์ของ Tony เพื่อให้คุณทำการเปลี่ยนแปลงในภายหลังได้ โดยทำดังนี้
รีมิกซ์โปรเจ็กต์ของเว็บไซต์ใน Glitch โปรเจ็กต์ใหม่จะเปิดในแท็บ แท็บนี้จะเรียกว่าแท็บเครื่องมือแก้ไข
ชื่อโปรเจ็กต์เปลี่ยนจาก tony เป็นชื่อที่ระบบสร้างขึ้นแบบสุ่ม ตอนนี้คุณมีสำเนาโค้ดที่แก้ไขได้ของคุณเองแล้ว คุณจะทําการเปลี่ยนแปลงรหัสนี้ในภายหลัง
ที่ด้านล่างของแท็บเครื่องมือแก้ไข ให้คลิกแสดงตัวอย่าง > แสดงตัวอย่างในหน้าต่างใหม่ ตัวอย่างจะเปิดในแท็บใหม่ แท็บนี้จะเรียกว่าแท็บเดโม การโหลดเว็บไซต์อาจใช้เวลาสักครู่
เปิดเครื่องมือสำหรับนักพัฒนาเว็บควบคู่ไปกับการสาธิต
สร้างเกณฑ์พื้นฐาน
เส้นฐานคือบันทึกประสิทธิภาพของเว็บไซต์ก่อนที่คุณจะทำการปรับปรุงประสิทธิภาพ
เปิดแผง Lighthouse แผงอาจซ่อนอยู่หลัง
แผงเพิ่มเติมจับคู่การตั้งค่าการกําหนดค่ารายงาน Lighthouse กับการตั้งค่าในภาพหน้าจอ คำอธิบายตัวเลือกต่างๆ มีดังนี้
- ล้างพื้นที่เก็บข้อมูล การเปิดใช้ช่องทำเครื่องหมายนี้จะล้างพื้นที่เก็บข้อมูลทั้งหมดที่เชื่อมโยงกับหน้าดังกล่าวก่อนการตรวจสอบทุกครั้ง ตั้งค่านี้ไว้หากต้องการตรวจสอบประสบการณ์ของผู้เข้าชมครั้งแรกในเว็บไซต์ ปิดใช้การตั้งค่านี้เมื่อคุณต้องการประสบการณ์การเข้าชมซ้ำ
- เปิดใช้การสุ่มตัวอย่าง JS ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น เมื่อเปิดใช้ ตัวเลือกนี้จะเพิ่มสแต็กการเรียก JavaScript โดยละเอียดลงในร่องรอยประสิทธิภาพ แต่อาจทําให้การสร้างรายงานช้าลง การติดตามจะอยู่ใน เมนูเครื่องมือ > ดูการติดตามที่ไม่มีการจำกัดหลังจากสร้างรายงาน Lighthouse แล้ว
- การควบคุมจำลอง (ค่าเริ่มต้น) ตัวเลือกนี้จะจําลองสภาพการท่องเว็บทั่วไปในอุปกรณ์เคลื่อนที่ วิธีนี้เรียกว่า "จำลอง" เนื่องจาก Lighthouse ไม่ได้ควบคุมการทำงานในระหว่างกระบวนการตรวจสอบ แต่เพียงประมาณว่าหน้าเว็บจะใช้เวลานานเท่าใดในการโหลดภายใต้เงื่อนไขของอุปกรณ์เคลื่อนที่ ในทางกลับกัน การตั้งค่าการควบคุมเครื่องมือสําหรับนักพัฒนาเว็บ (ขั้นสูง) จะควบคุม CPU และเครือข่ายจริง แต่กระบวนการตรวจสอบจะใช้เวลานานขึ้น
- โหมด > โหมด 3 โหมด การนำทาง (ค่าเริ่มต้น) โหมดนี้จะวิเคราะห์การโหลดหน้าเว็บ 1 ครั้ง และนั่นคือสิ่งที่เราต้องการในบทแนะนำนี้ ดูข้อมูลเพิ่มเติมได้ที่
- อุปกรณ์ > อุปกรณ์เคลื่อนที่ ตัวเลือกอุปกรณ์เคลื่อนที่จะเปลี่ยนสตริง User Agent และจำลองวิดเจ็ตของอุปกรณ์เคลื่อนที่ ตัวเลือกเดสก์ท็อปจะปิดใช้การเปลี่ยนแปลงในอุปกรณ์เคลื่อนที่
- หมวดหมู่ > ประสิทธิภาพ หมวดหมู่ที่เปิดใช้เพียงหมวดหมู่เดียวจะทำให้ Lighthouse สร้างรายงานที่มีชุดการตรวจสอบที่เกี่ยวข้องเท่านั้น คุณจะเปิดใช้หมวดหมู่อื่นๆ ไว้ได้หากต้องการดูประเภทคําแนะนําที่หมวดหมู่เหล่านั้นให้ การปิดใช้หมวดหมู่ที่ไม่เกี่ยวข้องจะช่วยทำให้กระบวนการตรวจสอบเร็วขึ้นเล็กน้อย
คลิกวิเคราะห์การโหลดหน้าเว็บ หลังจากผ่านไป 10-30 วินาที แผง Lighthouse จะแสดงรายงานประสิทธิภาพของเว็บไซต์
การจัดการข้อผิดพลาดของรายงาน
หากพบข้อผิดพลาดในรายงาน Lighthouse ให้ลองเรียกใช้แท็บสาธิตจากหน้าต่างที่ไม่ระบุตัวตนโดยไม่มีแท็บอื่นเปิดอยู่ วิธีนี้ช่วยให้คุณเรียกใช้ Chrome จากสถานะที่สะอาด โดยเฉพาะอย่างยิ่งส่วนขยาย Chrome อาจรบกวนกระบวนการตรวจสอบ
ทําความเข้าใจรายงาน
ตัวเลขที่ด้านบนของรายงานคือคะแนนประสิทธิภาพโดยรวมของเว็บไซต์ ในภายหลัง เมื่อคุณทําการเปลี่ยนแปลงโค้ด คุณควรเห็นว่าจํานวนนี้เพิ่มขึ้น คะแนนที่สูงขึ้นหมายถึงประสิทธิภาพที่ดีขึ้น
เมตริก
เลื่อนลงไปที่ส่วนเมตริก แล้วคลิกขยายมุมมอง หากต้องการอ่านเอกสารประกอบเกี่ยวกับเมตริก ให้คลิกดูข้อมูลเพิ่มเติม...
ส่วนนี้จะแสดงการวัดประสิทธิภาพของเว็บไซต์ในเชิงปริมาณ เมตริกแต่ละรายการให้ข้อมูลเชิงลึกเกี่ยวกับแง่มุมต่างๆ ของประสิทธิภาพ ตัวอย่างเช่น First Contentful Paint จะแจ้งเตือนคุณเมื่อการแสดงผลเนื้อหาลงบนหน้าจอครั้งแรก ซึ่งเป็นเหตุการณ์สำคัญในการรับรู้การโหลดหน้าเว็บของผู้ใช้ ในขณะที่ Time To Interactive ระบุถึงจุดที่หน้าเว็บปรากฏพร้อมเพียงพอที่จะรองรับการโต้ตอบของผู้ใช้
ภาพหน้าจอ
ถัดไปคือคอลเล็กชันภาพหน้าจอที่แสดงลักษณะของหน้าเว็บขณะโหลด
โอกาส
ส่วนถัดไปคือส่วนโอกาสซึ่งมีเคล็ดลับเฉพาะเกี่ยวกับวิธีปรับปรุงประสิทธิภาพการโหลดของหน้าเว็บนี้
คลิกโอกาสเพื่อดูข้อมูลเพิ่มเติม
คลิกดูข้อมูลเพิ่มเติม... เพื่อดูเอกสารประกอบเกี่ยวกับเหตุผลที่โอกาสมีความสําคัญ และคำแนะนำที่เฉพาะเจาะจงเกี่ยวกับวิธีแก้ไข
การวินิจฉัย
ส่วนการวินิจฉัยจะให้ข้อมูลเพิ่มเติมเกี่ยวกับปัจจัยที่ส่งผลต่อเวลาในการโหลดของหน้า
การตรวจสอบที่ผ่านแล้ว
ส่วนการตรวจสอบที่ผ่านจะแสดงสิ่งที่เว็บไซต์ทําได้อย่างถูกต้อง คลิกเพื่อขยายส่วน
ขั้นตอนที่ 2: การทดสอบ
ส่วนโอกาสของรายงาน Lighthouse มีเคล็ดลับเกี่ยวกับวิธีปรับปรุงประสิทธิภาพของหน้าเว็บ ในส่วนนี้ คุณจะได้ใช้การเปลี่ยนแปลงที่แนะนำกับฐานของโค้ด ซึ่งจะตรวจสอบเว็บไซต์หลังการเปลี่ยนแปลงแต่ละครั้งเพื่อวัดว่าส่งผลต่อความเร็วเว็บไซต์อย่างไร
เปิดใช้การบีบอัดข้อความ
รายงานระบุว่าการเปิดใช้การบีบอัดข้อความเป็นหนึ่งในโอกาสสําคัญในการปรับปรุงประสิทธิภาพของหน้าเว็บ
การบีบอัดข้อความคือการลดหรือบีบอัดขนาดของไฟล์ข้อความก่อนที่จะส่งผ่านเครือข่าย เช่น วิธีบีบอัดโฟลเดอร์ก่อนส่งอีเมลเพื่อลดขนาด
ก่อนเปิดใช้การบีบอัด มี 2-3 วิธีที่คุณสามารถตรวจสอบด้วยตนเองว่าได้บีบอัดทรัพยากรข้อความหรือไม่ ดังนี้
เปิดแผงเครือข่าย แล้วตรวจสอบ ใช้แถวคำขอขนาดใหญ่
การตั้งค่า >เซลล์ขนาดแต่ละเซลล์จะแสดงค่า 2 ค่า ค่าด้านบนคือขนาดของทรัพยากรที่ดาวน์โหลด ค่าด้านล่างคือขนาดของทรัพยากรที่ไม่ได้บีบอัด หากทั้ง 2 ค่าเหมือนกัน ระบบจะไม่บีบอัดทรัพยากรเมื่อมีการส่งผ่านเครือข่าย ในตัวอย่างนี้ ค่าด้านบนและด้านล่างของ bundle.js
จะเป็น 1.4 MB
ทั้งคู่
นอกจากนี้ คุณยังตรวจสอบการบีบอัดได้โดยการตรวจสอบส่วนหัว HTTP ของทรัพยากร ดังนี้
คลิก bundle.js แล้วเปิดแท็บส่วนหัว
ค้นหาส่วนส่วนหัวการตอบกลับเพื่อหาส่วนหัว
content-encoding
คุณไม่น่าจะเห็นโฆษณา หมายความว่าไม่ได้บีบอัดbundle.js
เมื่อทรัพยากรถูกบีบอัด ส่วนหัวนี้มักจะตั้งค่าเป็นgzip
,deflate
หรือbr
ดูคำอธิบายค่าเหล่านี้ได้ที่คำสั่ง
จบคำอธิบาย ถึงเวลาเปลี่ยนแปลงแล้ว เปิดใช้การบีบอัดข้อความ ด้วยการเพิ่มโค้ด 2-3 บรรทัด
ในแท็บเครื่องมือแก้ไข ให้เปิด
server.js
แล้วเพิ่ม 2 บรรทัด (ไฮไลต์) ต่อไปนี้... const fs = require('fs'); const compression = require('compression'); app.use(compression()); app.use(express.static('build')); ...
อย่าลืมใส่
app.use(compression())
ก่อนapp.use(express.static('build'))
รอให้ Glitch ติดตั้งใช้งานบิลด์ใหม่ของเว็บไซต์ อีโมจิหน้ายิ้มที่มุมล่างซ้ายแสดงว่าการติดตั้งใช้งานสําเร็จ
ใช้เวิร์กโฟลว์ที่คุณได้เรียนรู้ไปก่อนหน้านี้เพื่อตรวจสอบด้วยตนเองว่าการบีบอัดทำงานอยู่
กลับไปที่แท็บสาธิตและโหลดหน้าเว็บซ้ำ
ตอนนี้คอลัมน์ขนาดควรแสดงค่าที่แตกต่างกัน 2 ค่าสำหรับทรัพยากรข้อความ เช่น
bundle.js
ค่าด้านบนของ269 KB
สำหรับbundle.js
คือขนาดของไฟล์ที่ส่งผ่านเครือข่าย และค่าด้านล่างของ1.4 MB
คือขนาดไฟล์ที่ไม่มีการบีบอัดตอนนี้ส่วนส่วนหัวการตอบกลับสำหรับ
bundle.js
ควรมีส่วนหัวcontent-encoding: gzip
เรียกใช้รายงาน Lighthouse ในหน้าเว็บอีกครั้งเพื่อวัดผลกระทบที่การบีบอัดข้อความมีต่อประสิทธิภาพการโหลดของหน้าเว็บ
เปิดแผง Lighthouse แล้วคลิก ทําการตรวจสอบ... ในแถบการดำเนินการที่ด้านบน
ปล่อยการตั้งค่าไว้เหมือนเดิม แล้วคลิกวิเคราะห์การโหลดหน้าเว็บ
ไชโย ดูเหมือนจะกำลังคืบหน้านะ คะแนนประสิทธิภาพโดยรวมควรเพิ่มขึ้น ซึ่งหมายความว่าเว็บไซต์ทำงานเร็วขึ้น
การบีบอัดข้อความในสถานการณ์จริง
เซิร์ฟเวอร์ส่วนใหญ่มีวิธีแก้ปัญหาง่ายๆ แบบนี้สำหรับการเปิดใช้การบีบอัด เพียงค้นหาวิธีกำหนดค่าเซิร์ฟเวอร์ที่คุณใช้เพื่อบีบอัดข้อความ
ปรับขนาดรูปภาพ
รายงานใหม่ของคุณระบุว่าการปรับขนาดภาพอย่างเหมาะสมเป็นอีกโอกาสสำคัญ
การปรับขนาดรูปภาพจะช่วยเพิ่มความเร็วในการโหลดโดยลดขนาดไฟล์ของรูปภาพ หากผู้ใช้ดูรูปภาพของคุณบนหน้าจออุปกรณ์เคลื่อนที่ที่มีความกว้าง 500 พิกเซล จะไม่มีการส่งรูปภาพที่มีความกว้าง 1500 พิกเซลเลย คุณควรส่งรูปภาพที่มีความกว้างไม่เกิน 500 พิกเซล
ในรายงาน ให้คลิกปรับขนาดรูปภาพให้เหมาะสมเพื่อดูว่าควรปรับขนาดรูปภาพใด ดูเหมือนว่ารูปภาพทั้ง 4 รูปจะมีขนาดใหญ่เกินความจำเป็น
กลับไปที่แท็บเครื่องมือแก้ไข แล้วเปิด
src/model.js
แทนที่
const dir = 'big'
ด้วยconst dir = 'small'
ไดเรกทอรีนี้มีสำเนาของรูปภาพเดียวกันซึ่งปรับขนาดแล้วตรวจสอบหน้าเว็บอีกครั้งเพื่อดูว่าการเปลี่ยนแปลงนี้ส่งผลต่อประสิทธิภาพในการโหลดอย่างไร
ดูเหมือนว่าการเปลี่ยนแปลงจะมีผลเพียงเล็กน้อยต่อคะแนนประสิทธิภาพโดยรวม อย่างไรก็ตาม คะแนนนี้ไม่ได้แสดงอย่างชัดเจนถึงปริมาณข้อมูลเครือข่ายที่คุณช่วยประหยัดให้กับผู้ใช้ ขนาดรวมของรูปภาพเก่าอยู่ที่ประมาณ 6.1 MB แต่ตอนนี้เหลือเพียงประมาณ 633 KB คุณตรวจสอบข้อมูลนี้ได้ในแถบสถานะที่ด้านล่างของแผงเครือข่าย
การปรับขนาดรูปภาพในโลกแห่งความเป็นจริง
สําหรับแอปขนาดเล็ก การปรับขนาดแบบครั้งเดียวเช่นนี้อาจเพียงพอแล้ว แต่สำหรับแอปขนาดใหญ่ วิธีการนี้ไม่สามารถปรับขนาดได้ กลยุทธ์บางอย่างสำหรับการจัดการรูปภาพในแอปขนาดใหญ่มีดังนี้
- ปรับขนาดรูปภาพระหว่างขั้นตอนการสร้าง
- สร้างรูปภาพแต่ละรูปหลายขนาดในระหว่างกระบวนการบิลด์ แล้วใช้
srcset
ในโค้ด ขณะรันไทม์เบราว์เซอร์จะเลือกขนาดที่เหมาะกับอุปกรณ์ที่ใช้ โปรดดูรูปภาพขนาดสัมพัทธ์ - ใช้ CDN รูปภาพที่ให้คุณปรับขนาดรูปภาพแบบไดนามิกเมื่อขอ
- อย่างน้อยที่สุด ให้เพิ่มประสิทธิภาพรูปภาพแต่ละรูป ซึ่งมักจะช่วยประหยัดค่าใช้จ่ายได้มาก การเพิ่มประสิทธิภาพคือการดำเนินการกับรูปภาพผ่านโปรแกรมพิเศษที่ลดขนาดไฟล์รูปภาพ ดูการเพิ่มประสิทธิภาพรูปภาพ ที่สำคัญสำหรับเคล็ดลับเพิ่มเติม
กำจัดทรัพยากรที่บล็อกการแสดงผล
รายงานล่าสุดของคุณระบุว่าการขจัดทรัพยากรที่บล็อกการแสดงผลได้กลายเป็นโอกาสที่ดีที่สุดแล้ว
ทรัพยากรที่บล็อกการแสดงผลคือไฟล์ JavaScript หรือ CSS ภายนอกที่เบราว์เซอร์ต้องดาวน์โหลด แยกวิเคราะห์ และดำเนินการก่อนจึงจะแสดงหน้าเว็บได้ เป้าหมายคือการเรียกใช้เฉพาะโค้ด CSS และ JavaScript หลักที่จำเป็นต่อการแสดงหน้าเว็บอย่างถูกต้อง
งานแรกจึงเป็นการค้นหาโค้ดที่ไม่ต้องดำเนินการเมื่อโหลดหน้าเว็บ
คลิกกำจัดทรัพยากรที่บล็อกการแสดงผลเพื่อดูทรัพยากรที่บล็อกอยู่ ดังนี้
lodash.js
และjquery.js
กดแป้นต่อไปนี้เพื่อเปิดเมนูคำสั่ง ทั้งนี้ขึ้นอยู่กับระบบปฏิบัติการของคุณ
- ใน Mac ให้กด Command+Shift+P
- ใน Windows, Linux หรือ ChromeOS ให้กด Control+Shift+P
เริ่มพิมพ์
Coverage
แล้วเลือกแสดงความครอบคลุมแท็บความครอบคลุมจะเปิดขึ้นในลิ้นชัก
คลิก
โหลดซ้ำ แท็บการครอบคลุมจะแสดงภาพรวมของจำนวนโค้ดในbundle.js
,jquery.js
และlodash.js
ที่กำลังทำงานขณะที่หน้าเว็บโหลดภาพหน้าจอนี้ระบุว่ามีการใช้ไฟล์ jQuery และ Lodash ประมาณ 74% และ 30% ตามลำดับ
คลิกแถว jquery.js เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์จะเปิดไฟล์ในแผงแหล่งที่มา บรรทัดโค้ดจะทำงานหากมีแถบสีเขียวอยู่ข้างๆ แถบสีแดงข้างบรรทัดโค้ดหมายความว่าโค้ดนั้นไม่ได้ทำงานและไม่จำเป็นต้องใช้เมื่อโหลดหน้าเว็บ
เลื่อนดูโค้ด jQuery สักครู่ บรรทัดบางบรรทัดที่ได้รับการ "ดำเนินการ" นั้นแท้จริงแล้วเป็นเพียงความคิดเห็น การเรียกใช้โค้ดนี้ผ่านตัวลดขนาดที่ตัดความคิดเห็นออกเป็นอีกวิธีหนึ่งในการลดขนาดไฟล์นี้
กล่าวโดยย่อคือ เมื่อคุณทํางานกับโค้ดของคุณเอง แท็บการครอบคลุมจะช่วยคุณวิเคราะห์โค้ดทีละบรรทัด และส่งเฉพาะโค้ดที่จําเป็นสําหรับการโหลดหน้าเว็บ
ไฟล์ jquery.js
และ lodash.js
ต้องใช้โหลดหน้าเว็บไหม แท็บการบล็อกคำขอจะแสดงให้เห็นว่าจะเกิดอะไรขึ้นเมื่อทรัพยากรไม่พร้อมใช้งาน
- คลิกแท็บเครือข่าย แล้วเปิดเมนูคำสั่งอีกครั้ง
เริ่มพิมพ์
blocking
แล้วเลือกแสดงการบล็อกคำขอ แท็บการบล็อกคำขอจะเปิดขึ้นคลิก เพิ่มรูปแบบ พิมพ์
/libs/*
ในกล่องข้อความ แล้วกด Enter เพื่อยืนยันโหลดหน้าเว็บซ้ำ คำขอ jQuery และ Lodash เป็นสีแดง ซึ่งหมายความว่าถูกบล็อก หน้าเว็บยังคงโหลดและโต้ตอบได้อยู่ ดูเหมือนว่าจะไม่จําเป็นต้องใช้ทรัพยากรเหล่านี้เลย
คลิก นำรูปแบบทั้งหมดออกเพื่อลบรูปแบบการบล็อก
/libs/*
โดยทั่วไปแล้ว แท็บการบล็อกคำขอจะมีประโยชน์ในการจำลองลักษณะการทำงานของหน้าเว็บเมื่อทรัพยากรใดๆ ไม่พร้อมใช้งาน
ตอนนี้ ให้นำการอ้างอิงไฟล์เหล่านี้ออกจากโค้ดและตรวจสอบหน้าเว็บอีกครั้ง
- กลับไปที่แท็บเครื่องมือแก้ไข แล้วเปิด
template.html
ลบแท็ก
<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>
รอให้เว็บไซต์สร้างและทำให้ใช้งานได้อีกครั้ง
ตรวจสอบหน้าเว็บอีกครั้งจากแผง Lighthouse คะแนนโดยรวมควรดีขึ้นอีกครั้ง
การเพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญในโลกแห่งความเป็นจริง
เส้นทางการแสดงผลที่สำคัญหมายถึงโค้ดที่คุณต้องใช้ในการโหลดหน้าเว็บ โดยทั่วไป คุณสามารถเร่งความเร็วในการโหลดหน้าเว็บได้โดยส่งเฉพาะโค้ดที่สำคัญระหว่างการโหลดหน้าเว็บ จากนั้นจึงใช้การโหลดแบบเลื่อนเวลา (Lazy Loading) กับส่วนที่เหลือ
- คุณอาจไม่พบสคริปต์ที่นําออกได้ทันที แต่มักจะพบว่าสคริปต์จํานวนมากไม่จําเป็นต้องขอระหว่างการโหลดหน้าเว็บ และสามารถขอแบบไม่พร้อมกันได้ โปรดดูหัวข้อการใช้ async หรือ defer
- หากคุณใช้เฟรมเวิร์ก ให้ตรวจสอบว่าเฟรมเวิร์กมีโหมดที่ใช้งานจริงหรือไม่ โหมดนี้อาจใช้ฟีเจอร์อย่างTree Shaking เพื่อกำจัดโค้ดที่ไม่จำเป็นซึ่งบล็อกการแสดงผลที่สำคัญ
ทำงานในเทรดหลักน้อยลง
รายงานล่าสุดของคุณแสดงการประหยัดที่เป็นไปได้เล็กน้อยในส่วนโอกาส แต่หากคุณเลื่อนลงไปที่ส่วนการวินิจฉัย ดูเหมือนว่าปัญหาคอขวดที่สำคัญที่สุดคือกิจกรรมในเธรดหลักมากเกินไป
เทรดหลักคือที่ที่เบราว์เซอร์ทํางานส่วนใหญ่ที่จําเป็นในการแสดงหน้าเว็บ เช่น แยกวิเคราะห์และเรียกใช้ HTML, CSS และ JavaScript
เป้าหมายคือการใช้แผงประสิทธิภาพเพื่อวิเคราะห์สิ่งที่เธรดหลักทําขณะที่หน้าเว็บโหลด และหาวิธีเลื่อนหรือนํางานที่ไม่จําเป็นออก
เปิดประสิทธิภาพ > การตั้งค่าการจับภาพ และตั้งค่าเครือข่ายเป็น 3G ที่ช้าและ CPU เป็นช้าลง 6 เท่า
โดยทั่วไปอุปกรณ์เคลื่อนที่มีข้อจำกัดด้านฮาร์ดแวร์มากกว่าแล็ปท็อปหรือเดสก์ท็อป การตั้งค่าเหล่านี้จึงช่วยให้คุณเห็นการโหลดหน้าเว็บราวกับว่าคุณกำลังใช้อุปกรณ์ที่มีประสิทธิภาพน้อยกว่า
คลิก
โหลดซ้ำ เครื่องมือสำหรับนักพัฒนาเว็บจะโหลดหน้าเว็บซ้ำ จากนั้นจะแสดงภาพรวมของสิ่งที่ต้องทําทั้งหมดเพื่อโหลดหน้าเว็บ การแสดงภาพนี้จะเรียกว่าการติดตาม
การติดตามจะแสดงกิจกรรมตามลำดับเวลาจากซ้ายไปขวา แผนภูมิ FPS, CPU และ NET ที่ด้านบนจะแสดงภาพรวมของเฟรมต่อวินาที กิจกรรมของ CPU และกิจกรรมของเครือข่าย
แถบสีเหลืองที่คุณเห็นในส่วนภาพรวมหมายความว่า CPU ไม่ว่างเนื่องจากมีกิจกรรมสคริปต์ ข้อมูลนี้เป็นข้อบ่งชี้ว่าคุณสามารถเพิ่มความเร็วในการโหลดหน้าเว็บได้โดยเรียกใช้ JavaScript น้อยลง
ตรวจสอบการติดตามเพื่อหาวิธีลดการทำงานของ JavaScript
คลิกส่วนการกำหนดเวลาเพื่อขยาย
มีการวัดการกําหนดเวลาของผู้ใช้จํานวนมากจาก React ดูเหมือนว่าแอปของ Tony จะใช้โหมดการพัฒนาของ React การเปลี่ยนไปใช้โหมดการผลิตของ React อาจช่วยให้ประสบความสำเร็จได้ง่ายๆ
คลิกเวลาอีกครั้งเพื่อยุบส่วนนั้น
เรียกดูส่วนหลัก ส่วนนี้จะแสดงบันทึกกิจกรรมของเธรดหลักตามลำดับเวลาจากซ้ายไปขวา แกน Y (บนลงล่าง) จะแสดงสาเหตุที่เกิดเหตุการณ์
ในตัวอย่างนี้ เหตุการณ์
Evaluate Script
ทําให้ฟังก์ชัน(anonymous)
ทำงาน ซึ่งทําให้__webpack__require__
ทำงาน ซึ่งทําให้./src/index.jsx
ทำงาน และอื่นๆเลื่อนลงไปที่ด้านล่างของส่วนหลัก เมื่อคุณใช้เฟรมเวิร์ก กิจกรรมระดับบนส่วนใหญ่จะเกิดจากเฟรมเวิร์ก ซึ่งมักอยู่นอกเหนือการควบคุมของคุณ กิจกรรมที่เกิดจากแอปของคุณมักจะอยู่ที่ด้านล่าง
ในแอปนี้ ดูเหมือนว่าฟังก์ชันชื่อ
App
จะทําให้มีการเรียกใช้ฟังก์ชันmineBitcoin
เป็นจำนวนมาก ดูเหมือนว่า Tony อาจใช้อุปกรณ์ของแฟนๆ ในการขุดคริปโตเคอเรนซี...เปิดแท็บด้านล่างขึ้นที่ด้านล่าง แท็บนี้จะแสดงรายละเอียดกิจกรรมที่ใช้เวลามากที่สุด หากไม่เห็นข้อมูลใดๆ ในส่วนจากล่างขึ้นบน ให้คลิกป้ายกำกับของส่วนหลัก
ส่วนจากล่างขึ้นบนจะแสดงเฉพาะข้อมูลของกิจกรรมหรือกลุ่มกิจกรรมที่คุณเลือกอยู่ ตัวอย่างเช่น หากคุณคลิกกิจกรรม
mineBitcoin
รายการใดรายการหนึ่ง ส่วนจากล่างขึ้นบนจะแสดงข้อมูลของกิจกรรมนั้นรายการเดียวเท่านั้นคอลัมน์เวลาส่วนตัวแสดงจํานวนเวลาที่ใช้ในการดําเนินกิจกรรมแต่ละอย่างโดยตรง ในกรณีนี้ ใช้เวลาประมาณ 82% ของเทรดหลักในฟังก์ชัน
mineBitcoin
มาดูกันว่าการใช้โหมดเวอร์ชันที่ใช้งานจริงและการลดกิจกรรม JavaScript ช่วยเพิ่มความเร็วในการโหลดหน้าเว็บได้หรือไม่ เริ่มต้นด้วยโหมดที่ใช้งานจริง
- เปิด
webpack.config.js
ในแท็บเครื่องมือแก้ไข - เปลี่ยน
"mode":"development"
เป็น"mode":"production"
- รอให้บิลด์ใหม่ทำให้ใช้งานได้
ตรวจสอบหน้าเว็บอีกครั้ง
ลดกิจกรรม JavaScript ด้วยการนําการเรียก mineBitcoin
ออก
- เปิด
src/App.jsx
ในแท็บเครื่องมือแก้ไข - ยกเลิกการคอมเมนต์การเรียกใช้
this.mineBitcoin(1500)
ในconstructor
- รอให้บิวด์ใหม่ใช้งานได้
- ตรวจสอบหน้าเว็บอีกครั้ง
ยังคงมีสิ่งที่ต้องทํา เช่น ลดเมตริก Largest Contentful Paint และ Cumulative Layout Shift
ลดการทํางานของเทรดหลักในชีวิตจริง
โดยทั่วไปแล้ว แผงประสิทธิภาพเป็นวิธีที่พบบ่อยที่สุดในการทำความเข้าใจกิจกรรมที่เว็บไซต์ทำขณะโหลด และค้นหาวิธีนำกิจกรรมที่ไม่จำเป็นออก
หากต้องการแนวทางที่คล้ายกับ console.log()
มากกว่า User Timing API จะช่วยให้คุณทำเครื่องหมายระยะๆ ของวงจรของแอปได้ตามต้องการ เพื่อติดตามระยะเวลาของแต่ละระยะ
สรุป
- เมื่อใดก็ตามที่คุณต้องการเพิ่มประสิทธิภาพการโหลดของเว็บไซต์ ให้เริ่มต้นด้วยการตรวจสอบเสมอ การตรวจสอบจะสร้างเส้นฐานและให้เคล็ดลับในการปรับปรุง
- เปลี่ยนแปลงทีละรายการ และตรวจสอบหน้าเว็บหลังจากการเปลี่ยนแปลงแต่ละครั้งเพื่อดูว่าการเปลี่ยนแปลงที่แยกออกมานั้นส่งผลต่อประสิทธิภาพอย่างไร
ขั้นตอนถัดไป
เรียกใช้การตรวจสอบในเว็บไซต์ของคุณเอง หากต้องการความช่วยเหลือในการตีความรายงานหรือหาวิธีปรับปรุงประสิทธิภาพในการโหลด ลองดูวิธีทั้งหมดที่จะรับความช่วยเหลือจากชุมชนเครื่องมือสำหรับนักพัฒนาเว็บได้ ดังนี้
- รายงานข้อบกพร่องในเอกสารนี้ในที่เก็บข้อมูล developer.chrome.com
- รายงานข้อบกพร่องใน DevTools ที่หัวข้อข้อบกพร่องของ Chromium
- พูดคุยเกี่ยวกับฟีเจอร์และการเปลี่ยนแปลงในรายชื่ออีเมล โปรดอย่าใช้รายชื่ออีเมลสำหรับคำถามเกี่ยวกับการสนับสนุน โปรดใช้ Stack Overflow แทน
- รับความช่วยเหลือทั่วไปเกี่ยวกับวิธีใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Stack Overflow หากต้องการยื่นคำขอข้อบกพร่อง ให้ใช้ข้อบกพร่องของ Chromium เสมอ
- โปรดทวีตหาเราที่ @ChromeDevTools