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

Sofia Emelianova
Sofia Emelianova

ภาพรวม

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

  • ประสิทธิภาพ
  • การช่วยเหลือพิเศษ
  • แนวทางปฏิบัติแนะนำ
  • SEO

... และเมตริกอื่นๆ อีกมากมาย

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

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

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

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

อ่านต่อหรือดูบทแนะนำเวอร์ชันวิดีโอ

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

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

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

บทนำ

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

แมว Tony

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

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

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

ตั้งค่า

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

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

    แหล่งที่มาต้นฉบับและแท็บเครื่องมือแก้ไขหลังจากคลิก "รีมิกซ์"

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

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

    แท็บเดโม

  3. เปิดเครื่องมือสำหรับนักพัฒนาเว็บควบคู่ไปกับการแสดงตัวอย่าง

    เครื่องมือสําหรับนักพัฒนาเว็บและเดโม

กำหนดพื้นฐาน

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

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

    แผง Lighthouse

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

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

    รายงาน Lighthouse เกี่ยวกับประสิทธิภาพของเว็บไซต์

การจัดการข้อผิดพลาดของรายงาน

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

รายงานที่มีข้อผิดพลาด

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

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

คะแนนประสิทธิภาพโดยรวม

เมตริก

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

ส่วนเมตริก

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

ภาพหน้าจอ

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

ภาพหน้าจอที่แสดงลักษณะของหน้าเว็บขณะโหลด

โอกาส

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

ส่วนโอกาส

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

ข้อมูลเพิ่มเติมเกี่ยวกับโอกาสในการบีบอัดข้อความ

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

การวินิจฉัย

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

ส่วนการวินิจฉัย

ผ่านการตรวจสอบ

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

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

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

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

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

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

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

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

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

คอลัมน์ขนาดในแผงเครือข่ายที่แสดงแถวคำขอขนาดใหญ่

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

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

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

    แท็บส่วนหัว

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

จบคำอธิบาย ถึงเวลาเปลี่ยนแปลงแล้ว เปิดใช้การบีบอัดข้อความโดยเพิ่มโค้ด 2-3 บรรทัดดังนี้

  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'))

    การแก้ไข server.js

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

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

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

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

    ตอนนี้คอลัมน์ขนาดจะแสดงค่าที่แตกต่างกัน 2 ค่าสําหรับทรัพยากรข้อความ

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

    ตอนนี้ส่วนหัวการตอบกลับมีส่วนหัว "content-encoding" แล้ว

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

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

    ปุ่ม "ดําเนินการตรวจสอบ"

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

    รายงาน Lighthouse หลังจากเปิดใช้การบีบอัดข้อความ

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

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

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

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

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

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

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

    รายละเอียดเกี่ยวกับโอกาสในการ "ปรับขนาดรูปภาพให้เหมาะสม"

  2. กลับไปที่แท็บเครื่องมือแก้ไข แล้วเปิด src/model.js

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

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

    รายงาน Lighthouse หลังจากปรับขนาดรูปภาพ

ดูเหมือนว่าการเปลี่ยนแปลงจะมีผลเพียงเล็กน้อยต่อคะแนนประสิทธิภาพโดยรวม อย่างไรก็ตาม คะแนนนี้ไม่ได้แสดงอย่างชัดเจนถึงปริมาณข้อมูลเครือข่ายที่คุณช่วยประหยัดให้กับผู้ใช้ ขนาดรวมของรูปภาพเก่าอยู่ที่ประมาณ 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 แล้วเลือกแสดงความครอบคลุม

    การเปิดเมนูคำสั่งจากแผง Lighthouse

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

    แท็บความครอบคลุม

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

    รายงานการครอบคลุม

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

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

    การดูไฟล์ jQuery ในแผงแหล่งที่มา

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

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

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

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

    แท็บการบล็อกคำขอ

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

    การเพิ่มรูปแบบเพื่อบล็อกคําขอไปยังไดเรกทอรี "libs"

  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 คะแนนโดยรวมควรดีขึ้นอีกครั้ง

    รายงาน Lighthouse หลังจากนําทรัพยากรที่บล็อกการแสดงผลออก

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

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

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

ทำงานในเทรดหลักน้อยลง

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

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

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

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

    การตั้งค่าการจำกัด CPU และเครือข่ายในแผงประสิทธิภาพ

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

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

    การติดตามการโหลดหน้าเว็บของแผงประสิทธิภาพ

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

ส่วนภาพรวมของการติดตาม

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

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

  1. คลิกส่วนการกำหนดเวลาเพื่อขยาย

    ส่วน &quot;ช่วงเวลา&quot;

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

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

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

    ส่วนหลัก

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

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

    กิจกรรม mineBitcoin

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

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

    แท็บ &quot;ล่างขึ้นบน&quot;

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

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

มาดูกันว่าการใช้โหมดเวอร์ชันที่ใช้งานจริงและการลดกิจกรรม JavaScript ช่วยเพิ่มความเร็วในการโหลดหน้าเว็บได้หรือไม่ เริ่มต้นด้วยโหมดที่ใช้งานจริง

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

    รายงาน Lighthouse หลังจากกําหนดค่า webpack ให้ใช้โหมดเวอร์ชันที่ใช้งานจริง

ลดกิจกรรม JavaScript โดยการนําการเรียก mineBitcoin ออก

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

รายงาน Lighthouse หลังจากนำการทํางานที่ไม่จําเป็นใน JavaScript ออก

ยังคงมีสิ่งที่ต้องทํา เช่น ลดเมตริก Largest Contentful Paint และ Cumulative Layout Shift

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

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

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

สรุป

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

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

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

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