เว็บไซต์ที่ช้าแทบไม่เคยล้มเหลวแบบเสียงดัง ไม่มีใครส่งอีเมลมาบอกว่าหน้าโหลดนานเกินไป เขาแค่กดย้อนกลับ แล้วเลือกเจ้าอื่น และ analytics ของคุณอาจไม่ได้บันทึกการเข้าชมนั้นด้วยซ้ำ นี่คือเหตุผลที่ความเชื่อมโยงระหว่างความเร็วของหน้าเว็บกับคอนเวอร์ชัน เป็นเรื่องที่เชื่อได้ง่าย แต่ใส่ตัวเลขได้ยาก
คู่มือนี้ครอบคลุมทั้งสองด้าน คือความช้าทำให้เสียลีดและยอดขายอย่างไร และวิธีวัดว่ามันทำให้เว็บไซต์ของคุณเสียไปเท่าไร ก่อนจะตั้งงบสำหรับงานปรับปรุงความเร็ว
คำตอบสั้นๆ
ความเร็วของหน้าเว็บส่งผลต่อคอนเวอร์ชัน ผ่านกลไกที่จับต้องได้ไม่กี่อย่าง ไม่ใช่สูตรสากล
- หน้าจอแรกที่ช้าทำให้เสียผู้เข้าชมก่อนเขาจะได้อ่านสักคำ และมักเกิดก่อนที่ analytics จะบันทึกเขาได้
- ค่าคลิกโฆษณาเท่าเดิม ไม่ว่าหน้าจะโหลดขึ้นหรือไม่ แลนดิ้งเพจที่ช้าจึงเผางบโฆษณาโดยตรง
- ปุ่มที่ตอบสนองช้า (INP แย่) และเลย์เอาต์ที่กระโดด (CLS แย่) ทำให้คนส่งการติดต่อสอบถามหรือชำระเงินจนจบได้ยากขึ้น
- ขนาดของผลกระทบต่างกันไปในแต่ละเว็บไซต์ ถ้าอยากรู้ว่าความช้าทำให้คุณเสียเท่าไร ให้แบ่งคอนเวอร์ชันตามอุปกรณ์และหน้า เทียบกับข้อมูลความเร็วจากผู้ใช้จริงของ Chrome และวัดผลก่อนและหลังการแก้ไขแต่ละครั้ง
สี่ทางที่ความเร็วส่งผลต่อคอนเวอร์ชัน
1. ผู้เข้าชมออกไปก่อนหน้าจะขึ้น
มีคนแตะผลการค้นหาใน Google หรือโฆษณาบนโซเชียลของคุณ แล้วเห็นหน้าจอขาว บน Wi-Fi ของออฟฟิศมันกินเวลาแค่ครู่เดียว แต่บนมือถือระดับกลางที่ใช้เน็ตมือถือ อาจนานหลายวินาที และทุกวินาทีคือคำเชิญให้ลองผลการค้นหาถัดไป
ทำไมจึงมองเห็นยาก analytics จะบันทึกการเข้าชม ก็ต่อเมื่อแท็กของมันโหลดและทำงานแล้ว คนที่ยอมแพ้ก่อนหน้านั้นจะไม่กลายเป็นเซสชันเลย ความสูญเสียจากความเร็วที่หนักที่สุด จึงมองไม่เห็นในรายงานที่คุณจะเปิดดูตามปกติ
ตัวชี้วัดที่ต้องจับตาคือ Largest Contentful Paint หรือ LCP (เวลาที่เนื้อหาชิ้นใหญ่ที่สุดแสดงผล) ซึ่ง Google ให้คะแนนว่าดีเมื่อไม่เกิน 2.5 วินาที ในการเข้าชมจริงอย่างน้อย 75% บทความ อธิบาย Core Web Vitals อธิบายแต่ละตัวชี้วัดและสาเหตุที่พบบ่อย
2. คลิกโฆษณาสูญเปล่ากับหน้าที่ช้า
ในการโฆษณาแบบจ่ายต่อคลิก คุณจ่ายเมื่อมีคนคลิก ไม่ใช่เมื่อหน้าของคุณโหลดเสร็จ ทุกคนที่ยอมแพ้ต่อหน้าจอว่าง คือการเข้าชมที่คุณซื้อมาแต่ไม่เคยได้รับ
Google Ads ยังนับประสบการณ์บนแลนดิ้งเพจ (หน้านั้นเกี่ยวข้องและมีประโยชน์กับคนที่คลิกแค่ไหน) เป็นหนึ่งในสามองค์ประกอบของ Quality Score ศูนย์ช่วยเหลือสำหรับผู้ลงโฆษณาของ Google แนะนำให้ใช้หน้ามือถือที่โหลดเร็ว แต่ไม่ได้เปิดเผยว่าความเร็วมีน้ำหนักในคะแนนนั้นแค่ไหน จึงควรมองว่า Quality Score ที่ดีขึ้นเป็นโบนัส ส่วนคลิกที่สูญเปล่านั้นคือต้นทุนที่แน่นอน
3. ปุ่มและฟอร์มที่ตอบสนองช้า
หน้าเว็บอาจดูพร้อมแล้ว แต่ยังไม่ตอบสนอง ผู้เข้าชมแตะ “ส่งคำถาม” แล้วไม่มีอะไรเกิดขึ้น เพราะเบราว์เซอร์กำลังยุ่งกับการรันสคริปต์ บางคนแตะซ้ำแล้วส่งซ้ำสองครั้ง บางคนคิดว่าฟอร์มเสียแล้วออกไป ในร้านค้าออนไลน์ ความล่าช้าแบบเดียวกันเกิดกับตัวกรองและปุ่ม “หยิบใส่ตะกร้า”
INP (เวลาตอบสนองต่อการกดหรือแตะ) วัดเรื่องนี้ และ Google ให้คะแนนว่าดีเมื่อไม่เกิน 200 มิลลิวินาที วิดเจ็ตแชต แท็กติดตามผลจำนวนมาก และตัวสร้างหน้าเว็บ (page builder) ที่หนัก เป็นตัวการที่พบบ่อย ฟอร์มอยู่ตรงจุดที่เกิดคอนเวอร์ชันพอดี การออกแบบฟอร์มบนเว็บ จึงควรค่าแก่การดูด้วย
4. เลย์เอาต์ที่ขยับจนแตะผิด
แบนเนอร์หรือภาพที่โหลดช้าดันข้อความลงไป ผู้เข้าชมเอื้อมไปแตะ “โทรหาเรา” แต่กลับโดนลิงก์อื่น ในจังหวะที่เขาพร้อมจะลงมือพอดี
Cumulative Layout Shift หรือ CLS วัดเรื่องนี้ โดยค่า 0.1 หรือต่ำกว่าถือว่าดี และมักเป็นเรื่องที่แก้ได้ถูกที่สุดในสามข้อ คือจองพื้นที่ไว้ให้ภาพ สิ่งที่ฝังในหน้า (embed) และแบนเนอร์ ก่อนที่มันจะโหลด
งานวิจัยบอกอะไร และควรอ่านอย่างไร
หลักฐานสาธารณะที่มีประโยชน์ที่สุด มาจากการทดลองที่มีการควบคุม ใน กรณีศึกษาของ Vodafone บน web.dev (2021) Vodafone Italy แบ่งทราฟฟิกระหว่างแลนดิ้งเพจสองเวอร์ชัน เวอร์ชันที่มี LCP ดีกว่า 31% ในข้อมูลภาคสนาม (จากผู้ใช้จริง) สร้างยอดขายมากขึ้น 8% และอัตราลีดต่อการเข้าชมเพิ่มขึ้น 15% บทสรุปของ web.dev เรื่อง ผลกระทบทางธุรกิจของ Core Web Vitals รวบรวมผลลัพธ์จากเว็บไซต์ขนาดใหญ่อื่นๆ ไว้
งานวิจัยเชิงสังเกตก็ชี้ไปทางเดียวกัน Milliseconds Make Millions การศึกษาในปี 2020 ที่ Google ว่าจ้าง และดำเนินการโดย Deloitte และ fifty-five ติดตามเว็บไซต์ของ 37 แบรนด์ในกลุ่มค้าปลีก ท่องเที่ยว สินค้าหรูหรา และการสร้างลีด และพบว่าความเร็วบนมือถือที่ดีขึ้น 0.1 วินาที สัมพันธ์กับการที่ผู้เข้าชมเดินผ่านแต่ละขั้นของ funnel มากขึ้น
ก่อนนำไปใช้กับธุรกิจของคุณ ให้ถามว่า
- ใครเป็นคนทำ? หลักฐานส่วนใหญ่มาจาก Google หรือบริษัทที่ทำงานร่วมกับ Google ไม่ได้ผิด แต่ก็ไม่เป็นกลาง
- เป็นการทดลอง หรือแค่ความสัมพันธ์? A/B test แยกผลของความเร็วออกมาได้ แต่การศึกษาที่แค่สังเกต ตัดความเป็นไปได้ไม่ได้ว่า เว็บไซต์ที่เร็วกว่า หรือช่วงเวลาที่เร็วกว่า อาจต่างกันในด้านอื่นด้วย
- เป็นเว็บไซต์แบบไหน? แบรนด์โทรคมนาคมที่มีทราฟฟิกมหาศาล มีพฤติกรรมต่างจากผู้ผลิตที่ผู้ซื้อใช้เวลาหลายเดือนในการตัดสินใจ
- เริ่มจากจุดไหน? การขยับจากช้ามากมาเป็นพอรับได้ มักคุ้มกว่าการขยับจากเร็วเป็นเร็วขึ้นอีกนิดอยู่มาก
ผลการศึกษาที่เผยแพร่แสดงว่าผลกระทบมีอยู่จริง แต่ไม่ได้บอกขนาดของมันบนเว็บไซต์ของคุณ
วิธีวัดว่าความช้าทำให้คุณเสียเท่าไร
ส่วนนี้คือที่ที่คุณสร้างเหตุผลทางธุรกิจ (business case) ได้ด้วยเครื่องมือฟรี ได้แก่ Google Analytics 4, Search Console และ PageSpeed Insights
ขั้นที่ 1: ตรวจว่าข้อมูลคอนเวอร์ชันเชื่อถือได้
ตรวจว่า GA4 บันทึกการติดต่อสอบถาม การโทร การคลิกไปยังแอปแชต หรือการซื้อ เป็น key event และจำนวนของเดือนที่แล้ว ใกล้เคียงกับที่ทีมของคุณได้รับจริง ถ้าไม่ ให้แก้การติดตามผลก่อน บทความ ติดตามการติดต่อสอบถามใน GA4 อธิบายทีละขั้น
ขั้นที่ 2: แบ่งคอนเวอร์ชันตามอุปกรณ์และแลนดิ้งเพจ
ใน GA4 เปิด Explore แล้วสร้าง free-form exploration โดยใส่ Device category และ Landing page + query string เป็นแถว และใส่ Sessions, Key events และ อัตรา key event ของเซสชัน เป็นค่า ย้อนหลังอย่างน้อยสามเดือน แล้วมองหารูปแบบสองอย่าง
- ช่องว่างระหว่างมือถือกับเดสก์ท็อปที่กว้างมากในหน้าเดียวกัน ช่องว่างบ้างเป็นเรื่องปกติ เพราะหลายคนหาข้อมูลบนมือถือแล้วติดต่อจากคอมพิวเตอร์ แต่ถ้าอัตราบนมือถือต่ำกว่าเดสก์ท็อปมาก ในหน้าที่คนใช้มือถือเป็นหลัก ก็ควรดูให้ละเอียด
- หน้าสำคัญที่คอนเวอร์ชันแย่กว่าหน้าที่คล้ายกัน ถ้าหน้าบริการสองหน้าดึงดูดผู้เข้าชมคล้ายกัน แต่หน้าหนึ่งมีอัตราคอนเวอร์ชันแค่ครึ่งเดียว และยังช้ากว่ามาก ให้ตามเบาะแสนั้นไป
ขั้นที่ 3: เทียบกับข้อมูลความเร็วจากผู้ใช้จริง
วางข้อมูลผู้ใช้จริงของ Chrome คือ Chrome UX Report (CrUX) ไว้ข้างกลุ่มเหล่านั้น PageSpeed Insights แสดงข้อมูลนี้ต่อ URL เมื่อมีทราฟฟิกพอ (ถ้าไม่พอจะแสดงของทั้งโดเมน) แยกมือถือกับเดสก์ท็อป รายงาน Core Web Vitals ใน Search Console จัดกลุ่ม URL ที่คล้ายกัน ให้เห็นว่าปัญหาเป็นของเทมเพลตเดียว หรือของทั้งเว็บไซต์ บทความ วิธีอ่าน PageSpeed Insights อธิบายว่าส่วนไหนควรลงมือแก้
เรียงทุกอย่างไว้ในตารางเดียว ได้แก่ หน้าหรือเทมเพลต อุปกรณ์ เซสชัน อัตราคอนเวอร์ชัน และสถานะ LCP, INP และ CLS ถ้าหน้าที่ไม่ผ่าน Core Web Vitals เป็นหน้าที่คอนเวอร์ชันแย่ที่สุดด้วย คุณได้สมมติฐานที่ต้องทดสอบ ไม่ใช่ข้อพิสูจน์ เพราะหน้าที่ช้าอาจเป็นหน้าที่อ่อนในด้านอื่นด้วย CrUX Vis ซึ่งเป็นเครื่องมือดูข้อมูล CrUX ของ Google แสดงกราฟข้อมูลภาคสนามรายสัปดาห์ย้อนหลังหลายเดือน คุณจึงตรวจได้ว่า การติดต่อสอบถามที่ลดลง เกิดขึ้นหลังจากเว็บช้าลงเพราะอัปเดตปลั๊กอินหรือเพิ่มแท็กใหม่หรือไม่
ขั้นที่ 4: เชื่อมความเร็วกับการเข้าชมแต่ละครั้ง
หลักฐานที่แข็งแรงที่สุด คือการเชื่อมความเร็วเข้ากับการเข้าชมแต่ละครั้ง ไลบรารี web-vitals แบบโอเพนซอร์สของ Google ส่งค่า LCP, INP และ CLS จากผู้เข้าชมจริงไปยัง GA4 เป็น event ได้ คู่มือของ web.dev เรื่อง การวัดประสิทธิภาพด้วย GA4 และ BigQuery แสดงวิธีทำ จากนั้นเทียบอัตราคอนเวอร์ชันของการเข้าชมที่ LCP ดี กับที่ LCP แย่ ภายในอุปกรณ์ประเภทเดียวกันและประเทศเดียวกัน เพราะการเข้าชมที่ช้ามักเอียงไปทางมือถือรุ่นเก่าและการเชื่อมต่อที่อ่อนกว่า
ขั้นที่ 5: เทียบคลิกโฆษณากับเซสชัน
เทียบจำนวนคลิกบนแพลตฟอร์มโฆษณาของแต่ละแคมเปญ กับจำนวนเซสชันใน GA4 ในช่วงวันเดียวกัน ตัวเลือกความยินยอม ตัวบล็อกโฆษณา และช่องโหว่ในการติดแท็ก ทำให้ตัวเลขไม่มีวันตรงกันเป๊ะ แต่ถ้าแลนดิ้งเพจที่ช้าหน้าหนึ่ง เสียคนระหว่างคลิกกับเซสชันมากกว่าหน้าอื่นมาก ส่วนต่างนั้นคือตัวแทนคร่าวๆ ของคนที่รอไม่ไหว
ขั้นที่ 6: วัดผลก่อนและหลังอย่างถูกวิธี
- บันทึกค่าฐาน อย่างน้อยสี่สัปดาห์ ได้แก่ อัตราคอนเวอร์ชันแยกตามอุปกรณ์ของหน้าที่ได้รับผลกระทบ และข้อมูลภาคสนามของหน้าเหล่านั้น
- เปลี่ยนทีละอย่างเมื่อทำได้ และจดวันที่ปล่อยงาน
- มีกลุ่มเปรียบเทียบ แก้เทมเพลตหนึ่งก่อน และปล่อยเทมเพลตที่คล้ายกันไว้ไม่แตะ ถ้าเฉพาะหน้าที่แก้แล้วดีขึ้นในช่วงสัปดาห์เดียวกัน ฤดูกาลและแคมเปญก็ไม่น่าจะเป็นคำอธิบาย
- ให้เวลาประมาณหนึ่งเดือน ตัวเลข CrUX ใน PageSpeed Insights และ Search Console ครอบคลุม 28 วันที่ผ่านมา
- เทียบสิ่งที่เทียบกันได้ ได้แก่ ช่วงเวลาที่ยาวเท่ากัน สัดส่วนวันในสัปดาห์เหมือนกัน และเทียบปีต่อปีถ้าธุรกิจของคุณมีฤดูกาล
ถ้ามีทราฟฟิกมากพอ A/B test แบบของ Vodafone คือคำตอบที่ชัดที่สุด บทความ A/B testing แลนดิ้งเพจ อธิบายว่าเมื่อไหร่ที่การทดสอบแบบนี้เป็นไปได้จริง
ใส่ตัวเลขให้ต้นทุนของเว็บที่ช้า
เมื่อมีข้อมูลแบ่งกลุ่มแล้ว การประมาณคร่าวๆ ก็เป็นแค่เลขคณิตง่ายๆ ตัวอย่างสมมติ
การปิดช่องว่างนั้น หมายถึงการติดต่อสอบถามเพิ่มขึ้นประมาณ 12 ครั้งต่อเดือน และลูกค้าเพิ่มขึ้นสองถึงสามราย คูณด้วยมูลค่าเฉลี่ยต่อลูกค้าของคุณ แล้วบวกด้วยคลิกโฆษณาที่เสียไปคูณต้นทุนต่อคลิก ให้ถือว่ายอดรวมเป็นตัวเลขสูงสุดที่เป็นไปได้ เพราะช่องว่างบางส่วนอาจไม่ได้เกิดจากความเร็ว แต่มันเปลี่ยนความรู้สึกว่า “เว็บดูช้า” ให้เป็นตัวเลข ที่คุณเทียบกับค่าใช้จ่ายในการแก้ได้
เมื่อไหร่งานเพิ่มความเร็วคุ้มค่า
ถ้าความเร็วไม่ใช่ข้อจำกัด คู่มือการเพิ่มอัตราคอนเวอร์ชัน จะช่วยให้คุณหาว่าอะไรคือข้อจำกัด แต่ถ้าใช่ บทความ ทำไมเว็บไซต์ของคุณช้า? จะชี้สาเหตุ และ คู่มือเพิ่มความเร็วเว็บไซต์ เรียงลำดับวิธีแก้ตามผลกระทบและแรงที่ใช้
ตัวอย่างจริง พร้อมข้อควรระวัง
ใน เว็บไซต์ของผู้พัฒนาอสังหาริมทรัพย์ที่เรารีดีไซน์ เวลาโหลดลดลงจากประมาณเก้าวินาทีเหลือสองวินาที และการติดต่อสอบถามจากผู้ซื้อเพิ่มขึ้น 40% ในสามเดือนหลังเปิดตัว ความเร็วเป็นหนึ่งในการเปลี่ยนแปลงหลายอย่าง รวมถึงโครงสร้างตามเส้นทางของผู้ซื้อ เลย์เอาต์ที่ใช้งานง่ายบนมือถือ และฟอร์มติดต่อสอบถามที่วัดผลได้ ความเร็วจึงเป็นส่วนหนึ่งของชุดการเปลี่ยนแปลงที่ได้ผล ไม่ใช่สาเหตุเดียว บทความ เว็บไซต์ผู้พัฒนาอสังหาริมทรัพย์ต้องมีอะไร อธิบายส่วนที่เหลือ
คำถามที่พบบ่อย
ความเร็วเว็บไซต์ส่งผลต่อยอดขายไหม?
ส่งผลได้ โดยเฉพาะบนมือถือและแลนดิ้งเพจของโฆษณา ซึ่งหน้าจอแรกที่ช้าทำให้เสียผู้เข้าชมก่อนเขาจะเห็นข้อเสนอ การทดสอบที่มีการควบคุม เช่น ของ Vodafone เชื่อมโยงหน้าที่เร็วขึ้นกับยอดขายที่มากขึ้น แต่ขนาดของผลกระทบขึ้นอยู่กับเว็บไซต์ กลุ่มเป้าหมาย และจุดเริ่มต้นของคุณ
ทำไม bounce rate ไม่แสดงผลของเว็บที่ช้า?
ใน GA4 bounce rate คือสัดส่วนของเซสชันที่ไม่มีการมีส่วนร่วม (engaged) ผู้เข้าชมที่ออกไปก่อนแท็ก analytics โหลด ไม่เคยกลายเป็นเซสชัน ความสูญเสียที่หนักที่สุดจากหน้าจอแรกที่ช้า จึงไม่เคยไปถึงรายงานนั้น
ความเร็วส่งผลต่อค่าโฆษณา Google Ads ไหม?
ทำให้ต้นทุนต่อลีดสูงขึ้น เพราะคุณจ่ายทุกคลิก ไม่ว่าหน้าจะโหลดขึ้นหรือไม่ ส่วนผลต่อราคาของแต่ละคลิกนั้นชัดเจนน้อยกว่า ประสบการณ์บนแลนดิ้งเพจเป็นส่วนหนึ่งของ Quality Score แต่ Google ไม่ได้บอกว่าความเร็วมีส่วนในนั้นแค่ไหน
ขั้นตอนต่อไป
งานเพิ่มความเร็วคุ้มค่าที่จะจ่าย เมื่อข้อมูลของคุณเองแสดงว่าหน้าที่ช้าและคอนเวอร์ชันที่อ่อนอยู่ในที่เดียวกัน โดยเฉพาะบนมือถือและแลนดิ้งเพจของโฆษณา ขั้นที่ 2 และ 3 ข้างต้นบอกคุณได้ในบ่ายเดียวว่า ความเร็วน่าจะเป็นสาเหตุ หรือเป็นแค่เรื่องที่ทำให้ไขว้เขว
ถ้าอยากได้ความเห็นที่สองก่อนตั้งงบใดๆ ขอ ตรวจสอบเว็บไซต์ฟรี ได้ คนจริงๆ จะตรวจว่าหน้าสำคัญของคุณโหลดและทำงานอย่างไรบนมือถือ และชี้ว่าความช้าน่าจะขวางระหว่างผู้เข้าชมกับการติดต่อสอบถามอยู่ตรงไหนมากที่สุด เก็บรายงานไว้ เพราะมันใช้เป็นภาพ “ก่อน” ของการแก้ไขที่คุณทำได้ด้วย