เว็บ WordPress ช้า แก้อย่างไร (เคสจริง: TTFB จาก 0.8 วิ เหลือ 0.07 วิ)

เว็บ WordPress ช้า คืออาการที่เซิร์ฟเวอร์ตอบกลับช้า หรือหน้าเว็บโหลดเนื้อหาหลักนานเกินเกณฑ์ของ Google ซึ่งส่วนใหญ่แก้ได้ด้วยการตั้งค่า Page Cache จัดการ JavaScript รูปภาพ และจำนวนไฟล์ที่หน้าเว็บเรียกใช้ บทความนี้อธิบายตามลำดับที่ควรทำจริง ได้แก่ การวัดว่าเว็บช้าจริงไหม, สาเหตุที่ทำให้เว็บ WordPress ช้า, เคสจริงของเว็บ rankfinder.in.th ที่ลด TTFB จาก 0.8 วินาทีเหลือ 0.07 วินาที, การตั้งค่า WP Rocket ทีละขั้น, การปรับรูปภาพ ฟอนต์ และจำนวน Request, การตรวจโฮสติ้งและปลั๊กอิน และสัญญาณที่บอกว่าควรให้ผู้เชี่ยวชาญช่วย

วัดก่อนแก้: ตัวเลขที่บอกว่าเว็บ WordPress ช้าจริงไหม

เว็บ WordPress ช้าจริงหรือไม่ ให้ตัดสินจากตัวเลข 4 ตัว คือ TTFB และ Core Web Vitals อีก 3 ค่า ไม่ใช่จากความรู้สึกตอนเปิดเว็บบนเครื่องตัวเอง เพราะเบราว์เซอร์ของเจ้าของเว็บมักเก็บไฟล์ไว้แล้วจึงดูเร็วกว่าที่ลูกค้าเห็น ความเร็วเป็นหนึ่งในหัวข้อของ Technical SEO Checklist ที่ควรตรวจเป็นประจำ

เกณฑ์ TTFB มาจากบทความ Time to First Byte ของ web.dev ซึ่งใช้ 0.8 วินาทีเป็นแนวทางคร่าว ๆ ส่วนเกณฑ์ LCP, INP และ CLS มาจาก Web Vitals ที่ให้วัดที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชม แยกมือถือและเดสก์ท็อป ใช้ PageSpeed Insights ดูข้อมูลรายหน้า และใช้รายงาน Core Web Vitals ใน Google Search Console ดูภาพรวมทั้งเว็บ

สาเหตุที่ทำให้เว็บ WordPress ช้า

เว็บ WordPress ช้าเพราะทุกครั้งที่มีคนเปิดหน้า เซิร์ฟเวอร์ต้องรัน PHP และดึงข้อมูลจากฐานข้อมูลเพื่อสร้าง HTML ใหม่ ถ้าไม่มี Cache ช่วย ยิ่งมีปลั๊กอินและธีมที่หนักมาก งานต่อหนึ่งหน้ายิ่งเพิ่ม คู่มือ Optimization ของ WordPress.org ระบุว่าคุณภาพโฮสติ้ง Cache ปลั๊กอิน รูปภาพ และเวอร์ชัน PHP ล้วนมีผลต่อความเร็ว

• ไม่มี Page Cache: เซิร์ฟเวอร์สร้างหน้าใหม่ทุกครั้ง ทำให้ TTFB สูง
• JavaScript และ CSS มากเกินไป: Page Builder และปลั๊กอินแต่ละตัวโหลดไฟล์ของตัวเองแม้หน้านั้นไม่ได้ใช้
• รูปภาพใหญ่เกินจำเป็น: รูปขนาดเต็มถูกแสดงในช่องเล็ก หรือรูปหลักถูกตั้งให้โหลดทีหลัง
• ฟอนต์จากภายนอก: ฟอนต์หลายน้ำหนักที่ไม่ได้ใช้จริงเพิ่มขนาดดาวน์โหลด
• โฮสติ้งและ PHP เก่า: ทรัพยากรไม่พอ หรือใช้ PHP เวอร์ชันที่หมดอายุแล้ว
• ปลั๊กอินที่ไม่จำเป็น: ปลั๊กอินที่ติดตั้งไว้แต่ไม่ได้ใช้ยังรันโค้ดอยู่เบื้องหลัง

เคสจริง: rankfinder.in.th ลด TTFB จาก 0.8 วินาที เหลือ 0.07 วินาที

เว็บ rankfinder.in.th ซึ่งสร้างด้วย WordPress และ Elementor ลด TTFB จากประมาณ 0.8 วินาที เหลือประมาณ 0.07 วินาทีในทุกหน้าหลัก หลังทีม Rankfinder ตั้งค่า Page Cache และเลื่อนการโหลด JavaScript ที่ไม่จำเป็นเมื่อวันที่ 26 กันยายน 2026 ตัวเลขนี้คือผลที่เราวัดจากเว็บของเราเอง ไม่ใช่ค่าเฉลี่ยของอุตสาหกรรม

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

ในรอบปรับต่อมาเมื่อวันที่ 7 ตุลาคม 2026 เราตัดฟอนต์ Roboto ที่ไม่ได้ใช้ออก และหยุดการ Lazy Load รูปหลักของบทความ ผลจาก Lighthouse บนมือถือของหน้าบทความหนึ่ง คะแนนขยับจาก 86 และ 89 เป็น 99 และ 95 ขนาดฟอนต์ที่ต้องดาวน์โหลดลดจาก 133 KB เหลือ 31 KB ส่วนหน้ารวมบทความมีค่า CLS ลดจาก 0.139 เหลือ 0.007

ตั้งค่า WP Rocket ทีละขั้นให้เว็บเร็วขึ้น

การตั้งค่า WP Rocket ที่ปลอดภัยที่สุดคือเปิดทีละฟีเจอร์ แล้วตรวจหน้าสำคัญหลังเปิดแต่ละฟีเจอร์ ตามคำแนะนำในเอกสาร Find the best settings for your site ของ WP Rocket เพราะค่าที่ดีที่สุดของแต่ละเว็บต่างกันตามธีม ปลั๊กอิน และโฮสติ้ง ตารางด้านล่างเรียงลำดับที่เราใช้

เอกสาร Delay JavaScript execution ของ WP Rocket อธิบายว่าฟีเจอร์นี้เลื่อนการรันสคริปต์ไปจนผู้ใช้ขยับเมาส์ แตะ เลื่อน หรือกดปุ่ม และเตือนว่าสคริปต์บางตัวอาจทำงานผิดปกติ ให้ยกเว้นเฉพาะตัวที่มีปัญหา เพราะยิ่งยกเว้นมาก ประโยชน์ยิ่งลดลง ข้อสังเกตอีกข้อคือ URL ที่มี query string เช่น ?t= จะข้าม Cache ของ WP Rocket ไป จึงควรตรวจผลบน URL ปกติเสมอ

ปรับรูปภาพ ฟอนต์ และจำนวน Request

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

• รูปหลักด้านบนหน้า: ยกเว้นจาก Lazy Load และใส่ fetchpriority=”high” ให้เบราว์เซอร์โหลดก่อน
• รูปในการ์ดหรือรายการบทความ: เลือกขนาดรูปที่พอดีกับช่อง แทนการแสดงไฟล์ขนาดเต็ม
• ฟอร์แมตรูป: ใช้ WebP ซึ่งคู่มือของ WordPress.org แนะนำว่ามักมีขนาดเล็กกว่าฟอร์แมตเดิม
• ฟอนต์: ตัดฟอนต์และน้ำหนักฟอนต์ที่หน้าไม่ได้ใช้ออก
• จำนวน Request: รวมไฟล์ CSS ขนาดเล็กเข้าไปในหน้า เพื่อลดจำนวนไฟล์ที่ต้องเรียก

เรื่องจำนวน Request มีบทเรียนจากเว็บเราเองเช่นกัน หน้าแรกเคยเรียกไฟล์ราว 70 ไฟล์ในการโหลดครั้งแรก และเซิร์ฟเวอร์ตอบรหัส 429 (คำขอมากเกินไป) กลับมาบางไฟล์ทุกครั้ง หลังรวม CSS ขนาดเล็กของ Elementor และธีมเข้าไปในหน้า จำนวน Request ลดเหลือ 43 และไม่พบรหัส 429 อีก โฮสต์แต่ละที่ตั้งขีดจำกัดต่างกัน จึงควรตรวจในแท็บ Network ของเบราว์เซอร์ด้วยตัวเอง

ตรวจโฮสติ้ง เวอร์ชัน PHP และปลั๊กอิน

ถ้าตั้งค่า Cache แล้ว TTFB ของหน้าที่ไม่ได้ Cache ยังสูง ปัญหามักอยู่ที่โฮสติ้ง เวอร์ชัน PHP หรือปลั๊กอิน หน้า Requirements ของ WordPress.org แนะนำ PHP 8.3 ขึ้นไป และ MySQL 8.0 หรือ MariaDB 10.11 ขึ้นไป ส่วนคู่มือ Optimization แนะนำให้ใช้ Object Cache เพื่อลดการเรียกฐานข้อมูลซ้ำ และปิดพร้อมลบปลั๊กอินที่ไม่จำเป็น

1. ตรวจเวอร์ชัน PHP: ดูได้ที่ Tools → Site Health ใน WordPress แล้วอัปเกรดผ่านแผงควบคุมโฮสติ้ง หลังทดสอบบนเว็บสำรอง
2. ถามโฮสต์เรื่อง Object Cache: เช่น Redis หรือ Memcached ซึ่งต้องเปิดที่เซิร์ฟเวอร์ก่อนใช้ปลั๊กอิน
3. ไล่ปิดปลั๊กอินทีละตัว: วัดความเร็วหลังปิดแต่ละตัว เพื่อหาตัวที่ทำให้ช้า
4. ปิดโมดูลที่ไม่ได้ใช้: ปลั๊กอินขนาดใหญ่หลายตัวแบ่งเป็นโมดูล ปิดส่วนที่ไม่ใช้ได้โดยไม่ต้องถอนทั้งปลั๊กอิน

เมื่อไหร่ควรให้ผู้เชี่ยวชาญช่วยแก้เว็บช้า

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

• TTFB ของหน้าที่ Cache แล้วยังเกิน 0.8 วินาที
• หน้าเว็บแสดงไม่ครบหรือฟอร์มส่งไม่ได้หลังเปิด Delay JavaScript
• เซิร์ฟเวอร์ตอบรหัส 429 หรือ 5xx เป็นช่วง ๆ
• คะแนนมือถือต่างจากเดสก์ท็อปมากโดยไม่ทราบสาเหตุ

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

ประเด็นสำคัญของการแก้เว็บ WordPress ช้า

• วัดก่อนแก้: TTFB ไม่เกิน 0.8 วินาที LCP ไม่เกิน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที CLS ไม่เกิน 0.1
• สาเหตุหลัก: ไม่มี Page Cache, JavaScript และ CSS มาก, รูปใหญ่, ฟอนต์, โฮสติ้งหรือ PHP เก่า และปลั๊กอินเกินจำเป็น
• เคสจริง: rankfinder.in.th ลด TTFB จาก 0.8 เหลือ 0.07 วินาทีด้วย Page Cache และการเลื่อน JavaScript
• WP Rocket: เปิดทีละฟีเจอร์และตรวจหน้าทุกครั้ง โดยเฉพาะ Delay JavaScript
• รูปภาพ ฟอนต์ Request: ห้าม Lazy Load รูปหลัก เลือกขนาดรูปให้พอดี ตัดฟอนต์ที่ไม่ใช้ และลดจำนวนไฟล์
• โฮสติ้งและปลั๊กอิน: ใช้ PHP 8.3 ขึ้นไป พิจารณา Object Cache และลบปลั๊กอินที่ไม่ใช้
• ขอความช่วยเหลือ: เมื่อแก้แล้ว Core Web Vitals ยังไม่ผ่าน หรือหน้าเว็บพังหลังเปิดฟีเจอร์

อ่านต่อในหัวข้อเดียวกัน

• Schema Markup คืออะไร? คู่มือใส่ Structured Data ให้เว็บไทย 2026

คำถามที่พบบ่อยเกี่ยวกับเว็บ WordPress ช้า

ความเร็วเว็บมีผลต่ออันดับ SEO ไหม

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

ต้องใช้ WP Rocket ไหม หรือมีปลั๊กอินฟรีที่ใช้แทนได้

ไม่จำเป็นต้องใช้ WP Rocket เสมอไป ปลั๊กอิน Cache ฟรีหลายตัวทำ Page Cache ได้ และโฮสติ้งบางรายมี Cache ระดับเซิร์ฟเวอร์ให้อยู่แล้ว หลักการตั้งค่าเหมือนกัน คือเปิดทีละฟีเจอร์และตรวจหน้าทุกครั้ง ที่สำคัญคืออย่าเปิดปลั๊กอิน Cache สองตัวพร้อมกัน

ทำไมคะแนน PageSpeed Insights ขึ้นลงทุกครั้งที่วัด

คะแนน PageSpeed Insights ขึ้นลงเพราะการทดสอบแต่ละรอบได้รับผลจากเครือข่ายและภาระของเซิร์ฟเวอร์ในขณะนั้น ในเว็บของเราเอง หน้าแรกได้คะแนนมือถือจาก Lighthouse ต่างกันตั้งแต่ 76 ถึง 94 ในการวัดหลายรอบ จึงควรวัดหลายครั้งแล้วดูค่ากลาง และยึดข้อมูลผู้ใช้จริงในรายงาน Core Web Vitals เป็นหลัก

Page Builder อย่าง Elementor ทำให้เว็บช้าเสมอไหม

Elementor ไม่ได้ทำให้เว็บช้าเสมอไป แต่มักโหลดไฟล์ CSS และ JavaScript หลายไฟล์ต่อหน้า เว็บ rankfinder.in.th เองสร้างด้วย Elementor และผ่านเกณฑ์ TTFB ได้หลังตั้งค่า Cache จัดการสคริปต์ และลดจำนวนไฟล์ตามขั้นตอนในบทความนี้