วิธีทำให้เว็บไซต์เร็วขึ้น: เช็กลิสต์ปฏิบัติ

วิธีทำให้เว็บไซต์เร็วขึ้นคือวัดก่อนด้วย PageSpeed Insights แล้วแก้สาเหตุที่ใหญ่ที่สุดที่มันชี้ ซึ่งมักเป็นรูปภาพขนาดใหญ่เกินไป JavaScript มากเกินไป ฟอนต์หนัก หรือสคริปต์ของบุคคลที่สาม ตั้งเป้าให้ได้ค่า "ดี" ของ Core Web Vitals ของ Google: เนื้อหาหลักแสดงภายใน 2.5 วินาที การตอบสนองต่อการแตะภายใน 200 มิลลิวินาที และแทบไม่มีการกระโดดของเลย์เอาต์ เว็บส่วนใหญ่ไปถึงจุดนั้นได้ด้วยการเปลี่ยนแปลงไม่กี่อย่าง ไม่ต้องเขียนใหม่ทั้งหมด

วัดก่อนเปลี่ยนอะไรทั้งนั้น

การเดาทำให้เสียเวลา เครื่องมือฟรีสองอย่างครอบคลุมเกือบทุกคน:

• PageSpeed Insights (pagespeed.web.dev) วาง URL สดลงไป มันแสดง ข้อมูลภาคสนาม จากผู้ใช้ Chrome จริง (หากเว็บของคุณมีการเข้าชมมากพอ) และ ข้อมูลแล็บ จากการโหลดจำลอง พร้อมรายการปัญหาเฉพาะ
• Lighthouse ใน Chrome DevTools เป็นการทดสอบแล็บแบบเดียวกัน รันบนหน้าใดก็ได้ที่คุณเปิดได้ รวมถึงพรีวิว ทดสอบในโหมดมือถือ เพราะปัญหาจะเห็นได้ชัดบนโทรศัพท์ที่เครือข่ายช้ากว่า

ตัวเลขที่สำคัญคือ Core Web Vitals ของ Google ณ เดือนกันยายน 2026 เอกสารของ Google บน web.dev ให้เกณฑ์ "ดี" เหล่านี้ วัดที่เปอร์เซ็นไทล์ที่ 75 ของการโหลดหน้า:

INP เข้ามาแทนที่ตัวชี้วัด First Input Delay รุ่นเก่าในปี 2024 หากเครื่องมือยังรายงาน FID แสดงว่าล้าสมัยแล้ว

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

เวลาหายไปที่ไหน: ตัวเลือกและข้อแลกเปลี่ยน

สาเหตุที่พบบ่อยแต่ละอย่างมีวิธีแก้ และวิธีแก้แต่ละอย่างมีต้นทุน เริ่มจากรายการด้านบน เพราะถูกที่สุดและพบบ่อยที่สุด

รูปภาพ

รูปภาพเป็นปัญหาที่พบบ่อยที่สุดและแก้ได้ง่ายที่สุด รูปถ่ายขนาด 4,000 พิกเซลที่แสดงกว้าง 800 พิกเซลบังคับให้ผู้เข้าชมทุกคนดาวน์โหลดมากกว่าที่เห็นถึงห้าเท่า

• เสิร์ฟรูปภาพตามขนาดที่แสดง ด้วยขนาด srcset ที่ตอบสนองสำหรับโทรศัพท์และเดสก์ท็อป
• ใช้รูปแบบสมัยใหม่ (WebP หรือ AVIF) และการบีบอัดที่เหมาะสม
• ตั้ง width และ height ให้ทุกรูปเพื่อให้เบราว์เซอร์สงวนพื้นที่ ซึ่งเพียงอย่างเดียวแก้การเลื่อนของเลย์เอาต์ได้ส่วนใหญ่
• lazy-load รูปที่อยู่ใต้จุดพับด้วย loading="lazy"
• อย่า lazy-load รูปหลักที่ด้านบนของหน้า แนวทาง LCP ของ Google พูดชัดเจนว่าการ lazy-load รูป LCP ทำให้มันช้าลงเสมอ ให้ fetchpriority="high" แทน

JavaScript

เว็บที่สร้างด้วย AI หลายแห่งเป็นแอปหน้าเดียว (SPA): เบราว์เซอร์ดาวน์โหลดบันเดิล JavaScript แล้วจึงวาดหน้า ยิ่งบันเดิลใหญ่ หน้าจอว่างยิ่งนาน การแก้ไข เรียงตามความพยายาม:

1. ลบสิ่งที่ไม่ได้ใช้ ขอรายการ dependency และตัดไลบรารีที่เพิ่มครั้งเดียวแล้วถูกลืม เช่น ไลบรารีวันที่สำหรับวันเดียว หรือชุดไอคอนเต็มสำหรับไอคอนห้าตัว
2. แยกตามเส้นทาง โหลดโค้ดของแดชบอร์ดผู้ดูแลเฉพาะเมื่อมีคนเปิด ไม่ใช่ในหน้าแรก
3. Prerender หน้าสาธารณะ หน้าการตลาดที่ส่งมาเป็น HTML จริงจะปรากฏก่อนที่ JavaScript ใดจะทำงาน สิ่งนี้ยังช่วยเครื่องมือค้นหาด้วย ดู SEO สำหรับเว็บไซต์ที่สร้างด้วย AI

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

ฟอนต์

ฟอนต์แต่ละตระกูลและน้ำหนักคือไฟล์อีกไฟล์หนึ่ง สองตระกูลและสามถึงสี่น้ำหนักมักเพียงพอ preload ฟอนต์ที่ใช้เหนือจุดพับ ใช้ font-display: swap เพื่อให้ข้อความแสดงทันที และโฮสต์ฟอนต์เองหากบริการฟอนต์ภายนอกช้าสำหรับผู้เข้าชมของคุณ

สคริปต์ของบุคคลที่สาม

วิดเจ็ตแชต การวิเคราะห์ แผนที่ความร้อน พิกเซลโฆษณา วิดีโอที่ฝังไว้ และฟีดโซเชียลล้วนโหลดโค้ดจากเซิร์ฟเวอร์อื่น แต่ละอย่างดูเล็ก รวมกันมักเป็นส่วนที่ช้าที่สุดของหน้า เก็บเฉพาะที่คุณดูจริงๆ โหลดที่เหลือหลังจากหน้าโต้ตอบได้แล้ว และแทนที่ embed หนัก (เครื่องเล่น YouTube แผนที่) ด้วยตัวอย่างน้ำหนักเบาที่โหลดของจริงเมื่อคลิก

การตอบสนองของเซิร์ฟเวอร์

Time to First Byte (TTFB) คือเวลาที่เซิร์ฟเวอร์ใช้เริ่มตอบ และอยู่ใต้ตัวชี้วัดอื่นทุกตัว หน้าสแตติกที่เสิร์ฟจาก CDN (เครือข่ายเซิร์ฟเวอร์ใกล้ผู้เข้าชม ดู CDN คืออะไร) เร็วเกือบทุกที่ หน้าที่เซิร์ฟเวอร์สร้างทุกครั้งที่มีการร้องขอ ขึ้นอยู่กับเซิร์ฟเวอร์และฐานข้อมูลการแคช งานที่ซ้ำกันและการเพิ่มดัชนีฐานข้อมูลสำหรับคิวรีที่ช้า คือวิธีแก้ที่พบบ่อย

พรอมต์ที่ได้ผล

ระบุให้ชัดเจน: ชื่อหน้า ตัวชี้วัด และข้อจำกัด วางผลการตรวจของ PageSpeed Insights หากคุณมี

PageSpeed Insights รายงาน LCP 4.8 วินาทีบนมือถือสำหรับหน้าแรก และองค์ประกอบ LCP คือรูปฮีโร่ ปรับขนาดและแปลงรูปฮีโร่เป็น WebP เสิร์ฟขนาดที่ตอบสนอง ตั้ง width และ height ให้ fetchpriority="high" และตรวจว่าไม่ได้ lazy-load lazy-load ทุกรูปที่อยู่ใต้จุดพับ อย่าเปลี่ยนดีไซน์

ตรวจ dependency ของแอปนี้ ระบุแต่ละแพ็กเกจ สิ่งที่ใช้มัน และขนาดโดยประมาณที่เพิ่มให้บันเดิล ลบที่ไม่ได้ใช้ และแยกเส้นทาง /admin และ /settings ออกเป็นชิ้นที่โหลดเฉพาะเมื่อเข้าชม

ช่องค้นหาในหน้า /products รู้สึกหน่วง ทำ debounce ให้ตัวกรอง หลีกเลี่ยงการเรนเดอร์รายการทั้งหมดทุกการพิมพ์ และแบ่งหน้าหรือ virtualize รายการหากมีมากกว่า 200 รายการ

ทีละขั้นตอน

1. ทดสอบหน้าสดบน PageSpeed Insights ในโหมดมือถือ จดค่า LCP, INP และ CLS และปัญหาสามอันดับแรกที่ระบุ
2. แก้รูปภาพก่อน: ขนาด รูปแบบ ขนาดมิติ lazy-load ใต้จุดพับ ลำดับความสำคัญสำหรับรูปฮีโร่
3. ตัดสคริปต์ของบุคคลที่สามที่ไม่ได้ใช้ และเลื่อนส่วนที่เหลือ
4. ลดฟอนต์ ให้เหลือเท่าที่ดีไซน์ต้องการ
5. ลด JavaScript: ลบแพ็กเกจที่ไม่ได้ใช้ แยกตามเส้นทาง
6. Prerender หน้าสาธารณะ หากยังเป็นการเรนเดอร์ฝั่งไคลเอนต์และ LCP ยังช้าอยู่
7. ตรวจเซิร์ฟเวอร์: แคช ดัชนีฐานข้อมูล โฮสติ้งแบบสแตติกสำหรับเนื้อหาที่แทบไม่เปลี่ยน
8. เผยแพร่อีกครั้งและทดสอบใหม่ ข้อมูลภาคสนามใน PageSpeed Insights อัปเดตในสัปดาห์ต่อๆ มาเมื่อมีการเข้าชมจริงเข้ามา ดังนั้นให้ตัดสินผลเบื้องต้นจากข้อมูลแล็บ

ข้อผิดพลาดที่พบบ่อย

• ทดสอบเฉพาะบนแล็ปท็อปเร็วๆ ผู้เข้าชมของคุณใช้โทรศัพท์ระดับกลางและอินเทอร์เน็ตมือถือที่ไม่เสถียร ทดสอบในโหมดมือถือ
• ไล่ตามคะแนน 100 แบบสมบูรณ์แบบ คะแนนแล็บเป็นแนวทาง เมื่อ Core Web Vitals อยู่ในช่วงดีแล้ว เนื้อหาและการใช้งานสำคัญกว่าไม่กี่คะแนนสุดท้าย
• lazy-load ทุกอย่าง รวมถึงรูปฮีโร่ ซึ่งทำให้ LCP แย่ลง
• เพิ่มปลั๊กอินหรือไลบรารีเร่งความเร็วทับลงไป การลดน้ำหนักเกือบจะดีกว่าการเพิ่มโค้ดเพื่อจัดการมันเสมอ
• เพิ่มประสิทธิภาพพรีวิวแทนเว็บสด พรีวิวการพัฒนารันบิลด์ที่ไม่ได้ปรับแต่ง วัดที่ URL ที่เผยแพร่แล้ว
• แก้ความเร็วครั้งเดียวแล้วจบ วิดเจ็ต รูป และฟีเจอร์ใหม่ทุกอย่างเพิ่มน้ำหนัก ทดสอบใหม่หลังการเปลี่ยนแปลงใหญ่

เช็กลิสต์ความเร็ว

• LCP ≤ 2.5 วินาที, INP ≤ 200 มิลลิวินาที, CLS ≤ 0.1 บนมือถือ
• รูปภาพปรับขนาด บีบอัด ใช้รูปแบบสมัยใหม่ พร้อม width และ height
• รูปฮีโร่ไม่ถูก lazy-load รูปที่อยู่ใต้จุดพับถูก lazy-load
• ไม่มีไลบรารี JavaScript ที่ไม่ได้ใช้ เส้นทางหนักถูกแยกออก
• ฟอนต์สองตระกูลหรือน้อยกว่า ฟอนต์หลักถูก preload
• มีเฉพาะสคริปต์ของบุคคลที่สามที่คุณใช้จริง โหลดช้า
• หน้าสาธารณะถูก prerender หรือเป็นแบบสแตติกเท่าที่ทำได้
• ทดสอบใหม่บน URL สดหลังเผยแพร่

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

ความเร็วบน Mythex

บน Mythex คุณทำการเปลี่ยนแปลงเหล่านี้โดยขอในแชต หรือในโปรแกรมแก้ไขโค้ดบน Pro เช็ก URL ที่เผยแพร่แล้ว ไม่ใช่พรีวิว เพราะพรีวิวรันเซิร์ฟเวอร์พัฒนา ฟรอนต์เอนด์แบบสแตติกถูก deploy เป็นเว็บไซต์สแตติกเมื่อคุณเผยแพร่ (เว็บไซต์สแตติก) ซึ่งเหมาะกับหน้าเนื้อหา แอปที่มีเซิร์ฟเวอร์จะปรับขนาดเป็นศูนย์: มันหลับเมื่อว่างและตื่นเมื่อมีการเข้าชมถัดไป ดังนั้นคำขอแรกหลังช่วงเงียบจะช้ากว่า และฐานข้อมูลที่แนบอยู่จะหลับหลังว่าง 5 นาที (ข้อจำกัดการโฮสต์) หากหน้าสาธารณะช้าเฉพาะการเข้าชมแรก นั่นคือสาเหตุที่น่าจะเป็น การเก็บหน้าการตลาดให้เป็นแบบสแตติกช่วยได้ หลังการเปลี่ยนแปลง ให้เผยแพร่อีกครั้งและรีเฟรชแบบบังคับ

คำถาม