เป้าหมายของบทแนะนำ
บทแนะนำนี้จะสอนวิธีใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อหาวิธีทำให้เว็บไซต์โหลดเร็วขึ้น
อ่านต่อ หรือดูวิดีโอบทแนะนำนี้:
สิ่งที่ต้องดำเนินการก่อน
คุณควรมีประสบการณ์การพัฒนาเว็บขั้นพื้นฐาน เช่นเดียวกับที่สอนในชั้นเรียนข้อมูลเบื้องต้นเกี่ยวกับการพัฒนาเว็บนี้
คุณไม่จำเป็นต้องทราบเกี่ยวกับประสิทธิภาพการโหลด
เกริ่นนำ
และ Tony จะเป็นผู้ดูแลคุณในวันนี้ โทนี่มีชื่อเสียงมากในสังคมแมว เขาสร้างเว็บไซต์เพื่อให้แฟนๆ ได้ทราบว่าอาหารที่เขาชื่นชอบมีอะไรบ้าง แฟนๆ ของเขาชอบเว็บไซต์นี้ แต่โทนียังคงได้ยินบ่นอยู่ว่าเว็บไซต์โหลดช้า ธนาขอให้คุณช่วยเขาเพิ่มความเร็วเว็บไซต์
![](https://developer.chrome.com/static/docs/devtools/lighthouse/image/tony-cat-e1c9e37033804.jpg?authuser=5&hl=th)
ขั้นตอนที่ 1: ตรวจสอบเว็บไซต์
เมื่อใดก็ตามที่คุณเริ่มปรับปรุงประสิทธิภาพการโหลดของเว็บไซต์ ให้เริ่มต้นด้วยการตรวจสอบเสมอ การตรวจสอบมีหน้าที่สำคัญ 2 ประการดังนี้
- ซึ่งเป็นการสร้างเกณฑ์พื้นฐานเพื่อให้คุณวัดการเปลี่ยนแปลงหลังจากนั้น
- พร้อมด้วยเคล็ดลับที่นำไปใช้ได้จริงเพื่อดูว่าการเปลี่ยนแปลงใดจะส่งผลกระทบมากที่สุด
ตั้งค่า
ก่อนอื่น คุณต้องตั้งค่าสภาพแวดล้อมในการทำงานใหม่สำหรับเว็บไซต์ของ Tony เพื่อทำการเปลี่ยนแปลงในภายหลังได้
รีมิกซ์โปรเจ็กต์ของเว็บไซต์ใน Glitch โปรเจ็กต์ใหม่จะเปิดขึ้นในแท็บ แท็บนี้จะเรียกว่าแท็บเครื่องมือแก้ไข
ชื่อของโปรเจ็กต์จะเปลี่ยนจาก tony เป็นชื่อที่สร้างขึ้นแบบสุ่ม ตอนนี้คุณมีสำเนาโค้ดที่แก้ไขได้ของคุณเองแล้ว คุณจะเปลี่ยนแปลงโค้ดนี้ในภายหลัง
ที่ด้านล่างแท็บตัวแก้ไข ให้คลิกแสดงตัวอย่าง > แสดงตัวอย่างในหน้าต่างใหม่ การสาธิตจะเปิดขึ้นในแท็บใหม่ แท็บนี้จะเรียกว่าแท็บสาธิต ระบบอาจใช้เวลาสักพักในการโหลดเว็บไซต์
เปิดเครื่องมือสำหรับนักพัฒนาเว็บควบคู่ไปกับการสาธิต
สร้างเกณฑ์พื้นฐาน
เกณฑ์พื้นฐานคือบันทึกประสิทธิภาพของเว็บไซต์ก่อนที่คุณจะทำการปรับปรุงประสิทธิภาพใดๆ
เปิดแผง Lighthouse อาจซ่อนอยู่หลัง
แผงอื่นๆจับคู่การตั้งค่ากำหนดรายงาน Lighthouse ให้ตรงกับการตั้งค่าในภาพหน้าจอ คำอธิบายตัวเลือกต่างๆ มีดังนี้
- check_box ล้างพื้นที่เก็บข้อมูล การเปิดใช้ช่องทำเครื่องหมายนี้จะล้างพื้นที่เก็บข้อมูลทั้งหมดที่เชื่อมโยงกับหน้าดังกล่าวก่อนการตรวจสอบทุกครั้ง เปิดการตั้งค่านี้ไว้หากต้องการตรวจสอบว่าผู้เข้าชมครั้งแรกได้รับประสบการณ์อย่างไรจากเว็บไซต์ของคุณ ปิดใช้การตั้งค่านี้เมื่อต้องการประสบการณ์การเข้าชมซ้ำ
- check_box เปิดใช้การสุ่มตัวอย่าง JS ตัวเลือกนี้จะปิดอยู่โดยค่าเริ่มต้น เมื่อเปิดใช้ ระบบจะเพิ่มสแต็กการเรียกใช้ JavaScript แบบละเอียดลงในการติดตามประสิทธิภาพ แต่อาจชะลอการสร้างรายงาน การติดตามจะอยู่ใน more_vert เมนูเครื่องมือ > ดูการติดตามที่ไม่มีการควบคุมหลังจากสร้างรายงาน Lighthouse
- การควบคุมจำลอง (ค่าเริ่มต้น) ตัวเลือกนี้จะจำลองเงื่อนไขโดยทั่วไปของการเรียกดูบนอุปกรณ์เคลื่อนที่ วิธีนี้เรียกว่า "จำลอง" เนื่องจาก Lighthouse ไม่ได้ควบคุมการทำงานในระหว่างกระบวนการตรวจสอบ แต่เป็นเพียงการสรุปว่าหน้าเว็บจะใช้เวลาโหลดนานเท่าไรภายใต้สภาวะที่มีอุปกรณ์เคลื่อนที่ ในทางตรงกันข้าม การตั้งค่าการควบคุมเครื่องมือสำหรับนักพัฒนาเว็บ (ขั้นสูง) จะจำกัดการใช้งาน CPU และเครือข่ายของคุณ แต่จะต้องเลือกระหว่างกระบวนการตรวจสอบที่ยาวนานขึ้น
- โหมด > ทั้ง 3 โหมด การนำทาง (ค่าเริ่มต้น) โหมดนี้จะวิเคราะห์การโหลดหน้าเว็บ 1 ครั้ง และนั่นคือสิ่งที่เราต้องการในบทแนะนำนี้ ดูข้อมูลเพิ่มเติมได้ที่
- อุปกรณ์ > อุปกรณ์เคลื่อนที่ ตัวเลือกอุปกรณ์เคลื่อนที่จะเปลี่ยนสตริง User Agent และจำลองวิวพอร์ตของอุปกรณ์เคลื่อนที่ ตัวเลือกบนเดสก์ท็อปจะเพียงแค่ปิดใช้การเปลี่ยนแปลงบนอุปกรณ์เคลื่อนที่เท่านั้น
- หมวดหมู่ > check_box ประสิทธิภาพ หมวดหมู่ที่เปิดใช้เพียงหมวดหมู่เดียวทำให้ 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 ที่เหลือ
- คุณมักจะไม่พบสคริปต์ที่นำออกได้เลย แต่ก็มักจะพบว่าไม่จำเป็นต้องขอสคริปต์จำนวนมากระหว่างการโหลดหน้าเว็บ และสามารถขอแบบไม่พร้อมกันแทนได้ โปรดดูหัวข้อการใช้อะซิงโครนัสหรือเลื่อนเวลาออกไป
- หากใช้เฟรมเวิร์ก โปรดตรวจสอบว่าเฟรมเวิร์กมีโหมดการใช้งานจริงหรือไม่ โหมดนี้อาจใช้ฟีเจอร์อย่างเช่นการเขย่าต้นไม้ เพื่อกำจัดโค้ดที่ไม่จำเป็นซึ่งบล็อกการแสดงภาพวิกฤติ
ลดงานเทรดหลัก
รายงานล่าสุดแสดงให้เห็นถึงการประหยัดค่าใช้จ่ายได้เล็กน้อยในส่วนโอกาส แต่หากคุณเลื่อนลงไปที่ส่วนการวินิจฉัย ดูเหมือนว่าจุดคอขวดที่ใหญ่ที่สุดคือกิจกรรมของเทรดหลักมากเกินไป
เทรดหลักคือส่วนที่เบราว์เซอร์ทำงานส่วนใหญ่ที่จำเป็นต่อการแสดงหน้าเว็บ เช่น การแยกวิเคราะห์และเรียกใช้ HTML, CSS และ JavaScript
เป้าหมายคือการใช้แผงประสิทธิภาพเพื่อวิเคราะห์งานที่เทรดหลักกําลังทําในขณะที่โหลดหน้าเว็บ และหาวิธีเลื่อนหรือนำงานที่ไม่จำเป็นออก
เปิดประสิทธิภาพ >
การตั้งค่าการจับภาพ และตั้งค่าเครือข่ายเป็น 3G ที่ช้าและ CPU เป็นช้าลง 6 เท่า
อุปกรณ์เคลื่อนที่มักจะมีข้อจำกัดด้านฮาร์ดแวร์มากกว่าแล็ปท็อปหรือเดสก์ท็อป ดังนั้นการตั้งค่าเหล่านี้จึงช่วยให้คุณโหลดหน้าเว็บได้ราวกับกำลังใช้อุปกรณ์ที่มีประสิทธิภาพต่ำกว่า
คลิกรีเฟรช โหลดซ้ำ เครื่องมือสำหรับนักพัฒนาเว็บจะโหลดหน้าเว็บซ้ำ แล้วสร้างภาพของสิ่งที่ต้องทำเพื่อโหลดหน้าเว็บ การแสดงภาพนี้จะเรียกว่าtrace
การติดตามจะแสดงกิจกรรมตามลำดับเวลาจากซ้ายไปขวา แผนภูมิ 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
- ส่งรายงานข้อบกพร่องเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บไว้ที่ข้อบกพร่องของ Chromium
- พูดคุยเกี่ยวกับฟีเจอร์และการเปลี่ยนแปลงในรายชื่ออีเมล โปรดอย่าใช้รายชื่ออีเมลสำหรับคำถามเกี่ยวกับการสนับสนุน โปรดใช้ Stack Overflow แทน
- รับความช่วยเหลือทั่วไปเกี่ยวกับวิธีใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Stack Overflow หากต้องการยื่นคำขอข้อบกพร่อง ให้ใช้ข้อบกพร่องของ Chromium เสมอ
- ทวีตถึงเราที่ @ChromeDevTools