การอัปเดตพฤษภาคม 2021 ของ Google: ดู Core Web Vitals อย่างละเอียดยิ่งขึ้น

อัปเดต: โลกของการตลาดดิจิทัลเปลี่ยนแปลงตลอดเวลา แต่ไม่ต้องกังวล เราพร้อมเสมอ Google ได้เปลี่ยนใจเกี่ยวกับอัลกอริธึมที่กำลังจะมีขึ้น

อ่านการเปลี่ยนแปลงล่าสุดที่นี่ในการอัปเดตของเรา แต่โปรดอ่านบล็อกนี้ด้วย

ในเดือนพฤษภาคม 2564 Google จะเปิดตัวเมตริก Core Web Vitals (CWV) เพื่อเป็นส่วนหนึ่งของอัลกอริทึมการจัดอันดับการค้นหา นี่คือสิ่งที่คุณต้องรู้และทำก่อนหน้านั้น...

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

แต่ Google ไม่ได้หยุดอยู่แค่นั้น ย้อนกลับไปในเดือนพฤษภาคม 2020 พวกเขาบอกเราเกี่ยวกับ Core Web Vitals และในวันที่ 10 พฤศจิกายน 2020 พวกเขาประกาศว่าในเดือนพฤษภาคม 2021 Core Web Vitals จะถูกรวมเป็นสัญญาณการค้นหาในอัลกอริธึมการจัดอันดับโดยรวม

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

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

แต่ก่อนอื่น สรุป...

สรุป: Core Web Vitals คืออะไร?

Core Web Vitals คือชุดของตัวชี้วัดประสบการณ์หน้าเว็บใหม่ 3 ตัวที่รวมอยู่ในคะแนนความเร็วไซต์โดยรวม เมตริกเหล่านี้มีบทบาทสำคัญอยู่แล้วในเครื่องมือ PageSpeed ​​Insights ของ Google PSI และการตรวจสอบประสิทธิภาพของ Lighthouse ในที่อื่นๆ

ตัวชี้วัด CWV ใหม่ประกอบด้วยสิ่งต่อไปนี้:

Largest Contentful Paint (LCP)

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

ปัจจัยหลายประการส่งผลให้ LCP สูง รวมถึงการตอบสนองของเซิร์ฟเวอร์ สคริปต์และสไตล์การบล็อกการแสดงผล ความซับซ้อนของ CSS แบบอักษรและรูปภาพ

ความล่าช้าในการป้อนข้อมูลครั้งแรก (FID)

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

หากเบราว์เซอร์กำลังแยกวิเคราะห์หรือเรียกใช้ JavaScript จำนวนมากในระหว่างการโหลดหน้าเว็บ การดำเนินการนี้จะผูก CPU หรือบล็อก 'เธรดหลัก' ทำให้อุปกรณ์ตอบสนองต่ออินพุตน้อยลง FID สูงมักจะเป็นตัวบ่งชี้ JavaScript ที่ซับซ้อน นี่อาจเป็นสคริปต์หรือฟังก์ชันเดียวหรือหลายสคริปต์

ตัววัด PSI ที่มีอยู่สำหรับ Time to Interactivity และ Total Blocking Time นั้นเกี่ยวข้องกับ FID และรวมแล้วคิดเป็น 35% ของคะแนนความเร็วโดยรวม

การเปลี่ยนแปลงเค้าโครงสะสม (CLS)

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

รายละเอียดคะแนนความเร็ว

แผนภาพด้านล่างแสดงรายละเอียดของคะแนนความเร็วโดยรวมและบทบาทของเมตริก CWV ใหม่เหล่านี้ที่มีต่อคะแนน GPSI

แหล่งข้อมูลจากการอัปเดตคะแนน Lighthouse

ขณะที่เมตริกที่ไม่ใช่ CWV ยังสร้างคะแนนโดยรวม ซึ่งรวมถึง First Content Paint (FCP), Time to Interactive (TTI) และ Total Blocking Time (TBT) การเน้นที่เมตริก CWV ทั้งสามรายการจะส่งผลโดยตรงต่อเมตริกอื่นๆ LCP ที่รวดเร็วไม่สามารถทำได้ ตัวอย่างเช่น หากไม่มี FCP ที่รวดเร็ว และคะแนน FID ที่สูงจะได้รับผลกระทบโดยตรงจาก TBT และ TTI

เคล็ดลับสำหรับการเพิ่มประสิทธิภาพ Paint ที่มีเนื้อหามากที่สุด

ตัวชี้วัด LCP ประกอบด้วยปัจจัยส่วนบุคคลจำนวนมากและได้รับผลกระทบโดยตรงจาก FCP ที่สูง หาก FCP ถูกตั้งค่าสถานะว่าไม่ดี คุณอาจต้องการเริ่มต้นที่นี่ ไม่ว่าจะเป็นการเชื่อมต่อเครือข่าย การตอบสนองของเซิร์ฟเวอร์ Time To First Byte TTFB และไฟล์การบล็อกการแสดงภาพ ล้วนส่งผลต่อค่า FCP หากต้องการทราบคำแนะนำทั่วไปเกี่ยวกับความเร็วของหน้า โปรดดูที่ eBook เกี่ยวกับความเร็วหน้าเว็บในหัวข้อเพิ่มเติมจากเคล็ดลับเฉพาะของ LCP ด้านล่าง

หากค่า LCP สูงกว่า FCP มาก เราต้องดูว่าเราจะปรับปรุงการแสดงองค์ประกอบที่ใหญ่ที่สุดนี้ได้อย่างไร

กำหนดองค์ประกอบที่ใหญ่ที่สุด

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

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

บนไซต์ Hallam ในตัวอย่างด้านบน การตรวจสอบประสิทธิภาพจะแสดง LCP เป็นหัวข้อ 'Thrive Online' หลัก ตามหลักการแล้ว LCP ควรปฏิบัติตาม FCP ทันทีดังตัวอย่างนี้ และหากมีช่องว่างระหว่างทั้งสอง เราจำเป็นต้องพยายามทำความเข้าใจว่าทำไม

แบบอักษรถูกปรับให้เหมาะสมหรือไม่?

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

1. ใช้ CSS font-display: swap; เพื่อให้แน่ใจว่าฟอนต์จะแสดงทันทีในขณะที่กำลังโหลดไฟล์ฟอนต์ ทั้ง Google Fonts และ Typekit ของ Adobe มีความสามารถในการตั้งค่าพารามิเตอร์ 'display' ของฟอนต์
2. ลองโฮสต์ไฟล์ฟอนต์ .woff และ .woff2 บนเซิร์ฟเวอร์แทนที่จะส่งคำขอข้ามโดเมนไปยังฟอนต์ของบุคคลที่สาม Google Fonts ค่อนข้างเร็ว ฟอนต์ Typekit นั้นช้ากว่า และฟอนต์ของบุคคลที่สามบางตัวมีความน่าเชื่อถือน้อยกว่า
3. การโหลดไฟล์ฟอนต์ล่วงหน้าสามารถช่วยได้ แบบอักษรที่โฮสต์ในเครื่องมักจะรวมอยู่ในสไตล์ชีตหลักของเว็บไซต์ แต่สไตล์ชีตนี้จะต้องดาวน์โหลดและแยกวิเคราะห์ก่อนที่จะมีการร้องขอเพิ่มเติมกับแบบอักษรภายใน การโหลดล่วงหน้าบอกให้เบราว์เซอร์เริ่มดาวน์โหลดฟอนต์เร็วขึ้น โดยไม่ต้องรอให้แยกวิเคราะห์ CSS
4. ใช้การเชื่อมต่อล่วงหน้าและดึงข้อมูล DNS ล่วงหน้าสำหรับโรงหล่อแบบอักษรบุคคลที่สาม คำสั่งเหล่านี้จะช่วยสร้างการเชื่อมต่อ DNS, TLS และ TCP ระหว่างโดเมนบุคคลที่สามก่อนที่จะมีการร้องขอแบบอักษร
5. รวมเฉพาะไฟล์ฟอนต์สำหรับการพิมพ์ที่จำเป็นสำหรับด้านบนจอแสดงผลแบบพับ เนื้อหาแบบอักษรสำหรับไลบรารีไอคอนเช่น Font Awesome นั้นค่อนข้างหนัก แต่คำขอเหล่านี้ (และ CSS ไลบรารีไอคอนที่เกี่ยวข้อง) มักจะถูกเลื่อนและโหลดหลังจากองค์ประกอบ <head>
6. ห้ามส่งคำขอข้ามโดเมนไปยังไฟล์ฟอนต์ภายในสไตล์ชีตของเว็บไซต์หลัก เนื่องจากต้องอาศัยการเชื่อมต่อและการค้นหาเพิ่มเติมของโดเมนบุคคลที่สาม
7. พิจารณาแบบอักษรที่ปลอดภัยสำหรับเว็บ สิ่งเหล่านี้ไม่ต้องการคำขอใด ๆ ไปยังไฟล์ฟอนต์ แม้ว่าจะมีข้อจำกัดในแง่ของความสวยงามก็ตาม

รูปภาพถูกปรับให้เหมาะสมหรือไม่?

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

1. ใช้ประเภทไฟล์ภาพที่ถูกต้อง ควรใช้ภาพ JPG สำหรับภาพถ่าย, SVG สำหรับกราฟิกแบบเวกเตอร์และไอคอน หรือ PNG สำหรับภาพที่ซับซ้อนกว่าที่ไม่ใช่ภาพถ่าย และหากต้องการความโปร่งใส
2. ตรวจสอบให้แน่ใจว่ารูปภาพ JPG ถูกบันทึกหรือส่งออกคุณภาพประมาณ 50-60% ในระดับนี้ ไม่ควรมีการสูญเสียคุณภาพที่เห็นได้ชัดเจน นอกจากนี้ ตรวจสอบให้แน่ใจว่าได้ลบข้อมูลเมตาออกจากรูปภาพแล้ว
3. ปลั๊กอินหรือบริการบีบอัด เช่น tinypng.com สามารถเพิ่มประสิทธิภาพรูปภาพโดยอัตโนมัติและเป็นกลุ่ม และดึงข้อมูลเมตาที่ไม่จำเป็นออก
4. รูปภาพควรมีขนาดเหมาะสมสำหรับพื้นที่ที่แสดง ห้ามแสดงรูปภาพเดสก์ท็อปคุณภาพสูงบนมือถือ
5. รูปภาพควรส่งออกโดยใช้แท็ก <img> มาตรฐานพร้อมแอตทริบิวต์ 'srcset' สำหรับรูปภาพที่ตอบสนอง
6. ภาพครึ่งหน้าล่างหรือนอกจอควรใช้แอตทริบิวต์ loading=”lazy”
7. ใช้รูปแบบไฟล์ภาพ .web รุ่นใหม่เพื่ออัตราการบีบอัดที่ดียิ่งขึ้น สิ่งนี้สามารถประหยัด 30% ได้อย่างง่ายดายและในหลาย ๆ กรณีสูงกว่ามาก
8. ลองโหลดรูปภาพครึ่งหน้าบนที่ใหญ่ที่สุดล่วงหน้าเพื่อเริ่มการดาวน์โหลดที่เร็วกว่าเนื้อหาอื่นๆ ที่อาจมีความสำคัญน้อยกว่า

ลดไฟล์การบล็อกการเรนเดอร์

ไฟล์ JavaScript หรือ CSS ที่โหลดในองค์ประกอบ <head></head> จะถือว่าเป็นการบล็อกการแสดงผล เนื่องจากต้องดาวน์โหลดไฟล์เหล่านี้ก่อนที่หน้าเว็บจะเริ่มแสดงผลได้ สิ่งนี้สามารถส่งผลกระทบอย่างมากต่อทั้งตัวชี้วัด FCP และ LCP ไฟล์การบล็อกการแสดงผลในส่วนหัวควรใช้เฉพาะในกรณีที่มีความสำคัญต่อการแสดงหน้าครึ่งหน้าบน

การลบไฟล์ที่ไม่ได้ใช้ใน <head> การโหลดไฟล์ที่ไม่สำคัญในส่วนท้าย หรือการรวมไฟล์หลายๆ ไฟล์เป็นไฟล์จำนวนน้อยลงจะลดปริมาณเนื้อหาการบล็อกการแสดงผล

อย่าใช้ JavaScript เพื่อแสดง LCP

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

หากการแสดงองค์ประกอบที่ใหญ่ที่สุดอาศัย JavaScript มักจะทำให้เกิดความล่าช้าเนื่องจากต้องดาวน์โหลด แยกวิเคราะห์ และดำเนินการ JavaScript ก่อนที่องค์ประกอบจะปรากฏขึ้น ไฟล์ JavaScript มักจะโหลด (และค่อนข้างถูกต้อง) หลังจากองค์ประกอบ <head> ดังนั้นจึงไม่ 'บล็อกการแสดงผล' แต่หมายความว่าไฟล์เหล่านี้ยังสามารถบล็อกการเรนเดอร์ของ LCP ได้อย่างมีประสิทธิภาพ

ดูตัวอย่างด้านล่าง (โลโก้เบลอและเปลี่ยนหัวข้อ) นี่มาจากไซต์ที่มีคะแนนสูงใน PSI LCP (ข้อความหัวเรื่องหลัก) อยู่ห่างจาก FCP หลายวินาที ซึ่งเกิดจากข้อกำหนดของ JavaScript (แสดงโดยแถบสีเหลือง) ในการดาวน์โหลด แยกวิเคราะห์ และดำเนินการก่อนที่ข้อความจะจางหายไป

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

เทคนิค JavaScript เช่นนี้สามารถลดคะแนนความเร็วโดยรวมลง 25% ได้ทันที และไม่ควรใช้เพื่อขัดขวางหรือป้องกันการโหลดองค์ประกอบที่ใหญ่ที่สุดไม่ว่าในทางใด

รันสคริปต์บน Window Load

JavaScript ไม่ค่อยจำเป็น (และไม่จำเป็น) เพื่อแสดงเนื้อหาที่สำคัญครึ่งหน้าบน แต่ปัญหาทั่วไปที่เราเห็นคือฟังก์ชันสามารถทริกเกอร์ได้ทันทีที่ DOM พร้อม ในเฟรมเวิร์ก jQuery ยอดนิยม ทำได้ผ่านเหตุการณ์ 'พร้อม' Google Tag Manager ยังสามารถทริกเกอร์ฟังก์ชันหรือ 'แท็ก' เมื่อพร้อมใช้งาน

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

สลับ LCP

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

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

เคล็ดลับสำหรับการเพิ่มประสิทธิภาพการหน่วงเวลาอินพุตครั้งแรก

ดังที่เราได้กล่าวไปแล้ว FID จะวัดว่าหน้าเว็บตอบสนองต่อการป้อนข้อมูลของผู้ใช้อย่างไร มันรวม Time To Interactive TTI และ Total Blocking Time TBT ซึ่งสามารถคิดเป็น 35% ของคะแนนความเร็วโดยรวม

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

สิ่งสำคัญคือต้องสังเกตว่า 'ข้อมูลห้องปฏิบัติการ' ที่แสดงใน PSI ไม่ได้วัด FID โดยตรง เนื่องจากลักษณะการโต้ตอบของการวัดจากการแตะหรือการคลิกโดยผู้ใช้ซึ่งยากต่อการจำลอง แต่จะถูกรวบรวมโดย 'ข้อมูลภาคสนาม'; การวัดที่รวบรวมจากผู้ใช้จริงในช่วง 28 วันตามรายงานประสบการณ์ผู้ใช้ Chrome CrUX

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

แล้วเราจะเพิ่มประสิทธิภาพสำหรับเมตริกเหล่านี้ได้อย่างไร

ตรวจสอบจาวาสคริปต์ของคุณ

JavaScript สามารถมาในรูปทรงและขนาดต่างๆ ได้ และไม่ใช่เรื่องแปลกที่การฝังวิดีโอ วิดเจ็ตการแชท สคริปต์ ReCaptcha หรือการรวม HubSpot จะเป็นสาเหตุเดียวที่อยู่เบื้องหลังเมตริก FID, TTI และ TBT ที่สูง

แผงการวินิจฉัยใน Page Speed ​​Insights เป็นจุดเริ่มต้นที่ดี ส่วนสำหรับ 'ลดการทำงานของเธรดหลัก' จะบอกคุณว่า JavaScript ใช้เวลาดำเนินการเท่าใด ส่วน 'ลดเวลาดำเนินการ JavaScript' จะระบุว่าไฟล์ใดมีเวลาแยกวิเคราะห์และดำเนินการสูงและ 'ลดผลกระทบของบุคคลที่สาม รหัส' จะเน้นและจัดกลุ่มสคริปต์บุคคลที่สามที่มีผลกระทบสูง

ภาพหน้าจอด้านล่างแสดงไซต์ที่มีสคริปต์จำนวนมาก โดยมีตัววัด Time to Interactive ที่ 15 วินาที สคริปต์จำนวนมากมาจากบุคคลที่สามรวมถึง HubSpot และ Vimeo

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

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

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

โหลดสคริปต์แบบอะซิงโครนัส

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

โหลด JavaScript แบบมีเงื่อนไข

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

ปรับปรุงการรวมกลุ่ม JavaScript

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

ขี้เกียจโหลดสคริปต์เมื่อจำเป็น

แม้ว่าจาวาสคริปต์จะโหลดเฉพาะในหน้าที่จำเป็นเท่านั้น ตัวสคริปต์เองก็ไม่จำเป็นต้องแยกวิเคราะห์และดำเนินการในระหว่างการโหลดหน้าหรือเหตุการณ์การโหลดหน้าต่าง การโหลด JavaScript เมื่อจำเป็นเท่านั้นสามารถสร้างความแตกต่างอย่างมากให้กับเมตริก TTI, TBT และ FID นี่คือตัวอย่างบางส่วน:

1. การฝังวิดีโอ เช่น YouTube และ Vimeo มักมีผลกระทบสูง ลองโหลดสคริปต์เหล่านี้เมื่อคลิกภาพขนาดย่อของวิดีโอแทนเท่านั้น
2. การรวมแบบฟอร์มของบุคคลที่สามเช่น HubSpot สามารถทำได้อย่างเข้มข้น หากแบบฟอร์มปรากฏในโมดอลหรือที่ด้านล่างของหน้า ให้ลองโหลดหรือฉีดสคริปต์ที่จำเป็นในการเปิดใช้การเลื่อนหรือโมดอลแทนการโหลดหน้า
3. วิดเจ็ตแชทสดสามารถส่งผลต่อคะแนนความเร็วโดยรวมได้ถึง 35% พิจารณาย้ายวิดเจ็ตแชทสดไปยังหน้าติดต่อเฉพาะที่รองรับ CTA 'แชทสด' ทั่วโลก หรือใส่สคริปต์แชทสดเฉพาะเมื่อมีการคลิกปุ่ม 'แชทกับเรา'
4. การเพิ่มแอตทริบิวต์ 'loading=”lazy” บนเนื้อหาที่ใช้ iFrame แบบฝังสามารถช่วยได้ แต่เป็นคุณลักษณะใหม่ของเบราว์เซอร์และจะต้องทำการทดสอบโดยขึ้นอยู่กับการฝัง iFrame ที่ใช้

ประเมินเครื่องมือข่าวกรองธุรกิจ

การวิเคราะห์พฤติกรรมผู้ใช้ด้วยเครื่องมือต่างๆ เช่น ซอฟต์แวร์ Hotjar หรือ A/B Testing เช่น VWO มีความสำคัญอย่างยิ่งต่อระบบธุรกิจอัจฉริยะ และในหลายกรณี ประโยชน์ของสิ่งเหล่านี้จะมีมากกว่าผลกระทบต่อความเร็วของไซต์

ต้องบอกว่ายังคงคุ้มค่าที่จะประเมินความสำคัญของการเรียกใช้เครื่องมือเหล่านี้ตลอด 24 ชั่วโมงทุกวัน ขึ้นอยู่กับความถี่ที่มีการวิเคราะห์ข้อมูล การทดสอบ A/B ควรถูกปิดหากไม่มีการทดสอบที่ใช้งานอยู่ ตัวอย่างเช่น และเครื่องมือวิเคราะห์พฤติกรรม เช่น Hotjar อาจถูกปิดใช้งานหลังจากมีการรวบรวมและประมวลผลข้อมูลที่เพียงพอ

เคล็ดลับสำหรับการเพิ่มประสิทธิภาพการเปลี่ยนเค้าโครงสะสม

Cumulative Layout Shift (CLS) อาจคิดได้เพียง 5% ของคะแนนความเร็วโดยรวม แต่ยังคงเป็นส่วนสำคัญของภาพรวมโดยเฉพาะอย่างยิ่ง เนื่องจากองค์ประกอบการขยับจำนวนมากในการโหลดหน้าเว็บอาจสร้างปัญหาให้กับผู้ใช้ได้

กำหนดองค์ประกอบ CLS

บางครั้งอาจปรากฏชัดเจนว่าองค์ประกอบหรือองค์ประกอบใดทำให้เกิดการเปลี่ยนแปลงในเนื้อหา แต่ควรตรวจสอบสิ่งนี้ผ่านแผง Layout Shift ใน PSI ดังที่แสดงด้านล่างเสมอ

เมตริก CLS ควรต่ำกว่า 0.1 แต่ในตัวอย่างข้างต้น เกิน 400% และจะทำให้คะแนนลดลง 5% หากเป็นปัญหาระดับโลก นั่นคือ 5% ในทุกหน้า

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

ระวังแอนิเมชั่น

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

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

ระบุขนาดภาพ

หากแท็ก <img> ไม่ได้ตั้งค่าแอตทริบิวต์ width และ height หรือ CSS ไม่ได้ใช้เพื่อกำหนดขนาดหรืออัตราส่วนของรูปภาพ เบราว์เซอร์จะต้องดาวน์โหลดรูปภาพก่อนจึงจะสามารถกำหนดพื้นที่พิกเซลที่ต้องการได้ แสดงผล ซึ่งอาจทำให้เนื้อหาใด ๆ ที่แสดงด้านล่างรูปภาพมีการเปลี่ยนแปลงเมื่อโหลดรูปภาพ

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

แบนเนอร์

โฆษณา แถบกฎหมายเกี่ยวกับคุกกี้หรือข้อมูลอื่นใดที่ใช้เพื่อแสดงข้อมูลสำคัญในแบนเนอร์อาจเป็นสาเหตุที่พบบ่อยที่สุดของ CLS ที่สูง

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

มีความละเอียดหลายประการสำหรับสิ่งนี้:

1. กำหนดความสูงขั้นต่ำสำหรับคอนเทนเนอร์แบนเนอร์หรือแบนเนอร์ใน CSS เพื่อให้เบราว์เซอร์สามารถแสดงตัวยึดตำแหน่งได้อย่างมีประสิทธิภาพ แม้ว่าสิ่งนี้อาจเป็นปัญหาได้หากปริมาณของเนื้อหาเป็นแบบไดนามิกและไม่ทราบ
2. อย่างแน่นอนหรือแก้ไขตำแหน่งแบนเนอร์ที่ด้านบนหรือด้านล่างของหน้าจอ สำหรับแบนเนอร์ที่สามารถปิดหรือยกเลิกได้ ข้อควรพิจารณาที่ดีเนื่องจากองค์ประกอบคงที่จะไม่ส่งผลต่อตำแหน่งขององค์ประกอบอื่นๆ
3. ดูการแสดงเนื้อหาแบนเนอร์ฝั่งเซิร์ฟเวอร์หากเป็นไปได้ ซึ่งหมายความว่าสามารถโหลดขนาดเนื้อหาและแบนเนอร์ล่วงหน้าได้ก่อนที่จะถึงผู้ใช้

สรุป

หวังว่าคุณจะพบว่าเทคนิคบางอย่างที่เน้นด้านบนมีประโยชน์ในการวินิจฉัยและแก้ไขปัญหาด้านประสิทธิภาพเกี่ยวกับ Core Web Vitals ใหม่ของ Google ในช่วงไม่กี่เดือนที่ผ่านมาที่ Hallam เราได้ช่วยลูกค้าจำนวนหนึ่งปรับปรุงประสิทธิภาพของเว็บไซต์ของตน ทั้งในแง่ของการตรวจสอบความเร็วและการปรับปรุงโดยตรงโดยทีมพัฒนาของเรา

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