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

ดูวิธีที่ผู้มีอำนาจตัดสินใจทางธุรกิจและผู้ที่ไม่ใช่นักพัฒนาสามารถปรับปรุง Core Web Vitals

เกริ่นนำ

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

อย่างไรก็ตาม เอกสารจำนวนมากของ Core Web Vitals ก็มุ่งเป้าไปที่นักพัฒนาเว็บซึ่งมีความเข้าใจทางเทคนิคที่ลึกซึ้งและการควบคุมโค้ดของตนอย่างเต็มที่ เว็บไซต์จำนวนมากสร้างขึ้นโดยผู้ที่ไม่ใช่นักพัฒนาซอฟต์แวร์โดยใช้แพลตฟอร์ม "เครื่องมือสร้างเว็บไซต์" เช่น WordPress, Shopify, Wix หรือโซลูชันอื่นๆ ที่คล้ายกัน และมักไม่มีทีมพัฒนาเว็บ

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

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

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

Core Web Vitals คืออะไร

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

• Largest Contentful Paint (LCP) จะวัดประสิทธิภาพการโหลด นั่นคือใช้เวลาเป็นวินาทีกว่าที่เนื้อหาที่โดดเด่นที่สุดของหน้าเว็บจะปรากฏขึ้นหลังจากเริ่มโหลดหน้าเว็บ
• Cumulative Layout Shift (CLS) จะวัดความเสถียรของภาพของหน้าเว็บ ซึ่งเป็นระดับที่เนื้อหาเคลื่อนที่ไปมาขณะโหลด
• การโต้ตอบกับ Next Paint (INP) ซึ่งแทนที่ FID อย่างเป็นทางการเมื่อวันที่ 12 มีนาคม 2024 จะวัดการตอบสนองของหน้าเว็บ ซึ่งก็คือความเร็วที่หน้าเว็บตอบสนองต่อการคลิก การแตะ และการโต้ตอบกับแป้นพิมพ์

แต่ละเมตริกจะวัดประสบการณ์ของผู้ใช้ในด้านต่างๆ นอกจากนี้ 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 ต่างจาก PageSpeed Insights ตรงที่จะแสดงหน้าทั้งหมดที่ Google Search รู้จักในเว็บไซต์ของคุณ และให้รายละเอียด Core Web Vitals สำหรับทุกหน้าเว็บ ดังนี้

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

ปัญหา Core Web Vitals ที่พบบ่อยสำหรับเครื่องมือสร้างเว็บไซต์

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

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

ปัญหาเกี่ยวกับ Largest Contentful Paint (LCP)

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

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

ดูปัญหาทั่วไปส่วนหนึ่งซึ่งส่งผลต่อ LCP ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจได้อธิบายไว้ในส่วนถัดไป

ความล่าช้าในการเริ่มต้นโหลดหน้าเว็บ

เรามักคิดเกี่ยวกับการปรับปรุงเวลาในการโหลดหน้าเว็บ แต่หลายครั้งก่อนที่จะเริ่มต้น ค่า LCP จะต่ำกว่าเกณฑ์ 2.5 วินาที ซึ่งเป็นไปไม่ได้หากเว็บไซต์ไม่ได้ดาวน์โหลดเป็นเวลา 2-3 วินาที

Time to First Byte (TTFB) คือเวลาที่ใช้ในการดาวน์โหลดส่วนแรกของหน้าเว็บ หาก PageSpeed Insights แสดงเมตริกการวินิจฉัย TTFB ขนาดใหญ่เป็นสีแดงหรือเหลืองอำพัน การแก้ไขดังกล่าวถือเป็นกุญแจสำคัญและน่าจะส่งผลดีต่อ LCP โดยตรง

ทำความเข้าใจผู้ชม

สำหรับปัญหาเกี่ยวกับ TTFB สิ่งสำคัญคือการทำความเข้าใจผู้ชมของคุณ หากเว็บไซต์ของคุณโฮสต์อยู่ในประเทศหนึ่ง แต่ให้บริการแก่ผู้ชมทั่วโลก ความใกล้ชิดทางภูมิศาสตร์ระหว่างผู้ใช้ของเว็บไซต์และเว็บเซิร์ฟเวอร์ของคุณจะกลายเป็นปัจจัยหนึ่งในการพิจารณา TTFB ของหน้าเว็บ เครือข่ายนำส่งข้อมูล (Content Delivery Network หรือ 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 สูงกว่า 0.25 คือแย่

ดูปัญหาทั่วไปส่วนหนึ่งที่ส่งผลต่อ CLS ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจได้อธิบายไว้ในส่วนถัดไป

ตรวจสอบว่ารูปภาพโหลดอย่างไรขณะที่คุณเลื่อนหน้าลง

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

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

โปรดระวังโฆษณาที่วางอยู่ตรงกลางเนื้อหา

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

หลีกเลี่ยงการเพิ่มเนื้อหาแบบไดนามิกที่ด้านบนของหน้า

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

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

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

INP จะวัดการโต้ตอบที่ผ่านเกณฑ์ทั้งหมดและทุกครั้งตลอดช่วงชีวิตของหน้าเว็บ และรายงานการโต้ตอบที่แย่ที่สุด INP มีเกณฑ์ที่ดีที่ 200 มิลลิวินาที และเกณฑ์ที่แย่อยู่ที่ 500 มิลลิวินาที INP เป็นการเพิ่มประสิทธิภาพ FID และสามารถวัดการตอบสนองได้ดีขึ้น จึงเป็นเหตุผลที่ FID แทนที่ FID เป็น Core Web Vitals สำหรับการวัดการตอบสนอง

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

ดูปัญหาทั่วไปส่วนหนึ่งที่ส่งผลต่อ INP ซึ่งผู้มีอำนาจตัดสินใจทางธุรกิจได้อธิบายไว้ในส่วนถัดไป

ขอให้สนุกกับฤดูใบไม้ผลิ

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

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

หลีกเลี่ยงวิดเจ็ตและปลั๊กอินราคาแพง

วิดเจ็ตและปลั๊กอินที่มีราคาแพงในการคำนวณอาจดูดี แต่จะช่วยปรับปรุงประสบการณ์ของผู้ใช้หรือแย่ลงใช่ไหม รายงานการวินิจฉัยปัญหาด้านประสิทธิภาพ/Lighthouse ใน PageSpeed Insights จะช่วยระบุ JavaScript ที่กำลังส่งผลกระทบอย่างชัดเจนต่อประสิทธิภาพของเว็บไซต์

ตามหลักการแล้ว ให้จำกัดวิดเจ็ตไว้เฉพาะหน้าเว็บที่ต้องใช้เท่านั้น หากคุณใช้เฉพาะ Google Maps ที่ฝังในหน้า "ติดต่อเรา" ก็ไม่จำเป็นต้องโหลดในทุกหน้าที่อาจทำให้เกิดปัญหาด้านการตอบสนองได้

พิจารณาจำนวนโฆษณา โดยเฉพาะบนอุปกรณ์เคลื่อนที่

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

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

หลีกเลี่ยงขนาดหน้าเว็บมากเกินไป

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

ฉันจะขอความช่วยเหลือเพิ่มเติมได้อย่างไร

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

ข้อมูลเฉพาะแพลตฟอร์ม

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

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

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

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

การมีส่วนร่วมกับนักพัฒนาเว็บ

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

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

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

บทสรุป

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

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

ข้อความแสดงการยอมรับ

ภาพขนาดย่อโดย Carlos Muza ใน Unsplash