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

เว็บช้า เสียอะไรบ้าง (มากกว่าที่คิด)

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

  • เสียลูกค้าก่อนได้คุย — คนที่คลิกเข้ามาจากโฆษณาหรือผลค้นหา ถ้ารอเกินไม่กี่วินาทีแล้วยังเห็นหน้าขาว เขากดย้อนกลับไปหาคู่แข่งทันที เงินค่าโฆษณาที่จ่ายไปคือจ่ายฟรี

  • เสียอันดับบน Google — เมื่อเนื้อหาสูสีกัน เว็บที่ผ่านเกณฑ์ Core Web Vitals ได้เปรียบเว็บที่ไม่ผ่าน และหน้าที่ช้ามากยังถูกเก็บเข้า index ได้ช้าลงด้วย

  • เสียความน่าเชื่อถือ — เว็บที่โหลดอืด ปุ่มกดแล้วไม่ตอบสนอง หรือหน้ากระตุกขณะอ่าน ให้ความรู้สึกเดียวกับหน้าร้านที่ไฟดับ ลูกค้าไม่กล้ากรอกข้อมูลหรือโอนเงิน

Core Web Vitals คืออะไร — รู้จัก 3 ค่าที่ Google ใช้วัด

Core Web Vitals คือตัวชี้วัดประสบการณ์ใช้งานจริง 3 ตัวที่ Google เก็บจากผู้ใช้ Chrome ทั่วโลก ปัจจุบัน (ปี 2026) ประกอบด้วย:

  • LCP (Largest Contentful Paint) — เวลาที่เนื้อหาชิ้นใหญ่สุดของหน้าโผล่ขึ้นมา เช่น รูป hero หรือพาดหัว เกณฑ์ผ่านคือ ไม่เกิน 2.5 วินาที ค่านี้ตอบคำถามว่า "คนเห็นของเร็วแค่ไหน"

  • INP (Interaction to Next Paint) — ความไวในการตอบสนองเมื่อผู้ใช้กดปุ่ม แตะเมนู หรือพิมพ์ เกณฑ์ผ่านคือ ไม่เกิน 200 มิลลิวินาที ค่านี้เข้ามาแทน FID เดิมตั้งแต่ปี 2024 แล้ว — ถ้าเจอบทความที่ยังสอนเรื่อง FID อยู่ แปลว่าบทความนั้นเก่าเกินไป

  • CLS (Cumulative Layout Shift) — ความนิ่งของหน้า วัดว่าเนื้อหากระโดดหนีขณะโหลดแค่ไหน อาการคลาสสิกคือกำลังจะกดปุ่ม แล้วแบนเนอร์โผล่มาดันทุกอย่างลง ทำให้กดผิด เกณฑ์ผ่านคือ ไม่เกิน 0.1

วัดเว็บตัวเองยังไง — ฟรีทั้งหมด

  1. PageSpeed Insights (pagespeed.web.dev) — ใส่ URL แล้วได้ทั้งคะแนนและข้อมูลผู้ใช้จริง แยกมือถือกับเดสก์ท็อป ให้ดูส่วน "สำรวจสิ่งที่ผู้ใช้จริงพบเจอ" เป็นหลัก เพราะนั่นคือข้อมูลจากคนใช้จริง ไม่ใช่การจำลอง

  2. Google Search Console — เมนู Core Web Vitals แสดงว่าหน้าไหนในเว็บผ่านหรือไม่ผ่านบ้าง เหมาะกับการไล่ดูทั้งเว็บ ไม่ใช่ทีละหน้า

  3. ลองเปิดเองจากมือถือผ่านเน็ตมือถือ — วิธีบ้าน ๆ ที่ได้ผลสุด เพราะลูกค้าส่วนใหญ่เข้าเว็บคุณจากมือถือ ไม่ใช่จากคอมในออฟฟิศที่ต่อ WiFi แรง ๆ

ข้อควรระวัง: คะแนน Lighthouse ที่วิ่ง 0–100 เป็นการทดสอบในสภาพจำลอง ใช้หาจุดที่ต้องแก้ได้ดี แต่ตัวตัดสินจริงคือข้อมูลผู้ใช้จริง (field data) สองอย่างนี้ไม่จำเป็นต้องตรงกันสาเหตุยอดฮิตที่ทำให้เว็บช้า — และวิธีแก้

  • รูปใหญ่เกินจำเป็น — ต้นเหตุอันดับหนึ่งของเว็บไทย รูปถ่ายจากมือถือหลาย MB ถูกอัปขึ้นเว็บตรง ๆ วิธีแก้: ย่อขนาดและแปลงเป็น WebP ก่อนอัป ตั้งให้รูปใต้จอโหลดแบบ lazy และอย่าใส่ lazy กับรูป hero บนสุด เพราะจะทำ LCP แย่ลงแทน

  • ปลั๊กอินและสคริปต์รกเกิน — เว็บ WordPress ที่ลงปลั๊กอินไว้หลายสิบตัว หรือฝังสคริปต์การตลาด แชท และ pixel ไว้เต็มหน้า แต่ละตัวกินเวลาโหลดทั้งนั้น วิธีแก้: ไล่ปิดตัวที่ไม่ได้ใช้จริง เหลือเท่าที่จำเป็น แล้ววัดผลก่อน-หลังทุกครั้ง

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

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

แล้ว WordPress กับ Next.js ต่างกันยังไงเรื่องความเร็ว

WordPress ทำให้เร็วได้ ถ้าคุมวินัยเรื่องธีม ปลั๊กอิน และ cache ดี ๆ — ปัญหาคือเว็บ WordPress ส่วนใหญ่ไม่ได้ถูกคุม พออยากได้ฟีเจอร์อะไรก็ลงปลั๊กอินเพิ่มไปเรื่อย ๆ จนอืดโดยไม่มีใครตั้งใจ

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

เช็กลิสต์ลงมือได้เลยสัปดาห์นี้

  1. เอา URL หน้าแรกกับหน้าขายหลักไปวัดใน PageSpeed Insights ทั้งโหมดมือถือและเดสก์ท็อป จดค่า LCP, INP, CLS ไว้เป็นฐาน

  2. ย่อรูปทุกรูปที่ใหญ่เกิน แล้ววัดซ้ำ — เคสส่วนใหญ่เห็นผลชัดจากข้อนี้ข้อเดียว

  3. ไล่ปิดปลั๊กอิน/สคริปต์ที่ไม่ได้ใช้ วัดซ้ำทีละรอบ จะได้รู้ว่าตัวไหนคือตัวถ่วง

  4. เปิด Search Console ดูรายงาน Core Web Vitals ทุกเดือน ให้เหมือนเช็กสุขภาพประจำปีของเว็บ

ความเร็วยังเป็นฐานของเรื่องอื่นด้วย — เว็บที่โหลดไวและโครงสร้างสะอาด ทั้ง Google และ AI search อ่านง่ายขึ้น ซึ่งเราอธิบายละเอียดไว้ในคู่มือทำเว็บให้ ChatGPT และ Google AI หยิบไปตอบ และถ้าจะให้เครื่องเข้าใจเว็บสุด ๆ อย่าลืมใส่ข้อมูลโครงสร้างตามคู่มือ Schema Markup สำหรับธุรกิจไทยด้วย

ถ้าแก้เองแล้วยังช้า

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