ใช้ประโยชน์จากการทดสอบ A/B เพื่อประเมินผลกระทบที่ความเร็วเว็บไซต์มีต่อเมตริกธุรกิจของคุณ
ในช่วง 2-3 ปีที่ผ่านมา เราได้ทราบกันดีว่าประสิทธิภาพความเร็วเว็บไซต์เป็นส่วนสำคัญต่อประสบการณ์ของผู้ใช้และการปรับปรุงประสิทธิภาพด้านเมตริกธุรกิจต่างๆ เช่น อัตรา Conversion และอัตราตีกลับ หลายบทความและกรณีศึกษาต่างๆ ได้รับการเผยแพร่เพื่อสนับสนุนเรื่องนี้แล้ว ซึ่งรวมถึงประสิทธิภาพของเว็บไซต์ส่งผลต่ออัตรา Conversion อย่างไรของ Cloudflare, รายได้หลายล้านวินาทีของ Deloitte และ Shopping for Speed บน eBay.com เป็นต้น
ถึงแม้ข้อมูลเรื่องความเร็วจะชัดเจน แต่บริษัทจำนวนมากก็ยังคงประสบปัญหาในการจัดลำดับความสำคัญในการทำงานที่จะช่วยเพิ่มความเร็วเว็บไซต์ เนื่องจากไม่ทราบแน่ชัดว่าความเร็วนี้มีผลต่อผู้ใช้ของตนอย่างไร และส่งผลต่อธุรกิจของบริษัทอย่างไร
ในกรณีที่ไม่มีข้อมูล การชะลอการทำงานความเร็วของเว็บไซต์และมุ่งความสนใจไปที่งานอื่นๆ เป็นเรื่องง่าย สถานการณ์ที่พบบ่อยคือมีบางคนในบริษัทตระหนักถึงความสำคัญของความเร็วเว็บไซต์ แต่ยังไม่สามารถสร้างประเด็นให้กับผู้มีส่วนเกี่ยวข้องรายนี้และโน้มน้าวให้ผู้มีส่วนเกี่ยวข้องหลายรายลงทุนได้อย่างเหมาะสม
บทความนี้จะให้คำแนะนำระดับสูงเกี่ยวกับวิธีใช้ประโยชน์จากการทดสอบ A/B เพื่อประเมินผลกระทบที่ความเร็วเว็บไซต์มีต่อเมตริกธุรกิจ ซึ่งจะช่วยเพิ่มประสิทธิภาพในการตัดสินใจในเรื่องนี้
ขั้นตอนที่ 1: เลือกหน้าที่จะทดสอบ A/B
เป้าหมายของคุณคือการทดสอบสมมติฐานที่ว่าความเร็วหน้าเว็บเกี่ยวข้องกับเมตริกธุรกิจของคุณ เพื่อให้เข้าใจง่ายๆ คุณสามารถเริ่มต้นจำกัดตัวเองให้ระบุหน้าเว็บเดียวสำหรับการวิเคราะห์ งานในอนาคตอาจขยายไปยังหน้าเว็บประเภทเดียวกันหลายๆ หน้าเพื่อยืนยันข้อมูลที่พบ แล้วเพิ่มไปยังส่วนอื่นๆ ของเว็บไซต์ คำแนะนำบางประการสำหรับจุดเริ่มต้นแสดงอยู่ที่ด้านล่างของขั้นตอนนี้ กระบวนการเลือกหน้าเว็บมี ข้อกำหนดหลายประการดังนี้
- การทดสอบ A/B ควรทำงานในอุปกรณ์ของผู้ใช้อุปกรณ์เคลื่อนที่เท่านั้น เว็บไซต์พาร์ทเนอร์ที่เราให้ความช่วยเหลือทั่วโลกได้รับการเข้าชมมากกว่า 50% (และเพิ่มขึ้นอย่างต่อเนื่อง!) ที่มาจากอุปกรณ์เคลื่อนที่โดยเฉลี่ย แต่ก็อาจเพิ่มขึ้นได้มากตามภูมิภาคและประเภทธุรกิจ อุปกรณ์เคลื่อนที่ไวต่อเว็บไซต์ที่ช้ามากกว่า เนื่องจากข้อจำกัดด้านหน่วยความจำและเครือข่ายที่เสถียรน้อยกว่า นอกจากนี้ รูปแบบการใช้งานระหว่างเดินทาง ทำให้มีความเร็วสูงขึ้น
หน้าเว็บที่คุณเลือกมาทดสอบควรเป็นส่วนสำคัญของ Conversion Funnel ทุกเว็บไซต์มีจุดประสงค์แตกต่างกัน ดังนั้นทุกเว็บไซต์จึงติดตามเมตริกความสำเร็จที่ต่างกัน เมตริกเหล่านี้มักเกี่ยวข้องกับเส้นทางของผู้ใช้ซึ่งวิเคราะห์โดยใช้ Funnel ตัวอย่างเช่น ผู้ใช้ในเว็บไซต์อีคอมเมิร์ซจะต้องไปที่หน้าแรก หน้าหมวดหมู่ หน้าผลิตภัณฑ์ และหน้าชำระเงินเพื่อทำการซื้อให้เสร็จสมบูรณ์ หากคุณกำลังเพิ่มประสิทธิภาพสำหรับ Conversion หน้าใดหน้าหนึ่งก็เป็นตัวเลือกที่ดี
หน้าเว็บควรมีวัตถุประสงค์เดียว คุณควรหลีกเลี่ยงการใช้หน้าแรกในการทดสอบ เว้นแต่เว็บไซต์ของคุณจะมีพันธกิจที่เฉพาะเจาะจงมาก หน้าแรกของเว็บไซต์เชิงพาณิชย์หลายๆ แห่งเป็นพอร์ทัลของฟังก์ชันการทำงานที่หลากหลายที่จะทำให้การวิเคราะห์มีเสียงดังรบกวน ตัวอย่างเช่น หากคุณกำลังเพิ่มประสิทธิภาพสำหรับจำนวนการดูหน้าเว็บต่อเซสชันในเว็บไซต์ข่าว คุณควรยกเว้นส่วนที่ไม่ใช่เชิงพาณิชย์และเน้นส่วนและบทความที่สร้างรายได้
หน้าเว็บที่เลือกควรมีการเข้าชมเพียงพอเพื่อที่คุณจะได้ไม่ต้องรอเป็นเวลานานจนกว่าจะได้ผลลัพธ์ที่มีนัยสำคัญทางสถิติ
หน้าเว็บที่เลือกควรค่อนข้างช้า อันที่จริงแล้ว ยิ่งช้ายิ่งดี ซึ่งไม่เพียงแต่จะทำให้คุณปรับปรุงหน้าเว็บได้ง่ายขึ้นเท่านั้น แต่ยังทำให้ข้อมูลชัดเจนขึ้นด้วย คุณสามารถสแกนอย่างรวดเร็วผ่านรายงานความเร็วของ Google Analytics หรือรายงาน Core Web Vitals ของ Search Console เพื่อดูว่าหน้าเว็บใดที่ช้าที่สุด
หน้าเว็บควรมีความเสถียรพอสมควร อย่าอัปเดตหน้าเว็บ (สิ่งที่จะส่งผลต่อเมตริกธุรกิจ) จนกว่าการทดสอบจะเสร็จสมบูรณ์ ยิ่งมีปัจจัยภายนอกที่ต้องพิจารณาน้อย การวิเคราะห์ก็จะยิ่งชัดเจนขึ้น
เมื่อใช้ข้อมูลด้านบนเป็นแนวทาง ควรมีความชัดเจนมากขึ้นว่าหน้าใดเป็นตัวเลือกที่ดีสำหรับการทดสอบ นอกจากนี้ หน้า Landing Page ของโฆษณายังเป็นทางเลือกที่ดี เนื่องจากคุณมีแนวโน้มที่จะมีเมตริกธุรกิจ การทดสอบ A/B และการวิเคราะห์อยู่แล้วในตัว เผื่อว่าคุณยังไม่มั่นใจ ลองดูแนวคิดต่อไปนี้สำหรับแต่ละประเภทธุรกิจ
- เว็บไซต์เนื้อหา: ส่วน บทความ
- หน้าร้าน: หน้าหมวดหมู่ หน้าผลิตภัณฑ์
- โปรแกรมเล่นสื่อ: หน้าค้นหาวิดีโอ/การค้นพบ หน้าเล่นวิดีโอ
- บริการและ Discovery (การเดินทาง รถเช่า การจดทะเบียนบริการ ฯลฯ): หน้าป้อนข้อมูลแบบฟอร์มเริ่มต้น
ขั้นตอนที่ 2: วัดประสิทธิภาพ
วิธีทั่วไปในการวัดเมตริกมี 2 วิธี ได้แก่ ในห้องทดลองและในภาคสนาม โดยส่วนตัว เราพบว่าการวัดเมตริกในภาคสนาม (หรือที่เรียกว่าการตรวจสอบโดยผู้ใช้จริง (RUM)) ให้ประโยชน์มากกว่า เนื่องจากสามารถสะท้อนประสบการณ์ของผู้ใช้จริงได้ ตัวอย่างไลบรารีและบริการที่ช่วยให้คุณรายงานข้อมูล RUM ได้ ได้แก่ น้ำหอม การตรวจสอบประสิทธิภาพ Firebase และเหตุการณ์ Google Analytics
มีเมตริกจำนวนมากให้เลือกเนื่องจากมีเป้าหมายเพื่อบันทึกประสบการณ์ของผู้ใช้ในแง่มุมที่แตกต่างกัน อย่าลืมว่าเป้าหมายคือการพิจารณาความสัมพันธ์โดยตรงระหว่างความเร็วกับเมตริกทางธุรกิจ ดังนั้นการติดตามเมตริกความเร็ว 2-3 รายการอาจมีประโยชน์ในการพิจารณาว่ารายการใดมีความสัมพันธ์มากที่สุดกับความสำเร็จของธุรกิจ โดยทั่วไปแล้ว เราขอแนะนำให้เริ่มต้นด้วย Core Web Vitals ไลบรารี web-vitals.js ช่วยคุณวัดผล Core Web Vitals บางส่วนในพื้นที่ได้ แต่โปรดทราบว่าการรองรับเบราว์เซอร์ไม่ใช่ 100% นอกจาก Core Web Vitals แล้ว Other Web Vitals ก็น่าลองไปดูด้วย คุณยังกำหนดเมตริกที่กำหนดเอง เช่น "เวลาที่ใช้ในการคลิกโฆษณาครั้งแรก" ได้อีกด้วย
ขั้นตอนที่ 3: สร้างตัวแปรด้านประสิทธิภาพความเร็ว
ในขั้นตอนนี้ คุณจะใช้การเปลี่ยนแปลงเพื่อสร้างหน้าเว็บเวอร์ชันที่เร็วขึ้นเพื่อทดสอบกับเวอร์ชันปัจจุบัน
โปรดคำนึงถึง 2 สิ่งต่อไปนี้
- หลีกเลี่ยงการเปลี่ยนแปลง UI หรือ UX นอกจากหน้าเว็บหนึ่งจะเร็วกว่าหน้าอื่น ผู้ใช้จะต้องมองไม่เห็นการเปลี่ยนแปลงด้วย
- การวัดผลยังเป็นส่วนสำคัญของขั้นตอนนี้ด้วย ระหว่างการพัฒนา คุณควรใช้เครื่องมือทดสอบในห้องทดลอง เช่น Lighthouse เพื่อระบุผลกระทบที่การเปลี่ยนแปลงมีต่อประสิทธิภาพ โปรดทราบว่าการเปลี่ยนแปลงเมตริกหนึ่งมักจะส่งผลกับอีกเมตริกหนึ่งด้วย เมื่อเผยแพร่หน้าเว็บแล้ว ให้ใช้ RUM เพื่อให้ได้การประเมินที่แม่นยำยิ่งขึ้น
การสร้างตัวแปรด้านประสิทธิภาพทำได้หลายวิธี วัตถุประสงค์ของการทดสอบคือ คุณควรดำเนินการให้ง่ายที่สุด ด้านล่างนี้คือ ตัวเลือก 2-3 รายการ
สร้างหน้าเว็บได้เร็วขึ้น
- ใช้เครื่องมืออย่าง Squoosh เพื่อเพิ่มประสิทธิภาพรูปภาพในหน้าทดสอบด้วยตนเอง
- ใช้การครอบคลุมโค้ดสำหรับเครื่องมือสำหรับนักพัฒนาเว็บเพื่อกำจัด JavaScript หรือ CSS ที่ไม่ได้ใช้เฉพาะสำหรับหน้านั้นด้วยตนเอง
- โหลดสคริปต์ของบุคคลที่สามอย่างมีประสิทธิภาพ
- ใช้เครื่องมือ เช่น Critical เพื่อแยก CSS ที่สำคัญ และแทรกในบรรทัด
- นำโค้ด JavaScript ที่ไม่สำคัญซึ่งไม่ส่งผลต่อประสบการณ์การใช้งานของผู้ใช้ออก และโค้ดที่คุณสามารถทำได้โดยไม่ต้องทดสอบ (ตัวอย่างเช่น ไลบรารีของบุคคลที่สามบางรายการ)
- ใช้การโหลดแบบ Lazy Loading ระดับเบราว์เซอร์ ซึ่งบางเบราว์เซอร์ไม่รองรับ แต่ก็อาจเพิ่มประสิทธิภาพได้อย่างมากในกรณีที่รองรับ
- นำแท็ก Analytics ที่ไม่สำคัญออก หรือโหลดแท็กแบบอะซิงโครนัส
ดูการเพิ่มประสิทธิภาพอื่นๆ ที่ควรพิจารณาได้ที่เวลาในการโหลดที่รวดเร็วและรายการตรวจสอบประสิทธิภาพของฟรอนท์เอนด์ คุณยังใช้ PageSpeed Insights เพื่อเรียกใช้ Lighthouse เพื่อระบุโอกาสในการปรับปรุงประสิทธิภาพได้
ลดความเร็วหน้าเว็บ
วิธีนี้อาจเป็นวิธีที่ง่ายที่สุดในการสร้างตัวแปรต่างๆ และสามารถทำได้โดยการเพิ่มสคริปต์ง่ายๆ ทำให้เวลาในการตอบกลับของเซิร์ฟเวอร์ช้าลง การโหลดรูปภาพขนาดใหญ่ ฯลฯ Financial Times เลือกตัวเลือกนี้เมื่อทดสอบว่าประสิทธิภาพส่งผลต่อเมตริกธุรกิจอย่างไร ดู FT.com ที่เร็วขึ้น
เพิ่มความเร็วในการโหลดหน้าเว็บ
สำหรับกรณีที่หน้าทดสอบ (สมมติว่าเป็นหน้ารายละเอียดผลิตภัณฑ์) นั้นส่วนใหญ่ลิงก์มาจากหน้าอื่น (สมมติว่าเป็นหน้าแรก) การดึงข้อมูลล่วงหน้า หรือการแสดงผลล่วงหน้า หน้าผลิตภัณฑ์โดยตรงจากหน้าแรกของกลุ่มทดสอบจะเร่งการโหลดหน้าในครั้งต่อๆ ไป โปรดทราบว่าในกรณีนี้ การแยกการทดสอบ A/B (ขั้นตอนที่ 4) จะเกิดขึ้นในหน้าแรก นอกจากนี้ ทั้งหมดนี้อาจทําให้หน้าแรกช้าลง ดังนั้นให้วัดผลและนํามาพิจารณาเมื่อวิเคราะห์ผลการทดสอบ (ขั้นตอนที่ 5)
ขั้นตอนที่ 4: สร้างการทดสอบ A/B
เมื่อคุณมีหน้าเว็บเดียวกัน 2 เวอร์ชัน โดยที่เวอร์ชันหนึ่งเร็วกว่าอีกเวอร์ชันหนึ่ง ขั้นตอนถัดไปคือการแยกการเข้าชมเพื่อวัดผลกระทบ โดยทั่วไปจะมีเทคนิคและเครื่องมือมากมายที่ใช้ในการทำการทดสอบ A/B แต่โปรดทราบว่าไม่ใช่ทุกวิธีที่เหมาะสมในการวัดผลลัพธ์ด้านประสิทธิภาพความเร็ว
หากคุณใช้เครื่องมือทดสอบ A/B อย่างเพิ่มประสิทธิภาพหรือเพิ่มประสิทธิภาพ เราขอแนะนำอย่างยิ่งให้ตั้งค่าการทดสอบฝั่งเซิร์ฟเวอร์แทนการทดสอบฝั่งไคลเอ็นต์ เนื่องจากการทดสอบ A/B ฝั่งไคลเอ็นต์มักทำงานโดยการซ่อนเนื้อหาของหน้าไว้จนกว่าการทดสอบจะโหลดเสร็จ ซึ่งหมายความว่าการทดสอบ A/B เองอาจบิดเบือนเมตริกที่คุณต้องการวัดได้ หากคุณทำได้เพียงทดสอบฝั่งไคลเอ็นต์ ให้ลองตั้งค่าการทดสอบในหน้าอื่น และเปลี่ยนลิงก์ไปยังหน้าทดสอบเพื่อแยกการเข้าชม วิธีนี้จะช่วยให้การทดสอบฝั่งไคลเอ็นต์ไม่ลากหน้าทดสอบลง
ตัวอย่างการเปลี่ยนแปลงประสิทธิภาพของการทดสอบ AB ในหน้ารายละเอียดผลิตภัณฑ์ (PDP) หนึ่งๆ ผ่านการทดสอบฝั่งเซิร์ฟเวอร์
คำขอจะไปยังแบ็กเอนด์ ซึ่งกระจายผู้ใช้ไปยังหน้า 2 เวอร์ชันที่แตกต่างกัน แม้ว่าโดยทั่วไปจะเป็นการตั้งค่าที่ดี แต่ก็มักต้องใช้ทรัพยากรด้านไอทีในการตั้งค่าการแยกฝั่งเซิร์ฟเวอร์
ต่อไปนี้คือตัวอย่างการตั้งค่าการทดสอบฝั่งไคลเอ็นต์ โดยใช้หน้าก่อนหน้านี้ (หน้าแรกในแผนภาพด้านล่าง) เพื่อเรียกใช้ JavaScript การทดสอบ
JavaScript การทดสอบจะปรับเปลี่ยนลิงก์ขาออกเพื่อให้กลุ่มผู้ใช้ทดสอบ 2 กลุ่มลิงก์ไปยัง PDP ทั้ง 2 เวอร์ชันที่เป็นปัญหา วิธีนี้ง่ายต่อการตั้งค่าและบำรุงรักษาผ่านเครื่องมือทดสอบ A/B ทั่วไป เช่น Optimizely หรือ Optimize และไม่ส่งผลต่อการทดสอบประสิทธิภาพเนื่องจาก JavaScript การทดสอบทำงานในหน้าอื่น
หรือจะเลือกหน้าเว็บ 2 หน้าที่มีลักษณะการทำงานและมีประสิทธิภาพคล้ายกันมาก (เช่น สำหรับผลิตภัณฑ์ 2 รายการที่คล้ายกันมาก) ใช้การเปลี่ยนแปลงของคุณกับรายการใดรายการหนึ่ง แล้วเปรียบเทียบความแตกต่างของเมตริกเมื่อเวลาผ่านไป ซึ่งหมายความว่าคุณไม่ได้ทำการทดสอบ A/B ที่เหมาะสม แต่ก็ยังถือว่าเป็นข้อมูลเชิงลึกอยู่มาก
ในกรณีที่มีการใช้หน้าทดสอบเป็นหน้า Landing Page สำหรับแคมเปญโฆษณา คุณสามารถใช้เครื่องมือทดสอบ A/B ในตัวของเครือข่ายโฆษณา เช่น การทดสอบแยกโฆษณา Facebook หรือฉบับร่างและการทดสอบ Google Ads หากทำไม่ได้ คุณก็ใช้ 2 แคมเปญที่มีการตั้งค่าเหมือนกัน แล้วกำหนดหน้า Landing Page ที่ต่างกันเป็นเป้าหมายได้
ขั้นตอนที่ 5: วิเคราะห์การทดสอบ A/B
หลังจากที่คุณทำการทดสอบเป็นเวลานานเพียงพอและมีข้อมูลเพียงพอที่จะรู้สึกมั่นใจในผลลัพธ์ ก็ได้เวลารวมทุกอย่างเข้าด้วยกันและทำการวิเคราะห์ วิธีการจะขึ้นอยู่กับวิธีที่คุณทดสอบนั้น ดังนั้นเราจะพูดถึงตัวเลือกต่างๆ
หากการทดสอบของคุณเรียกใช้บนหน้า Landing Page ของโฆษณาโดยใช้เครื่องมือที่กล่าวถึงข้างต้น การวิเคราะห์ควรจะตรงไปตรงมาพอๆ กับการอ่านผลลัพธ์ หากคุณกำลังใช้แบบร่างและการทดสอบของ Google ให้ดูการเปรียบเทียบโดยใช้ ScoreCard
แพลตฟอร์มอย่าง Optimizely หรือ Optimize ยังมีวิธีง่ายๆ ในการตีความผลลัพธ์และพิจารณาว่าความเร็วของผลลัพธ์มีมากน้อยเพียงใดในหน้าเว็บ
ถ้าคุณใช้ Google Analytics หรือเครื่องมือที่คล้ายกัน คุณจะต้องดึงรายงานมารวมเข้าด้วยกัน โชคดีที่ Google Analytics ทำให้การสร้างรายงานที่กำหนดเองเป็นเรื่องง่าย ซึ่งเป็นจุดที่ควรเริ่มต้น หากคุณส่งข้อมูลความเร็วไปยัง Google Analytics โดยใช้มิติข้อมูลที่กำหนดเองแล้ว ให้ดูคู่มือการรายงานเพื่อเรียนรู้วิธีตั้งค่าและรวมมิติข้อมูลเหล่านั้นไว้ในรายงานที่กำหนดเอง ตรวจสอบว่ารายงานของคุณครอบคลุมวันที่ของการทดสอบ และมีการกำหนดค่าให้แสดงทั้ง 2 ตัวแปร รายงานนี้ควรมีข้อมูลอะไรบ้าง
- หลักๆ แล้ว คุณต้องใส่เมตริกธุรกิจที่คุณสนใจมากที่สุด เช่น Conversion, การดูหน้าเว็บ, โฆษณาดู, อัตรา Conversion, เมตริกอีคอมเมิร์ซ, อัตราการคลิกผ่าน ฯลฯ
- นอกจากนี้ เมตริกหน้าเว็บมาตรฐานอื่นๆ ที่มีประโยชน์ในการปรับปรุงความเร็วของเว็บไซต์ก็คืออัตราตีกลับ ระยะเวลาเซสชันเฉลี่ย และเปอร์เซ็นต์การออก
นอกจากนี้ คุณอาจต้องกรองอุปกรณ์เคลื่อนที่และตรวจสอบว่าได้ยกเว้นบ็อตและการเข้าชมอื่นๆ ที่ไม่ใช่ของผู้ใช้แล้ว การวิเคราะห์ขั้นสูงขึ้นยังจะกรองตามภูมิภาค เครือข่าย อุปกรณ์ แหล่งที่มาของการเข้าชม รวมถึงโปรไฟล์และประเภทผู้ใช้ เช่น ผู้ใช้ใหม่เทียบกับผู้เข้าชมที่กลับมา ผู้ใช้แต่ละกลุ่มอาจมีความละเอียดอ่อนต่อความเร็วที่ลดลงหรือน้อยลง และการระบุว่าสิ่งเหล่านี้ก็มีประโยชน์มากทีเดียว
Looker Studio (เดิมคือ Data Studio) หรือเครื่องมือแสดงข้อมูลเป็นภาพแบบอื่นๆ ช่วยให้ผสานรวมแหล่งข้อมูลต่างๆ เช่น Google Analytics ได้อย่างง่ายดาย วิธีนี้จะช่วยให้วิเคราะห์ข้อมูลได้ง่าย และยังสร้างหน้าแดชบอร์ดที่แชร์กับผู้มีส่วนเกี่ยวข้องหลายๆ ฝ่ายที่เกี่ยวข้องในการจัดทำเว็บไซต์ที่ทันสมัยเพื่อให้มีการยอมรับเพิ่มเติมอีกด้วย ตัวอย่างเช่น The Guardian สร้างระบบการแจ้งเตือนอัตโนมัติที่จะเตือนทีมบรรณาธิการเมื่อเนื้อหาที่เพิ่งเผยแพร่เมื่อเร็วๆ นี้มีขนาดหน้าเว็บหรือความเร็วเกินขีดจำกัด และมีแนวโน้มว่าจะทำให้ผู้ใช้ไม่พอใจ
ขั้นตอนที่ 6: เขียนข้อสรุปและตัดสินใจในขั้นตอนถัดไป
เมื่อคุณมีข้อมูลที่เชื่อมโยงประสิทธิภาพกับเมตริกธุรกิจแล้ว คุณจะสามารถตรวจสอบผลลัพธ์และเริ่มหาข้อสรุปได้
หากคุณมองเห็นความสัมพันธ์ระหว่างการปรับปรุงประสิทธิภาพและการปรับปรุงเมตริกธุรกิจได้อย่างชัดเจน ให้สรุปผลลัพธ์และรายงานทั่วทั้งบริษัท ตอนนี้เมื่อพูดถึงประสิทธิภาพด้านความเร็วเป็น "ภาษาทางธุรกิจ" คุณก็มีแนวโน้มที่จะดึงดูดความสนใจของผู้มีส่วนเกี่ยวข้องที่แตกต่างกันและทำให้ประสิทธิภาพความเร็วเว็บไซต์เป็นไปในสายตาของทุกคนมากขึ้น ขั้นตอนต่อไปคือการกำหนดงบประมาณด้านประสิทธิภาพตามผลลัพธ์ และวางแผนงานเพื่อให้ใช้งบประมาณตรงตามงบประมาณเหล่านั้น เมื่อคุณทราบว่าผลงานดังกล่าวจะมีประโยชน์อย่างไร คุณก็จะจัดลำดับความสำคัญได้ตามความเหมาะสม
หากระบุความสัมพันธ์ไม่ได้ ให้ดูคําเตือนด้านล่างและประเมินว่าควรทำการทดสอบที่คล้ายกันที่อื่นในเว็บไซต์หรือไม่ (เช่น ผ่าน Funnel การซื้อทั้งหมดหรือหน้าประเภทอื่น)
คำเตือน
อาจมีสาเหตุหลายประการที่ทำให้คุณไม่พบความสัมพันธ์ที่สำคัญระหว่างเมตริกความเร็วเว็บไซต์กับเมตริกธุรกิจดังนี้
- หน้าเว็บที่เลือกมีอิทธิพลไม่เพียงพอต่อเมตริกธุรกิจที่คุณกำลังตรวจสอบ เช่น หน้าผลิตภัณฑ์ที่เร็วขึ้นอาจไม่ส่งผลกระทบอย่างมากต่ออัตรา Conversion หากหน้าชำระเงินใช้งานช้ามากหรือใช้งานไม่ได้ ลองดูเมตริกที่เกี่ยวข้องมากขึ้น เช่น อัตราตีกลับ อัตราการเพิ่มลงในตะกร้า หรือเมตริกอื่นๆ ที่มีความเชื่อมโยงกับหน้าเว็บที่คุณกำลังทดสอบโดยตรงมากกว่า
- ความแตกต่างของความเร็วระหว่าง 2 เวอร์ชันนี้ไม่มากพอ ระบบจะประเมินข้อมูลนี้ตามเมตริก RUM ที่คุณกำลังวัด
- กลไกการทดสอบ A/B มีข้อผิดพลาด การเข้าชมอาจไม่ได้รับการกระจายอย่างถูกต้อง หรือรายงานการวิเคราะห์ไม่ถูกต้อง หากไม่ต้องการให้เป็นเช่นนั้น ให้พิจารณาทำการทดสอบ A/A โดยทดสอบหน้าเว็บเวอร์ชันเดียวกันโดยใช้กลไกการทดสอบเดียวกันและตรวจสอบว่าผลลัพธ์ไม่ต่างกัน
- จริงๆ แล้วความเร็วเว็บไซต์ไม่มีผลต่อเมตริกธุรกิจของคุณ กรณีเช่นนี้เกิดขึ้นได้ยาก แต่ก็สามารถเกิดขึ้นได้ในกรณีที่ตลาดเป้าหมายมีความไวต่อความเร็วน้อย (เช่น เว็บไซต์ส่วนใหญ่เข้าถึงจากอุปกรณ์ที่มีประสิทธิภาพในเครือข่ายที่มีสัญญาณแรง) หรือความต้องการของผู้ใช้สูงมากและมีทางเลือกจำกัด (เช่น บริการจำหน่ายตั๋วที่จำหน่ายตั๋วสำหรับการแสดงที่มีความต้องการสูงเท่านั้น) โปรดทราบว่านี่ไม่ได้หมายความว่าเว็บไซต์ที่เร็วกว่าไม่ได้ปรับปรุงประสบการณ์ของผู้ใช้และส่งผลต่อชื่อเสียงของแบรนด์
บทสรุป
แม้ว่าการเพิ่มประสิทธิภาพความเร็วทั่วทั้งเว็บไซต์จะเป็นสิ่งที่น่าสนใจ แต่ในระยะยาวแล้วเราควรทำความเข้าใจว่าการมีเว็บไซต์ที่เร็วขึ้นนั้นสำคัญต่อผู้ใช้และบริษัทอย่างไร ซึ่งจะเป็นประโยชน์มากกว่าในระยะยาว ผลที่ได้คือ "เราปรับปรุง FCP ได้ 1.5 วินาที" กับ "เราปรับปรุง FCP ได้ 1.5 วินาที และมีอัตรา Conversion สูงขึ้น 5%" ซึ่งจะช่วยให้คุณสามารถจัดลำดับความสำคัญของงานได้มากขึ้น ได้รับความเห็นชอบจากผู้มีส่วนเกี่ยวข้องต่างๆ และทำให้ประสิทธิภาพความเร็วของเว็บไซต์เป็นความพยายามในระดับบริษัท