ปัญหา Core Web Vitals ทั่วไปใน WordPress และวิธีแก้ไข

ประสบปัญหาในการผ่าน Core Web Vitals ใช่ไหม

ตามที่ Google:

55.4% ของเว็บไซต์ทั้งหมดที่มีข้อมูล CrUX ขาดตลาดเมื่อต้องเป็นไปตามเกณฑ์ที่ดีสำหรับตัวชี้วัดทั้งสาม – LCP, FID และ CLS

อย่างไรก็ตาม การผ่านการประเมิน CWV ไม่ว่าด้วยวิธีใดก็ตามถือเป็นภารกิจที่เป็นไปไม่ได้

อันที่จริงมันเป็นกระบวนการ 3 ขั้นตอน:

• เรียกใช้การทดสอบประสิทธิภาพ
• ระบุปัญหาของ Core Web Vitals
• ปรับให้เหมาะสม

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

ดังนั้นอ่านต่อ!

สรุปสั้นๆ ของ Core Web Vitals

คุณอาจสะดุดกับคำชี้แจงของ Google นี้:

แต่ดังสุภาษิตชื่อดังที่ว่า คุณไม่สามารถปรับปรุงสิ่งที่คุณไม่ได้วัดผลได้

หรืออย่างน้อยนั่นก็คือสถานการณ์ในการวัดประสบการณ์ผู้ใช้ก่อน CWV

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

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

• ประสิทธิภาพการโหลด (LCP)
• การโต้ตอบ (FID)
• ความเสถียรทางการมองเห็น (CLS)

LCP หรือ Largest Contentful Paint วัดประสิทธิภาพการโหลดหน้าเว็บ โดยจะวัดเวลาที่ใช้ในการโหลดเนื้อหาหลักของหน้า LCP ที่เหมาะสมจะถือว่าต่ำกว่า 2.5 วินาที

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

CLS หรือ Cumulative Layout Shift ประเมินความเสถียรของการมองเห็นของเพจ โดยจะดูการเปลี่ยนแปลงเค้าโครงที่ไม่คาดคิดที่เกิดขึ้นโดยที่ผู้ใช้ไม่ได้ป้อนข้อมูล คะแนน CLS ที่น่ายกย่องจะน้อยกว่า 0.1

นอกจากนี้ยังมีตัวชี้วัดที่สี่ที่จะมาแทนที่ FID ในเดือนมีนาคม 2024 - Interaction to Next Paint (INP)

INP จะบันทึกเวลาแฝงของการโต้ตอบทั้งหมดตลอดวงจรการใช้งานเพจทั้งหมด จากนั้น ความล่าช้าที่ยาวที่สุดจากการโต้ตอบทั้งหมดจะถูกบันทึกเป็น INP ของเพจ

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

แม้ว่า INP จะไม่ส่งผลกระทบโดยตรงต่อการประเมิน Core Web Vitals ของคุณ (ในขณะนี้) แต่ Google ได้เริ่มแจ้งปัญหา INP ผ่าน Search Console แล้ว

เรียนรู้เทคนิคที่ดีที่สุดในการเพิ่มคะแนน INP ของคุณจาก Google เอง ลงทะเบียนสำหรับการสัมมนาผ่านเว็บสุดพิเศษของเรา →

การส่งผ่าน Core Web Vitals: เปอร์เซ็นไทล์ที่ 75

เมื่อพูดถึงเมตริก Core Web Vitals Google มักจะอ้างถึงเปอร์เซ็นไทล์ที่ 75

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

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

เครื่องมือในการระบุปัญหา Core Web Vitals

ใน 2 ขั้นตอนแรกบนเส้นทางการเพิ่มประสิทธิภาพ Core Web Vitals คุณต้องทำการทดสอบและระบุผู้กระทำผิดที่อาจเกิดขึ้น

มีเครื่องมือยอดนิยมหลายอย่างที่คุณสามารถใช้ประโยชน์ได้ระหว่างทาง:

1. ข้อมูลเชิงลึกของ PageSpeed

PageSpeed ​​Insights ของ Google นำเสนอข้อมูล CWV ทั้งเฉพาะหน้าและทั่วทั้งต้นทางในช่วง 28 วันที่ผ่านมา นอกจากนี้ยังให้คำแนะนำที่นำไปใช้ได้จริงเพื่อเพิ่มประสิทธิภาพอีกด้วย

เป็นหนึ่งในเครื่องมือประสิทธิภาพที่ใช้กันอย่างแพร่หลายเนื่องจากมี UX/UI ที่เป็นมิตร หน้ารายงานประกอบด้วยการประเมิน Core Web Vitals ตามข้อมูลภาคสนามและคะแนนประสิทธิภาพตามข้อมูลห้องปฏิบัติการ

และที่ด้านล่าง คุณจะมีวิดเจ็ตโอกาสและการวินิจฉัย ซึ่งแสดงรายการปัญหาและเมตริกที่เกี่ยวข้องที่ปัญหาเหล่านั้นส่งผลกระทบ

2. Google ค้นหาคอนโซล

รายงาน Core Web Vitals ใน Search Console มีข้อมูลประสิทธิภาพของ URL แต่ละรายการ ทำให้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับการระบุหน้าเว็บเฉพาะที่ต้องปรับปรุง การรายงาน Search Console ต่างจาก PageSpeed ​​Insights ตรงที่มีข้อมูลประสิทธิภาพที่ผ่านมา

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

รายงานประสบการณ์ผู้ใช้ Chrome (CrUX)

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

คุณสามารถใช้ประโยชน์จากชุดข้อมูล CrUX ได้ 2 วิธีหลัก:

• Chrome UX Report API - เหมาะสำหรับผู้ที่คุ้นเคยกับ JavaScript และ JSON
• BigQuery - เหมาะสำหรับผู้ที่มีโครงการ Google Cloud และมีความรู้เกี่ยวกับ SQL

แม้ว่าวิธีการเหล่านี้ต้องใช้ความพยายามมากกว่าการตรวจสอบ PageSpeed ​​Insights หรือการตรวจสอบ GSC อย่างรวดเร็ว แต่ก็นำเสนอตัวเลือกการวิเคราะห์ข้อมูลและการแสดงภาพที่หลากหลาย ตัวอย่างเช่น BigQuery ช่วยให้สามารถแบ่งกลุ่มข้อมูลและผสานรวมกับชุดข้อมูลอื่นๆ ได้

ดูผลลัพธ์ก่อนและหลัง CWV ของคุณด้วย NitroPack ทดสอบเว็บไซต์ของคุณฟรี →

ปัญหา Core Web Vitals ที่พบบ่อยที่สุดใน WordPress

ปัญหา Contentful Paint (LCP) ที่ใหญ่ที่สุด

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

ความล่าช้าในการดึงเอกสาร HTML เริ่มต้นจากเซิร์ฟเวอร์สามารถผลักดันตัววัด LCP ให้อยู่ในช่วงที่ไม่เอื้ออำนวย

และนี่คือสาเหตุหลัก:

1. เวลาตอบสนองของเซิร์ฟเวอร์ช้าเนื่องจากการโฮสต์งบประมาณ

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

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

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

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

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

2. JavaScript และ CSS ที่บล็อกการแสดงผลโดยธีมและปลั๊กอินบางตัว

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

เมื่อธีมหรือปลั๊กอิน WordPress แนะนำองค์ประกอบที่ขัดขวางการเรนเดอร์ จะทำให้การมองเห็นเนื้อหาหลักล่าช้า ส่งผลให้เว็บไซต์ไม่ผ่านการประเมิน LCP

ดังนั้นเมื่อพูดถึงเว็บไซต์ WordPress ของคุณ น้อยมาก

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

3. รูปภาพที่ไม่ได้เพิ่มประสิทธิภาพ

ตาม Web Almanac:

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

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

ปัญหากะเค้าโครงสะสม (CLS)

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

นี่คือสิ่งที่ทำให้เนื้อหาในหน้าของคุณกระโดดขึ้นและลง:

1. รูปภาพที่แทรกโดยไม่ได้กำหนดขนาดไว้

รายละเอียดประการหนึ่งที่มักถูกมองข้ามในการพัฒนาเว็บคือข้อกำหนดของขนาดภาพ

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

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

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

2. ตำแหน่งโฆษณาที่ไม่มีพื้นที่สงวน

คุณรวมองค์ประกอบแบบไดนามิก เช่น โฆษณา วิดีโอ หรือเนื้อหาที่ฝังไว้อื่นๆ หรือไม่

คุณควรรู้ว่าการบูรณาการนี้มาพร้อมกับความท้าทายมากมาย

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

สิ่งนี้จะกลายเป็นปัญหาเมื่อมีการโหลดองค์ประกอบเหล่านี้ โดยเฉพาะโฆษณาแบบไดนามิก หากขนาดจริงเกินพื้นที่ที่ไม่ได้จัดสรรหรือเป็นค่าเริ่มต้น เนื้อหานั้นจะบุกรุกเนื้อหาอื่น ส่งผลให้มีการเปลี่ยนแปลง

3. การจัดส่งแบบอักษรที่ไม่เหมาะสม

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

แต่พวกเขานำเสนอความท้าทาย ได้แก่ FOIT (Flash of Invisible Text) และ FOUT (Flash of Unstyled Text)

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

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

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

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

และนี่คือทรัพยากรที่บล็อกเธรดหลักโดยทั่วไปที่สุด:

1. การดำเนินการ JavaScript จำนวนมาก

การดำเนินการ JavaScript จำนวนมากอาจส่งผลกระทบอย่างมากต่อ FID บนเว็บไซต์ โดยสาเหตุหลักมาจากลักษณะของ JavaScript แบบเธรดเดียว

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

2. การจัดลำดับความสำคัญของทรัพยากรไม่ดี

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

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

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

3. ใช้งานสคริปต์บุคคลที่สามมากเกินไป

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

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

นอกจากนี้ โปรดทราบว่าสคริปต์ของบุคคลที่สามมักจะอาศัยเซิร์ฟเวอร์ภายนอก ความล่าช้าใด ๆ ในเวลาตอบสนองของเซิร์ฟเวอร์อาจทำให้เกิดเวลาแฝงได้เช่นกัน

การโต้ตอบกับปัญหา Next Paint (INP)

เมื่อพิจารณาว่า INP จะมาแทนที่ FID ในปีหน้า จึงไม่น่าแปลกใจที่สิ่งที่ส่งผลเสียต่อตัววัดการตอบสนองในปัจจุบันจะส่งผลต่อตัววัดที่กำลังจะมาถึงด้วย

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

แต่มีอีกอย่างหนึ่ง:

1. มีขนาด DOM ขนาดใหญ่

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

แม้ว่า DOM จะเป็นพื้นฐานของฟังก์ชันของหน้าเว็บ แต่ขนาดของ DOM ก็สามารถนำไปสู่ปัญหาการตอบสนองได้ เนื่องจาก:

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

ในแง่ที่ง่ายกว่า:

เพื่อให้ตอบสนองต่อการกระทำของผู้ใช้ได้ทันที การปรับปรุง DOM ของคุณให้เป็นองค์ประกอบที่จำเป็นเท่านั้นจึงเป็นสิ่งสำคัญ

คุณอาจไตร่ตรองถึงคำจำกัดความของ "จำเป็น" ตามเกณฑ์ของ Lighthouse ขนาด DOM จะถือเป็นภาระหากเกิน1,400 โหนด

เข้าร่วม 45% ของเว็บไซต์ที่ผ่าน Core Web Vitals ติดตั้ง NitroPack วันนี้ →

วิธีแก้ไขปัญหา Core Web Vitals ใน WordPress (รายการตรวจสอบ)

การเพิ่มประสิทธิภาพ LCP

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

• อัปเกรดโฮสติ้งของคุณ : พิจารณาย้ายออกจากโฮสติ้งที่ใช้ร่วมกันแม้ว่าจะคุ้มค่า แต่ก็อาจช้ากว่าตัวเลือกที่มีราคาแพงกว่า เช่น โซลูชันเฉพาะหรือโฮสติ้งบนคลาวด์ ตัวเลือกโฮสติ้งแบบพรีเมียมมักจะมีเวลาตอบสนองที่เร็วกว่า
  
• ใช้เครือข่ายการจัดส่งเนื้อหา (CDN): CDN จัดเก็บเวอร์ชันแคชของไซต์ของคุณบนเซิร์ฟเวอร์หลายเครื่องที่ตั้งอยู่ทั่วโลก สิ่งนี้ทำให้มั่นใจได้ว่าผู้ใช้จะได้รับข้อมูลจากเซิร์ฟเวอร์ที่ใกล้ที่สุด ซึ่งช่วยลดเวลาที่ใช้ในการดึงข้อมูล
  
• ปรับฐานข้อมูลให้เหมาะสม : ซึ่งรวมถึงการลบข้อมูลเก่า การปรับแบบสอบถามให้เหมาะสม และการใช้ดัชนีอย่างมีประสิทธิภาพ สำหรับเว็บไซต์ที่มี WordPress ปลั๊กอินเช่น WP-Optimize สามารถช่วยในการบำรุงรักษาฐานข้อมูลได้
  
• เลือกรูปแบบภาพที่เหมาะสม : เลือกรูปแบบที่มีประสิทธิภาพที่สุดสำหรับภาพของคุณ แม้ว่า JPEG จะเหมาะสำหรับภาพถ่าย แต่ PNG ก็ดีกว่าสำหรับรูปภาพที่มีความโปร่งใส รูปแบบสมัยใหม่ เช่น WebP สามารถนำเสนอภาพคุณภาพสูงโดยมีขนาดไฟล์เล็กลง
  
• ใช้การบีบอัด : ใช้การบีบอัดแบบ lossy เพื่อลดขนาดไฟล์โดยไม่ทำให้ภาพเสื่อมลงอย่างมีนัยสำคัญ ใช้การบีบอัดแบบไม่สูญเสียข้อมูลเพื่อรักษาทุกรายละเอียดสำหรับภาพที่คุณภาพเป็นสิ่งสำคัญยิ่ง
  
• ปรับขนาดรูปภาพ: ส่งรูปภาพที่เหมาะกับอุปกรณ์และวิวพอร์ต หลีกเลี่ยงการใช้รูปภาพขนาดใหญ่ที่ปรับขนาดแล้วด้วย CSS หรือในเบราว์เซอร์ สร้างขนาดรูปภาพที่แตกต่างกันสำหรับความละเอียดหน้าจอต่างๆ และให้บริการโดยใช้แอตทริบิวต์ "srcset" หรือลองใช้ปลั๊กอินเช่น NitroPack ซึ่งจะปรับขนาดรูปภาพของคุณโดยอัตโนมัติ
  
• ย่อขนาดไฟล์ JS และ CSS : ลดขนาดของสคริปต์และสไตล์ชีตของคุณโดยการลบอักขระ ช่องว่าง และโค้ดที่ไม่จำเป็นออก เครื่องมืออย่าง Terser (สำหรับ JS) และ CSSNano (สำหรับ CSS) สามารถช่วยได้
  
• ใช้ defer หรือ async: ใช้แอตทริบิวต์ defer สำหรับสคริปต์ที่ไม่จำเป็นสำหรับการแสดงผลหน้าแรก เพื่อให้แน่ใจว่าไฟล์ JS จะถูกดำเนินการตามลำดับหลังจากแยกวิเคราะห์ HTML แล้ว ใช้แอตทริบิวต์ async สำหรับสคริปต์ที่ไม่ต้องอาศัยสคริปต์อื่นและไม่สำคัญสำหรับการแสดงผลครั้งแรก ซึ่งจะทำให้เบราว์เซอร์สามารถแยกวิเคราะห์เพจต่อไปได้ในขณะที่กำลังดาวน์โหลดสคริปต์
  
• CSS ที่สำคัญแบบอินไลน์: ระบุ CSS ที่จำเป็นขั้นต่ำสำหรับการแสดงผลหน้าแรกและอินไลน์โดยตรงภายใน HTML เพื่อให้แน่ใจว่าสไตล์ที่จำเป็นสำหรับเนื้อหาครึ่งหน้าบนจะพร้อมใช้งานทันที
  

การปรับปรุง FID

เพื่อรับประกันการตอบสนองของเพจที่ราบรื่นและรวดเร็ว ให้ใช้การเพิ่มประสิทธิภาพต่อไปนี้:

• ใช้ Web Workers : ถ่ายโอนการคำนวณที่ซับซ้อนให้กับ Web Workers พวกเขาเรียกใช้ JavaScript ในพื้นหลังบนเธรดที่แยกจากกัน เพื่อให้แน่ใจว่าเธรดหลักยังคงตอบสนอง
  
• จัดลำดับความสำคัญ JS ที่สำคัญ : จัดลำดับความสำคัญในการโหลดและเรียกใช้โค้ด JS ที่สำคัญที่สุดก่อน ใช้ rel="preload" เพื่อแจ้งเบราว์เซอร์เกี่ยวกับสคริปต์ที่มีลำดับความสำคัญสูง
  
• ลด CSS ที่ไม่ได้ใช้ : แม้ว่า JavaScript มักจะเป็นตัวร้ายหลัก แต่ CSS ก็บล็อกเธรดหลักด้วย การลด CSS ที่ไม่ได้ใช้จะเป็นการลดจำนวนไบต์ทั้งหมดที่ต้องดาวน์โหลด ที่สำคัญกว่านั้น คุณมั่นใจได้ว่าเบราว์เซอร์สามารถเริ่มแสดงผลเพจได้เร็วขึ้น เนื่องจากมีการดำเนินการน้อยลง
  
• แบ่งงานที่มีความยาว: แบ่งงานที่มีความยาวออกเป็นชิ้นเล็กๆ แบบอะซิงโครนัสโดยใช้เทคนิค เช่น requestIdleCallback() เพื่อให้แน่ใจว่าเธรดหลักยังคงว่างสำหรับการป้อนข้อมูลของผู้ใช้บ่อยขึ้น
  
• ปรับผู้ฟังเหตุการณ์ให้เหมาะสม: หากคุณมีผู้ฟังเหตุการณ์จำนวนมากในหลายองค์ประกอบ ให้พิจารณาการมอบหมายกิจกรรม วิธีนี้จะแนบ Listener เหตุการณ์เดียวเข้ากับพาเรนต์ทั่วไป ซึ่งจะช่วยลดจำนวน Listener และปรับปรุงประสิทธิภาพ
  

การลด CLS

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

• กำหนดขนาดสำหรับรูปภาพ โฆษณา และการฝัง: รวมแอตทริบิวต์ความกว้างและความสูงสำหรับรูปภาพของคุณเสมอ ซึ่งช่วยให้เบราว์เซอร์จัดสรรพื้นที่รูปภาพให้ถูกต้องก่อนที่จะโหลด
  
• Use Font-display: option: การใช้ Font-display: option ร่วมกับ link rel=preload สำหรับฟอนต์ที่สำคัญที่สุดของคุณ ถือเป็นกลยุทธ์ฟอนต์โดยรวมที่ดีที่สุดสำหรับ CLS ที่ดี ค่าที่ไม่บังคับจะไม่ทำให้เกิดการจัดวางใหม่เมื่อแบบอักษรของเว็บพร้อมใช้งาน ในเวลาเดียวกัน แบบอักษรที่โหลดไว้ล่วงหน้ามีแนวโน้มที่จะตรงตามสีแรก เพื่อให้แน่ใจว่าไม่มีการเปลี่ยนแปลงเค้าโครงเกิดขึ้น
  
• สำรองพื้นที่สำหรับเนื้อหาแบบไดนามิก : จัดสรรพื้นที่ที่เหมาะสมล่วงหน้าเสมอสำหรับเนื้อหาที่โหลดแบบไดนามิก เช่น โฆษณาหรือ iframe วิธีนี้จะป้องกันไม่ให้เนื้อหาผลักองค์ประกอบอื่นๆ ไปมาเมื่อโหลด
  

ผ่าน INP

เทคนิคการปรับให้เหมาะสมทั้งหมดที่กล่าวถึงในส่วน FID จะปรับปรุงคะแนน INP ของคุณอย่างหลีกเลี่ยงไม่ได้ ยิ่งไปกว่านั้น คุณควรดำเนินการดังต่อไปนี้:

• ลดขนาด DOM: ในการลดความลึกของ DOM ของไซต์ของคุณ ให้หลีกเลี่ยงปลั๊กอินและธีมที่เขียนโค้ดไม่ดี อย่าซ่อนองค์ประกอบที่ไม่ต้องการโดยใช้ display:none ถอยห่างจากเครื่องมือสร้างเพจที่ทำให้โค้ดของคุณขยายใหญ่ขึ้น และลดโหนด DOM ที่ใช้ JavaScript ให้เหลือน้อยที่สุด
  
• หลีกเลี่ยงตัวจับเวลาที่เกิดซ้ำ: setTimeout และ setInterval เป็นฟังก์ชันตัวจับเวลา JavaScript ที่ใช้กันทั่วไปซึ่งอาจทำให้เกิดความล่าช้าในการป้อนข้อมูลได้ หากคุณสามารถควบคุมตัวจับเวลาในโค้ดของคุณได้ ให้ประเมินความจำเป็นและลดภาระงานให้มากที่สุด

สรุป

การดูรายการเพิ่มประสิทธิภาพที่มีมากมายอาจทำให้คุณคิดว่า:

ฉันจำเป็นต้องผ่านการประเมิน Core Web Vitals จริงๆ หรือไม่ พวกเขามีอิทธิพลขนาดนั้นเลยเหรอ?

และความจริงก็คือ มันไม่เกี่ยวกับตัวเมตริกเอง

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

แต่มูลค่าที่แท้จริงนั้นมาจากการที่การส่ง CWV ของคุณโดยตรงจะส่งผลให้คุณได้รับประสบการณ์การใช้งานที่ยอดเยี่ยม

และสิ่งนี้นำไปสู่ผลลัพธ์ในโลกแห่งความเป็นจริงเช่น:

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

กลับมาที่คำถาม เราจะบอกว่าการส่ง Core Web Vitals เป็นสิ่งสำคัญ

แต่เราก็ยอมรับด้วยว่าการจัดการกับการเพิ่มประสิทธิภาพทั้งหมดไม่ใช่เรื่องง่าย

นั่นเป็นเหตุผลที่เราสร้าง NitroPack

NitroPack เป็นโซลูชันประสิทธิภาพเว็บขนาดเล็กที่ขับเคลื่อนเว็บไซต์มากกว่า 180,000 แห่งทั่วโลก ช่วยให้เว็บไซต์เหล่านี้ได้รับ Core Web Vitals คะแนนประสิทธิภาพ และประสบการณ์ผู้ใช้ที่ยอดเยี่ยม

ด้วย คุณสมบัติการเพิ่มประสิทธิภาพความเร็วเพจในตัวมากกว่า 35 รายการ NitroPack เป็นผู้นำในการเพิ่มประสิทธิภาพ Core Web Vitals:

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

ทดสอบ NitroPack ฟรี →