ดูวิธีที่ผู้มีอำนาจตัดสินใจทางธุรกิจและผู้ที่ไม่ใช่นักพัฒนาซอฟต์แวร์สามารถปรับปรุง Core Web Vitals
บทนำ
เราพบว่าประสบการณ์ของผู้ใช้เว็บไซต์มีผลโดยตรงต่อผลลัพธ์ทางธุรกิจ การมอบประสบการณ์ที่ดีขึ้น ซึ่งก็คือการที่เว็บไซต์โหลดและตอบสนองผู้ใช้ได้เร็วขึ้น มักทำให้การมีส่วนร่วมและ Conversion เพิ่มขึ้น Core Web Vitals เป็นโครงการริเริ่มสำหรับวัดประสิทธิภาพของประสบการณ์ของผู้ใช้เว็บไซต์เพื่อหาสิ่งที่ควรปรับปรุง
อย่างไรก็ตาม เอกสารประกอบเกี่ยวกับ Core Web Vitals จำนวนมากมีวัตถุประสงค์เพื่อนักพัฒนาเว็บ ให้มีความเข้าใจทางเทคนิคอย่างลึกซึ้งและควบคุมโค้ดของตนได้อย่างเต็มที่ เว็บไซต์จำนวนมากสร้างขึ้นโดยผู้ที่ไม่ใช่นักพัฒนาซอฟต์แวร์โดยใช้ "เครื่องมือสร้างเว็บไซต์" แพลตฟอร์มอย่าง WordPress, Shopify, Wix หรือโซลูชันที่คล้ายกันอื่นๆ ซึ่งมักไม่มีทีมพัฒนาเว็บ
แม้จะมีทีมหรือนักพัฒนาเว็บที่ดูแลเรื่องนี้โดยเฉพาะ พวกเขาก็ไม่ได้เป็นผู้เดียวที่รับผิดชอบเรื่องประสิทธิภาพของเว็บ ผู้มีอำนาจตัดสินใจทางธุรกิจมีอิทธิพลอย่างมากต่อประสิทธิภาพของเว็บไซต์ ตั้งแต่การเลือกเนื้อหาและการออกแบบ ไปจนถึงการพัฒนากลยุทธ์การโฆษณาเพื่อพยายามเพิ่มการเข้าชมเว็บไซต์ของตน การตัดสินใจเหล่านี้มักมีผลกระทบอย่างมากต่อประสิทธิภาพเว็บไซต์
คู่มือนี้มีจุดประสงค์เพื่อให้ข้อมูลที่เกี่ยวข้องบางส่วนเพื่อให้เครื่องมือสร้างเว็บไซต์และเจ้าของเว็บไซต์เข้าใจและปรับปรุงประสบการณ์ของผู้ใช้ให้มากที่สุดเท่าที่จะเป็นไปได้ โดยไม่จำเป็นต้องมีความรู้ทางเทคนิคอย่างละเอียดเกี่ยวกับการพัฒนาเว็บ
ในขณะเดียวกัน ปัญหาด้านประสิทธิภาพจำนวนมากก็ทำให้นักพัฒนาแอปต้องใช้การแก้ไขทางเทคนิค และคู่มือสำหรับนักพัฒนาซอฟต์แวร์ของเราเองที่สามารถช่วยแก้ปัญหานี้ได้ บทความนี้ไม่ได้มีจุดประสงค์เพื่อให้เป็นคำแนะนำที่ครอบคลุม แต่เป็นการแนะนําโครงการริเริ่ม Core Web Vitals สำหรับผู้มีอำนาจตัดสินใจทางธุรกิจซึ่งมีสาเหตุทั่วไปบางประการที่ไม่ได้รับการพัฒนาซึ่งทำให้หน้าเว็บมีประสิทธิภาพไม่ดี นอกเหนือจากนี้ นักพัฒนาเว็บจะต้องมีส่วนร่วมเพื่อทำความคืบหน้าต่อไป
Core Web Vitals คืออะไร
Core Web Vitals คือชุดเมตริก 3 รายการที่ออกแบบมาเพื่อวัดประสบการณ์ของผู้ใช้ของหน้าเว็บ โดยเฉพาะความเร็วที่ผู้ใช้รู้สึกหน้าเว็บ อักษรแต่ละอันมีอักษรย่อ 3 ตัว ดังนี้
- การแสดงผลเนื้อหาขนาดใหญ่ที่สุด (LCP) จะวัดประสิทธิภาพของการโหลด ซึ่งก็คือเวลาเป็นวินาทีที่ใช้จนกว่าเนื้อหาที่โดดเด่นที่สุดของหน้าเว็บจะปรากฏหลังจากที่หน้าเริ่มโหลด
- Cumulative Layout Shift (CLS) วัดความเสถียรของภาพของหน้า หรือวัดว่าเนื้อหาเคลื่อนไหวไปมามากน้อยเพียงใดระหว่างที่โหลด
- การโต้ตอบกับ Next Paint (INP): หน้าเว็บตอบสนองต่อการคลิก การแตะ และการโต้ตอบกับแป้นพิมพ์ได้เร็วเพียงใด
แต่ละเมตริกจะวัดประสบการณ์ของผู้ใช้ในแง่ต่างๆ กัน นอกจากนี้ Google ยังมีเกณฑ์ที่แนะนำสำหรับเมตริกแต่ละรายการ และประสบการณ์ของผู้ใช้ที่ต่ำกว่าเกณฑ์ที่ต่ำกว่าเกณฑ์จะถือว่าเป็นดี และประสบการณ์ของผู้ใช้ที่สูงกว่าเกณฑ์ที่สูงกว่าจะถือว่าแย่ ระหว่างเกณฑ์เหล่านี้ ระบบจะถือว่าหน้าเว็บอยู่ในช่วงต้องปรับปรุง โปรดทราบว่าด้วยเมตริกเหล่านี้ ตัวเลขที่ต่ำกว่าย่อมดีกว่า
Core Web Vitals มีการวัดอย่างไร
Core Web Vitals วัดโดยผู้ใช้จริงของเว็บไซต์ และผู้ใช้รายต่างๆ จะให้ผลลัพธ์ที่แตกต่างกัน นี่ไม่ใช่ "อย่างที่ Google คิด" หรือ "คิดของ googlebot" แต่ผู้ใช้เว็บไซต์จริงได้พบด้วย
ผู้ใช้บางคนจะใช้อุปกรณ์ที่เร็วกว่าและเครือข่ายที่เร็วกว่า โดยบางอุปกรณ์จะทำงานได้ในอุปกรณ์ที่ช้าหรือเครือข่ายที่ช้า ผู้ใช้บางคนจะเข้าชมหน้าเว็บที่ใช้ง่ายและเร็วขึ้นในเว็บไซต์ ส่วนคนอื่นๆ จะไปที่หน้าที่ช้าและช้าลง จากนั้น ระบบจะนำผลลัพธ์ของประสบการณ์ของผู้ใช้เหล่านี้มารวมเข้าด้วยกันเพื่อวัดผลโดยรวมของเว็บไซต์ทั้งเว็บ
Google จะแสดงข้อมูลจากผู้ใช้ Chrome ที่เลือกใช้ไว้ในรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ซึ่งจะป้อนข้อมูลลงในเครื่องมือมากมายของ Google เช่น PageSpeed Insights และ Google Search Console
CrUX มีให้บริการในเว็บไซต์ยอดนิยมหลายล้านแห่ง แต่มีเพียงบางเว็บไซต์เท่านั้นที่อยู่ใน CrUX เครื่องมือการตรวจสอบผู้ใช้จริง (RUM) อื่นๆ ก็สามารถรวบรวมเมตริกเหล่านี้สำหรับเว็บไซต์ของคุณได้เช่นกัน
ฉันจะหา Core Web Vitals ของเว็บไซต์ได้อย่างไร
มีเครื่องมือจำนวนมากที่แสดงเมตริก Core Web Vitals ที่ให้บริการโดย Google และโดยบุคคลที่สาม โพสต์นี้จะแนะนำเครื่องมือ 2 อย่างที่ช่วยให้คุณดู Core Web Vitals สำหรับเว็บไซต์ได้อย่างรวดเร็ว หากต้องการทราบรายละเอียดเพิ่มเติมเกี่ยวกับเครื่องมืออื่นๆ ของ Google รวมถึงเวิร์กโฟลว์สำหรับการใช้เครื่องมือเหล่านี้เพื่อจัดการกับ Core Web Vitals โปรดดูโพสต์เวิร์กโฟลว์ Core Web Vitals โดยใช้เครื่องมือของ Google
หากแพลตฟอร์มของคุณมีโซลูชัน RUM แบบผสานรวม แพลตฟอร์มนั้นจะให้ข้อมูลที่มีรายละเอียดมากขึ้นสำหรับหน้าเว็บในเว็บไซต์ หรือให้คุณเจาะลึกหน้าเว็บที่เฉพาะเจาะจงหรือแบ่งกลุ่มผู้ใช้เพื่อช่วยทำความเข้าใจและระบุปัญหาได้
PageSpeed Insights
หากต้องการดูข้อมูลพร็อพเพอร์ตี้แบบรวดเร็วโดยไม่ต้องตั้งค่า คุณสามารถใช้ PageSpeed Insights (PSI) ได้ พิมพ์ URL แล้วคลิกวิเคราะห์ หากเว็บไซต์ของคุณรวมอยู่ใน CrUX คุณควรเห็นหน้า "สำรวจประสบการณ์ของผู้ใช้จริง" อย่างรวดเร็ว ส่วน:
ข้อมูลนี้แสดงให้เห็นว่าผู้ใช้ Chrome จริงได้รับประสบการณ์บนเว็บไซต์ของคุณอย่างไรในช่วง 28 วันที่ผ่านมา คุณจะเห็น Core Web Vitals ทั้ง 3 รายการที่ด้านบน พร้อมกับเมตริกสนับสนุนอื่นๆ ด้านล่าง (รวมถึงเมตริก INP ที่รอดำเนินการ) เฉพาะจำนวน Core Web Vitals เท่านั้นในการประเมินโดยรวมที่ผ่านหรือไม่ผ่านที่ด้านบนของหน้า แต่เมตริกอื่นๆ จะเป็นประโยชน์ในการแก้ปัญหาเกี่ยวกับ Core Web Vitals ดังที่แสดงในส่วนถัดไป
คุณสามารถสลับระหว่างมุมมอง "อุปกรณ์เคลื่อนที่" และ "เดสก์ท็อป" ได้โดยใช้ปุ่มที่ด้านบนของส่วนนี้ นอกจากนี้ คุณยังสลับระหว่าง URL นี้และข้อมูลทั้งหมดของต้นทางดังกล่าวได้โดยใช้การสลับที่ด้านบนขวา ซึ่งมีข้อมูลสําหรับทั้ง 2 แบบ
ตัวเลขเหล่านี้ควรเป็นตัวบ่งชี้กว้างๆ เกี่ยวกับประสิทธิภาพของเว็บไซต์ และเมตริกที่สามารถปรับปรุงได้ และประเภทของอุปกรณ์
Google Search Console
Google Search Console (GSC) มีไว้สำหรับเจ้าของเว็บไซต์เท่านั้น ดังนั้นจึงต้องมีการลงทะเบียนและยืนยันการเป็นเจ้าของเว็บไซต์จึงจะใช้เว็บไซต์ได้ ซึ่งจะให้รายละเอียดเกี่ยวกับวิธีที่ Google Search เห็นเว็บไซต์ของคุณ
GSC จะแสดงหน้าเว็บทั้งหมดที่ Google Search รู้จักในเว็บไซต์ของคุณ และให้รายละเอียดเกี่ยวกับ Core Web Vitals สำหรับหน้าทั้งหมด ซึ่งต่างจาก PageSpeed Insights
ระบบจะรวบรวมหน้าเว็บไว้ในกลุ่ม URL เพื่อให้คุณดูได้ว่าหน้าเว็บบางหมวดหมู่ (เช่น หน้ารายละเอียดผลิตภัณฑ์ หน้าบล็อก และอื่นๆ) มีปัญหาเกี่ยวกับ Core Web Vitals หรือไม่ เนื่องจากโฆษณาเหล่านี้มักสร้างขึ้นจากเทคโนโลยีหรือเทมเพลตที่คล้ายกัน จึงอาจมีปัญหาทั่วไปเกี่ยวกับหน้าเว็บเหล่านี้
ปัญหาทั่วไปเกี่ยวกับ Core Web Vitals สำหรับเครื่องมือสร้างเว็บไซต์
ปัญหาด้านประสิทธิภาพจำนวนมากทำให้นักพัฒนาซอฟต์แวร์ใช้การแก้ไขทางเทคนิค และคู่มือสำหรับนักพัฒนาซอฟต์แวร์โดยเฉพาะจะช่วยนักพัฒนาซอฟต์แวร์ในเรื่องนี้ได้ ในส่วนนี้ เราจะกล่าวถึงปัญหาที่พบได้ทั่วไปบางส่วนซึ่งไม่เกี่ยวข้องกับนักพัฒนาซอฟต์แวร์ ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจสามารถช่วยในการปรับปรุงเมตริกเหล่านี้ได้
เมื่อเราพูดว่า "ไม่ใช่นักพัฒนาซอฟต์แวร์" เราหมายถึงผู้ที่ใช้แพลตฟอร์มเครื่องมือสร้างเว็บไซต์ ซึ่งสามารถควบคุมวิธีการเขียนโค้ดจริงของเว็บไซต์ หรือผู้มีอำนาจตัดสินใจทางธุรกิจที่อาจตัดสินใจเกี่ยวกับการออกแบบเว็บไซต์ หรือช่วยจัดลําดับความสําคัญของงบประมาณได้อย่างจำกัด
ปัญหา Largest Contentful Paint (LCP)
LCP มุ่งวัดความเร็วในการโหลดของหน้าเว็บโดยวัดระยะเวลาตั้งแต่เมื่อมีการคลิกลิงก์จนกระทั่งเนื้อหาขนาดใหญ่ที่สุด (โดยปกติจะเป็นรูปภาพแบนเนอร์หรือบรรทัดแรก) ปรากฏในเบราว์เซอร์
หน้าเว็บควรมุ่งแสดงเนื้อหานี้ภายใน 2.5 วินาทีนับจากที่มีการคลิกลิงก์ เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานหน้าเว็บที่ดี หากใช้เวลานานกว่า 4 วินาที ระบบจะถือว่าหน้าเว็บได้รับประสบการณ์ที่ไม่ดี
หัวข้อถัดไปกล่าวถึงปัญหาที่พบได้ทั่วไปซึ่งส่งผลต่อ LCP ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจมีอิทธิพลได้
ความล่าช้าในการเริ่มโหลดหน้าเว็บ
เรามักนึกถึงการปรับปรุงความเร็วในการโหลดหน้าเว็บ แต่มักจะเกิดความล่าช้าก่อนที่จะเริ่มดำเนินการดังกล่าว การที่ LCP ต่ำกว่าเกณฑ์ 2.5 วินาทีจะเป็นไปไม่ได้หากเว็บไซต์ไม่ได้ดาวน์โหลดแค่ไม่กี่วินาที
Time to First Byte (TTFB) คือเวลาที่ใช้ในการดาวน์โหลดส่วนแรกของหน้าเว็บ หาก PageSpeed Insights แสดงเมตริกการวินิจฉัย TTFB ขนาดใหญ่เป็นสีแดงหรือสีเหลืองอำพัน การจัดการกับสิ่งเหล่านี้เป็นสิ่งสำคัญและควรมีผลโดยตรงต่อ LCP
ทำความเข้าใจผู้ชม
สำหรับปัญหา TTFB โปรดทำความเข้าใจกลุ่มเป้าหมาย หากเว็บไซต์โฮสต์อยู่ในประเทศหนึ่งแต่ให้บริการแก่กลุ่มเป้าหมายทั่วโลก ความใกล้ชิดทางภูมิศาสตร์ระหว่างผู้ใช้เว็บไซต์กับเว็บเซิร์ฟเวอร์ของคุณจะกลายเป็นปัจจัยหนึ่งใน TTFB ของหน้าเว็บ เครือข่ายนำส่งข้อมูล (CDN) ช่วยให้ระบบแคชสำเนาของเว็บไซต์ของคุณไว้ทั่วโลก เพื่อให้ใกล้เคียงกับผู้ใช้ของคุณมากขึ้น ผู้ให้บริการโฮสติ้งหลายรายรวม CDN เป็นส่วนหนึ่งของบริการและจะดูแลเรื่องนี้โดยอัตโนมัติ ตรวจสอบว่ากรณีนี้ตรงกับที่ที่คุณโฮสต์เว็บไซต์อยู่หรือไม่ บางแพลตฟอร์มมีบริการระดับที่แตกต่างกัน โดยมีตำแหน่ง CDN มากกว่าสำหรับระดับที่เสียค่าใช้จ่ายที่สูงกว่า ธุรกิจระดับโลกควรพิจารณาระดับที่สูงกว่าในกรณีเหล่านี้
ลดการเปลี่ยนเส้นทางให้เหลือน้อยที่สุด
การเปลี่ยนเส้นทางเป็นอีกสาเหตุหนึ่งที่ทำให้ TTFB ทำงานช้า เมื่อใช้งานแคมเปญโฆษณาหรือส่งการสื่อสารทางอีเมล พยายามลดจำนวนการเปลี่ยนเส้นทางโดยหลีกเลี่ยงการใช้เครื่องมือย่อลิงก์หลายรายการ หรือใส่ URL ที่ต้องเปลี่ยนเส้นทางลง เช่น การใช้ example.com/blog ในแคมเปญที่ต้องเปลี่ยนเส้นทางไปยัง www.example.com/blog ซึ่งจะเปลี่ยนเส้นทางไปยัง https://www.example.com/blog จะเพิ่มเวลาให้กับ TTFB ของหน้าเว็บ ตรวจสอบให้แน่ใจว่าแคมเปญการตลาดของคุณใช้จำนวนการเปลี่ยนเส้นทางขั้นต่ำที่สุดเท่าที่จะเป็นไปได้
ตรวจสอบให้แน่ใจว่าแคมเปญโฆษณามุ่งไปยังกลุ่มเป้าหมายที่ถูกต้อง
นอกจากนี้ ให้แน่ใจว่าแคมเปญโฆษณากำหนดเป้าหมายไปยังผู้ชมของคุณอย่างมีประสิทธิภาพ การได้รับการเข้าชมใหม่ๆ จำนวนมากจากผู้ใช้ที่อยู่ครึ่งโลก แต่คุณไม่สามารถนำเสนอผลิตภัณฑ์ได้ ถือเป็นทั้งค่าโฆษณาที่เสียเปล่าและส่งผลเสียต่อประสิทธิภาพของเว็บไซต์
พารามิเตอร์ของ URL อาจส่งผลต่อประสิทธิภาพของเว็บ
พารามิเตอร์ของ URL เช่น พารามิเตอร์ UTM มักใช้กับแคมเปญการตลาด วิธีนี้จะลดประสิทธิภาพในการแคชในโครงสร้างพื้นฐาน เนื่องจาก URL แต่ละรายการอาจดูเหมือนเป็นหน้าเว็บที่ไม่ซ้ำกัน แม้ว่าจะมีการแสดงหน้าเดียวกันทุกครั้งก็ตาม หากคุณใช้พารามิเตอร์ UTM โปรดปรึกษาผู้ให้บริการ CDN หรือทีมโครงสร้างพื้นฐานเพื่อให้แน่ใจว่าโครงสร้างพื้นฐานการแคชจะไม่สนใจพารามิเตอร์ของ URL เหล่านี้ เพื่อให้แคมเปญได้รับประโยชน์จากหน้าเว็บที่แคชไว้อยู่แล้ว
สื่ออาจมีต้นทุนสูงสำหรับประสิทธิภาพ
พิจารณาผลกระทบของสื่อที่มีต่อหน้าเว็บของคุณ สื่ออย่างรูปภาพและวิดีโอมักมีขนาดใหญ่กว่ามาก จึงใช้เวลาในการดาวน์โหลดนานกว่าข้อความ และยังทำให้การโหลดหน้าเว็บที่เหลือช้าลงอีกด้วย ซึ่งสำคัญมากเมื่อองค์ประกอบ LCP เป็นสื่อไม่ใช่ข้อความ องค์ประกอบ LCP คือรูปภาพในประมาณ 80% ของหน้าเว็บ คุณจึงต้องพิจารณาผลกระทบของสื่อในเว็บไซต์
ในขณะเดียวกัน เนื้อหาสื่อก็ช่วยสร้างประสบการณ์ด้านภาพที่สมบูรณ์ให้แก่ผู้ใช้ ซึ่งสร้างการมีส่วนร่วมได้มากกว่าเว็บไซต์ที่มีข้อความมากมาย ดังนั้น การนำสื่อออกจึงไม่ใช่ทางเลือกที่ดีนัก แต่การตระหนักถึงค่าใช้จ่ายของสื่อและวิธีลดสื่ออาจช่วยลดปัญหาด้านประสิทธิภาพได้
หลีกเลี่ยงภาพสไลด์
ภาพหมุนที่สร้างขึ้นจากรูปภาพหลายรูปอาจส่งผลต่อเวลาในการโหลดหน้าเว็บโดยรวม เนื่องจากอาจทำให้ต้องดาวน์โหลดรูปภาพหลายรูปพร้อมกันหากไม่ได้ใช้อย่างเหมาะสม นอกจากนี้ แม้จะมีการใช้งานอย่างแพร่หลาย แต่ภาพหมุนมักไม่ได้มอบประสบการณ์การใช้งานที่ยอดเยี่ยมแก่ผู้ใช้ ดังนั้นโปรดคิดให้รอบคอบก่อนใช้งานบนเว็บไซต์ของคุณ
ใช้รูปภาพที่เพิ่มประสิทธิภาพเว็บ
จากนั้นก็จะมีขนาดของเนื้อหาสื่อ รูปภาพจำนวนมากบนเว็บแสดงด้วยความละเอียดที่สูงเกินไป ตรวจสอบว่าพาร์ทเนอร์สื่อหรือเอเจนซีออกแบบจัดหารูปภาพที่เพิ่มประสิทธิภาพเว็บแทนรูปภาพที่มีคุณภาพสำหรับการพิมพ์ขนาดเต็มที่มักจัดหาให้ คุณสามารถใช้บริการอย่าง TinyJPG เพื่อนำข้อมูลที่ไม่จำเป็นออกจากรูปภาพอย่างรวดเร็วก่อนที่จะอัปโหลดได้ แพลตฟอร์มเว็บหลายแห่งจะพยายามเพิ่มประสิทธิภาพรูปภาพโดยอัตโนมัติเมื่ออัปโหลด แต่เนื่องจากไม่ทราบขนาดที่รูปภาพเหล่านั้นจะแสดงในอุปกรณ์ของผู้ใช้ การเริ่มต้นใช้รูปภาพขนาดเล็กกว่าอาจให้ผลตอบแทนที่คุ้มค่า
ระมัดระวังเป็นพิเศษกับวิดีโอ
พิจารณาเพิ่มเติมเมื่อใช้วิดีโอ วิดีโอเป็นเนื้อหาที่ใหญ่ที่สุดประเภทหนึ่งและช้าที่สุดที่เว็บไซต์ดาวน์โหลดและแสดงผล ดังนั้น พยายามอย่าใช้วิดีโอมากเกินไป หลีกเลี่ยงการใช้โฆษณาที่ด้านบนของหน้าเว็บ และบันทึกไว้ที่ด้านล่างของหน้าเว็บ ซึ่งจะทําให้เนื้อหาที่ราคาถูกกว่าโหลดได้อย่างรวดเร็วเพื่อมอบประสบการณ์การโหลดที่ดีขึ้นให้แก่ผู้ใช้และช่วยให้มั่นใจว่า LCP จะไม่ได้รับผลกระทบ
การทดสอบ A/B
ธุรกิจจำนวนมากทำการทดสอบ A/B เพื่อทดลองการเปลี่ยนแปลงในเว็บไซต์ วิธีการติดตั้งใช้งานเหล่านี้อาจส่งผลกระทบอย่างมากต่อ LCP
โซลูชันการทดสอบ A/B จำนวนมากจะล่าช้าเมื่อเว็บไซต์แสดงต่อผู้ใช้เป็นครั้งแรกจนกว่าจะมีการนำการเปลี่ยนแปลงในการทดสอบไปใช้ การดำเนินการนี้จะหลีกเลี่ยงการแสดงเว็บไซต์เวอร์ชันเดิม แต่ต้องชะลอระดับการเข้าถึงเว็บไซต์ต่อผู้ใช้ ระบบจะใช้โซลูชันอื่นๆ จากฝั่งเซิร์ฟเวอร์เพื่อหลีกเลี่ยงความล่าช้านี้ ใช้เวลาทำความเข้าใจประสิทธิภาพของการทดสอบ A/B และดูว่าการทดสอบเกิดปัญหาล่าช้าหรือไม่ นอกจากนี้ ให้พิจารณาใช้โซลูชันการทดสอบ A/B ฝั่งเซิร์ฟเวอร์แทนหากเป็นไปได้
การทดสอบ A/B จะให้ความคิดเห็นที่มีประโยชน์ก่อนที่จะเปิดตัวการเปลี่ยนแปลงใหม่ๆ แต่จะต้องชั่งน้ำหนักค่าใช้จ่ายสำหรับประสิทธิภาพของหน้าเว็บเทียบกับประโยชน์ที่อาจได้รับ
ไม่ว่าโครงสร้างพื้นฐานจะเป็นอย่างไร ทุกคนที่ทำการทดสอบ A/B ควรคำนึงถึงแนวทางปฏิบัติแนะนำต่อไปนี้เสมอ
- จำกัดเครื่องมือทดสอบ A/B ให้อยู่เฉพาะหน้าที่เป็นส่วนหนึ่งของการทดสอบเท่านั้น แทนที่จะหน่วงเวลาทุกหน้า ในกรณีที่หน้าเว็บส่วนใหญ่อาจไม่ได้ทำการทดสอบ A/B ในช่วงเวลาหนึ่งๆ
- จำกัดการทดสอบ A/B ให้กับผู้ใช้กลุ่มย่อยเพื่อหลีกเลี่ยงไม่ให้ส่งผลต่อผู้ใช้ส่วนใหญ่
- จำกัดการทดสอบ A/B ให้น้อยที่สุดโดยใช้เวลาขั้นต่ำที่จำเป็นต่อการให้ผลลัพธ์ที่สรุปผลได้ ยิ่งทำการทดสอบ A/B นานเท่าไร หน้าเว็บก็ยิ่งพบว่าหน้าเว็บมีประสิทธิภาพแย่
- สิ่งสำคัญที่สุดคือ อย่าลืมนำการทดสอบ A/B ออกเมื่อไม่จำเป็นต้องใช้แล้ว
ปัญหา Cumulative Layout Shift (CLS)
CLS จะวัดความเสถียรของภาพของหน้าเว็บ นั่นคือการเปลี่ยนแปลงเนื้อหาของหน้าเมื่อเนื้อหาโหลด ซึ่งอาจเป็นการเสียสมาธิหากผู้ใช้ได้เริ่มอ่านหน้าเว็บแล้ว แต่กลับเสียตำแหน่งไปเมื่อมีการวางเนื้อหาหรือโฆษณาเพิ่มเติม นอกจากนี้ยังอาจส่งผลให้ผู้ใช้คลิกเนื้อหาที่ไม่ถูกต้องโดยไม่ได้ตั้งใจหากเลย์เอาต์ของหน้าเว็บเปลี่ยนไปบ่อยเกินไป โปรดระมัดระวังอย่างมากกับเนื้อหาแบบไดนามิกที่โหลดในภายหลัง และอาจย้ายเนื้อหาของหน้าแรกบางส่วนได้
ซึ่งวัดด้วยสูตรทางคณิตศาสตร์ที่คํานวณปริมาณการเลื่อนเนื้อหาและปริมาณการเลื่อนเนื้อหา โดยจะแสดงเป็นเศษส่วนที่ไม่มีหน่วยที่มีค่าเท่ากับ 0.1 หรือน้อยกว่า และมองว่าเป็นดี และค่า 0.25 ขึ้นไปเป็นแย่
อ่านหัวข้อถัดไปเกี่ยวกับปัญหาที่พบบ่อยซึ่งส่งผลต่อ CLS ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจสามารถตัดสินได้
ตรวจสอบการโหลดรูปภาพเมื่อคุณเลื่อนหน้าเว็บ
เทมเพลตจำนวนมากหลีกเลี่ยงการโหลดรูปภาพที่อยู่ด้านล่างของหน้าเพื่อเพิ่มทรัพยากรให้กับรูปภาพที่อยู่บนหน้าจอระหว่างการโหลดหน้าเว็บครั้งแรก จากนั้นรูปภาพจะโหลดเมื่อผู้ใช้เลื่อนลง เทคนิคการโหลดรูปภาพนี้เรียกว่าการโหลดแบบ Lazy Loading
เทมเพลตหน้าเว็บควรสำรองพื้นที่สำหรับรูปภาพที่โหลดแบบ Lazy Loading ไว้ เพื่อที่หากผู้ใช้เลื่อนอย่างรวดเร็วก่อนที่จะโหลดรูปภาพ เนื้อหารอบๆ ก็จะไม่เลื่อนไปรอบๆ หากเทมเพลตหรือแพลตฟอร์มของคุณไม่เป็นเช่นนั้น ให้ลองเปลี่ยนไปใช้เทมเพลตหรือแพลตฟอร์มที่รองรับ
โปรดระวังโฆษณาที่วางไว้ตรงกลางเนื้อหา
โฆษณาที่แทรกไว้ตรงกลางเนื้อหามีความเสี่ยงที่จะดันเนื้อหาลงไปอยู่ด้านล่าง เนื่องจากโฆษณามักใช้เวลาโหลดนานกว่าเล็กน้อย ซึ่งนานกว่ารูปภาพที่อธิบายไว้ในส่วนก่อนหน้า การมีตัวระบุดังกล่าวที่ด้านข้างของเนื้อหาหลักในหน้าเป็นรูปแบบที่พบได้บ่อยซึ่งช่วยลดความเสี่ยงนี้ วิธีการที่จะบรรลุผลในทางปฏิบัตินั้นขึ้นอยู่กับแพลตฟอร์มนั้นๆ และเทมเพลตที่คุณใช้สร้างเว็บไซต์
หลีกเลี่ยงการเพิ่มเนื้อหาแบบไดนามิกที่ด้านบนของหน้า
หลีกเลี่ยงการเพิ่มการแจ้งเตือนและแบนเนอร์ที่ด้านบนของหน้าหลังจากโหลดหน้าเว็บ เช่น แบนเนอร์คุกกี้หรือข้อเสนอพิเศษ การเลือกซ้อนการแจ้งเตือนและแบนเนอร์เหนือเนื้อหาหลักแทนจะทำให้เนื้อหาในหน้าเว็บไม่เลื่อนตำแหน่ง ตัวเลือกในส่วนนี้จะขึ้นอยู่กับแพลตฟอร์มและเทมเพลตที่ใช้สำหรับหน้าเว็บของคุณ เช่นเดียวกับส่วนก่อนหน้านี้
ปัญหาการโต้ตอบกับ Next Paint (INP)
INP วัดการตอบสนองของหน้าเว็บ ซึ่งจะประเมินว่าหน้าเว็บตอบสนองต่อการโต้ตอบอย่างรวดเร็ว เช่น การคลิก การแตะ และการป้อนข้อมูลด้วยแป้นพิมพ์หรือไม่ หน้าเว็บที่ไม่ได้ตอบสนองต่อข้อมูลจากผู้ใช้อย่างรวดเร็วมักจะรู้สึกว่าช้าและทำให้ผู้ใช้รู้สึกหงุดหงิด
INP วัดการโต้ตอบที่ตรงตามเกณฑ์ทั้งหมดทุกครั้งในช่วงชีวิตของหน้าเว็บ และรายงานการโต้ตอบที่แย่ที่สุด INP มีเกณฑ์ดีที่ 200 มิลลิวินาที และเกณฑ์ที่แย่ที่ 500 มิลลิวินาที
เมตริกการปรับเปลี่ยนตามอุปกรณ์และโดยเฉพาะ INP เป็นเมตริกที่มีปัญหาในการเพิ่มประสิทธิภาพ เมื่อเมตริกเหล่านี้อยู่ในเกณฑ์ด้อยคุณภาพ มักเป็นเพราะการโต้ตอบล่าช้าเนื่องจากหน้าเว็บพยายามทำสิ่งต่างๆ มากเกินไป ดังนั้นวิธีแก้ไขหลักๆ จึงเกี่ยวข้องกับการนำโค้ดที่ไม่จำเป็นออกเพื่อทำให้หน้าเว็บเบาลง
หัวข้อถัดไปจะกล่าวถึงปัญหาที่พบบ่อยบางส่วนที่ส่งผลต่อ INP ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจสามารถพิจารณาได้
ดูแลฤดูใบไม้ผลิให้สะอาด
ตรวจสอบปลั๊กอินและวิดเจ็ตที่เพิ่มลงในเว็บไซต์ และนำออกหากไม่ได้ใช้งานแล้ว บ่อยครั้งที่การเพิ่มปลั๊กอินเพื่อทดลองบางอย่างทำได้ง่ายกว่าการต้องจำไว้ว่าต้องนำปลั๊กอินออกไปในภายหลังหากรู้สึกว่าการใช้ปลั๊กอินนั้นไม่มีประโยชน์ นี่เป็นสาเหตุที่ทำให้การโต้ตอบช้าลง แต่เป็นการเพิ่มประสิทธิภาพที่ค่อนข้างง่ายกว่าแพลตฟอร์มอื่นๆ
ในทำนองเดียวกัน หากคุณใช้เครื่องจัดการแท็กสำหรับแคมเปญการตลาด ให้ตรวจสอบว่ามีการนำแคมเปญเก่าออกแล้ว ถึงแม้ว่าจะไม่มีการเริ่มทำงานอีกต่อไป แต่ยังคงต้องดาวน์โหลดและรวบรวมโค้ดจากแคมเปญการตลาดที่หมดอายุแล้วในแต่ละหน้า ซึ่งอาจทำให้การโต้ตอบของผู้ใช้ช้าลงระหว่างการโหลดหน้าเว็บเริ่มต้น
หลีกเลี่ยงวิดเจ็ตและปลั๊กอินราคาแพง
วิดเจ็ตและปลั๊กอินราคาแพงสำหรับการคำนวณนั้นอาจดูดี แต่ช่วยปรับปรุงประสบการณ์ของผู้ใช้หรือแย่ลงได้จริง Lighthouse มีรายงาน "วิเคราะห์ปัญหาด้านประสิทธิภาพ" ใน PageSpeed Insights ที่ช่วยระบุ JavaScript ที่ส่งผลต่อประสิทธิภาพของเว็บไซต์อย่างเห็นได้ชัด
โดยหลักการแล้ว ให้จำกัดวิดเจ็ตไว้เฉพาะหน้าที่จำเป็นต้องใช้เท่านั้น หากคุณใช้การฝัง Google Maps ในหน้าติดต่อเราเท่านั้น ก็ไม่จำเป็นต้องโหลดวิดเจ็ตบนทุกหน้าที่อาจทำให้เกิดปัญหาการตอบสนอง
พิจารณาจํานวนโฆษณา โดยเฉพาะบนอุปกรณ์เคลื่อนที่
โฆษณาเป็นกลยุทธ์การสร้างรายได้ที่ดีสำหรับธุรกิจหลายแห่ง แต่มักมีความซับซ้อนและใช้ทรัพยากรจำนวนมาก ยิ่งมีโฆษณามาก ทรัพยากรก็จะยิ่งใช้ทรัพยากรมาก ซึ่งอาจรบกวนความเร็วของหน้า โดยเฉพาะอย่างยิ่งในอุปกรณ์เคลื่อนที่ซึ่งหน่วยความจำที่มีกำลังในการประมวลผลมักจะไม่ดีเท่าที่ทำในอุปกรณ์เดสก์ท็อปหรือแล็ปท็อป
ลองพิจารณาความสมดุลระหว่างการสร้างรายได้กับประสิทธิภาพ หากผู้ใช้ออกจากหน้าเว็บเร็วขึ้นเนื่องจากประสบการณ์ที่ไม่ดี โฆษณาเพิ่มเติมเหล่านั้นอาจทำให้คุณเสียรายได้มากกว่าที่ควร
หลีกเลี่ยงขนาดหน้าเว็บมากเกินไป
หน้าเว็บขนาดใหญ่และซับซ้อนต้องใช้เวลาในการประมวลผลมากกว่าเพื่อแสดง เช่น หากคุณมีแกลเลอรีผลิตภัณฑ์ที่มีผลิตภัณฑ์ต่างๆ กว่า 1,000 รายการ ก็อาจต้องใช้เวลาสักพักกว่าจะแสดงในหน้าต่างเบราว์เซอร์ของผู้ใช้ พิจารณาว่าเมื่อใดควรใส่เลขหน้าเพื่อลดเวลานี้
ฉันจะขอความช่วยเหลือเพิ่มเติมได้อย่างไร
โพสต์นี้มีข้อควรพิจารณาทั่วไปที่เจ้าของธุรกิจอาจใช้ซึ่งอาจส่งผลต่อประสิทธิภาพ นอกเหนือจากนี้ คุณอาจต้องปรึกษานักพัฒนาเว็บเพื่อรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับสิ่งที่คุณสามารถทำได้เพื่อปรับปรุงประสิทธิภาพเว็บไซต์ของคุณ
ข้อมูลเฉพาะแพลตฟอร์ม
แพลตฟอร์มส่วนใหญ่ให้ความสำคัญกับประสิทธิภาพของเว็บเป็นอย่างมาก และอาจมีคำแนะนำเฉพาะแพลตฟอร์มเกี่ยวกับวิธีปรับปรุงเรื่องนี้ นอกจากนี้ คุณยังอาจเข้าถึงทีมประสิทธิภาพบนเว็บโดยเฉพาะซึ่งเป็นส่วนหนึ่งของการใช้แพลตฟอร์มดังกล่าว ผู้ซึ่งสามารถให้คำแนะนำเพิ่มเติมเกี่ยวกับวิธีปรับปรุงเว็บไซต์ได้
Lighthouse ยังแสดงข้อมูลเฉพาะแพลตฟอร์มโดยใช้ฟังก์ชัน Stack Pack ซึ่งช่วยแนะนำคำแนะนำที่เหมาะสมให้แก่ผู้ใช้ของแพลตฟอร์มที่รองรับอีกด้วย
แพลตฟอร์มต่างๆ ได้รับการปรับปรุงอย่างต่อเนื่องเมื่อเวลาผ่านไป และหลายๆ แพลตฟอร์มก็มุ่งเน้นที่ประสิทธิภาพและ Core Web Vitals ในขณะนี้ ตรวจสอบว่าแพลตฟอร์มของคุณทันสมัยอยู่เสมอเพื่อรับประโยชน์จากการปรับปรุงล่าสุดที่นักพัฒนาซอฟต์แวร์แพลตฟอร์มทำ
ซึ่งวิธีนี้จะง่ายที่สุดเมื่อคุณใช้แพลตฟอร์มที่โฮสต์ซึ่งผู้ให้บริการแพลตฟอร์มจะจัดการแพลตฟอร์มดังกล่าวโดยอัตโนมัติ รวมถึงการอัปเดตแพลตฟอร์ม หากคุณโฮสต์แพลตฟอร์มด้วยตนเอง เช่น การติดตั้ง WordPress ในเครื่องในเซิร์ฟเวอร์ของคุณเอง การตรวจสอบว่าแพลตฟอร์มได้รับการอัปเดตเป็นประจำจะช่วยให้เว็บไซต์ของคุณได้รับประโยชน์จากการปรับปรุงต่างๆ ที่นักพัฒนาแพลตฟอร์มดำเนินการ ธุรกิจควรให้ความสำคัญกับการดูแลนี้ หรือเลือกบริการที่จัดการเรื่องนี้ให้
ดึงดูดนักพัฒนาเว็บ
นักพัฒนาเว็บที่มีความเชี่ยวชาญเกี่ยวกับประสิทธิภาพของเว็บมักจะแก้ไขปัญหาได้มากกว่าเจ้าของธุรกิจ คุณอาจให้นักพัฒนาเว็บสร้างเว็บไซต์ของคุณตั้งแต่ต้นหรือเพื่อการเปลี่ยนแปลงเป็นระยะ หรืออาจมีทีมพัฒนาเฉพาะหรือคุณอาจต้องหานักพัฒนาที่จะเข้ามามีส่วนร่วม (ควรจะเป็นทีมที่มีความเชี่ยวชาญด้านประสิทธิภาพของเว็บ)
ปรึกษานักพัฒนาซอฟต์แวร์หากคำแนะนำที่ให้ไว้ที่นี่ไม่เพียงพอที่จะช่วยแก้ปัญหาด้านประสิทธิภาพของเว็บไซต์คุณ แต่หวังว่าตัวอย่างก่อนหน้านี้ได้แสดงให้เห็นว่าการทำงานร่วมกับนักพัฒนาซอฟต์แวร์ควรจัดสมดุลระหว่างลำดับความสำคัญของธุรกิจกับการตัดสินใจด้านการพัฒนาซอฟต์แวร์เพื่อให้ได้โซลูชันที่เหมาะสมสำหรับเว็บไซต์ของคุณ
โปรดทราบว่าประสิทธิภาพของเว็บไม่ใช่งานที่ต้องทำเพียงครั้งเดียว การรักษาเว็บไซต์ให้มีประสิทธิภาพดีมักต้องอาศัยการตรวจสอบและการบำรุงรักษาเป็นประจำ เพื่อให้แน่ใจว่าเว็บไซต์จะไม่ถดถอยหลังจากมีการปรับปรุง
บทสรุป
เว็บไซต์มักเป็นจุดเริ่มต้นแรกสำหรับธุรกิจที่มีลูกค้า และคุณต้องการให้เว็บไซต์เป็นประสบการณ์ที่ยอดเยี่ยมสำหรับลูกค้า วิธีการนี้ใช้กับทั้งผู้เข้าชมครั้งแรกที่รู้สึกประทับใจในธุรกิจของคุณ แต่ก็รวมถึงผู้เข้าชมซ้ำและลูกค้าที่ภักดี ซึ่งควรได้รับประสบการณ์ที่ราบรื่นที่สุด ซึ่งควรปราศจากความไม่พอใจซึ่งอาจทำให้มีความประทับใจในด้านลบ Core Web Vitals เป็นการวัดประสบการณ์ของผู้ใช้ที่ Google แนะนำให้เว็บไซต์พิจารณา ด้วยประโยชน์ที่เว็บมีทั้งหมด ผู้ใช้สามารถ (และจะลอง) ลองเว็บไซต์อื่นหากพวกเขารู้สึกหงุดหงิดกับเว็บไซต์ของคุณ
ในขณะเดียวกัน Core Web Vitals เป็นเพียงข้อมูลการวัดค่าหนึ่งของเว็บไซต์ ธุรกิจจำเป็นต้องตัดสินใจด้วยตนเองว่าจะลงทุนในเว็บไซต์ของตัวเองเท่าใด และผลตอบแทนที่จะได้รับจากการลงทุนนั้น
กิตติกรรมประกาศ
ภาพขนาดย่อโดย Carlos Muza จาก Unsplash