แนวคิดขั้นสูงสำหรับการวัดความเร็วเพจในปี 2020

เผยแพร่แล้ว: 2020-04-09

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

เนื่องจากเว็บไซต์และเว็บเบราว์เซอร์มีความซับซ้อนมากขึ้น ความเร็วของหน้าจึงเป็นมากกว่าแค่หน้าเพจขนาดใหญ่หรือเซิร์ฟเวอร์ตอบสนองได้เร็วเพียงใด ในบทความนี้ เราจะพิจารณาเมตริกใหม่และที่เกิดขึ้นใหม่สำหรับความเร็วหน้าเว็บในปี 2020 และปีต่อๆ ไป: จำนวนและขนาดของคำขอทรัพยากร เส้นทางการแสดงผลที่สำคัญ LCP, CLS และเวลาบล็อกทั้งหมด

บทความนี้เป็นบทความที่สองในชุดบทความสี่บทความเกี่ยวกับความเร็วของหน้า คุณสามารถค้นหาบทความแรกได้ที่นี่: เบราว์เซอร์สร้างหน้าเว็บได้อย่างไร

การจัดการคำสั่ง ขนาด และจำนวนคำขอทรัพยากร

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

ซึ่งหมายความว่าลำดับ จำนวน และขนาดของคำขอมีบทบาทสำคัญในการวัดความเร็วของหน้าในปัจจุบัน

การสนับสนุนที่สำคัญที่สุดของลำดับทรัพยากรและการเพิ่มประสิทธิภาพคำแนะนำในการโหลดทรัพยากรคือการลด TTI (Time to Interactive) ผ่าน Largest Contentful Paint ด้วยการเพิ่มประสิทธิภาพลำดับทรัพยากร คุณสามารถอัปโหลดไฟล์ที่มีหมายเลขเดียวกันและขนาดเท่ากันได้ในเวลาอันสั้น และส่งไปยังผู้ใช้และเครื่องมือค้นหา

เส้นทางการแสดงผลที่สำคัญคืออะไร?

เส้นทางการแสดงผลที่สำคัญประกอบด้วยทรัพยากรทั้งหมดที่จะสร้างส่วนของหน้าเว็บในครึ่งหน้าบน

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

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

นี่คือเครื่องจำลองความสัมพันธ์ความเร็วของหน้าและอัตราการแปลงซึ่งสร้างโดย Sergey Chernyshev คุณอาจพบคำตอบสำหรับคำถามว่าจะเกิดอะไรขึ้นหากหน้าเว็บของฉันโหลดเร็วขึ้น 0.5 วินาทีสำหรับผู้ใช้ และแสดงให้ทีมนักพัฒนาของคุณทราบเพื่อระบุว่าทุก ๆ มิลลิวินาทีสามารถปรับปรุงการแปลงได้

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

  1. แหล่งข้อมูลใดบ้างที่ป้องกันไม่ให้เบราว์เซอร์ดาวน์โหลดแหล่งข้อมูลที่สำคัญ
  2. สามารถลดขนาดและจำนวนของแหล่งที่มาที่สำคัญได้หรือไม่?
  3. สามารถแทรกแหล่งข้อมูลที่สำคัญได้หรือไม่
  4. แหล่งที่มาของเส้นทางการแสดงผลที่สำคัญสามารถรวมกันเพื่อจำกัดกระบวนการค้นหา DNS ได้หรือไม่

เราจะดูตัวอย่าง นอกจากนี้เรายังจะให้คำแนะนำสำหรับการเร่ง CSS, JS และ HTML

นี่คือตัวอย่างส่วนที่สำคัญจากหน้าเว็บของ Amazon ด้วย DevTools คุณสามารถดูองค์ประกอบ <div> ที่สำคัญที่สุดในส่วนสำคัญของหน้าพร้อมกับโค้ด CSS ที่จำเป็น ด้วยวิธีนี้ คุณสามารถสร้างบล็อกโค้ด CSS แบบอินไลน์ได้ก่อนที่จะแสดงทรัพยากรที่บล็อกการบล็อกรบกวนเบราว์เซอร์ คุณอาจเห็นรหัสกองซ้อนที่ด้านล่าง Amazon ใช้รูปแบบทรัพยากร CSS/JS เดียวกันสำหรับหมวดหมู่ต่างๆ เสมอ แม้ว่าจะไม่ได้รับการปรับให้เหมาะสมก็ตาม

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

คุณสามารถใช้ Puppeteer (เครื่องมือรวบรวมข้อมูลของ Googlebot) เพื่อตรวจสอบปัญหาประเภทนี้และถ่ายภาพหน้าจออัตโนมัติสำหรับสมาร์ทโฟน/แท็บเล็ตทุกรุ่น และตรวจสอบการออกแบบส่วนสำคัญของหน้าเว็บ Jean-Francois Lagarde มีห้องสมุด Puppeteer ที่ดีสำหรับงานนี้ ซึ่งคุณอาจต้องการลองดู

นี่คือภาพหน้าจอสั้นๆ สำหรับการกำหนดค่าอุปกรณ์ในหน้าจออัตโนมัติของ Puppeteer สำหรับเครื่องมือวิวพอร์ตของอุปกรณ์ทุกเครื่อง

อะไรคือสีที่มีเนื้อหามากที่สุด?

Largest Contentful Paint (LCP) คือพื้นที่ที่ใหญ่ที่สุดในหน้าเว็บในแง่ของจำนวนไบต์และขนาด ในทุกหน้าเว็บมีองค์ประกอบ "div" มากมาย และองค์ประกอบทั้งหมดมีองค์ประกอบของหน้าที่แตกต่างกัน และส่วนประกอบเหล่านี้มีค่าการโหลดหน้าเว็บที่แตกต่างกัน

Google ระบุว่า Largest Contentful Paint ส่วนใหญ่ได้รับผลกระทบจากองค์ประกอบที่สำคัญที่สุดของหน้า เพื่อให้คุณได้ทราบถึงความสำคัญของ LCP นั้น Google ได้ตัดสินใจเพิ่มตัวชี้วัดใหม่นี้ในรายงานของ Lighthouse ในอนาคต

นอกจากนี้ยังหมายความว่าเราจะได้ยินเกี่ยวกับ LCP มากขึ้นเรื่อยๆ เนื่องจากจะใช้ร่วมกับ Real User Metrics (RUM) และจะเป็นตัวชี้วัดหลัก โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับเส้นทางการแสดงผลที่สำคัญ

นี่คือตัวอย่าง Contentful Paint ที่ใหญ่ที่สุดจาก Lendio อย่างที่คุณเห็น DevTools จะแสดง LCP บนหน้าพร้อมกับข้อมูลเกี่ยวกับประเภท ขนาด และเวลาในการโหลด เนื้อหาของ Largest Contentful Paint ควรมีจุดประสงค์และคุณค่าของหน้า ควบคู่ไปกับฟังก์ชันที่สำคัญที่สุดหรือ CTA และที่สำคัญที่สุด ควรโหลดไว้ก่อน!

ในตัวอย่างนี้ เป็นเพียงข้อความเท่านั้น การรวมเข้ากับเครื่องมือที่ใช้งานได้ดีกว่า LCP แบบข้อความ/รูปภาพ

LCP พิจารณาเฉพาะทรัพยากรบางประเภทเท่านั้น เหตุผลหลักคือทำให้การวัด LCP เรียบง่ายในตอนแรก ด้านล่างนี้คือ “อินสแตนซ์สคริปต์” ซึ่งประทับตราเพื่อสร้างรายการ LCP การศึกษาโค้ดเหล่านี้จะสอนคุณว่า Google Developers ให้ความสนใจกับสิ่งใดและอย่างไรเมื่อโหลดหน้าเว็บ

[เปิดเผย=หน้าต่าง]
ส่วนต่อประสาน LargestContentfulPaint : PerformanceEntry {
แอตทริบิวต์แบบอ่านอย่างเดียว DOMHighResTimeStamp renderTime;
แอตทริบิวต์แบบอ่านอย่างเดียว DOMHighResTimeStamp loadTime;
แอตทริบิวต์อ่านอย่างเดียวขนาดยาวที่ไม่ได้ลงนาม
id แอตทริบิวต์แบบอ่านอย่างเดียว DOMString id;
แอตทริบิวต์แบบอ่านอย่างเดียว DOMString url;
องค์ประกอบแอตทริบิวต์แบบอ่านอย่างเดียว? องค์ประกอบ;
[ค่าเริ่มต้น] วัตถุ toJSON();
};

สิ่งที่คุณเห็นในรายการนี้คือมาตราส่วนที่จำเป็นสำหรับการเปรียบเทียบรายการตัวเลือกที่เข้าสู่รายการรายการ LCP ด้านล่างนี้ ฉันจะแสดงวิธีการในการเลือกผู้สมัครสอบ LCP (“ข้อความเนื้อหาขนาดใหญ่” และ “รูปภาพขนาดใหญ่”)

ทำความเข้าใจหลักการและกระบวนการกำหนด LCP . ของคุณ

หลักการในการพิจารณา LCP มีความสำคัญอย่างยิ่ง:

  • ขณะโหลดหน้า LCP สามารถเปลี่ยนแปลงได้ในไม่กี่วินาที บางครั้ง แม้ว่าองค์ประกอบของหน้าจะยาวเพียงพอเท่ากับ LCP บนหน้าจอ แม้แต่องค์ประกอบหน้าที่ใหญ่กว่าที่โหลดอยู่เบื้องหลังก็ไม่เปลี่ยนสถานะก่อนหน้า
  • บางครั้ง องค์ประกอบครึ่งหน้าบน (ในส่วนสำคัญของหน้าเว็บ) จะถูกเลือกเป็น LCP แทนที่จะเป็นรายการขนาดใหญ่ที่อยู่ครึ่งหน้าล่าง (ส่วนที่ไม่สำคัญของหน้าเว็บ)
  • ไม่สามารถเลือกองค์ประกอบขนาดใหญ่ <div> เป็น LCP ได้หากส่วนประกอบถูกแบ่งบนหน้าจอ แต่จะเลือกองค์ประกอบบล็อก <div> เป็น LCP แทน ด้านล่างคุณจะเห็นตัวอย่างที่แสดงสิ่งนี้

ในตัวอย่างนี้ เราจะเห็นว่าองค์ประกอบที่ใหญ่ที่สุดคือ <div> ซึ่งประกอบด้วยรูปภาพสี่รูปที่แตกต่างกัน แต่ไม่มีรูปภาพใดที่ใหญ่กว่าโลโก้ Oncrawl และข้อความที่รวมอยู่ในองค์ประกอบ <div> เดียวกัน เนื่องจากทั้งคู่อยู่ในส่วนสำคัญของหน้าเว็บ องค์ประกอบที่สองจะเป็น LCP

ขณะคำนวณเวลา LCP และกำหนดมุมมองของ Google Developers คุณควรเน้นที่การออกแบบ "การทบต้น" ด้วย หากองค์ประกอบ <div> ไม่มีความรู้สึก/มุมมองการออกแบบที่ผสมผสานและรวมกันเป็นหนึ่ง ก็อาจจะไม่ถูกเลือกเป็น LCP

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

Layout Shifting และ Cumulative Layout Shifting คืออะไร?

การเปลี่ยนเค้าโครงเป็นแนวคิดที่ว่าในขณะที่เบราว์เซอร์กำลังดาวน์โหลดหน้าเว็บ องค์ประกอบของหน้าจะเปลี่ยนตำแหน่งในลักษณะที่อาจรบกวนผู้ใช้

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

Cumulative Layout Shifting (CLS) คือผลรวมของเหตุการณ์การเปลี่ยนเลย์เอาต์ทั้งหมด

ประสบการณ์ผู้ใช้ Chrome ยังมีส่วนเกี่ยวกับคะแนน CLS แต่มันไม่ใช่แค่เกี่ยวกับ UX การเปลี่ยนเลย์เอาต์อาจเป็นอันตรายต่อผู้ป่วยโรคลมบ้าหมูที่ไวต่อแสง ในฐานะ "บริษัทด้านสุขภาพ" Google ยังต้องให้ความสำคัญกับสุขภาพของผู้ใช้ พวกเขาพยายามลด "ความเครียดจากเว็บ" ในทุกที่ที่ทำได้

“ฉันเชื่อว่า Google เป็นบริษัทด้านสุขภาพอยู่แล้ว มันอยู่ใน DNA ของบริษัทตั้งแต่แรกเริ่ม”
David Feinberg – หัวหน้า Google Health

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

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับ Layout Shifting, Flickers, Flashes และ Color Variations ซึ่งเป็นอันตรายต่อสุขภาพได้จาก Moz Developers

วิธีค้นหาการเปลี่ยนเลย์เอาต์สะสมบนเว็บไซต์ของคุณ

หากต้องการดูส่วนเลย์เอาต์ที่เปลี่ยนไปของหน้าเว็บของคุณ คุณสามารถใช้ Google Chrome DevTools หรือคุณสามารถใช้ Layout Instability API เพื่อปรับขนาดกระบวนการสำหรับหน้าเว็บทั้งหมดของคุณ

Cumulative Layout Shifting หรือผลรวมของเหตุการณ์การเปลี่ยนเลย์เอาต์ทั้งหมดเป็นเกณฑ์สำคัญทั้งความเร็วของเพจและ UX ในปี 2020 และต่อๆ ไป หากส่วนครึ่งบนของหน้าเว็บขยับขณะโหลด คุณจะต้องปรับให้เหมาะสมเมื่อทำการเพิ่มประสิทธิภาพเพื่อความเร็วด้วย

ด้านล่างนี้ คุณจะพบกับ Layout Shifting Formula รวมถึงตัวอย่าง Layout Instability API Code เพื่อให้คุณได้มุมมองเกี่ยวกับการมีส่วนร่วมของ CLS และวิธีการคำนวณ Layout Shifting Score

สูตรการเลื่อนเค้าโครงอยู่ด้านล่าง:
คะแนนการเปลี่ยนเลย์เอาต์ = เศษส่วนกระทบ * เศษระยะทาง

คะแนนการเปลี่ยนเลย์เอาต์คำนวณด้วยคำศัพท์ใหม่ที่เป็นประโยชน์สองคำ ได้แก่ Impact Fraction และ Distance Fraction:

  • เศษส่วนผลกระทบ คือเปอร์เซ็นต์ของหน้าจอที่ได้รับผลกระทบจากกะ คุณรู้ว่า CLS ของคุณจะสูงหากองค์ประกอบของหน้า ซึ่งครอบคลุม 50% ของวิวพอร์ตบนอุปกรณ์มือถือ สร้างการเลื่อนเลย์เอาต์ เนื่องจากการย้ายจะส่งผลกระทบต่อหน้าจออย่างน้อยมากกว่า 50%
  • เศษส่วนระยะทาง วัดจากระยะที่องค์ประกอบขยับเคลื่อนห่างจากจุดเดิมในทิศทางที่ขยับระหว่างการเปลี่ยนเกียร์ หากระยะห่างระหว่างตำแหน่งแรกและตำแหน่งสุดท้ายมากเกินไป ส่วนของระยะทางก็จะมากเกินไป

วิธีนี้จะช่วยให้คุณประเมินคะแนน CLS และแนะนำทีมไอทีและ UX ของคุณได้ง่ายขึ้น

ด้านบน คุณสามารถดูข้อมูลโค้ด CLS API และด้านล่าง GIF ที่แสดงวิธีการคำนวณ Cumulative Layout Shifting

ในเว็บไซต์ข่าวของตุรกีที่เรากำลังดูอยู่ CLS ของเราคือ 0,47 เมื่อพิจารณาจากการคำนวณระหว่าง 0 ถึง 1 นี่เป็นคะแนนที่ค่อนข้างแย่
คุณสามารถคำนวณ CLS ของคุณได้ด้วย Advanced Custom Metric System ของ Webpagetest.org คุณควรใช้รหัสของ CLS API จนกว่า “ส่งส่วนข้อมูล” หลังจากนั้น คุณต้องเปลี่ยน URL จาก root/results/ เป็น root/custom_metrics.php?test={Same Result Number}

เวลาบล็อกทั้งหมดคืออะไร?

คุณสามารถดาวน์โหลดครึ่งหน้าบนของหน้าเว็บได้อย่างรวดเร็วโดยไม่ต้องเปลี่ยนเลย์เอาต์ แต่ถ้าไม่ตอบสนองต่อการป้อนข้อมูลของผู้ใช้ Google Algorithms จะอ้างว่าคุณมีปัญหา UX และความเร็วหน้าเว็บอื่น Total Blocking Time คือเวลาที่เสียไปในขั้นตอนนี้

เช่นเดียวกับการเปลี่ยนเลย์เอาต์สะสมและระบายสีเนื้อหาที่ใหญ่ที่สุด Total Blocking Time คือความเร็วของหน้าใหม่และเมตริก UX สำหรับปี 2020 และปีต่อๆ ไป

สิ่งที่นับรวม Total Blocking Time (TBT) คือเหตุการณ์การโหลดใดๆ ระหว่าง First Paint (FP) และ Time to Interactive (TTI) ที่บล็อกเธรดหลักของเบราว์เซอร์ (หรืออุปกรณ์) เป็นเวลานานกว่า 50 มิลลิวินาที และป้องกันไม่ให้ผู้ใช้ ดำเนินการตามกระบวนการใดๆ

วิธีคำนวณและเพิ่มประสิทธิภาพ TBT

คุณสามารถคำนวณ Total Blocking Time (TBT) ของคุณด้วย Long Tasks API

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

อันนี้มาจากเว็ปเดิมครับ ดังที่คุณอาจสังเกตเห็น เธรดหลักกำลังยุ่งมากกว่า 5 วินาทีโดยไม่หยุด LCP ของพวกเขายังคงถูกโหลดหลังจากผ่านไปเกือบ 2.5 วินาที… สิ่งสำคัญที่ควรทราบคือคำของานที่ยาวที่สุดของพวกเขานั้นยาวกว่า 350 MS ซึ่งหมายความว่าจะถือว่าบล็อกเธรดหลักมากกว่า 300 MS

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

หาก TBT ของคุณมากกว่า 300 มิลลิวินาที อาจเป็นอันตรายต่อการรักษาผู้ใช้และอัตรา Conversion อย่างมาก

คุณอาจเห็นตัวอย่างการคำนวณ TBT สำหรับเธรดหลักด้านบน ในตัวอย่างนี้ มีสี่คำขอ Google Chrome สามารถสร้างคำขอได้ 6 รายการจากเซิร์ฟเวอร์เดียวกันในคราวเดียว มีเพียง 50 MS แรกเท่านั้นที่จะไปได้อย่างราบรื่น หลังจากนั้นจะเริ่มทำงานหลายอย่างพร้อมกัน เท่าที่ CPU/Network power อนุญาต จำไว้ว่ามนุษย์สามารถเห็นหนึ่งเฟรมทุกๆ 16 MS Google ใส่ใจผู้ใช้ทุก ๆ มิลลิวินาที

ในตัวอย่างนี้ Total Blocking Time คือ 1 วินาทีและ 100 MS

ขั้นตอนต่อไปในการเพิ่มประสิทธิภาพความเร็วหน้า

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

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

เริ่มการทดลองใช้ฟรีของคุณ