Core Web Vitals สำหรับการทดสอบ A/B: ซอฟต์แวร์ทดสอบ A/B ของคุณทำให้เว็บไซต์ของคุณช้าลงหรือไม่

Google เพิ่งปล่อยการอัปเดต Core Web Vitals และเราจำเป็นต้องให้ความสนใจ

ทำไมต้องดูแล?

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

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

ไม่ดีใช่มั้ย?

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

เครื่องมือทดสอบ A/B ของฉันจะทำให้ไซต์ของฉันช้าลงและส่งผลต่อคะแนน Core Web Vitals ของฉันหรือไม่

ขอเอาสิ่งนี้ออกไปให้พ้นทางด้านบน แอป Convert นั้นรวดเร็วอย่างไม่น่าเชื่อและไม่ควรส่งผลเสียต่อ Page Experience หรือคะแนน Core Web Vitals ของ คุณ ตราบใดที่คุณปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับทั้งการทดสอบและการตั้งค่า CWV

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

ข่าวดี?

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

อะไรคือความแตกต่างระหว่าง Core Web Vitals และ Google Page Experience?

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

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

ทำไมเราถึงสนใจ?

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

เหตุใด Google จึงสนใจเกี่ยวกับประสบการณ์ของผู้ใช้

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

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

(เนื้อหาที่ยอดเยี่ยม ข้อเสนอ EAT และลิงก์ย้อนกลับมักจะขยับเข็มได้มากที่สุด)

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

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

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

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

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

วิธีวัดผล Core Web Vitals และประสบการณ์หน้าปัจจุบันของคุณ

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

ให้ไปที่เครื่องมือ PageSpeed ​​Insights ของ Google แล้วตรวจสอบไซต์ของคุณที่นั่น

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

เป้าหมายของคุณคือการได้รับคะแนน 90 ขึ้นไปสำหรับอุปกรณ์เคลื่อนที่และเดสก์ท็อป

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

มีเหตุผลว่าทำไมหน้านี้จึงใช้เวลานานในการโหลดบนมือถือ มีคำศัพท์ประมาณ 11,000 คำ โดยมีรูปภาพประมาณ 30 ภาพและวิดีโอ 3 รายการ

โดย GIPHY

นั่นเป็นหน้าใหญ่!

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

จากนั้น เมื่อฉันอัปเดตไซต์และเพจเพื่อให้ตรงกับ Page Experience และ Core Web Vitals ฉันจะแสดงให้เห็นว่าการตั้งค่าการทดสอบ A/B บนหน้านี้อาจส่งผลต่อผลลัพธ์ของฉันอย่างไร

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

สิ่งที่น่าสนใจที่ควรทราบคือแอป Convert Experiences ทำให้หน้าเว็บของฉันช้าลง 107 มิลลิวินาทีในพื้นหลัง ในขณะที่แอป Vimeo ทำให้เกิดความล่าช้า 1,567 มิลลิวินาที

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

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

เครื่องมือ PageSpeed ​​Insights มาพร้อมกับผลลัพธ์เหล่านี้อย่างไร

เครื่องมือ PageSpeed ​​Insights ใช้เครื่องมือทดสอบนักพัฒนาซอฟต์แวร์ Lighthouse ของ Google เพื่อให้ทราบถึงประสิทธิภาพของหน้าเว็บของคุณ

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

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

หากเราเปรียบเทียบการถ่วงน้ำหนักเวอร์ชันล่าสุดกับ Lighthouse เวอร์ชันใหม่ล่าสุด เราจะเห็นได้ว่า Cumulative Layout Shift และ Total Blocking Time ได้รับการถ่วงน้ำหนักในความสำคัญที่หนักกว่ามากเมื่อเทียบกับเวอร์ชันก่อนหน้า

นี่หมายความว่าองค์ประกอบอื่น ๆ มีความสำคัญน้อยลงหรือไม่?

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

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

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

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

ข้อมูลห้องปฏิบัติการและภาคสนามคืออะไร?

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

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

ข้อมูลคะแนนผู้ใช้ในฟิลด์ขึ้นอยู่กับเปอร์เซ็นไทล์ที่ 75 ของประสบการณ์ของผู้ใช้ในหน้านั้น

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

หาก 26% ของผู้ชมของคุณเรียกดูบน iPhone 5 ที่มีการเชื่อมต่อช้า คะแนนของคุณอาจลดลงเหลือ 74% และแสดงว่าเพจของคุณ 'ต้องปรับปรุง'

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

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

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

ตัวชี้วัดประสบการณ์การใช้งานเพจของ Google คืออะไร ตัวชี้วัด Web Vitals หลักสามประการ และเราจะปรับปรุงได้อย่างไร

มี เมตริก Page Experience พื้นฐาน 4 รายการและ อีก 3 รายการในชุดย่อยเฉพาะที่เรียกว่า Core Web Vitals (โฟกัสของการอัปเดตล่าสุดของ Google)

แต่ละเมตริกพื้นฐานเหล่านี้ทำได้ง่ายมาก สิ่งที่คุณต้องมีคือไซต์ที่ตอบสนอง ไม่มีโค้ดที่หลบเลี่ยง ไม่ครอบคลุมไซต์ในป๊อปอัป และให้ทำงานผ่าน HTTPS

นี่เป็นเพียงองค์ประกอบพื้นฐานเท่านั้น มีเมตริก Page Experience อีก 6 ตัวที่ใช้โดย Lighthouse เมื่อวัดประสิทธิภาพประสบการณ์ใช้งานเพจของคุณโดยใช้ข้อมูล Lab

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

เพื่อช่วยลดความซับซ้อนทั้งหมดนี้ Google ได้แบ่งสิ่งเหล่านี้ออกเป็น 3 Core Web Vitals:

• ระบายสีเนื้อหาที่ใหญ่ที่สุด
• ความล่าช้าในการป้อนข้อมูลครั้งแรกและ
• เลื่อนเค้าโครงสะสม

นี่คือจุดที่เราต้องปรับปรุง และการทดสอบของเราอาจส่งผลต่อการจัดอันดับของเราด้วย

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

1. Largest Contentful Paint (LCP)

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

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

ปัจจุบัน LCP ชั่งน้ำหนักที่ 25% ของคะแนน CWV ของคุณ

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

เป้าหมายของคุณควรทำให้ LCP โหลดได้ภายใน 2.5 วินาที

ปัญหาหลักที่ลดคะแนน/ความเร็ว LCP ของคุณคือ:

• เวลาตอบสนองของเซิร์ฟเวอร์ช้า
• Render-blocking JavaScript และ CSS ทำให้องค์ประกอบล่าช้า
• เวลาโหลดทรัพยากรช้า
• การแสดงผลฝั่งไคลเอ็นต์ช้า
• ไม่ดี/ตั้งค่าการเพิ่มประสิทธิภาพภาพไม่ถูกต้อง

วิธีปรับปรุงคะแนน LCP ของคุณ

มีหลายสิ่งที่คุณสามารถนำมาใช้เพื่อปรับปรุงคะแนน LCP ของคุณได้

ที่นี่ คุณสามารถดูตัวอย่างคะแนน LCP ของหน้าการขายก่อนที่จะทำการปรับแต่งตามที่แนะนำ

ขณะนี้องค์ประกอบ LCP ของฉันใช้เวลา 3.4 วินาทีในการโหลดบนหน้า แม้ว่าจะเป็นเพียงข้อความพาดหัว และหน้าของฉันใช้เวลาโหลด 14.7 วินาทีก่อนที่จะมีการโต้ตอบ

หากเราเลื่อนลงผ่านเครื่องมือ PageSpeed ​​Insights และดูโอกาส มีหลายสิ่งที่ฉันสามารถทำได้เพื่อปรับปรุงความเร็วของหน้าโดยรวมและหยุดบางสิ่งที่ทำให้ LCP ช้าลง

ลองผ่านพวกเขาทั้งหมด

ก. โหลดองค์ประกอบ LCP ล่วงหน้า

สิ่งแรกที่คุณต้องทำคือตรวจสอบว่าองค์ประกอบ LCP ที่แท้จริงคืออะไรสำหรับหน้าปัจจุบันของคุณ เนื่องจากองค์ประกอบอาจแตกต่างกันไปในแต่ละหน้า

ขณะอยู่ในมุมมองอุปกรณ์เคลื่อนที่ของเครื่องมือ PageSpeed ​​ให้เลื่อนหน้าลงไปยังส่วนการวินิจฉัยและคลิกองค์ประกอบ 'Largest Contentful Paint' และดูว่าเกิดอะไรขึ้น

ในหน้านี้ องค์ประกอบ LCP ของฉันคือพาดหัว

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

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

ด้วยวิธีนี้ รูปภาพจะเริ่มโหลดทันทีและไม่ถูกทำให้ช้าลงด้วยโค้ดหรือคำขออื่น

นี่เป็นเรื่องใหญ่

แนวปฏิบัติมาตรฐานคือขี้เกียจโหลดรูปภาพทั้งหมดบนหน้า เพื่อช่วยในความเร็วของหน้า แต่เมื่อคุณทำเช่นนั้นกับอิมเมจ LCP ของคุณ มันทำให้โหลดช้าลงจริง ๆ ทำให้คะแนน LCP ของคุณลดลง!

(นี่เป็นปัญหาใหญ่หากคุณกำลังทดสอบ A/B องค์ประกอบ LCP ของคุณด้วย!)

แล้วเราจะแก้ไขอย่างไร?

เราต้องการเขียนโค้ดเพื่อระบุว่าองค์ประกอบ LCP นี้ควรโหลดไว้ล่วงหน้าในหน้าใดหน้าหนึ่งโดยเฉพาะ

สคริปต์ที่คุณต้องการเพิ่มคือสคริปต์ rel=”preload” และจะมีลักษณะดังนี้:

ในตัวอย่างนี้ ฉันกำลังบอกให้หน้านี้โหลดรูปภาพ TRAFFIC-SMALL-HEADER ล่วงหน้า (ซึ่งเป็นองค์ประกอบรูปภาพ LCP สำหรับหน้านั้น) ฉันยังระบุตัวเลือกมิติข้อมูลหลายแบบเพื่อให้สามารถโหลดรูปภาพที่ตอบสนองได้สำหรับอุปกรณ์เคลื่อนที่และเดสก์ท็อป

การเปลี่ยนแปลงนี้เพียงอย่างเดียวจะช่วยให้ภาพที่โหลดช้าซึ่งส่งผลต่อคะแนน LCP ของคุณ

ธีม WordPress หรือ Shopify บางธีมจะอนุญาตให้คุณเพิ่มโค้ดที่กำหนดเองลงในส่วนหัวของหน้านั้นๆ ในขณะที่ปลั๊กอินบางตัวจะอนุญาต หากไม่สำเร็จ คุณยังสามารถแก้ไขไฟล์ header.php สำหรับเพจของคุณและเพิ่มโค้ดได้โดยตรง

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

เนื่องจากไซต์ของฉันสร้างขึ้นบน WordPress ฉันจะใช้ปลั๊กอิน WPRocket เนื่องจากจะช่วยฉันแก้ไขปัญหาส่วนใหญ่เกี่ยวกับ LCP ได้ในที่เดียว

ข. ใช้ประสิทธิภาพสูง/โฮสติ้งเฉพาะ

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

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

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

ที่นี่คุณจะเห็นว่าเวลาตอบสนองเซิร์ฟเวอร์เริ่มต้นของไซต์ของฉันคือ 2.67 วินาที

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

ค. เปิดใช้งานการแคชและเพิ่มความยาวแคช (ถ้าจำเป็น)

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

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

ง. เลื่อน JS ที่ไม่สำคัญ + ลบ JS . ที่ไม่ได้ใช้

เมื่อหน้าโหลด จะผลัดกันโหลดทีละอย่าง (ไม่พร้อมกัน) หรือช้าลงและพยายามโหลดหลาย ๆ อย่างพร้อมกัน (ซิงค์) สิ่งนี้ไม่เลวร้ายนักหากคุณมีเซิร์ฟเวอร์ที่รวดเร็ว หรือหากแอปพลิเคชันบุคคลที่สามที่คุณกำลังดึงมาจากการโหลดที่รวดเร็ว เช่น แอป Convert Experiences

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

ซึ่งมักจะเป็นสาเหตุใหญ่ของปัญหาการโหลด LCP เนื่องจากองค์ประกอบเหล่านั้นพยายามโหลดก่อนองค์ประกอบ LCP (นอกจากนี้ยังสามารถส่งผลต่อ First Input Delay)

คุณสามารถระบุ JS, แอพ หรือปลั๊กอินที่จะเลื่อนหรือลบภายใน WPRocket (เพียงตรวจสอบให้แน่ใจว่าได้ตั้งค่าสคริปต์ Convert ให้โหลดเป็นลำดับความสำคัญและไม่ถูกเลื่อนออกไป)

ด้วยวิธีนี้ JS ที่ไม่จำเป็นจะถูกลบออก JS อื่น ๆ จะถูกเลื่อนออกไปจนกว่าจะใช้งาน และสคริปต์ Convert สามารถทำงานได้โดยเร็ว

ไซด์โน้ต:

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

อี พิจารณาการลดขนาดโค้ด

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

ปลั๊กอินจำนวนมากจะช่วยให้คุณทำสิ่งนี้ได้

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

ฉ. ปรับรูปภาพให้เหมาะสมสำหรับการโหลดและการตอบสนองที่ขี้เกียจ (ไม่ใช่รูปภาพ LCP)

สิ่งที่ทำให้ประสิทธิภาพของหน้าช้าลงคือขนาดรูปภาพและปริมาณของรูปภาพที่คุณมี

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

(อย่าลืมโหลดอิมเมจ LCP ล่วงหน้า!)

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

กรัม ใช้การบีบอัดรูปภาพและการปรับขนาดที่ปรับเปลี่ยนตามอุปกรณ์

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

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

WPRocket ยังรวมเข้ากับปลั๊กอินที่เรียกว่า Imagify เพื่อบีบอัดและส่งรูปภาพที่ตอบสนอง (โดยเพิ่มตัวเลือก scrset หลายตัวสำหรับขนาดหน้าจอที่แตกต่างกัน)

ชม. สร้างการเชื่อมต่อบุคคลที่สามโดยเร็ว

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

จำได้ไหมว่าวิดีโอของฉันทำให้หน้าของฉันช้าลงได้อย่างไร

ด้วยการตั้งค่าคำขอดึงข้อมูล DNS ล่วงหน้าของบุคคลที่สาม ฉันสามารถเร่งการโหลดวิดีโอเหล่านั้นทั้งหมดได้

ผม. ใช้ CDN เพื่อลดเวลาในการโหลด

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

คุณสามารถทำเช่นนี้กับบางอย่างเช่น Cloudflare ได้ฟรี

เจ ใช้การบีบอัด Gzip หรือ Brotli เพื่อปรับขนาดไฟล์ให้เหมาะสม

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

แล้วการเปลี่ยนแปลงทั้งหมดนี้มีผลกระทบอย่างไร?

ฉันได้ปรับปรุงความเร็วในการโหลดไซต์ของฉัน โดยเริ่มจาก 13.5 วินาทีเป็น 3.3 วินาทีบนมือถือ ความเร็ว LCP ของฉันตอนนี้คือ 2.1 วินาที

นั่นคือการประหยัด 10.2 วินาที!

ไม่เลวใช่มั้ย

ยังมีบางสิ่งที่ต้องแก้ไข แต่ควรปรับปรุงในขณะที่เราทำงานกับ Core Web Vitals อื่นๆ อีก 2 รายการ

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

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

สาเหตุที่พบบ่อยที่สุดของ FID ที่ไม่ดีคือ:

• การดำเนินการสคริปต์ของบุคคลที่หนึ่งทำให้เกิดความล่าช้าในความพร้อมในการโต้ตอบ
• การดึงข้อมูลส่งผลต่อความพร้อมในการโต้ตอบ
• การดำเนินการสคริปต์ของบุคคลที่สามทำให้เวลาในการตอบสนองล่าช้า

First Input Delay จะถ่วงน้ำหนักเป็น 30% ของคะแนน CWV ของคุณและเป้าหมายของคุณคือทำให้การตอบสนองนั้นลดลงเหลือ 100 มิลลิวินาทีหรือน้อยกว่า

วิธีปรับปรุงคะแนนความล่าช้าในการป้อนข้อมูลครั้งแรกของคุณ

เราไม่สามารถวัด FID ได้หากไม่มีผู้ใช้จริง ดังนั้นเราจึงพยายามปรับปรุง Total Blocking Time (TBT) แทน เนื่องจากทั้งคู่เชื่อมต่อกัน

ลองย้อนกลับไปที่ผลลัพธ์ของหน้าของเรา...

ย้อนกลับไปเมื่อฉันวัดหน้าเว็บครั้งแรก TBT ของฉันคือ 1.5 วินาที (หรือ 1,560 มิลลิวินาที)

เนื่องจากฉันปรับปรุงองค์ประกอบ LCP มันจึงลดลงเหลือ 0.2 วินาที (210 มิลลิวินาที) และ 3.5 วินาทีจนกว่าจะมีการโต้ตอบอย่างเต็มที่

เนื่องจากเราได้แก้ไขปัญหาบางอย่างที่ทำให้ Total Blocking Time ช้าลงแล้ว โดยเพียงแค่แก้ไขปัญหา LCP บางอย่าง เช่น การลดขนาดโค้ดและการเลื่อนหรือลบ JS

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

ก. โหลดเนื้อหาและลิงก์ล่วงหน้า

นี่คือคุณสมบัติที่ยอดเยี่ยมภายใน WProcket ด้วยการโหลดอิมเมจ LCP ล่วงหน้า เรากำลังบอกให้เพจเริ่มโหลดอิมเมจ LCP โดยเร็วที่สุด

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

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

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

สิ่งสำคัญที่เราสามารถทำได้เพื่อปรับปรุง FID คือการลบโค้ดที่ล้นออกจากไซต์ของเรา

ไปข้างหน้าและโหลดหน้าของคุณใน GTMetrix

ว้าว คะแนนนั้นดูน่าทึ่งใช่มั้ยล่ะ!?

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

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

แถบสีเบจเป็นส่วนที่เราต้องปรับปรุง เนื่องจากเป็นช่วงที่โค้ดอื่นถูกบล็อกไม่ให้โหลด

ฉันสามารถเห็นได้ใน Waterfall ว่าปลั๊กอินและแบบอักษรเก่าบางตัวทำให้การโหลดหน้าเว็บช้าลง ดังนั้นฉันจึงสามารถกลับไปโหลดแบบอักษรที่กำหนดเองเหล่านี้ล่วงหน้าได้

เปิดขึ้นมาใน Waterfall จากนั้นคัดลอกและวาง URL แบบอักษรลงใน WProcket (ฉันควรจะเพิ่มพวกเขาก่อนหน้านี้ แต่ลืมอ๊ะ!)

มาดูวิธีการลบบล็อคเพิ่มเติมและโค้ดที่ล้นออกมาสองสามวิธีกัน

ข. ลบ Plugin Bloat

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

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

นอกจากนี้คุณยังสามารถ:

• อัปเดตปลั๊กอินเพื่อดูว่าทำงานเร็วขึ้นหรือไม่
• หรือมองหาปลั๊กอินอื่นที่ทำสิ่งเดียวกันสำหรับโค้ดที่น้อยกว่า

ค. ลบรหัสธีม Bloat

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

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

โดยส่วนตัวแล้ว ฉันใช้ธีมฟรีของ Neve เพราะมันสะอาดและน้ำหนักเบาด้วยขนาดการติดตั้งรวมเพียง 75kb แต่คุณสามารถใช้ธีมใดก็ได้ที่คุณต้องการ (เพียงค้นหาธีม 'โหลดเร็ว' หรือ 'มือถือมาก่อน')

ง. ลบหน้าบวม

ปัญหาสำคัญอีกประการหนึ่งที่อาจทำให้หน้าบวมและปัญหา CLS คือ Page Builders ส่วนใหญ่เป็นเพราะโค้ดส่วนเกินที่พวกเขาใช้เพื่อแสดงคุณลักษณะบางอย่าง

คุณสามารถดูคะแนน DOM ที่ต่ำกว่ามากได้โดยการลบปลั๊กอิน Page Builder หรือลดความซับซ้อนของโค้ดเพจ สร้างใหม่ด้วยตัวสร้าง หรือสร้างเพจ HTML ที่กำหนดเอง

คะแนนของฉันหลังจากเปลี่ยนสิ่งนี้เป็นเท่าไหร่?

ฉันยังไม่ได้ลบเครื่องมือสร้างเพจ แต่คะแนนยังคงลดลงเหลือเพียง 130 มิลลิวินาที เวลาบล็อกทั้งหมด และหน้าโหลดใน 1.9 วินาที

ต้องการปรับปรุงความเร็วหน้าเว็บของคุณให้ดียิ่งขึ้นไปอีกหรือไม่?

มีปลั๊กอินที่ยอดเยี่ยมอีกตัวหนึ่งที่คุณสามารถใช้เรียกว่า การล้างข้อมูลสินทรัพย์ (เป็นสิ่งที่ทีมของเราใช้ในการแปลง)

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

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

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

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

คุณเคยพยายามคลิกที่บางอย่างบนไซต์แล้วย้ายไปแล้วโฆษณาหรือแบนเนอร์แสดงแทนหรือไม่?

น่าผิดหวังใช่มั้ย?

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

(คนไร้ยางอายบางคนจะสร้างสิ่งนี้ขึ้นมาในรูปแบบมืดเพื่อรับการคลิกที่เฉพาะเจาะจง ฯลฯ โดยเฉพาะไซต์ที่ขายพื้นที่โฆษณา…)

CLS วัดจำนวนองค์ประกอบที่เคลื่อนที่ไปมาบนหน้าเว็บ (หรือที่เรียกว่าความเสถียรของภาพ) แล้วให้คะแนนไซต์ของคุณในเรื่องนี้ เป้าหมายคือหยุดไซต์เหล่านี้ไม่ให้สร้างประสบการณ์การใช้งานที่ไม่ดีนี้ และการถ่วงน้ำหนักในปัจจุบันคือ 15% ของคะแนน CMV ของคุณ

เป้าหมายของคุณคือการได้รับคะแนน CLS 0.1 หรือต่ำกว่า

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

• ภาพไม่มีมิติ
• โฆษณา การฝัง และ iframes ที่ไม่มีมิติ
• เนื้อหาที่แทรกแบบไดนามิก เช่น โฆษณาในแถบด้านข้างหรือส่วนหัวที่ดันเนื้อหาไปรอบๆ
• แบบอักษรเว็บทำให้เกิด FOIT/FOUT โดยการเปลี่ยนจากแบบอักษรทั่วไปเป็นแบบอักษรที่กำหนดเองและส่งผลต่อระยะห่างของเค้าโครง
• การดำเนินการที่รอการตอบสนองของเครือข่ายก่อนที่จะอัปเดต DOM

ข่าวดีก็คือเราได้แก้ไขปัญหานี้ไปมากแล้วด้วยการแก้ไขปัญหา LCP และ FID

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

หากคุณเลื่อนลงไปที่เครื่องมือ PageSpeed ​​Insights และคลิก 'หลีกเลี่ยงการเปลี่ยนแปลงการจัดวางขนาดใหญ่' คุณจะเห็นว่าองค์ประกอบใดในหน้าเว็บของคุณที่ทำให้เกิดปัญหา CLS

ในตัวอย่างของฉัน มันเป็นเพียงส่วนหัวที่เปลี่ยนเป็นเลย์เอาต์ที่ตอบสนองสำหรับอุปกรณ์เคลื่อนที่ และไม่ส่งผลกระทบต่อ CLS มากนัก

เว็บไซต์ของคุณอาจแตกต่างออกไป ดังนั้นให้ตรวจดูว่าอะไรเป็นสาเหตุของปัญหาและแก้ไขปัญหา

ตอนนี้เราได้ครอบคลุมแต่ละส่วนของ Core Web Vitals และวิธีปรับปรุงแล้ว มาดูกันว่าการทดสอบของคุณอาจส่งผลต่อคะแนนของคุณอย่างไร

Core Web Vitals ส่งผลต่อการทดสอบ UX และ A/B อย่างไร (และวิธีผ่านการประเมิน Core Web Vitals ขณะใช้สคริปต์การแปลง)

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

วิธีที่จะไม่ส่งผลกระทบเชิงลบต่อคะแนนสีที่มีเนื้อหามากที่สุดเมื่อทำการทดสอบ A/B

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

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

The issue you might have here is not with the Convert Experiences tool, but rather with bad practices for LCP improvements.

Like we mentioned earlier, most people make the mistake of lazy loading all images, including the LCP image, which affects the LCP score.

Convert Experiences uses both 'synchronous load' and 'body hide' methods to run tests. Simply put, the tool recognizes the element to be tested and then hides it as soon as it starts to load so the user never sees it, before changing it in under 50 milliseconds.

If you've lazy-loaded that LCP element though, the Convert Experiences app is going to have to wait for that element to load before it can do its job.

You can fix this by preloading the specific LCP elements on your control and test pages like we suggested above. This will get them to start loading immediately on page load, allow them to be recognized and hidden by the Convert app, and be replaced asap before the user notices.

Not only will this reduce flicker, but it will also give a good LCP score as the main LCP element (even when tested) will load fast.

And if the LCP element is not what you're testing? You should be pre-loading it anyway to improve that LCP score.

How to Improve First Input Delay when A/B Testing

The Convert code is incredibly fast, but your FID score still relies on all the other elements of your page.

Make sure to hit all the main requirements for speed that we talked about before so that there is no delay in the Convert code running. (Otherwise, the element you are testing will be hidden until it loads and then changes.)

• You can remove code bloat from other JS and defer them from running.
• You can also 'exclude' the Convert script from being deferred so that it loads up before any other JS so that it can make those test changes asap, while not hurting FID.

If you don't prioritize the Convert code and instead defer it by accident, it may not affect your FID score that much, but it might cause your test element to delay loading, while the script waits to run.

How To Decrease Cumulative Layout Shift Issues When A/B Testing

The potential issues with Cumulative Layout Shift and testing come down to how you run a layout test.

Ideally, you don't want to test massive layout changes with just the Convert Experiences editor. Instead, you want to test similar elements for variations ie swapping out a hero image for another image or swapping text for variations, etc. This means that the page layout stays the same, but a key element is swapped out for a variation.

But what if you want to test a minor layout shift, such as swapping the hero image and text location?

I recommend using Convert Experiences for small layout shifts to set up the test and then see how much it affects your CLS score before you push it live.

A real-world example:

Let's say that I set up that same flipped layout test as above. First, I would build the test inside the Convert Experiences app.

Then I can test this page variant in the page speed tool to get an idea of how it affects CLS.

Make sure you have the variant page open, and then click on the pen icon next to the variant in the Convert Experiences app, then select 'Open Force Variation URL':

This will load a pop up.

Make sure you have the variation page highlighted and then click to copy the URL.

You can input that URL into the PageSpeed Insights tool and measure the CLS and other CWV vitals for that variant.

Full disclosure:

In this particular example, I have not fixed any of the code bloat issues on this other page yet, but here you can see the original control page results based on just the LCP improvements.

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

แต่ที่น่าสนใจคือ ให้เปรียบเทียบคะแนน CLS นั้นในหน้าควบคุมกับผลลัพธ์ของตัวแปร:

อย่างที่คุณเห็น CLS ในหน้าตัวเลือกสินค้านั้นใช้ได้เนื่องจากคะแนนยังอยู่ในหลักเกณฑ์

(ปัญหาความเร็วจะได้รับการแก้ไขเมื่อฉันจัดเรียงปัญหาโค้ดล้นด้วยตัวสร้างเพจของฉัน แต่แอป Convert Experiences และการทดสอบเลย์เอาต์ทำงานได้อย่างรวดเร็วอย่างไม่น่าเชื่อ)

ดังนั้นการเปลี่ยนแปลงเลย์เอาต์เล็กๆ น้อยๆ ก็สามารถทำได้ เพียงต้องแน่ใจว่าได้ทดสอบก่อนแล้วค่อยเผยแพร่

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

โดย GIPHY

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

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

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

บทสรุป + ประเด็นสำคัญ

ดังนั้นคุณมีมัน คู่มือฉบับสมบูรณ์เกี่ยวกับ Google Page Experience การอัปเดต 3 Core Web Vitals การทดสอบของคุณอาจส่งผลต่อ Vitals เหล่านั้นอย่างไร และวิธีปรับปรุงคะแนนของคุณ

ต้องการปรับแต่งให้มากขึ้น?

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

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

จดจำ:

• แอป Convert Experiences ทำงานได้รวดเร็วอย่างเหลือเชื่อ แต่สามารถทำงานได้ดีขึ้นหากคุณปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบ Core Web Vitals & A/B
• Google ไม่ค่อยให้ข้อมูลเกี่ยวกับสัญญาณการจัดอันดับโดยเฉพาะ ดังนั้น Page Experience และ Core Web Vitals จึงมีความสำคัญและอาจมีความสำคัญมากขึ้นต่อไปในอนาคต (พวกเขาได้เพิ่มเกณฑ์ความเร็วไซต์แล้วตั้งแต่รุ่นก่อนหน้า)
• จากข้อมูลของ Google Core Web Vitals เป็นตัวแบ่งเมื่อสิ่งอื่น ๆ ทั้งหมดเท่าเทียมกัน ดังนั้นจึงคุ้มค่าที่จะทำเมื่อแข่งขันในระดับไฮเอนด์ หากเนื้อหาหรือข้อเสนอมีคุณภาพเท่ากัน และอันดับเพจของเพจที่แข่งขันกันมีความคล้ายคลึงกัน ประสบการณ์ของผู้ใช้จะกำหนดการจัดอันดับหน้าการค้นหา
• Core Web Vitals เกี่ยวข้องกับประสบการณ์ผู้ใช้จริงในหน้า ดังนั้นสิ่งนี้จึงสำคัญสำหรับ CRO ควรใช้แนวทางปฏิบัติที่ดีที่สุดเนื่องจากอาจส่งผลต่อความเร็วในการโหลดหน้าเว็บ อัตราตีกลับ CTR อัตรา Conversion และอื่นๆ โดยเฉพาะอย่างยิ่งบนอุปกรณ์เคลื่อนที่
• Core Web Vitals อาจเริ่มส่งผลกระทบต่อประสบการณ์หน้า Landing Page ของการเข้าชมที่เสียค่าใช้จ่าย และวิธีที่คุณแสดงในการประมูลโฆษณา/ค่าใช้จ่ายในการแสดงโฆษณา การปรับปรุงนี้อาจส่งผลต่อต้นทุนโฆษณาและการแสดงโฆษณา
• คุณต้องมีองค์ประกอบพื้นฐานเพื่อให้เป็นไปตามข้อกำหนดประสบการณ์การใช้งานเพจ โหลดเร็ว, CDN, แคช, HTTPS ก่อนที่คุณจะดูองค์ประกอบอื่นๆ เพื่อปรับปรุง
• การขยายโค้ดและลำดับการโหลดอาจส่งผลต่อทั้ง First Input Delay และ Largest Contentful Paint คุณจำเป็นต้องรู้วิธีตั้งค่า จำกัด โหลดองค์ประกอบล่วงหน้า หรือเลื่อน JSS และ CSS เพื่อโหลดหน้าของคุณอย่างมีประสิทธิภาพ
• เมื่อทดสอบเนื้อหาที่อยู่ครึ่งหน้าบน (ในพื้นที่ดูบนอุปกรณ์ใดก็ตาม) ให้ระวังองค์ประกอบ LCP และความจำเป็นในการโหลดล่วงหน้าเพื่อลดปัญหา LCP โดยเฉพาะอย่างยิ่งหากนั่นคือจุดเน้นในการทดสอบของคุณ
• แอป Convert Experiences ทำงานเร็วมากจนไม่ส่งผลกระทบกับ Core Web Vitals ในทางลบ สมมติว่าคุณกำลังเรียกใช้การทดสอบ A/B โดยที่การเปลี่ยนแปลงเลย์เอาต์ขนาดใหญ่จะไม่มีการเปลี่ยนแปลง (การสลับองค์ประกอบสำหรับองค์ประกอบที่คล้ายกัน ข้อความสำหรับข้อความ รูปภาพสำหรับรูปภาพ รูปแบบปุ่ม ฯลฯ) มิฉะนั้น จะส่งผลต่อ CLS (คุณสามารถทดสอบรูปแบบการเปลี่ยนแปลงเลย์เอาต์ก่อนเผยแพร่ได้เสมอ)
• เมื่อทำการเปลี่ยนแปลงเลย์เอาต์ที่ใหญ่ขึ้น ขอแนะนำให้ทำการทดสอบ URL แบบแยกส่วน (เช่นเดียวกับที่คุณทำสำหรับการทดสอบไดนามิก) เนื่องจากสิ่งนี้จะส่งผลต่อ CLS เพียงให้แน่ใจว่าได้อัปเดตรูปแบบที่ชนะเป็น URL เดิมและ 301 เปลี่ยนเส้นทางลิงก์ใดๆ ที่รูปแบบต่างๆ อาจได้รับ (สถานการณ์ที่ไม่ค่อยเกิดขึ้น)