เพิ่มประสิทธิภาพ 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) วัดความเสถียรของภาพในหน้าเว็บ ซึ่งก็คือเนื้อหาขยับไปมามากน้อยเพียงใดขณะโหลด
  • Interaction to Next Paint (INP): ความรวดเร็วที่หน้าเว็บตอบสนองต่อการคลิก การแตะ และการโต้ตอบด้วยแป้นพิมพ์

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

ระบบวัด Core Web Vitals อย่างไร

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

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

Google แสดงข้อมูลจากผู้ใช้ Chrome ที่เลือกใช้ในรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ซึ่งจะป้อนข้อมูลลงในเครื่องมือต่างๆ ของ Google เช่น PageSpeed Insights และ Google Search Console

CrUX พร้อมใช้งานในเว็บไซต์ยอดนิยมหลายล้านเว็บไซต์ แต่บางเว็บไซต์อาจไม่มี CrUX เครื่องมือ Real User Monitoring (RUM) อื่นๆ ยังรวบรวมเมตริกเหล่านี้สำหรับเว็บไซต์ของคุณได้ด้วย

ฉันจะดู Core Web Vitals ของเว็บไซต์ได้อย่างไร

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

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

PageSpeed Insights

หากต้องการดูข้อมูลอย่างรวดเร็วโดยไม่ต้องตั้งค่า คุณสามารถใช้ PageSpeed Insights (PSI) พิมพ์ URL แล้วคลิกวิเคราะห์ หากเว็บไซต์ของคุณรวมอยู่ใน CrUX คุณจะเห็นส่วน "ดูว่าผู้ใช้จริงได้รับประสบการณ์อย่างไร" อย่างรวดเร็ว

วิธีที่ PageSpeed Insights แสดงข้อมูล CrUX สำหรับ Core Web Vitals ของ URL ระบบจะแสดง Core Web Vitals แต่ละรายการแยกกัน โดยจัดกลุ่ม Core Web Vitals แต่ละรายการไว้ในเกณฑ์ "ดี" "ต้องปรับปรุง" และ "ไม่ดี" สำหรับช่วง 28 วันที่ผ่านมา
PageSpeed Insights แสดง Core Web Vitals ที่ผู้ใช้จริงได้รับ

ซึ่งแสดงให้เห็นว่าผู้ใช้ 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 ดังนี้

รายงาน Core Web Vitals ใน Search Console รายงานจะแบ่งออกเป็นหมวดหมู่เดสก์ท็อปและอุปกรณ์เคลื่อนที่ โดยมีกราฟเส้นที่แสดงรายละเอียดการกระจายของหน้าเว็บที่มี Core Web Vitals ในหมวดหมู่ "ดี" "ต้องปรับปรุง" และ "ไม่ดี" เมื่อเวลาผ่านไป
รายงาน Core Web Vitals ของ Google Search Console

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

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

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

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

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

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

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

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

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

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

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

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

Screencast ที่แสดงให้เห็นว่าความไม่เสถียรของเลย์เอาต์ส่งผลเสียต่อผู้ใช้อย่างไร

ซึ่งวัดด้วยสูตรทางคณิตศาสตร์ที่คำนวณปริมาณเนื้อหาที่เปลี่ยนตำแหน่งและระยะทางที่เปลี่ยนไป โดยจะแสดงเป็นเศษส่วนที่ไม่มีหน่วย โดยค่า 0.1 หรือน้อยกว่าจะถือว่าดี และค่า 0.25 ขึ้นไปจะถือว่าไม่ดี

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

ตรวจสอบวิธีโหลดรูปภาพขณะเลื่อนหน้าเว็บ

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

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

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

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

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

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

ปัญหาเกี่ยวกับ Interaction to Next Paint (INP)

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

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

INP จะวัดการโต้ตอบที่มีคุณสมบัติตรงตามเกณฑ์ทั้งหมดตลอดอายุการใช้งานของหน้าเว็บ และรายงานการโต้ตอบที่แย่ที่สุด INP มีเกณฑ์ดีอยู่ที่ 200 มิลลิวินาที และเกณฑ์แย่อยู่ที่ 500 มิลลิวินาที

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

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

ทำความสะอาดครั้งใหญ่

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

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

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

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

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

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

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

ความสมดุลระหว่างการสร้างรายได้และประสิทธิภาพ

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

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

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

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

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

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

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

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

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

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

จ้างนักพัฒนาเว็บ

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

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

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

บทสรุป

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

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