ปรับความเร็วเว็บ WordPress เคสจริง 4 เว็บ ทำยังไงให้ PageSpeed 90+

ปรับความเร็วเว็บ WordPress ให้ PageSpeed มือถือได้ 90+ ไม่ได้มาจากการลงปลั๊กอินแคชตัวเดียว จาก 3 เว็บลูกค้าที่ผมเพิ่งปรับเสร็จในเดือนตุลาคม 2026 คะแนนมือถือขึ้นจาก 58, 69 และ 70 เป็น 96, 95 และ 93 ทั้งที่ทุกเว็บมี LiteSpeed Cache ติดตั้งอยู่แล้วตั้งแต่ก่อนเริ่มงาน ส่วน ehowme.com ซึ่งเป็นเว็บของเราเองได้ 99 บนมือถือ และ 100 บนคอม

บทความนี้เล่าตรงๆ ว่าแต่ละเว็บช้าเพราะอะไร แก้อะไรไปบ้าง และมีจุดไหนที่แก้แล้วพังจนต้องย้อนกลับไปแก้ใหม่ ตัวเลขทุกตัววัดด้วย Google PageSpeed Insights โหมดมือถือ และมีลิงก์ผลจริงให้กดดูเองได้ทุกเว็บ

สรุปสั้นๆ ก่อนอ่าน

• ต้นเหตุที่เจอซ้ำทุกเว็บคือ JavaScript ที่โหลดก่อนเนื้อหา และไฟล์ที่แย่งกันโหลดตอนเปิดหน้า ไม่ใช่โฮสติ้งช้า
• ขั้นที่ดันคะแนนข้าม 90 คือการหน่วง JavaScript ให้โหลดตอนผู้ใช้แตะหรือเลื่อนจอครั้งแรก แต่ต้องเช็คทุกครั้งว่าไม่มีอะไรพัง เพราะ WooCommerce พังให้เห็นมาแล้ว
• AVIF ไม่ได้เล็กกว่า WebP เสมอ รูปถ่ายบางรูปเป็น AVIF แล้วใหญ่กว่าเกือบเท่าตัว
• เว็บที่สร้างให้เบาตั้งแต่แรกอย่าง ehowme.com ได้ 99 โดยแทบไม่ต้องใช้ทริกพวกนี้เลย

ผลก่อนและหลังปรับของทั้ง 4 เว็บ

ตารางนี้คือคะแนน Performance ฝั่งมือถือ ซึ่งทำให้ได้คะแนนสูงยากกว่าฝั่งคอมมาก เพราะ PageSpeed จำลองมือถือรุ่นกลางๆ กับเน็ต 4G ที่ค่อนข้างช้า ถ้ายังไม่คุ้นกับหน้าผลลัพธ์ อ่านวิธีดูคะแนนได้ในบทความ Page Speed คืออะไร ก่อน

คะแนน “ก่อน” วัดจากลิงก์แบบมี www ตอนเริ่มงาน ส่วนคะแนน “หลัง” เป็นรอบสุดท้ายหลังเคลียร์แคชแล้ว คะแนนมือถือแกว่งได้ราว ±5 ในแต่ละรอบ ถ้าเปิดลิงก์แล้วเจอเลขต่างจากตารางนิดหน่อยถือว่าปกติ

ehowme.com ได้ 99 เพราะไม่ได้แบกของหนักไว้ตั้งแต่แรก

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

ผลล่าสุดของ ehowme.com ได้ 99 บนมือถือ LCP 1.9 วินาที, TBT 0 มิลลิวินาที และ CLS 0 ส่วนบนคอมได้ 100 ทั้งที่ LiteSpeed Cache ตั้งไว้แค่ไม่กี่อย่าง ยังไม่ได้เปิด Unique CSS หรือ lazy load ของปลั๊กอินด้วยซ้ำ สิ่งที่ทำให้เว็บเบาคือโครงสร้างของเว็บเอง

• สร้างด้วย Elementor V4 แบบ atomic ซึ่งเขียน HTML และ CSS ออกมาน้อยกว่า widget แบบเก่ามาก
• เปิดใช้ปลั๊กอิน 15 ตัว ไม่มีสไลเดอร์ ป๊อปอัป หรือ page builder ซ้อนกันหลายตัว แนวคิดการเลือกปลั๊กอินอยู่ในบทความ ปลั๊กอิน WordPress ที่ควรมี
• ฟอนต์ไทยโฮสต์ไว้ในเว็บเอง และแยกไฟล์ด้วย unicode-range ให้โหลดเฉพาะชุดอักษรที่ใช้จริง เรื่องนี้เขียนละเอียดไว้ในบทความฟอนต์ไทยฟรีที่ใช้เชิงพาณิชย์ได้
• รูปทุกรูปแปลงเป็น AVIF/WebP อัตโนมัติด้วยปลั๊กอินที่เราพัฒนาเอง และคุมขนาดรูปในบทความไม่ให้เกิน 250 KB ตั้งแต่ตอนอัปโหลด
• LiteSpeed Cache เปิดแค่ย่อไฟล์ CSS, JS, HTML กับ defer JavaScript

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

แต่เว็บลูกค้าส่วนใหญ่ไม่ได้เริ่มจากศูนย์ มีธีม ปลั๊กอิน โฆษณา และระบบขายของที่ใช้งานจริงอยู่แล้ว 3 เคสข้างล่างคือการแก้ในสภาพแบบนั้น

เคสที่ 1 blackstreetstore.com บล็อกท่องเที่ยวที่โฆษณากินเวลาโหลด

เว็บรีวิวที่เที่ยวและร้านอาหาร ใช้ธีม Flatsome และมีโฆษณา AdSense แทรกในหน้า ตอนเริ่มงานได้ 58 บนมือถือ First Contentful Paint 6.9 วินาที และ LCP 12.7 วินาที แปลว่าคนเปิดจากมือถือจะเห็นหน้าขาวนานเกือบ 7 วินาทีก่อนมีอะไรขึ้นมา

สิ่งที่เจอ

• jQuery ถูกตั้งไว้ไม่ให้ defer เลยบล็อกการแสดงผลราว 1.3 วินาที
• สคริปต์โฆษณาโหลด 322 KB และใช้ CPU ราว 0.6 วินาทีตั้งแต่เปิดหน้า
• รูปบทความแนะนำ 6 รูปถูกตั้งให้โหลดด่วน (fetchpriority=”high”) พร้อมกันหมด ทั้งที่บนมือถือเห็นแค่รูปแรก
• ฟอนต์ไทยไม่ได้ตั้ง font-display: swap ตัวหนังสือเลยต้องรอฟอนต์โหลดเสร็จก่อนถึงจะขึ้น

สิ่งที่แก้

1. เอา jQuery ออกจากรายการยกเว้น ให้โหลดแบบ defer พร้อมสคริปต์อื่น
2. ให้สคริปต์ AdSense โหลดตอนผู้ใช้เลื่อนหรือแตะจอครั้งแรก
3. เหลือ priority สูงไว้ให้รูปแรกรูปเดียว รูปที่เหลือเปลี่ยนเป็น lazy load
4. เปิด font-display: swap และ preload ไฟล์ฟอนต์ไทยที่ใช้ด้านบนหน้า
5. หน่วง JavaScript ทั้งหมดให้โหลดหลังผู้ใช้เริ่มใช้งานหน้า

ผลรอบสุดท้าย มือถือ 96 คอม 99 ข้อแลกเปลี่ยนที่ต้องคุยกับเจ้าของเว็บก่อนคือโฆษณาจะขึ้นช้ากว่าเดิมเล็กน้อย สำหรับบล็อกที่หารายได้จากโฆษณา เรื่องนี้ต้องตัดสินใจร่วมกัน ไม่ใช่แก้เงียบๆ เพื่อเอาคะแนนอย่างเดียว

เคสที่ 2 yourpetthai.com ร้าน WooCommerce ที่มีปลั๊กอินแคชแต่ไม่ได้ใช้

ร้านขายสุนัขสองภาษา ใช้ Elementor, WooCommerce และ Polylang เริ่มที่ 69 จุดที่น่าสนใจคือมี LiteSpeed Cache ติดตั้งอยู่แล้ว แต่ฟีเจอร์ปรับแต่งหน้าเว็บแทบทุกตัวยังปิดอยู่ ทั้งการย่อไฟล์ lazy load และการจัดการ JavaScript ถ้าถามว่า “ลงปลั๊กอินแคชหรือยัง” คำตอบคือลงแล้ว แต่มันแทบไม่ได้ทำอะไรให้

สิ่งที่เจอ

• ไฟล์ CSS 3 ไฟล์บล็อกการแสดงผล ไฟล์ใหญ่สุด 69 KB เสียเวลาราว 1.9 วินาที
• Google Fonts โหลดจากเซิร์ฟเวอร์ภายนอกรวม 136 KB
• ข้อความที่เป็น LCP ขึ้นช้าเพราะต้องรอทั้ง CSS และฟอนต์

สิ่งที่แก้

1. เปิดย่อและรวมไฟล์ CSS/JS แล้วสร้าง Unique CSS ผ่าน QUIC.cloud ให้แต่ละหน้าโหลดเฉพาะ CSS ที่ใช้จริง
2. ตั้ง Elementor ให้โหลด Google Fonts จากเซิร์ฟเวอร์ของเว็บเอง
3. เปิด lazy load พร้อม placeholder ที่รู้ขนาดรูป เพราะตอนแรกเปิด lazy load เฉยๆ แล้ว CLS ขึ้นไป 0.09 พอเปลี่ยนเป็น placeholder ที่ถูกขนาด CLS ลงมาเหลือ 0.008
4. หน่วง JavaScript ให้โหลดหลังผู้ใช้เริ่มใช้งาน

จุดที่แก้แล้วพัง

หลังเปิดหน่วง JavaScript คะแนนขึ้นเป็น 95 ทันที แต่ console ขึ้น error ว่า “jQuery is not defined” สาเหตุคือสคริปต์ของ WooCommerce ถูก WordPress ติดป้ายให้โหลดแบบ defer มาอยู่แล้ว ปลั๊กอินแคชเลยข้ามไม่หน่วงสคริปต์กลุ่มนี้ มันจึงรันก่อน jQuery ที่ถูกหน่วงไว้ ผลคือปุ่มหยิบใส่ตะกร้าแบบไม่โหลดหน้าใหม่บนหน้าแรกใช้งานไม่ได้

ผมแก้ด้วยการเอาป้าย defer ของ WordPress ออก ให้สคริปต์เหล่านั้นถูกหน่วงตามลำดับเดียวกับ jQuery หลังแก้ console ไม่มี error แล้ว และคะแนนยังอยู่ที่ มือถือ 95 คอม 100

คะแนนเขียวแต่ปุ่มสั่งซื้อพัง แย่กว่าคะแนนส้มที่ขายของได้ ทุกครั้งที่หน่วง JavaScript ต้องเปิด console และลองกดของจริงเสมอ

เคสที่ 3 aiagoodlife.com ข้อความหลักขึ้นช้าเพราะรูปกับฟอนต์แย่งกัน

เว็บตัวแทนประกันชีวิต ใช้ Flatsome เหมือนเคสแรก เริ่มที่ 70 เคสนี้ LCP บนมือถือไม่ใช่รูป แต่เป็นย่อหน้าแนะนำทีมงาน ซึ่งค้างอยู่ราว 1.4 ถึง 2.4 วินาทีหลังโหลด HTML เสร็จแล้ว

สิ่งที่เจอ

• มีรูป 4 รูปตั้งให้โหลดด่วน รวมโลโก้สีเข้มที่ซ่อนอยู่ และโลโก้ AIA บนแถบด้านบนที่ไม่แสดงบนมือถือ
• ไฟล์ฟอนต์ Kanit และ Sarabun ถูกค้นเจอช้า เพราะประกาศไว้ใน CSS อีกชั้นหนึ่ง
• รูปทีมงานหน้าแรกส่งเป็น AVIF ขนาด 178 KB ทั้งที่ WebP ของรูปเดียวกันมีแค่ 96 KB

สิ่งที่แก้

1. เอา priority สูงออกจากโลโก้ ให้รูปหลักกับข้อความได้ใช้แบนด์วิดท์ก่อน
2. preload ไฟล์ฟอนต์ไทย 3 ไฟล์ที่ใช้ด้านบนหน้า
3. ให้ระบบเลือกส่งรูปฟอร์แมตที่เล็กกว่า แทนการส่ง AVIF ทุกครั้ง
4. หน่วง JavaScript ที่ไม่จำเป็นต่อการแสดงผลครั้งแรก

ผลรอบสุดท้าย มือถือ 93 คอม 100

สิ่งที่หลายคนมักพลาดตอนไล่แก้ PageSpeed

ลงปลั๊กอินแคชแล้วคิดว่าจบ

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

เชื่อว่า AVIF เล็กกว่าเสมอ

ในงานนี้ รูปถ่ายขนาด 768px บน blackstreetstore เป็น AVIF 75 KB แต่ WebP แค่ 55 KB ส่วนรูปทีมงานบน aiagoodlife ห่างกันเกือบเท่าตัว กลับกัน กราฟิกสีเรียบ AVIF ชนะ 13 KB ต่อ 23 KB ทางที่ถูกคือให้ระบบเทียบขนาดแล้วส่งไฟล์ที่เล็กกว่า ซึ่งเราอัปเดตปลั๊กอินแปลงรูปของเราให้ทำแบบนี้ระหว่างงานนี้เลย

วัดผิดลิงก์ หรือวัดรอบเดียวแล้วสรุป

ถ้าวัดลิงก์ที่ไม่มี www แต่เว็บจริงอยู่ที่ www, PageSpeed จะนับเวลา redirect รวมไปด้วย คะแนนเลยไม่ตรงกับที่ผู้ใช้เจอจริง ควรวัดลิงก์ที่ใช้งานจริงเสมอ และวัดหลายรอบ เพราะคะแนนมือถือแกว่งได้ราว ±5

หน่วง JavaScript แล้วไม่เช็คว่าอะไรพัง

การหน่วง JavaScript คือขั้นที่ดันคะแนนจากช่วง 75 ถึง 85 ขึ้นไปเกิน 90 ได้ทั้งสามเว็บ แต่ก็เป็นขั้นที่เสี่ยงที่สุด หลังเปิดต้องเช็ค console เมนูมือถือ ฟอร์มติดต่อ และตะกร้าสินค้าทุกครั้ง

ดูแค่คะแนน ไม่ดูข้อมูลจากผู้ใช้จริง

คะแนน PageSpeed เป็นการจำลอง ส่วนที่ Google ใช้ประกอบการจัดอันดับคือ Core Web Vitals จากผู้ใช้จริง ถ้าอยากเข้าใจว่า LCP, INP และ CLS แต่ละตัวแก้ยังไง อ่านต่อได้ที่คู่มือทำเว็บ WordPress ให้ผ่าน Core Web Vitals

แก้เองได้แค่ไหน และเมื่อไหร่ควรให้คนช่วย

ถ้าเว็บเล็กและปลั๊กอินไม่เยอะ การเปิดฟีเจอร์พื้นฐานของปลั๊กอินแคช ย่อรูป และย้ายฟอนต์มาไว้ในเว็บ มักพาคะแนนขึ้นได้อีกหลายสิบคะแนนแล้ว แต่ช่วงจาก 80 ไป 90+ มักต้องไล่ทีละสคริปต์ ทีละรูป และต้องรู้ว่าอะไรจะพังตามมา โดยเฉพาะเว็บที่มีระบบขายของหรือหารายได้จากโฆษณา

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

คำถามที่เจอบ่อย