ลดค่า TBT ด้วยการโหลด JavaScript แบบหน่วงเวลา (Defer/Async) สำหรับเว็บไซต์คุณ

การโหลด JavaScript แบบหน่วงเวลา เป็นวิธีการลด Total Blocking Time (TBT) โดยการเลื่อนการโหลดไฟล์ JavaScript ที่ไม่จำเป็นต้องรันทันทีออกไปอย่างถูกลำดับ เพื่อไม่ให้เบราว์เซอร์หยุดวาดเนื้อหาของหน้าเว็บ วิธีนี้ช่วยลดการล็อกของเธรดหลัก ทำให้ผู้ใช้เห็นหน้าเว็บได้เร็วขึ้นและสามารถคลิกใช้งานได้เร็วขึ้น อีกทั้งยังช่วยปรับปรุงคะแนน Core Web Vitals โดยการเพิ่มแอตทริบิวต์ defer หรือ async ให้กับสคริปต์ที่ไม่สำคัญต่อการแสดงผลทันที คุณควรเริ่มจากการตรวจสอบไฟล์ JavaScript ที่จำเป็น จากนั้นให้เลือกใช้ defer กับสคริปต์ที่มีความสัมพันธ์กัน และ async สำหรับสคริปต์จากแหล่งภายนอกที่ทำงานอิสระ และอย่าลืมวัดผลหลังปรับปรุงด้วย PageSpeed Insights, Lighthouse และ Chrome DevTools เพื่อดูค่าของ TBT ว่าลดลงหรือไม่

เว็บไซต์สมัยใหม่ส่วนใหญ่ประสบปัญหาด้านประสิทธิภาพจากการใช้ JavaScript อย่างไม่เหมาะสม มากกว่าที่จะมาจากภาพกราฟิก ตัวอย่างเช่น เว็บไซต์อีคอมเมิร์ซที่โหลดฟิลเตอร์สินค้า, ระบบแชทสด, โค้ดโฆษณา, เครื่องมือวิเคราะห์, ปลั๊กอินคอมเมนต์, เครื่องมือทดสอบ A/B และสคริปต์ธีมพร้อมกัน จะทำให้เธรดหลักของเบราว์เซอร์ถูกใช้งานหนัก โดยเฉพาะบนมือถือ ผู้ใช้แม้จะเห็นหัวข้อบนหน้าจอแต่กดเมนูแล้วอาจไม่มีปฏิกิริยา ในรายงาน Lighthouse จึงมักแสดงค่า Total Blocking Time สูง

ในบทความนี้ เราจะอธิบายว่าคุณสมบัติ defer และ async ทำงานอย่างไร ใช้เมื่อไหร่ รวมถึงวิธีนำไปใช้ในโปรเจค WordPress และโปรเจคซอฟต์แวร์เฉพาะทาง พร้อมคำแนะนำการวัดผลและประเมินผลลัพธ์ที่เป็นจริง นอกจากนี้ยังมีข้อแนะนำเกี่ยวกับการเลือกโฮสติ้งที่เหมาะสม, การใช้ CDN, SSL และการตั้งค่าการแคชเพื่อสนับสนุนการปรับแต่ง JavaScript ให้มีประสิทธิภาพมากขึ้น แพ็คเกจเว็บโฮสติง Hostragons

TBT คืออะไร และทำไมจึงเกี่ยวข้องกับ JavaScript อย่างใกล้ชิด?

TBT ย่อมาจาก Total Blocking Time เป็นตัวชี้วัดเวลาที่เธรดหลักของเบราว์เซอร์ถูกบล็อกจนทำให้หน้าเว็บไม่สามารถตอบสนองต่อการโต้ตอบของผู้ใช้ได้ ในการทดสอบด้วย Lighthouse ช่วงเวลาระหว่าง First Contentful Paint กับ Time to Interactive หากมีงานที่กินเวลานานเกิน 50 มิลลิวินาทีซ้ำ ๆ จะทำให้ค่า TBT เพิ่มสูงขึ้น เช่น หากงาน JavaScript งานหนึ่งใช้เวลา 180 มิลลิวินาที ค่า TBT จะนับเฉพาะเวลาที่เกิน 50 มิลลิวินาที คือ 130 มิลลิวินาที

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

สัญญาณของค่า TBT สูงที่พบได้บ่อย

• ค่า TBT บนรายงาน PageSpeed Insights สำหรับมือถือสูงเกิน 300 มิลลิวินาที
• รายงาน Lighthouse แจ้งเตือนเรื่อง Reduce JavaScript execution time หรือ Minimize main-thread work
• หน้าเว็บแสดงผลแล้วแต่เมนู, สไลเดอร์, ฟิลเตอร์ หรือแบบฟอร์มตอบสนองช้า
• สคริปต์โฆษณา, แชทสด หรือวิเคราะห์จากแหล่งภายนอกแสดงค่าใช้จ่ายสูงในรายงาน
• พบอาการหน่วงการเลื่อนหน้าและการแตะบนมือถือ Android รุ่นเบื้องต้น

เป้าหมายที่ดีคือรักษาค่า TBT ให้น้อยกว่า 200 มิลลิวินาที สำหรับเว็บไซต์เนื้อหาทั่วไป แต่สำหรับอีคอมเมิร์ซหรือ SaaS ที่ซับซ้อน อาจต้องใช้วิธีอื่นร่วมด้วย เช่น การแบ่งโค้ด, ลบแพ็กเกจที่ไม่จำเป็น, แคช, ปรับปรุงเวลาเซิร์ฟเวอร์ตอบสนอง และจัดการ CSS ที่สำคัญ อย่างไรก็ดี การโหลด JavaScript แบบหน่วงเวลายังเป็นหนึ่งในวิธีที่ง่ายและให้ผลเร็วที่สุดในหลายโปรเจค

Defer และ Async คืออะไร?

โดยปกติ สคริปต์ใน HTML จะหยุดการแยกวิเคราะห์ (parsing) หน้าเว็บเพื่อดาวน์โหลดและรัน JavaScript ก่อนแล้วจึงดำเนินการต่อ วิธีนี้อาจจำเป็นสำหรับสคริปต์สำคัญ แต่ถ้าใช้กับทุกไฟล์จะทำให้เกิดความล่าช้าโดยไม่จำเป็น แอตทริบิวต์ defer และ async จึงถูกสร้างขึ้นเพื่อเปลี่ยนพฤติกรรมนี้ โดยกำหนดวิธีดาวน์โหลดและรันไฟล์ให้แตกต่างกัน

defer ทำงานอย่างไร?

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

ตัวอย่างการใช้งาน: <script defer src=/js/app.js></script> ซึ่งไฟล์ app.js จะดาวน์โหลดโดยไม่บล็อกการแสดงผลหน้าเว็บและรันเมื่อ DOM พร้อมใช้งานแล้ว เบราว์เซอร์สมัยใหม่รองรับ defer อย่างกว้างขวาง เป็นเครื่องมือปรับแต่งที่ปลอดภัยและน่าเชื่อถือสำหรับสคริปต์ทั่วไป

async ทำงานอย่างไร?

สคริปต์ที่เพิ่ม async จะดาวน์โหลดพร้อมกับการแยกวิเคราะห์ HTML และจะรันทันทีที่ดาวน์โหลดเสร็จ อาจทำให้การแยกวิเคราะห์ HTML หยุดชั่วคราว และ async ไม่รับประกันลำดับการรันของสคริปต์ ไฟล์ใดดาวน์โหลดเสร็จก่อนก็จะรันก่อน เหมาะกับสคริปต์จากแหล่งภายนอก เช่น โค้ดวิเคราะห์, โฆษณา, พิกเซลติดตาม หรือวิดเจ็ตโซเชียลมีเดียที่ทำงานอิสระ

ตัวอย่างการใช้งาน: <script async src=/js/analytics.js></script> โดยไฟล์นี้ไม่ควรรอไฟล์อื่นรันก่อน หาก analytics.js พึ่งพาตัวแปรหรือไลบรารีที่โหลดหลังจากนั้น อาจทำให้เกิดข้อผิดพลาดได้ async จึงเร็วแต่ต้องเลือกใช้ด้วยความระมัดระวัง

ตารางเปรียบเทียบ defer และ async

กฎคร่าว ๆ คือ หากสคริปต์ต้องรันตามลำดับให้ใช้ defer แต่ถ้าอิสระต่อกันให้ใช้ async หากไม่แน่ใจให้ทดลอง defer ในสภาพแวดล้อมทดสอบ พร้อมตรวจสอบข้อผิดพลาดและการโต้ตอบที่สำคัญก่อน คู่มือสเตจิงและการสำรองข้อมูล

แผนการใช้งานโหลด JavaScript แบบหน่วงเวลาทีละขั้นตอน

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

1. วัดประสิทธิภาพปัจจุบัน

ก่อนเริ่มทำงาน ให้บันทึกคะแนนพื้นฐานจาก PageSpeed Insights ทั้งมือถือและเดสก์ท็อป พร้อมจดค่า TBT, First Contentful Paint, Largest Contentful Paint และ Speed Index จากรายงาน Lighthouse ตรวจสอบเธรดหลักในแท็บ Performance ของ Chrome DevTools หาเวลาที่ใช้ในสคริปต์ JavaScript โดยบล็อกสีเหลืองยาวแสดงถึงการประมวลผลหนัก

ตัวอย่างเช่น ตารางเริ่มต้นอาจมีค่า TBT มือถือ 780 มิลลิวินาที, เวลารัน JavaScript 2.8 วินาที, เวลาทำงานเธรดหลัก 4.5 วินาที ถ้าหลังปรับแต่งค่า TBT ลดเหลือ 280 มิลลิวินาที เท่ากับปรับปรุงได้ประมาณ 64% ข้อมูลแบบนี้ช่วยให้ทีมเข้าใจว่าการเปลี่ยนแปลงใดมีผล

2. รวบรวมสคริปต์ทั้งหมดในหน้า

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

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

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

3. เลือกไฟล์ที่เหมาะจะใช้ defer

โดยทั่วไป สคริปต์ธีมหลัก, เมนู, สไลเดอร์, โมดูลแกลเลอรี่ และไฟล์แอปควรใช้ defer แต่ต้องมั่นใจว่าไม่ขึ้นกับ document.write หรือวิธีการบล็อกเก่า และสคริปต์สามารถรันหลังจาก DOM พร้อมได้

ในธีม WordPress บางไฟล์ เช่น jquery-migrate, สคริปต์ธีมหลัก และปลั๊กอิน อาจมีความสัมพันธ์ซับซ้อน การตั้ง jquery เป็น async อาจเสี่ยง เพราะปลั๊กอินหลายตัวรอ jquery โหลดก่อน วิธีที่ปลอดภัยคือใช้ defer กับไฟล์ที่ขึ้นกับ jquery หรือใช้ตัวเลือกโหลดที่ปรับแต่งเฉพาะในปลั๊กอิน คู่มือการปรับแต่งความเร็ว WordPress

4. เลือกไฟล์ที่เหมาะจะใช้ async

ไฟล์อย่าง Google Analytics, โค้ดโฆษณา, Facebook Pixel, LinkedIn Insight Tag, วิดเจ็ตแชทภายนอก และโค้ดแชร์โซเชียล เหมาะใช้ async แต่ต้องตรวจสอบเอกสารประกอบ เพราะบางระบบแชทอาจต้องสร้างเซสชันผู้ใช้ทันที และโฆษณาบางตัวอาจต้องโหลดตามลำดับ

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

5. เพิ่มการโหลดแบบเงื่อนไขและตามเหตุการณ์

defer และ async เป็นจุดเริ่มต้นที่ดี แต่การโหลด JavaScript ตามพฤติกรรมผู้ใช้จะช่วยลดค่า TBT ได้มากกว่า เช่น กล่องแชทสดอาจโหลดหลังจากผู้ใช้เปิดหน้าเว็บไป 5 วินาที หรือกดปุ่มช่วยเหลือ, โค้ดฝังแผนที่โหลดเมื่อลากสกรอลล์มาถึงส่วนติดต่อ, สคริปต์เล่นวิดีโอเรียกเมื่อกดปุ่มเล่น

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

6. ทดสอบและปล่อยใช้งานอย่างค่อยเป็นค่อยไป

อย่าแก้ไขโค้ดและปล่อยใช้เลยในเว็บไซต์จริง ควรทดลองในสภาพแวดล้อมทดสอบ ตรวจสอบหน้าหลัก, หมวดหมู่, หน้าสินค้า/บริการ, หน้าติดต่อ, ฟอร์มล็อกอินและระบบชำระเงินด้วยวิธีแมนนวล ตรวจสอบว่าไม่มี error ในคอนโซล โดยเฉพาะ error แบบ Cannot read property, is not defined หรือ undefined function ซึ่งบ่งชี้ปัญหาเรื่องลำดับหรือความสัมพันธ์

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

ข้อควรระวังเมื่อใช้ defer และ async ใน WordPress

ในระบบ WordPress ไฟล์ JavaScript จะถูกโหลดผ่านฟังก์ชัน wp_enqueue_script ในธีมและปลั๊กอิน ตั้งแต่ปี 2026 เป็นต้นไป WordPress รุ่นใหม่รองรับการจัดการโหลดสคริปต์ที่ละเอียดขึ้น แต่ธีมเก่า, ปลั๊กอินสร้างหน้า (page builder) และปลั๊กอินปรับแต่งความเร็ว อาจเกิดปัญหาขัดแย้งกันได้

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

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

ข้อควรระวังสำหรับโปรเจคซอฟต์แวร์และ Framework

ในโปรเจคที่ใช้ React, Vue, Angular, Next.js, Nuxt หรือเฟรมเวิร์กอื่น ๆ การปรับแต่ง JavaScript มากกว่าการเพิ่ม defer ในแท็ก HTML เท่านั้น ต้องพิจารณาขนาดแพ็กเกจ, การแบ่งโค้ด (code splitting), การตัดโค้ดที่ไม่ใช้ (tree shaking), การโหลดแบบไดนามิก และค่าใช้จ่ายในการ hydration หากมีแพ็กเกจขนาดใหญ่เกิน 700 KB แม้ใช้ defer ก็อาจทำให้เธรดหลักถูกบล็อกนาน

โปรเจคซอฟต์แวร์เฉพาะทางควรใช้การแบ่งโค้ดตามเส้นทาง (route-based code splitting) เช่น เมื่อผู้ใช้ดูหน้าแรก จะไม่โหลดโค้ดแดชบอร์ดหรือไลบรารีกราฟหนัก ๆ จนกว่าจะเรียกใช้งานจริง ควรเรียกใช้ไดนามิก (dynamic import) เฉพาะเมื่อจำเป็น และตรวจสอบแพ็กเกจที่ไม่ใช้ด้วยเครื่องมือวิเคราะห์แพ็กเกจ รวมถึงเลือกไลบรารีที่เบากว่าแทนไลบรารีขนาดใหญ่ที่มีฟีเจอร์เกินจำเป็น

สำหรับโปรเจคที่ใช้ render ฝั่งเซิร์ฟเวอร์หรือ static generation ต้องระวังช่วง hydration ที่อาจทำให้คอมโพเนนต์จำนวนมากทำงานพร้อมกันจนเพิ่ม TBT การหลีกเลี่ยง JavaScript ที่ไม่จำเป็นในฝั่งลูกค้าเป็นหนึ่งในแนวทางหลักของการปรับปรุงประสิทธิภาพในปี 2026

ความสัมพันธ์ระหว่างโฮสติ้ง, เวลาเซิร์ฟเวอร์ตอบสนอง และประสิทธิภาพ JavaScript

TBT วัดเวลาการรัน JavaScript ในเบราว์เซอร์โดยตรง แต่โครงสร้างพื้นฐานโฮสติ้งมีผลทางอ้อมที่สำคัญ เช่น เวลา TTFB ที่ช้า, ไม่มีการบีบอัดข้อมูล, ไม่มีการรองรับ HTTP/2 หรือ HTTP/3, แคชไม่ดี และระยะทางของเซิร์ฟเวอร์ที่อยู่ไกล ล้วนทำให้ไฟล์ JavaScript ถึงเบราว์เซอร์ช้า เมื่อไฟล์ถึงช้าก็ทำให้วงจรชีวิตของหน้าเว็บยาวขึ้นและประสบการณ์ผู้ใช้แย่ลง

โฮสติ้งคุณภาพสูงที่มีการบีบอัด Brotli หรือ Gzip, แคชที่มีประสิทธิภาพ, ใช้ PHP เวอร์ชันใหม่, เทคโนโลยีดิสก์เร็ว และการเชื่อมต่อ CDN จะช่วยให้การโหลด JavaScript เร็วขึ้น การตั้งค่า SSL ที่ถูกต้องก็สำคัญเพราะช่วยให้เบราว์เซอร์รองรับฟีเจอร์ใหม่ ๆ ของ HTTP/2 และการใช้งานร่วมกับแหล่งภายนอกอย่างปลอดภัย ใบรับรอง SSL Hostragons การตรวจสอบโดเมน Hostragons

ตัวอย่างเช่น ไฟล์ JavaScript ขนาด 320 KB ที่ไม่ได้บีบอัด อาจลดลงเหลือ 95 KB ด้วย Brotli แม้ว่าค่า TBT จะไม่ลดลงในอัตราส่วนเดียวกันเนื่องจาก TBT วัดเวลารันไม่ใช่เวลาโหลด แต่การลดขนาดไฟล์ช่วยลดเวลาโหลด ทำให้จัดการลำดับความสำคัญของทรัพยากรได้ดีขึ้นและประสบการณ์โหลดรวมดีขึ้น ดังนั้น defer, async, แคช และโฮสติ้งที่เหมาะสมควรใช้ร่วมกัน

เช็คลิสต์วัดผลและตรวจสอบ

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

• เปรียบเทียบค่า TBT บนมือถือก่อนและหลังปรับแต่งหรือไม่?
• เวลา JavaScript execution time ของไฟล์ที่ใช้เยอะลดลงหรือไม่?
• จำนวนงานยาวใน Chrome DevTools Performance ลดลงหรือไม่?
• ไม่มี error ของ JavaScript ในคอนโซลหรือไม่?
• เมนู, ช่องค้นหา, ฟิลเตอร์, แบบฟอร์ม, รถเข็น และระบบชำระเงินทำงานได้ไม่มีปัญหาหรือไม่?
• สคริปต์วิเคราะห์และโฆษณาจากภายนอกถูกเรียกใช้อย่างถูกต้องหรือไม่?
• ข้อมูลผู้ใช้จริงแสดงว่า Interaction to Next Paint (INP) และการตอบสนองดีขึ้นหรือไม่?
• หลังจากเคลียร์แคชแล้วได้ทดสอบซ้ำหรือไม่?

จุดสำคัญคือแยกข้อมูลจากห้องทดลอง (laboratory) กับข้อมูลจากผู้ใช้จริง (field data) ออกจากกัน TBT เป็นตัวชี้วัดในห้องทดลอง ขณะที่ INP เริ่มเข้ามามีบทบาทในประสบการณ์ผู้ใช้จริง แต่การลด TBT มักช่วยให้ INP ดีขึ้นเพราะลดเวลาบล็อกเธรดหลัก

ข้อผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง

ตั้ง async ให้สคริปต์ทั้งหมดพร้อมกัน

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

ตั้ง jQuery และปลั๊กอินที่ขึ้นกับ jQuery เป็น async

ใน WordPress ปลั๊กอินหลายตัวต้องรอ jquery โหลดก่อน การตั้ง jquery เป็น async ทำให้ปลั๊กอินทำงานผิดพลาด วิธีแก้คือดูแผนผังความสัมพันธ์และตั้งลิสต์ไฟล์ที่ไม่ควรตั้ง async

ปล่อยสคริปต์ภายนอกโดยไม่ควบคุม

เจ้าของเว็บมักลืมสคริปต์โฆษณา, แชท และวิเคราะห์ในขณะที่ปรับแต่งสคริปต์ของธีม แต่สคริปต์เหล่านี้มักเป็นสาเหตุของงานหนักใน Lighthouse ควรลบแท็กที่ไม่ใช้, โหลดตามเงื่อนไข และหน่วงโหลดตามพฤติกรรมผู้ใช้

ติดตั้งปลั๊กอินปรับความเร็วโดยไม่วัดผล

ปลั๊กอินอาจช่วยได้แต่ถ้าไม่ได้วัดผลก่อนและหลัง ใช้อาจเพิ่ม JavaScript และ CSS ที่ไม่จำเป็น ตรวจสอบปัญหาก่อนเลือกเครื่องมือและทดสอบว่าปรับปรุง TBT จริง

ไม่จัดการแคชและการบีบอัดให้ถูกต้อง

การบีบอัด, รวมไฟล์, defer และ async หากใช้พร้อมกันโดยไม่จัดการลำดับไฟล์อาจทำให้เกิดปัญหาโดยเฉพาะบน CDN และแคชของเซิร์ฟเวอร์ ควรล้างแคชทุกชั้นหลังแก้ไข

ตัวอย่างสถานการณ์ปรับแต่งจริง

สมมุติว่ามีเว็บไซต์องค์กรขนาดกลางที่หน้าแรกโหลด JavaScript 18 ไฟล์ แบ่งเป็น 5 ไฟล์เกี่ยวกับธีมและเมนู, 4 ไฟล์สไลเดอร์และแอนิเมชัน, 3 ไฟล์ฟอร์มและแผนที่, และ 6 ไฟล์วิเคราะห์, พิกเซล และแชท ค่า TBT มือถือเริ่มต้นวัดได้ 920 มิลลิวินาที

ขั้นแรก ลบปลั๊กอินแอนิเมชันที่ไม่ได้ใช้สองตัว ลดโหลด JavaScript 140 KB ทำให้ TBT ลดเหลือ 760 มิลลิวินาที ขั้นที่สอง ตั้งสคริปต์ธีมและสไลเดอร์เป็น defer ทดสอบเรียงลำดับไฟล์ ค่า TBT ลดเหลือ 480 มิลลิวินาที ขั้นที่สาม โหลดแผนที่เฉพาะเวลาผู้ใช้เลื่อนมาถึงหน้าติดต่อ, เริ่มแชทสดหลังจากโหลด 7 วินาที, ตั้งสคริปต์วิเคราะห์และพิกเซลเป็น async ค่า TBT ลดลงเหลือ 210 มิลลิวินาที

กรณีศึกษานี้แสดงให้เห็นว่าการปรับแต่งที่ดีต้องทำเป็นชั้น ๆ defer และ async เป็นเครื่องมือที่ทรงพลัง แต่ผลลัพธ์ดีที่สุดเมื่อร่วมกับการลบโค้ดที่ไม่จำเป็น, โหลดตามเงื่อนไข, การจัดการแคช และโครงสร้างพื้นฐานโฮสติ้งที่ดี

สรุป: กลยุทธ์ JavaScript ที่สมดุลและผ่านการทดสอบเพื่อลด TBT

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

การใช้โครงสร้างพื้นฐาน Hostragons ที่รวดเร็ว, ปลอดภัย และขยายได้ พร้อมการตั้งค่าการโหลด JavaScript, แคช และ SSL อย่างถูกต้อง จะช่วยให้เว็บไซต์ของคุณมีประสิทธิภาพและเสถียรภาพสูงขึ้น หากต้องการปรับปรุงค่า TBT ให้เริ่มจากการวิเคราะห์รายงานปัจจุบัน แล้วค่อยๆ ปรับทีละน้อยด้วยวิธีที่สามารถวัดผลได้ สำหรับบริการโฮสติ้งและโซลูชันประสิทธิภาพ ดูข้อมูลเพิ่มเติมได้ที่ Hostragons แพ็คเกจเว็บโฮสติง Hostragons

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

สามารถใช้ defer และ async พร้อมกันในสคริปต์เดียวได้ไหม?

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

การโหลด JavaScript แบบหน่วงเวลาช่วยเพิ่มอันดับ SEO โดยตรงไหม?

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

การเพิ่ม defer ให้กับ JavaScript ทุกไฟล์ปลอดภัยไหม?

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

แค่ใช้ defer และ async เพียงพอไหมในการลด TBT?

สำหรับเว็บไซต์ขนาดเล็กถึงกลาง การใช้ defer และ async อาจช่วยได้มาก แต่สำหรับเว็บไซต์ที่ใช้เฟรมเวิร์กหนัก, มีโค้ดภายนอกจำนวนมาก หรือไฟล์ขนาดใหญ่ อาจต้องใช้วิธีอื่นร่วมด้วย เช่น การแบ่งโค้ด, การลบ JavaScript ที่ไม่ใช้, โหลดตามเงื่อนไข, การแคช และโครงสร้างพื้นฐานที่ดี

ใน WordPress ควรหลีกเลี่ยงการตั้ง async กับสคริปต์ใดบ้าง?

ไฟล์ที่ขึ้นกับ jQuery, สคริปต์ระบบชำระเงินและรถเข็น, การตรวจสอบแบบฟอร์ม, สคริปต์ความปลอดภัย และฟังก์ชันธีมที่สำคัญ ไม่ควรตั้งเป็น async เพราะการเปลี่ยนลำดับทำให้ฟังก์ชันเหล่านี้ทำงานผิดพลาด ควรตั้ง defer ก่อน และถ้าจำเป็นให้ใส่ในลิสต์ไม่ให้หน่วง