ทำไมเว็บไซต์ช้า? วิธีหาสาเหตุที่แท้จริง ทีละขั้น

เว็บไซต์ที่ช้า เป็นอาการ ไม่ใช่การวินิจฉัย ถ้าถามว่า “ทำไมเว็บไซต์ของฉันช้า?” คำตอบอาจเป็นเซิร์ฟเวอร์ที่ใช้เวลาสองวินาทีกว่าจะตอบ รูปขนาด 4 MB ที่ด้านบนของหน้า หรือสคริปต์การตลาดกองโต ที่แย่งหน่วยประมวลผลของมือถือกัน แต่ละอย่างมีวิธีแก้ต่างกัน และบ่อยครั้ง คนที่ควรแก้ก็ต่างกันด้วย

นี่คือเหตุผลที่เคล็ดลับเพิ่มความเร็วแบบทั่วไป มักทำให้ผิดหวัง ปลั๊กอินแคชแก้วิดเจ็ตแชตไม่ได้ วินิจฉัยตามลำดับ ด้วยเครื่องมือฟรี แล้วค่อยตัดสินใจว่า จะปรับแต่ง หรือสร้างใหม่

ทำไมเว็บไซต์ช้า? คำตอบสั้น ๆ

เว็บไซต์ส่วนใหญ่ที่ช้า ช้าด้วยหนึ่งในสามเหตุผลนี้:

• เซิร์ฟเวอร์ตอบสนองช้า โฮสติ้งที่กำลังไม่พอ ไม่มีแคชหน้า ปลั๊กอินที่หนัก หรือเซิร์ฟเวอร์อยู่ไกลจากผู้เข้าชม
• หน้าเว็บหนักเกินไป รูปภาพขนาดใหญ่เกินไป page builder และปลั๊กอินที่บวม ฟอนต์บนเว็บมากเกินไป และ CSS หรือ JavaScript ที่ต้องโหลดเสร็จ ก่อนที่อะไรจะแสดงขึ้นมา
• สคริปต์ภายนอกขวางทาง แท็ก pixel โฆษณา วิดเจ็ตแชต แบนเนอร์คุกกี้ และวิดีโอหรือแผนที่ที่ฝังไว้ ซึ่งแย่งทรัพยากรของเบราว์เซอร์กัน

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

ขั้นที่ 1: ตรวจว่าผู้เข้าชมจริงเจออะไร

เริ่มจากข้อมูลภาคสนาม (field data) คือค่าที่วัดจากผู้ใช้ Chrome จริง ไม่ใช่การทดสอบครั้งเดียว

PageSpeed Insights ใส่ที่อยู่หน้าเว็บ แล้วอ่านส่วนบนสุด โดยดูมือถือก่อน ข้อมูลนี้มาจาก CrUX (รายงานประสบการณ์ผู้ใช้ Chrome) ครอบคลุม 28 วันที่ผ่านมา และรายงานแต่ละค่าที่เปอร์เซ็นไทล์ที่ 75 บทความ วิธีอ่านรายงาน PageSpeed Insights อธิบายส่วนที่เหลือ

Search Console รายงาน Core Web Vitals จัดกลุ่มหน้าที่คล้ายกัน แยกมือถือและเดสก์ท็อป ทำให้เห็นว่า หน้าประเภทเดียวได้รับผลกระทบ หรือทั้งเว็บไซต์

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

ค่าที่ไม่ผ่านบอกอะไรคุณ

Google ให้คะแนนหน้าเว็บว่าดี เมื่อที่เปอร์เซ็นไทล์ที่ 75 ค่า LCP (เวลาโหลดองค์ประกอบใหญ่ที่สุด) ไม่เกิน 2.5 วินาที ค่า INP (การตอบสนองต่อการแตะหรือคลิก) ไม่เกิน 200 มิลลิวินาที และค่า CLS (การขยับของเลย์เอาต์) ไม่เกิน 0.1 บทความ อธิบาย Core Web Vitals อธิบายแต่ละค่าด้วยภาษาง่าย ๆ ค่าไหนไม่ผ่าน คือเบาะแสแรกของคุณ:

TTFB ไม่ใช่ Core Web Vital แต่ PageSpeed Insights รายงานค่านี้ และถ้ามันช้า ทุกอย่างที่เหลือก็ช้าตาม

ขั้นที่ 2: ทดสอบความเร็วทีละเทมเพลตสำคัญ

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

ทดสอบเทมเพลต ไม่ใช่แค่หน้าแรก

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

เลือกเครื่องมือให้ถูก

PageSpeed Insights รัน Lighthouse ซึ่งจำลองมือถือระดับกลาง บนการเชื่อมต่อที่ช้า คะแนนมือถือจึงมักต่ำกว่าเดสก์ท็อป WebPageTest โหลดหน้าในเบราว์เซอร์จริง จากตำแหน่งและอุปกรณ์ที่คุณเลือก พร้อมภาพต่อเนื่อง (filmstrip) และ waterfall แบบละเอียด Chrome DevTools (คลิกขวาที่หน้าเว็บ แล้วเลือก Inspect) แสดงทุกคำขอ และสิ่งที่เบราว์เซอร์กำลังทำอยู่

ทดสอบให้ยุติธรรม

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

ขั้นที่ 3: อ่าน waterfall

waterfall คือเส้นเวลาของทุกไฟล์ ที่เบราว์เซอร์ดาวน์โหลดเพื่อสร้างหน้า หนึ่งแถวต่อหนึ่งคำขอ รัน WebPageTest หรือเปิดแผง Network ใน DevTools ติ๊ก “Disable cache” เลือกค่าจำลองความเร็วเครือข่ายมือถือ แล้วรีโหลด จากนั้นอ่านสี่อย่าง

1. แถวแรก: เซิร์ฟเวอร์ใช้เวลานานแค่ไหน

คำขอแรก คือเอกสาร HTML และไม่มีอะไรเริ่ม จนกว่าไบต์แรกของมันจะมาถึง การรอนานตรงนี้ ชี้ไปที่เซิร์ฟเวอร์ที่ช้า หรือ redirect หลายทอดก่อนหน้า เป็นแนวทางคร่าว ๆ web.dev แนะนำว่า เว็บไซต์ส่วนใหญ่ควรตั้งเป้า TTFB ไม่เกิน 0.8 วินาที

2. อะไรโหลดก่อนหน้าจอจะแสดงผล

filmstrip ของ WebPageTest แสดงว่า คอนเทนต์ปรากฏครั้งแรกเมื่อไร คิวของ CSS และ JavaScript ก่อนช่วงเวลานั้น มักหมายถึง render-blocking resources คือเบราว์เซอร์จะไม่วาดหน้าจอ จนกว่าจะได้ไฟล์เหล่านั้น บทความ Render-blocking resources แสดงวิธีจัดการ

3. ไฟล์ที่ใหญ่ที่สุด

เรียงตามขนาด รูปหลายเมกะไบต์ วิดีโอพื้นหลัง หรือไฟล์ฟอนต์นับสิบไฟล์ จะโดดเด่นทันที บน WordPress ให้กรองด้วย wp-content/plugins เพื่อดูว่าปลั๊กอินไหน โหลดไฟล์ในหน้านี้

4. โดเมนที่คุณไม่ได้ควบคุม

นับโดเมนที่ไม่ใช่ของคุณ ได้แก่ ระบบวิเคราะห์ข้อมูล โฆษณา แชต ฟอนต์ วิดีโอ และแผนที่ จากนั้นมองหาช่วง ที่แทบไม่มีอะไรดาวน์โหลด แต่หน้ายังไม่พร้อม ซึ่งแปลว่าเบราว์เซอร์กำลังยุ่งกับการรัน JavaScript ในแผง Performance ของ DevTools งานใดที่เกิน 50 มิลลิวินาที นับเป็นงานยาว (long task) และหน้าที่เต็มไปด้วยงานยาว จะรู้สึกไม่ตอบสนองบนมือถือ

ขั้นที่ 4: ไล่สาเหตุไปที่เซิร์ฟเวอร์ หน้าเว็บ หรือบริการภายนอก

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

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

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

จู่ ๆ ก็ช้าลง? เริ่มจากสิ่งที่เปลี่ยนไปในช่วงวันนั้น เช่น การอัปเดตปลั๊กอิน ธีม หรือ PHP แท็กหรือวิดเจ็ตใหม่ การย้ายโฮสติ้ง หรือทราฟฟิกจากบอตที่พุ่งขึ้น

สาเหตุที่เว็บไซต์ช้า ทีละอาการ

โฮสติ้งช้า ไม่มีแคช หรือเซิร์ฟเวอร์อยู่ไกล

อาการ แถวแรกรอนานทุกหน้า แย่ลงในช่วงคนเข้าเยอะ หรือเมื่ออยู่ไกลจากเซิร์ฟเวอร์ และแดชบอร์ด WordPress อืด

ตรวจ โฮสต์และ CDN หลายราย เพิ่ม response header ที่บอกว่า หน้านั้นมาจากแคช (HIT) หรือสร้างใหม่ (MISS) คลิกคำขอเอกสารใน DevTools แล้วดูใต้ Headers จากนั้นเปรียบเทียบเวลารอของแถวแรก จากตำแหน่งทดสอบของ WebPageTest ที่อยู่ใกล้เซิร์ฟเวอร์ กับตำแหน่งที่อยู่ใกล้ลูกค้า

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

รูปภาพใหญ่เกินไป

อาการ LCP ช้า โดยองค์ประกอบ LCP คือภาพ hero

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

แก้ ย่อขนาดก่อนอัปโหลด ใช้ WebP หรือ AVIF กำหนดความกว้างและความสูง และตั้ง lazy-load ให้รูปที่อยู่ต่ำกว่าหน้าจอแรก แต่ห้ามใช้กับรูปหลักด้านบน บทความ การปรับแต่งภาพสำหรับเว็บไซต์ มีคู่มือฉบับเต็ม

page builder และปลั๊กอินที่บวม

อาการ ไฟล์ CSS และ JavaScript หลายสิบไฟล์ คำเตือนเรื่องขนาด DOM ใน PageSpeed Insights และ INP แย่บนมือถือ

ตรวจ มองหาปลั๊กอินที่โหลดไฟล์ในทุกหน้า แต่ใช้แค่หน้าเดียว เช่น แบบฟอร์ม สไลเดอร์ หรือแกลเลอรี

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

ฟอนต์บนเว็บที่หนัก

อาการ ตัวอักษรหายไปชั่วครู่ หรือกระโดด เมื่อฟอนต์บนเว็บมาแทนฟอนต์สำรอง

ตรวจ กรอง waterfall ด้วยคำว่า font การเจอหลายตระกูลฟอนต์ในหลายน้ำหนัก หรือฟอนต์ไอคอนทั้งชุด เพื่อใช้ไอคอนห้าตัว เป็นเรื่องที่พบบ่อย

แก้ ลดตระกูลและน้ำหนักฟอนต์ โฮสต์ไฟล์ WOFF2 เอง preload เฉพาะฟอนต์ในหน้าจอแรก และใช้ font-display: swap พร้อมฟอนต์สำรองขนาดใกล้เคียงกัน

สคริปต์การตลาดที่ซ้อนกัน

อาการ โดเมนภายนอกจำนวนมาก และ INP แย่ เกินกว่าที่งานออกแบบอย่างเดียวจะอธิบายได้

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

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

ปรับแต่งหรือสร้างใหม่?

เมื่อรู้สาเหตุแล้ว ให้ถามคำถามเดียว การแก้ไขเปลี่ยนสิ่งที่หน้าเว็บโหลด หรือเปลี่ยนวิธีสร้างทุกหน้า?

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

ไม่ว่าทางไหน ให้ทดสอบเทมเพลตเดิม ด้วยวิธีเดิม ทั้งก่อนและหลัง และเฝ้าดูข้อมูลภาคสนามสี่สัปดาห์ เพราะ CrUX เป็นหน้าต่างเวลาแบบเลื่อน 28 วัน

คำถามที่พบบ่อย

ทำไมเว็บไซต์ช้าบนมือถือ แต่บนเดสก์ท็อปปกติ?

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

ปลั๊กอินแคชจะแก้เว็บไซต์ที่ช้าได้ไหม?

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

เมื่อแก้เว็บช้า ต้องตั้งเป้าคะแนน PageSpeed เต็มไหม?

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

ขั้นต่อไป

ไล่การวินิจฉัยตามลำดับ:

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

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

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