หาสาเหตุเว็บ WordPress ช้าด้วย Query Monitor

เมื่อเว็บช้า วิธีที่คนส่วนใหญ่ใช้คือปิดปลั๊กอินทีละตัวแล้วลองใหม่ ซึ่งกินเวลาและกระทบผู้ใช้จริง Query Monitor บอกได้ตรง ๆ ว่าเวลาหมดไปกับอะไร ในหน้าไหน และปลั๊กอินตัวใดเป็นเจ้าของ

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

สิ่งที่ต้องเตรียม

• สิทธิ์ผู้ดูแล WordPress
• ควรทดสอบบนเว็บ Staging หากเป็นไปได้ เพราะปลั๊กอินนี้เพิ่มภาระเล็กน้อย

wp plugin install query-monitor --activate

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

ขั้นตอนที่ 1: อ่านตัวเลขสรุปก่อน

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

• Page Generation Time เวลาที่ PHP ใช้สร้างหน้า ควรต่ำกว่า 0.5 วินาที เกิน 1 วินาทีถือว่าช้า
• Database Queries หน้าแรกทั่วไปควรต่ำกว่า 60-80 Query เกิน 200 คือสัญญาณว่ามีปลั๊กอินที่ทำงานหนักผิดปกติ
• Peak Memory Usage ควรต่ำกว่า 128 MB หากใกล้ขีดจำกัดของ PHP จะเริ่มมีข้อผิดพลาดแบบสุ่ม

เปรียบเทียบระหว่างหน้าแรก หน้าบทความ และหน้าหลังบ้าน เพื่อดูว่าปัญหาเกิดทุกหน้าหรือเฉพาะบางหน้า

ขั้นตอนที่ 2: แท็บ Queries หา Query ที่ช้า

คลิกที่หัวคอลัมน์ Time เพื่อเรียงจากช้าที่สุด Query ที่ใช้เวลาเกิน 0.05 วินาทีควรถูกตรวจสอบ

ดูคอลัมน์ Caller ซึ่งบอกว่าฟังก์ชันใดเรียก Query นั้น และมักบอกชื่อปลั๊กอินได้ทันที

ใช้เมนูย่อยสองอันนี้

• Queries by Component จัดกลุ่มตามปลั๊กอินและธีม เห็นภาพรวมทันทีว่าใครใช้ Query มากที่สุด
• Duplicate Queries แสดง Query ที่ถูกเรียกซ้ำหลายครั้งในคำขอเดียว ซึ่งเป็นสัญญาณว่าควรเปิด Object Cache

Query ที่มักเป็นปัญหา

• Query ที่มี meta_query หลายเงื่อนไข ซึ่งสร้าง JOIN กับ wp_postmeta หลายชั้น
• Query ที่ไม่มี LIMIT บนตารางใหญ่
• SELECT option_value FROM wp_options ที่ถูกเรียกหลายร้อยครั้ง แปลว่าไม่ได้ใช้ autoload หรือไม่มี Object Cache

ขั้นตอนที่ 3: แท็บ HTTP API Calls

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

ดูคอลัมน์ Time ของแต่ละรายการ การเรียกที่ใช้เวลาเกิน 1 วินาทีเป็นปัญหาแน่นอน

สาเหตุที่พบบ่อย

• ปลั๊กอินตรวจสอบใบอนุญาตทุกครั้งที่โหลดหน้าหลังบ้าน
• ปลั๊กอินขนส่งเรียก API คำนวณค่าส่งบนหน้าตะกร้า
• ปลั๊กอินที่ตรวจสอบการอัปเดตโดยไม่ใช้แคช

วิธีแก้คือใช้ transient เก็บผลไว้

function my_get_remote_data() {
    $cached = get_transient('my_remote_data');
    if ($cached !== false) return $cached;

    $res = wp_remote_get('https://api.example.com/data', array('timeout' => 5));
    if (is_wp_error($res)) return array();

    $data = json_decode(wp_remote_retrieve_body($res), true);
    set_transient('my_remote_data', $data, HOUR_IN_SECONDS);
    return $data;
}

ใส่ timeout เสมอ ค่าเริ่มต้นของ WordPress คือ 5 วินาที ซึ่งนานเกินไปสำหรับการเรียกที่ไม่จำเป็น

ขั้นตอนที่ 4: แท็บ Hooks & Actions

ดูว่าฟังก์ชันใดผูกกับ hook ไหนบ้าง มีประโยชน์เมื่อสงสัยว่ามีโค้ดทำงานในจังหวะที่ไม่ควร

ใช้ร่วมกับแท็บ Timing ซึ่งแสดงเวลาที่ใช้ในแต่ละช่วง หากเห็นช่วงใดกินเวลาผิดปกติ ให้ไล่ดูว่ามีอะไรผูกกับ hook ในช่วงนั้น

ขั้นตอนที่ 5: แท็บ Scripts และ Styles

นับจำนวนไฟล์ JavaScript และ CSS ที่ถูกโหลด เว็บที่โหลดไฟล์เกิน 40-50 ไฟล์จะช้าแม้ PHP จะเร็ว

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

// ถอดสคริปต์ที่ไม่จำเป็นออกจากหน้าที่ไม่ได้ใช้
add_action('wp_enqueue_scripts', function () {
    if (!is_page('contact')) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
    }
}, 99);

ใส่ลำดับความสำคัญสูง เช่น 99 เพื่อให้ทำงานหลังจากที่ปลั๊กอินลงทะเบียนสคริปต์แล้ว

ขั้นตอนที่ 6: แท็บ PHP Errors

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

เว็บที่มี Notice หลายร้อยรายการต่อหน้าจะช้าลงอย่างรู้สึกได้ และมักหมายถึงปลั๊กอินที่ไม่รองรับ PHP รุ่นที่ใช้อยู่

ขั้นตอนที่ 7: ดูข้อมูลของผู้ใช้ทั่วไป

โดยปกติ Query Monitor แสดงเฉพาะกับผู้ดูแลที่ล็อกอิน แต่ปัญหาบางอย่างเกิดเฉพาะกับผู้ใช้ทั่วไปหรือหน้าที่ถูกแคช

// wp-config.php ตั้งรหัสสำหรับดูข้อมูลโดยไม่ต้องล็อกอิน
define('QM_COOKIE_KEY', 'สตริงสุ่มยาว');

แล้วเข้าหน้า Query Monitor ในหลังบ้านเพื่อรับลิงก์ตั้งคุกกี้ จากนั้นเปิดหน้าเว็บในโหมดไม่ระบุตัวตนก็จะเห็นข้อมูล

ขั้นตอนที่ 8: สรุปและลงมือแก้

เรียงลำดับการแก้ตามผลที่ได้

• ถ้า HTTP API Calls ช้า ⟶ แก้ก่อน เพราะให้ผลมากที่สุดและแก้ง่าย
• ถ้า Query ซ้ำจำนวนมาก ⟶ เปิด Redis Object Cache
• ถ้า Query ช้าไม่กี่ตัว ⟶ เพิ่ม Index ในฐานข้อมูล
• ถ้าปลั๊กอินตัวเดียวกินเวลาส่วนใหญ่ ⟶ พิจารณาหาตัวแทนหรือติดต่อผู้พัฒนา
• ถ้าไฟล์ JavaScript และ CSS เยอะ ⟶ ถอดที่ไม่จำเป็นและรวมไฟล์

วัดผลด้วยตัวเลขเดิมหลังแก้แต่ละอย่าง อย่าแก้หลายอย่างพร้อมกันเพราะจะไม่รู้ว่าอะไรได้ผล

ปัญหาที่พบบ่อย

ไม่เห็นแถบ Query Monitor

ต้องล็อกอินด้วยบัญชีที่มีสิทธิ์ view_query_monitor ซึ่งปกติคือผู้ดูแล และแถบผู้ดูแลต้องไม่ถูกซ่อนโดยธีมหรือปลั๊กอินอื่น

ตัวเลขต่างกันมากในแต่ละครั้งที่โหลด

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

Query Monitor เองทำให้ช้า

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

หน้าเว็บเร็วแต่ผู้ใช้บอกว่าช้า

ปัญหาอาจอยู่ที่ฝั่งเบราว์เซอร์ ไม่ใช่เซิร์ฟเวอร์ ใช้ PageSpeed Insights และแท็บ Network ของเครื่องมือนักพัฒนาในเบราว์เซอร์ประกอบ

ต้องการให้ทีมวิศวกรช่วยวิเคราะห์และแก้ปัญหาเว็บช้า ติดต่อ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/