เป้าหมายของบทแนะนำ
บทแนะนำนี้จะสอนวิธีใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อหาวิธีทำให้เว็บไซต์โหลดเร็วขึ้น
อ่านต่อหรือดูวิดีโอบทแนะนำนี้
ข้อกำหนดเบื้องต้น
คุณจะต้องมีประสบการณ์การพัฒนาเว็บขั้นพื้นฐาน ซึ่งคล้ายกับสิ่งที่สอนในชั้นเรียนความรู้เบื้องต้นเกี่ยวกับการพัฒนาเว็บนี้
คุณไม่จำเป็นต้องทราบข้อมูลใดๆ เกี่ยวกับประสิทธิภาพการโหลด
เกริ่นนำ
และ Tony จะเป็นผู้ดูแลคุณในวันนี้ Tony มีชื่อเสียงมากในสังคมแมว เขาได้สร้างเว็บไซต์เพื่อให้แฟนๆ ได้เรียนรู้ว่าอาหารโปรดของเขาคืออะไร แฟนๆ ของเขาชอบเว็บไซต์ แต่ธเนศวร์ก็ได้ยินคำบ่นมาตลอดว่าเว็บไซต์โหลดช้า ธเนศวขอให้คุณช่วยเร่งความเร็วเว็บไซต์
ขั้นตอนที่ 1: ตรวจสอบเว็บไซต์
เมื่อใดก็ตามที่คุณตั้งใจเริ่มปรับปรุงประสิทธิภาพการโหลดของเว็บไซต์ ให้เริ่มต้นด้วยการตรวจสอบเสมอ การตรวจสอบนี้มีหน้าที่สำคัญ 2 ประการ ได้แก่
- ซึ่งจะสร้างเกณฑ์พื้นฐานเพื่อให้คุณใช้วัดการเปลี่ยนแปลงที่ตามมา
- และมอบเคล็ดลับที่นำไปใช้ได้จริงว่าการเปลี่ยนแปลงใดจะมีผลกระทบมากที่สุด
ตั้งค่า
ก่อนอื่น คุณต้องตั้งค่าสภาพแวดล้อมการทำงานใหม่สำหรับเว็บไซต์ของ Toy เพื่อให้คุณทำการเปลี่ยนแปลงในภายหลังได้
รีมิกซ์โปรเจ็กต์ของเว็บไซต์ใน Glitch โปรเจ็กต์ใหม่จะเปิดขึ้นในแท็บ แท็บนี้จะเรียกว่าแท็บตัวแก้ไข
ชื่อโปรเจ็กต์เปลี่ยนจาก tony เป็นชื่อที่สร้างขึ้นแบบสุ่ม ตอนนี้คุณมีสำเนาโค้ดที่แก้ไขได้ของคุณเองแล้ว คุณจะเปลี่ยนแปลงโค้ดนี้ในภายหลัง
ที่ด้านล่างของแท็บตัวแก้ไข ให้คลิกแสดงตัวอย่าง > แสดงตัวอย่างในหน้าต่างใหม่ เดโมจะเปิดขึ้นในแท็บใหม่ แท็บนี้จะเรียกว่าแท็บสาธิต อาจใช้เวลาสักพักกว่าเว็บไซต์จะโหลด
เปิดเครื่องมือสำหรับนักพัฒนาเว็บข้างๆ การสาธิต
สร้างเกณฑ์พื้นฐาน
เกณฑ์พื้นฐานคือบันทึกประสิทธิภาพของเว็บไซต์ก่อนที่คุณจะทำการปรับปรุงประสิทธิภาพใดๆ
เปิดแผง Lighthouse อาจซ่อนอยู่หลัง
แผงเพิ่มเติมปรับการกำหนดค่ารายงาน 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 บรรทัดดังนี้
ในแท็บตัวแก้ไข ให้เปิด
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
เพื่อโหลดหน้าเว็บไหม แท็บคำขอการบล็อกจะแสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อทรัพยากรไม่พร้อมใช้งาน
- คลิกแท็บ Network แล้วเปิดเมนูคำสั่งอีกครั้ง
เริ่มพิมพ์
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 มากมาย ดูเหมือนว่าแอปของธเนศวร์กำลังใช้โหมดการพัฒนาของ React การเปลี่ยนไปใช้โหมดการใช้งานจริงของ React อาจทำให้บรรลุเป้าหมายด้านประสิทธิภาพได้อย่างง่ายดาย
คลิกระยะเวลาอีกครั้งเพื่อยุบส่วนนั้น
เรียกดูส่วนหลัก ส่วนนี้จะแสดงบันทึกตามลำดับเวลาของกิจกรรมเทรดหลัก จากซ้ายไปขวา แกน Y (บนลงล่าง) แสดงสาเหตุที่เกิดเหตุการณ์
ในตัวอย่างนี้ เหตุการณ์
Evaluate Script
ทำให้ฟังก์ชัน(anonymous)
ทำงาน ซึ่งทำให้__webpack__require__
ทำงาน ซึ่งเป็นผลให้./src/index.jsx
ทำงาน เป็นต้นเลื่อนลงไปที่ด้านล่างของส่วนหลัก เมื่อใช้เฟรมเวิร์ก กิจกรรมส่วนบนส่วนใหญ่เกิดจากเฟรมเวิร์ก ซึ่งโดยปกติแล้วจะอยู่นอกเหนือการควบคุม กิจกรรมที่เกิดจากแอปของคุณมักจะอยู่ด้านล่าง
ในแอปนี้ ดูเหมือนว่าฟังก์ชันที่ชื่อว่า
App
ทำให้มีการเรียกฟังก์ชันmineBitcoin
เป็นจำนวนมาก ดูเหมือนว่าโทนีใช้อุปกรณ์ของแฟนๆ ในการขุดคริปโตเคอเรนซี...เปิดแท็บล่างขึ้นบนที่ด้านล่าง แท็บนี้จะแสดงกิจกรรมที่ใช้เวลามากที่สุด หากไม่เห็นอะไรในส่วนล่างขึ้นบน ให้คลิกป้ายกำกับสำหรับส่วนหลัก
ส่วนล่างขึ้นบนจะแสดงเฉพาะข้อมูลกิจกรรมหรือกลุ่มกิจกรรมใดๆ ที่คุณได้เลือกไว้เท่านั้น ตัวอย่างเช่น หากคุณคลิกกิจกรรมใดกิจกรรมหนึ่งของ
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