13 ผลลัพธ์
เว็บไซต์สมัยใหม่มักไล่ลดขนาดไฟล์ แต่ละเลยจำนวนคำขอ วิธีแก้ที่มักเร็วกว่า คือส่งคำขอให้น้อยลงและจัดจังหวะให้ดีกว่าเดิม
TTFB ที่ช้ามักหมายถึงการกำหนดเส้นทางที่ช้า, แคชที่หายไป, เซิร์ฟเวอร์รับภาระเกิน หรือการทำงานฝั่ง backend ที่มีต้นทุนสูง ต่อไปนี้คือวิธีวินิจฉัยและแก้ไข
เลือกวิดีโอโคเดกสำหรับเว็บจากกลุ่มผู้ชม การรองรับของอุปกรณ์ เป้าหมายด้านคุณภาพ ต้นทุนการเข้ารหัส และรูปแบบการส่งมอบ ไม่ใช่จากกราฟการบีบอัดเพียงอย่างเดียว
Core Web Vitals วัดการโหลด ความตอบสนอง และความเสถียรของภาพ นี่คือความหมายของ LCP, INP และ CLS ในเชิงปฏิบัติ
คู่มือเชิงปฏิบัติสำหรับ preload, prefetch และ preconnect: แต่ละ hint ทำอะไร ช่วยเมื่อใด และเมื่อใดควรปล่อยไว้เฉย ๆ
WebP แบบ lossless มักมีขนาดไฟล์เล็กกว่า PNG แต่ไม่เสมอไป ต่อไปนี้คือกรณีที่มันช่วยได้ กรณีที่ไม่ช่วย และวิธีทดสอบอย่างถูกต้อง
Self-host Google Fonts เพื่อลดคำขอไปยังบุคคลที่สาม ปรับปรุงท่าทีด้านความเป็นส่วนตัว และควบคุมประสิทธิภาพได้ดียิ่งขึ้น
Variable fonts มีพลังมาก แต่ผลลัพธ์ใน production ขึ้นอยู่กับ subsetting, caching, rendering, วินัยในการใช้ CSS และความยับยั้งชั่งใจด้านดีไซน์
บีบอัดเสียงบนเว็บให้ดีด้วยการเลือก codec, bitrate, เวิร์กโฟลว์ของไฟล์ต้นฉบับ และการทดสอบการฟังที่เหมาะสม—not by crushing everything to MP3.
Lazy loading จะช่วยปรับปรุงการโหลดหน้าได้ก็ต่อเมื่อมันเลื่อนงานที่ไม่สำคัญออกไป ใช้กับสื่อที่อยู่ below the fold ไม่ใช่รูปภาพ LCP ของคุณ
รายงาน Lighthouse มีรายละเอียดหนาแน่นและดูน่ากดดัน นี่คือวิธีแยกสัญญาณออกจากสัญญาณรบกวน และจัดลำดับความสำคัญของการแก้ไขที่ช่วยปรับปรุงประสบการณ์ผู้ใช้ได้จริง
เว็บไซต์ที่ช้าส่วนใหญ่มีสิ่งหนึ่งเหมือนกัน: ส่งน้ำหนักฟอนต์มากกว่าที่หน้าเว็บใช้งานจริง ใช้ฟอร์แมตที่เก่ากว่าที่จำเป็น และไม่มีแผนสำหรับฟอนต์สำรอง วิธีแก้ใช้เวลาทำงานครึ่งวัน
