เพิ่มความเร็วเว็บไซต์: คู่มือใช้งานจริงสำหรับเว็บไซต์ธุรกิจ

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

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

คำตอบสั้น ๆ

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

• วัดจากการเข้าชมจริง Google ให้คะแนนหน้าว่าดี เมื่อ LCP ไม่เกิน 2.5 วินาที INP ไม่เกิน 200 มิลลิวินาที และ CLS ไม่เกิน 0.1 ที่เปอร์เซ็นไทล์ที่ 75 ของการเข้าชม
• แก้จากเซิร์ฟเวอร์ออกไปด้านนอก เริ่มจากการตอบสนองของเซิร์ฟเวอร์และการแคช โค้ดที่บล็อกการเรนเดอร์ รูปภาพและฟอนต์ แล้วจึงสคริปต์ภายนอก
• เริ่มจากสิ่งที่ถูก การปรับขนาดรูปและการแคชหน้า มักมาก่อนการเปลี่ยนโฮสติ้งหรือการสร้างใหม่
• รักษาความเร็วไว้ ด้วยงบประมาณด้านประสิทธิภาพ (performance budget) และการตรวจข้อมูลผู้ใช้จริงทุกเดือน

“เร็ว” หมายถึงอะไร: ตัวเลขสามตัวจากการเข้าชมจริง

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

ช่วงตรงกลางคือ “ต้องปรับปรุง” หน้าจะผ่านเมื่อการเข้าชมอย่างน้อยสามในสี่ครั้ง (เปอร์เซ็นไทล์ที่ 75) ผ่านเกณฑ์แต่ละตัว โดยตัดสินแยกระหว่างมือถือกับเดสก์ท็อป มือถือรุ่นเก่า และอินเทอร์เน็ตมือถือที่สัญญาณไม่ดี ก็ถูกนับด้วย เว็บไซต์ที่รู้สึกว่าเร็วทันใจบน Wi-Fi ในออฟฟิศ จึงยังไม่ผ่านได้

INP เข้ามาแทน First Input Delay หรือ FID ในฐานะ Core Web Vital เมื่อเดือนมีนาคม 2024 บทความ อธิบาย Core Web Vitals ครอบคลุมตัวชี้วัดแต่ละตัว

ข้อมูลภาคสนามกับข้อมูลจากแล็บ

ข้อมูลภาคสนาม (field data) มาจากผู้ใช้ Chrome จริง ผ่าน Chrome UX Report หรือ CrUX ครอบคลุม 28 วันที่ผ่านมา ทั้งผลประเมิน Core Web Vitals ใน PageSpeed Insights และรายงาน Core Web Vitals ใน Search Console ใช้ข้อมูลนี้ หน้าที่มีทราฟฟิกน้อยอาจไม่มีข้อมูลของตัวเอง PageSpeed Insights จะแสดงตัวเลขของทั้งเว็บไซต์แทน หรือไม่แสดงอะไรเลย

ข้อมูลจากแล็บ (lab data) มาจาก Lighthouse คือการโหลดจำลองหนึ่งครั้ง บนมือถือระดับกลางที่จำลองขึ้น และการเชื่อมต่อที่ถูกจำกัดความเร็ว สำหรับการทดสอบบนมือถือ มันไม่ใช่สิ่งที่ผู้เข้าชมเจอจริง แต่ทำซ้ำได้ จึงเหมาะกับการวินิจฉัยปัญหาและทดสอบวิธีแก้ คะแนน 0–100 เป็นแค่บทสรุปจากแล็บ ไม่ใช่คำตัดสิน บทความ วิธีอ่านรายงาน PageSpeed Insights อธิบายว่าควรลงมือกับอะไร

ทำไมความเร็วคุ้มที่จะลงแรง และขีดจำกัดของมัน

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

สำหรับการค้นหา Google บอกว่า Core Web Vitals ถูกใช้โดยระบบจัดอันดับของ Google แม้ความเกี่ยวข้องจะยังมาก่อน

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

ความเร็วได้หรือเสียตรงไหน: จากเซิร์ฟเวอร์ออกไปด้านนอก

การโหลดหน้าเป็นห่วงโซ่ เซิร์ฟเวอร์ตอบกลับ เบราว์เซอร์อ่าน HTML ค้นพบ CSS ฟอนต์ รูปภาพ และสคริปต์ แล้ววาดหน้า ความล่าช้าช่วงต้น จะดันทุกอย่างหลังจากนั้นให้ช้าตาม จึงควรวินิจฉัยตามลำดับนั้น บทความ ทำไมเว็บไซต์ช้า? ไล่ให้ดูทีละขั้น

1. โฮสติ้งและการตอบสนองของเซิร์ฟเวอร์

shared hosting ที่แออัด PHP เวอร์ชันเก่า การ query ฐานข้อมูลที่ช้า และเซิร์ฟเวอร์ที่อยู่ไกลจากผู้เข้าชม ล้วนแสดงออกมาเป็นเวลาจนได้รับไบต์แรก (TTFB) ที่ยาว เป็นแนวทางคร่าว ๆ web.dev แนะนำว่าไม่ควรเกิน 0.8 วินาที TTFB ไม่ใช่ Core Web Vital แต่ถ้ามันช้า การได้ LCP ที่ดีจะยากมาก

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

2. การแคช การบีบอัด และ CDN

• การแคชหน้า ส่งสำเนาของหน้าที่เก็บไว้ แทนการสร้างใหม่ให้ผู้เข้าชมทุกคน โดยยกเว้นตะกร้าสินค้าและส่วนที่ต้องล็อกอิน และล้างแคชเมื่อเนื้อหาเปลี่ยน
• การแคชในเบราว์เซอร์ ให้ผู้เข้าชมที่กลับมาใช้รูป CSS และสคริปต์ซ้ำได้
• การบีบอัด (Brotli หรือ gzip) ย่อขนาด HTML, CSS และ JavaScript ระหว่างส่ง
• เครือข่ายส่งเนื้อหา (CDN) ส่งไฟล์จากจุดที่อยู่ใกล้ผู้เข้าชมแต่ละคน ซึ่งสำคัญที่สุด เมื่อลูกค้าอยู่ในหลายประเทศ

บทความ อธิบายการแคชเว็บไซต์และ CDN ครอบคลุมว่าเมื่อไรคุณต้องใช้แต่ละชั้น

3. HTML, CSS และ JavaScript

เบราว์เซอร์จะรอการแสดงผลครั้งแรก จนกว่าสไตล์ชีตในส่วน head จะมาถึง และสคริปต์ที่อยู่ตรงนั้นโดยไม่มี defer หรือ async จะหยุดการอ่าน HTML จนกว่าจะดาวน์โหลดและรันเสร็จ ธีมที่หนักและส่วนเสริมของ page builder มักโหลดทุกอย่างในทุกหน้า

JavaScript เป็นตัวกำหนด INP เป็นส่วนใหญ่ การแตะถูกจัดการบน main thread ของเบราว์เซอร์ และงานใดที่ยาวเกิน 50 มิลลิวินาที (web.dev เรียกว่า “long task”) อาจทำให้การแตะต้องรอ ให้ defer สิ่งที่หน้าจอแรกไม่ต้องใช้ โหลดฟีเจอร์เฉพาะในที่ที่ใช้ และแบ่งงานที่ยาวออกเป็นช่วง ๆ บทความ อธิบาย render-blocking resources แสดงวิธีหาตัวการ

4. รูปภาพและฟอนต์

ในหน้าธุรกิจจำนวนมาก อิลิเมนต์ LCP คือรูปภาพ ซึ่งมักเป็นรูป hero หรือสไลด์ของ carousel รูปภาพจึงมักเป็นทั้งปัญหาของ LCP และวิธีแก้ที่ถูกที่สุด

• ส่งรูปในขนาดที่แสดงจริง เป็น WebP หรือ AVIF พร้อม srcset และ sizes เพื่อให้มือถือได้ไฟล์ที่เล็กกว่า
• กำหนด width และ height เพื่อให้เบราว์เซอร์จองพื้นที่ไว้ และไม่มีอะไรกระโดด
• lazy-load รูปที่อยู่ใต้หน้าจอแรก แต่ห้ามทำกับรูป hero ให้ใส่ fetchpriority="high" กับรูป hero แทน
• อย่าใส่รูปหลักเป็นพื้นหลังของ CSS เพราะเบราว์เซอร์จะเจอมันช้า

สำหรับฟอนต์ ใช้ตระกูลและน้ำหนักให้น้อยลง ใช้ไฟล์ WOFF2 preload เฉพาะฟอนต์ที่หน้าจอแรกต้องใช้ และตั้ง font-display ให้ข้อความแสดงด้วยฟอนต์สำรอง ระหว่างที่ฟอนต์ของคุณกำลังโหลด บนเว็บไซต์หลายภาษา ให้แบ่งฟอนต์ขนาดใหญ่เป็นชุดย่อยด้วย unicode-range เพื่อให้เบราว์เซอร์ดึงเฉพาะชุดย่อย ที่ข้อความบนหน้าต้องใช้ บทความ การปรับแต่งรูปภาพสำหรับเว็บไซต์ ลงลึกกว่านี้

5. สคริปต์ภายนอก

วิดเจ็ตแชท tag manager, heatmap เครื่องมือทดสอบ A/B และ embed วิดีโอหรือแผนที่ รันโค้ดที่คุณควบคุมไม่ได้ บน main thread เดียวกับโค้ดของคุณ จึงเป็นสาเหตุที่พบบ่อยของ INP ที่แย่

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

วิธีเพิ่มความเร็ว เรียงตามผลลัพธ์และแรงที่ใช้

ถ้าอยากรู้วิธีทำให้เว็บไซต์เร็วขึ้น โดยไม่ต้องสร้างใหม่ ให้เริ่มจากรายงาน Core Web Vitals ใน Search Console ซึ่งจัดกลุ่ม URL ที่คล้ายกัน ทำให้เห็นว่าปัญหากระทบเทมเพลตเดียว หรือทั้งเว็บไซต์ จากนั้นไล่ลงตามรายการนี้

ทดสอบไปพร้อมกัน

1. หาว่าอะไรไม่ผ่าน ตัวชี้วัดไหน ในเทมเพลตไหน บนมือถือหรือเดสก์ท็อป
2. หาสาเหตุ PageSpeed Insights ระบุอิลิเมนต์ LCP และสิ่งที่ทำให้มันช้า ส่วนแผง Performance ใน Chrome DevTools แสดง long task ที่อยู่เบื้องหลัง INP ที่แย่
3. แก้ข้อต่อแรกสุดในห่วงโซ่ก่อน แล้วทดสอบในแล็บใหม่
4. ปล่อยใช้งาน แล้วเฝ้าดูข้อมูลภาคสนาม สักสองสามสัปดาห์ เพราะตัวเลขแต่ละตัวครอบคลุม 28 วันที่ผ่านมา

บน WordPress บทความ วิธีทำให้เว็บไซต์ WordPress เร็วขึ้น แสดงวิธีแก้เหล่านี้อย่างปลอดภัย

รักษาเว็บไซต์ให้เร็วหลังเปิดตัว

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

ตั้งงบประมาณด้านประสิทธิภาพ

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

เฝ้าดูข้อมูลผู้ใช้จริง

ตรวจรายงาน Core Web Vitals ใน Search Console ทุกเดือน และหลังการเปลี่ยนแปลงใหญ่ ถ้าทราฟฟิกน้อยเกินกว่าที่ CrUX จะเก็บได้ การเฝ้าดูผู้ใช้จริง (real-user monitoring) จะเก็บตัวชี้วัดเดียวกันจากผู้เข้าชมของคุณเอง ไลบรารี web-vitals แบบโอเพนซอร์สของ Google เป็นจุดเริ่มต้นที่ใช้กันทั่วไป

ใส่ความเร็วไว้ในงานดูแล

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

• เทมเพลตหลักผ่าน Core Web Vitals บนมือถือ ในข้อมูลภาคสนาม
• TTFB อยู่ราว 0.8 วินาทีหรือน้อยกว่าในหน้าสำคัญ
• แท็กภายนอกทุกตัวมีเจ้าของ และมีเหตุผล

ทุกบทความในชุดเรื่องประสิทธิภาพ

คำถามที่พบบ่อย

เวลาโหลดหน้าที่ดีสำหรับเว็บไซต์คือเท่าไร?

แทนที่จะดูเวลาโหลดรวมตัวเลขเดียว ให้ตั้งเป้าตามเกณฑ์ Largest Contentful Paint ของ Google คือเนื้อหาหลักปรากฏภายใน 2.5 วินาที ในอย่างน้อย 75% ของการเข้าชมจริง

ต้องไล่เก็บคะแนน PageSpeed ไม่กี่แต้มสุดท้ายไหม?

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

ความเร็วเว็บไซต์มีผลต่อ SEO ไหม?

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

เริ่มจากตรงไหน

รันหน้าที่สำคัญที่สุดของคุณผ่าน PageSpeed Insights บนมือถือ แล้วจดว่า Core Web Vital ตัวไหนห่างจากเกณฑ์ดีมากที่สุด LCP ชี้ไปที่เซิร์ฟเวอร์ โค้ดที่บล็อกการเรนเดอร์ หรือรูปภาพ INP ชี้ไปที่ JavaScript และสคริปต์ภายนอก ส่วน CLS ชี้ไปที่รูปที่ไม่ได้กำหนดขนาด embed และฟอนต์

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