วิธีทำให้เว็บไซต์ WordPress เร็วขึ้น โดยไม่ทำให้เว็บพัง

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

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

ยังไม่แน่ใจว่าเวลาหายไปตรงไหน? เริ่มจาก ทำไมเว็บไซต์ช้า? ส่วนหลักการเบื้องหลังแต่ละขั้น อยู่ใน คู่มือเพิ่มความเร็วเว็บไซต์

วิธีทำให้ WordPress เร็วขึ้น: คำตอบสั้น ๆ

ทำตามลำดับนี้ และทดสอบหลังทุกขั้น:

1. คัดลอกเว็บไซต์ไปยัง staging และบันทึกค่าพื้นฐาน
2. ใช้ PHP เวอร์ชันที่ยังได้รับการสนับสนุน และอัปเดต WordPress ธีม และปลั๊กอิน
3. ตรวจปลั๊กอินจากสิ่งที่มันโหลด ไม่ใช่จากจำนวน
4. ใช้แคชหน้าเพียงตัวเดียว เพิ่ม object cache สำหรับร้านค้า และอย่าซ้อนปลั๊กอินปรับแต่งหลายตัว
5. ให้ WordPress core จัดการรูปภาพ และการโหลดล่วงหน้า
6. ปรับแต่ง page builder และธีม และล้างฐานข้อมูล
7. แยกจัดการ WooCommerce เพราะหน้าตะกร้า หน้าชำระเงิน และหน้าบัญชี แคชทั้งหน้าไม่ได้

ทำครบเจ็ดข้อแล้วยังช้า? ธีมหรือ page builder น่าจะเป็นเพดานแล้ว

ขั้นที่ 1: ทำงานบนสำเนา staging พร้อมค่าพื้นฐาน

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

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

บทความ อธิบาย Core Web Vitals อธิบายเกณฑ์ “ดี” ของ Google ไว้ staging มักไม่มีแคช หรือ CDN แบบเว็บจริง จึงควรเทียบผลในสภาพแวดล้อมเดียวกันเสมอ

ขั้นที่ 2: อัปเดต PHP WordPress และส่วนอื่นทั้งหมด

ทุกหน้าที่ไม่ได้เสิร์ฟจากแคช ถูกสร้างโดย PHP และเวอร์ชันใหม่ โดยทั่วไปเร็วกว่า และยังได้รับแพตช์ความปลอดภัย ณ เวลาที่เขียน (กรกฎาคม 2026) php.net ระบุว่า ทุกเวอร์ชันที่เก่ากว่า PHP 8.2 หมดอายุการสนับสนุนแล้ว และ 8.2 เอง จะได้รับแพตช์ความปลอดภัย ถึงวันที่ 31 ธันวาคม 2026 เท่านั้น WordPress.org แนะนำ PHP 8.3 ขึ้นไป ถ้าคุณใช้ 8.2 หรือเก่ากว่า ให้วางแผนย้ายตั้งแต่ตอนนี้

ลองตรวจเอง เมนู Tools → Site Health → Info → Server แสดงเวอร์ชัน PHP ของคุณ และแผงควบคุมโฮสติ้งส่วนใหญ่ ให้เปลี่ยนเวอร์ชันแยกทีละเว็บได้

ทำอย่างปลอดภัย เปลี่ยนบน staging ก่อน คลิกไล่หน้าสำคัญ ส่งแบบฟอร์มทุกตัว และลองสั่งซื้อทดสอบ ถ้าคุณขายออนไลน์ ปลั๊กอินที่พัง และไม่ได้อัปเดตมาหลายปี ควรเอาออก ขอให้โฮสต์ยืนยันว่า เปิด OPcache ไว้ ซึ่งเก็บ PHP ที่คอมไพล์แล้วไว้ในหน่วยความจำ

จากนั้นอัปเดต core ธีม และปลั๊กอิน บน staging ก่อน ธีมที่ถูกแก้โค้ดโดยตรง จนไม่มีใครกล้าอัปเดต ต้องแก้ปัญหานี้ก่อน บทความ แนวปฏิบัติที่ดีของ WordPress อธิบายเรื่อง child theme ไว้

ขั้นที่ 3: ตรวจปลั๊กอินจากสิ่งที่โหลด ไม่ใช่จำนวน

“ปลั๊กอินเยอะเกินไป” เป็นคำแนะนำยอดนิยม เรื่องการเพิ่มความเร็ว WordPress แต่ปลั๊กอิน SEO ที่อัดแน่นด้วยฟีเจอร์ อาจทำให้ผู้เข้าชมเสียเวลาน้อยกว่าสไลเดอร์ตัวเดียว สิ่งที่สำคัญคือ ปลั๊กอินแต่ละตัวทำอะไร ในแต่ละคำขอ:

ลองตรวจเอง ออกจากระบบ เปิดหน้าสำคัญ พิมพ์ /plugins/ ในช่องกรองของแผง Network ใน DevTools แล้วรีโหลด path ของแต่ละไฟล์ จะบอกชื่อปลั๊กอิน ทำซ้ำกับหน้าที่ไม่ได้ใช้ฟีเจอร์นั้น ถ้าเจอไฟล์ของแบบฟอร์มในหน้าบทความบล็อก นั่นคือตัวที่ควรจำกัด

สำหรับปลั๊กอินแต่ละตัว:

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

ขั้นที่ 4: ตั้งค่าแคชครั้งเดียว ในชั้นที่ถูกต้อง

แคชมักเป็นการปรับอย่างเดียวที่ได้ผลมากที่สุด บนเว็บไซต์ WordPress และเป็นต้นเหตุทั่วไป ของบั๊กที่ก่อขึ้นเอง บทความ แคชเว็บไซต์และ CDN คืออะไร อธิบายทุกชั้นไว้ แต่ในที่นี้ มีสองชั้นที่สำคัญที่สุด:

• แคชหน้า (page caching) เก็บ HTML ที่สร้างเสร็จแล้ว เพื่อไม่ต้องสร้างหน้าใหม่ ให้ผู้เข้าชมทุกคน ใช้แคชหน้าเพียงตัวเดียว จะเป็นของโฮสต์หรือของปลั๊กอินก็ได้ เว้นแต่โฮสต์บอกว่า ทั้งสองออกแบบมาให้ทำงานร่วมกัน
• Object caching (Redis หรือ Memcached) เก็บผลลัพธ์จากฐานข้อมูลไว้ในหน่วยความจำ ช่วยส่วนที่แคชทั้งหน้าไม่ได้ ได้แก่ หน้าแดชบอร์ด ผู้ใช้ที่ล็อกอิน ตะกร้าสินค้า และหน้าชำระเงิน

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

อย่าซ้อนปลั๊กอินปรับแต่ง

ปลั๊กอินแคชมักพ่วงของแถม เช่น การ minify การรวมไฟล์ การลบ CSS ที่ไม่ได้ใช้ lazy loading และการหน่วง JavaScript ถ้าใช้สองตัว หรือใช้ตัวเดียวคู่กับเครื่องมือของโฮสต์ และการตั้งค่าของ page builder ไฟล์จะถูกประมวลผลสองรอบ เลย์เอาต์พังเฉพาะผู้เข้าชมที่ไม่ได้ล็อกอิน และแบบฟอร์มล้มเหลวแบบเงียบ ๆ

ทดสอบตัวที่เสี่ยงที่สุด ทีละตัว:

• หน่วง JavaScript ไว้จนกว่าจะมีการโต้ตอบ อาจทำให้คะแนนแล็บดูดี แต่สคริปต์จะไปโหลดตอนแตะครั้งแรก ทำให้การแตะนั้นช้า และบางครั้งทำให้เมนู แบนเนอร์คุกกี้ และระบบวิเคราะห์ข้อมูลพัง
• ลบ CSS ที่ไม่ได้ใช้ อาจตัดสไตล์ของเมนู ป๊อปอัป และแท็บ ที่แสดงหลังคลิกเท่านั้น
• รวมไฟล์ ช่วยได้น้อยกว่าเดิมมาก บน HTTP/2 และ HTTP/3

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

ขั้นที่ 5: ให้ core จัดการรูปภาพและการโหลดล่วงหน้า

รูปภาพ

สำหรับรูปในคลังสื่อ WordPress สร้างหลายขนาด พร้อม srcset เพื่อให้มือถือดาวน์โหลดไฟล์ที่เล็กกว่า กำหนดความกว้างและความสูง ตั้ง lazy-load ให้รูปที่อยู่ต่ำลงไปในหน้า และโดยค่าเริ่มต้น จะย่อรูปที่ใหญ่กว่า 2,560 พิกเซล ลงมาเหลือขนาดนั้น ตั้งแต่เวอร์ชัน 6.3 ยังเพิ่ม fetchpriority="high" ให้รูปที่มันประเมินว่า น่าจะเป็นองค์ประกอบ LCP มีสามอย่าง ที่มักทำให้สิ่งนี้เสียเปล่า:

• ภาพ hero ที่ตั้งเป็นพื้นหลัง CSS ซึ่งเป็นนิสัยของ page builder เบราว์เซอร์จะเจอรูปช้า และการจัดการของ WordPress ใช้ไม่ได้ ใช้รูปภาพธรรมดา ถ้าทำได้
• ปลั๊กอิน lazy-load ตัวที่สอง ซึ่งอาจตั้ง lazy-load ให้รูปหลัก และทำให้ LCP ช้าลง
• เทมเพลตที่เรียกรูปขนาดเต็ม รูปขนาด 2,560 พิกเซล จึงถูกใช้ในการ์ดขนาด 400 พิกเซล

บทความ การปรับแต่งภาพสำหรับเว็บไซต์ อธิบายเรื่องฟอร์แมต ขนาด และการอัปโหลด

การโหลดล่วงหน้า (speculative loading)

ตั้งแต่ WordPress 6.8 core เพิ่ม speculation rules ที่ให้เบราว์เซอร์ที่รองรับ เริ่มดึงหน้าถัดไป ตอนที่ผู้เข้าชมกดลงบนลิงก์ เบราว์เซอร์ที่ใช้ Chromium เช่น Chrome และ Edge จะทำตาม ส่วนเบราว์เซอร์อื่นแค่เพิกเฉย จึงไม่มีอะไรพัง ฟีเจอร์นี้ทำงานเฉพาะกับผู้เข้าชมที่ไม่ได้ล็อกอิน บนเว็บไซต์ที่ใช้ permalink แบบอ่านง่าย (pretty permalinks) และข้าม URL ที่มี query string ทำให้ไม่ไปยุ่งกับลิงก์เพิ่มสินค้าลงตะกร้า

ลองตรวจเอง ออกจากระบบ ดู source ของหน้า แล้วค้นหา speculationrules ไม่เจอ? ตรวจว่า Settings → Permalinks ไม่ได้ตั้งเป็น “Plain” ถ้าปลั๊กอินปรับแต่งก็ prefetch ลิงก์ด้วย ให้ใช้ระบบเดียว ไม่ใช่สองระบบ

ขั้นที่ 6: ปรับ page builder ธีม และฐานข้อมูล

การตั้งค่า page builder และธีม

ทั้ง Elementor และ Breakdance มีการตั้งค่าด้านประสิทธิภาพ ณ เวลาที่เขียน:

• แท็บ Performance ของ Elementor มีการโหลดรูปภาพแบบปรับแต่งแล้ว การโหลด Google Fonts จากเซิร์ฟเวอร์ของคุณเอง และการแคชองค์ประกอบ
• แท็บ Performance ของ Breakdance หยุดไม่ให้ WordPress โหลดสไตล์ของ block editor สคริปต์อีโมจิ และ Dashicons สำหรับผู้เข้าชมที่ไม่ได้ล็อกอินได้ ตัดสไตล์ของบล็อก เฉพาะเมื่อไม่มีคอนเทนต์ไหนใช้บล็อก ซึ่งบทความบล็อกมักใช้

วิธีสร้างหน้า ก็สำคัญพอกัน section ที่ซ้อนกันหลายชั้น ทำให้โครงสร้างหน้า (DOM) บวม มือถือต้องทำงานหนักขึ้น ทั้งตอนจัดเลย์เอาต์ และทุกครั้งที่แตะ ใน Elementor คอนเทนเนอร์แบบ flexbox โดยทั่วไปสร้าง markup น้อยกว่า section และ column แบบเก่า

ธีมอเนกประสงค์ มักพ่วงสไลเดอร์ ฟอนต์ไอคอน และ Google Fonts หลายน้ำหนักมาด้วย ปิดโมดูลที่ไม่ได้ใช้ และใช้ฟอนต์ไม่เกินสองตระกูล ตระกูลละสองถึงสามน้ำหนัก

ล้างฐานข้อมูลอย่างระมัดระวัง

การใช้งานหลายปี ทิ้ง revision, transient ที่หมดอายุ สแปม และการตั้งค่าของปลั๊กอินที่ลบไปแล้ว ไว้เต็มไปหมด ตัวที่สำคัญที่สุด คือ option แบบ autoload เพราะ WordPress โหลดมันทุกครั้ง ที่มีคำขอที่ไม่ได้แคช ตั้งแต่เวอร์ชัน 6.6 Site Health จะเตือน เมื่อขนาดรวมเกิน 800 KB สำรองข้อมูลก่อน แล้ว:

• จำกัดจำนวน revision ใน wp-config.php แทนการลบประวัติ ที่คนแก้ไขคอนเทนต์ต้องใช้
• ล้าง transient ที่หมดอายุ สแปม และรายการในถังขยะ
• ลบ option แบบ autoload ที่ตกค้าง เฉพาะเมื่อรู้ว่าปลั๊กอินไหนสร้างไว้
• ตรวจ Tools → Scheduled Actions ซึ่ง WooCommerce และปลั๊กอินหลายตัวใช้ ว่ามี action เก่ากองอยู่หรือไม่

WooCommerce: ทำไมร้านค้าจึงรักษาความเร็วยากกว่า

เว็บไซต์แนะนำธุรกิจ เสิร์ฟหน้าที่แคชไว้ ให้ผู้เข้าชมเกือบทุกคนได้ แต่ร้านค้าทำไม่ได้ ความเร็วของ WooCommerce จึงต้องมีแผนของตัวเอง ควบคู่กับการตัดสินใจด้านการออกแบบ ใน การออกแบบเว็บไซต์อีคอมเมิร์ซ

หน้าตะกร้า หน้าชำระเงิน และหน้า My Account แคชทั้งหน้าไม่ได้ เพราะแต่ละหน้า แสดงข้อมูลของคนคนเดียว ความเร็วของหน้าเหล่านี้ จึงขึ้นกับ PHP ฐานข้อมูล object caching และโฮสติ้ง ขั้นที่ 2 และ 4 จึงคุ้มค่าที่สุดตรงนี้

ส่วนที่ปรับตามแต่ละคน ทำให้แคชที่อื่นอ่อนลง ตั้งแต่เวอร์ชัน 7.8 WooCommerce โหลดสคริปต์ cart fragments เฉพาะหน้าที่มีวิดเจ็ต mini-cart แต่ธีมจำนวนมาก ใส่ mini-cart ไว้ในส่วนหัวของทุกหน้า ซึ่งอาจเพิ่มคำขอเบื้องหลังที่ไม่ได้แคช ให้ทุกการเปิดหน้า ตัวเลือก “Geolocate” แบบที่รองรับ page caching จะ redirect ผู้เข้าชมใหม่ ไปยัง URL ที่มี v= ต่อท้าย ทำให้แคชแตกออกเป็นหลายชุด ถ้าราคาและภาษี ไม่ได้ต่างกันตามพื้นที่ การตั้งตำแหน่งลูกค้าเริ่มต้นแบบตายตัว จะเลี่ยงปัญหานี้ได้

แกลเลอรีสินค้าหนัก ทั้งสคริปต์ซูม lightbox และสไลเดอร์ บวกรูปใหญ่หลายรูป ปรับขนาดรูปให้พอดีกับพื้นที่ lazy-load ทุกรูปยกเว้นรูปแรก และใช้ระบบแกลเลอรีระบบเดียว ไม่ใช่สองระบบ

ตัวกรองสร้าง query ที่ช้า และ URL ไม่รู้จบ ตัวกรองคุณสมบัติ ราคา และสต็อกที่ใช้ร่วมกัน รัน query ฐานข้อมูลที่หนัก และทุกการผสม คือ URL ใหม่ที่แทบไม่ถูกแคช ซึ่งบอตของเสิร์ชเอนจินเดินวนได้ไม่รู้จบ เสนอเฉพาะตัวกรองที่ผู้ซื้อใช้จริง

แอปร้านค้าเพิ่มสคริปต์ วิดเจ็ตรีวิว ป๊อปอัปชวนซื้อเพิ่ม และ pixel มักโหลดทุกหน้า ถามตัวเองว่า แต่ละตัวสร้างยอดขายคุ้มกับน้ำหนักไหม บทความ สคริปต์ภายนอกกับความเร็วเว็บไซต์ อธิบายวิธีตรวจไว้

เมื่อธีมหรือ page builder คือเพดานจริง

page builder ไม่ใช่ตัวร้าย ตัวที่ตั้งค่าด้วย global style และการตั้งค่าที่สมเหตุสมผล เร็วได้ เว็บไซต์ผู้พัฒนาอสังหาริมทรัพย์ ที่เราสร้างใหม่ ใช้ Breakdance และเวลาโหลดลดจากเก้าวินาที เหลือสองวินาที แต่ page builder ส่ง markup, CSS และ JavaScript มากกว่าธีมที่เขียนเองแบบกระชับ และแพ็กเสริมทุกตัว ก็เพิ่มเข้าไปอีก

คุณน่าจะชนเพดานแล้ว เมื่อ:

• TTFB ของหน้าที่ไม่ได้แคช ยังช้าบนโฮสติ้งที่ดี ทั้งที่เปิด object caching และตัดปลั๊กอินแล้ว
• PageSpeed Insights ยังเตือนเรื่อง DOM ที่ใหญ่มาก หรือ CSS และ JavaScript ที่ไม่ได้ใช้ จากธีมหรือ page builder
• ความเร็วที่ได้มา หายไปภายในไม่กี่เดือน เมื่อคนแก้ไขคอนเทนต์ เพิ่มหน้าด้วยวิธีเดิม

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

ขั้นต่อไป

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

อยากรู้ว่าเว็บไซต์ของคุณเสียเวลาไปตรงไหน ก่อนที่ใครจะแตะมัน? ขอ ตรวจสอบเว็บไซต์ฟรี โดยบอกชื่อธีม หรือ page builder ที่ใช้ และบอกว่าคุณใช้ WooCommerce หรือไม่