Render-blocking resources: CSS, JavaScript และฟอนต์ ทำให้หน้าเว็บช้าอย่างไร

PageSpeed Insights แจ้งเตือน “Render-blocking requests” (รายงานรุ่นเก่าเขียนว่า “กำจัดทรัพยากรที่บล็อกการแสดงผล”) แสดงรายการไฟล์ CSS และ JavaScript ไม่กี่ไฟล์ และประเมินว่าคุณจะประหยัดเวลาได้เท่าไร แต่ไม่ได้บอกว่าทำไมไฟล์เหล่านั้นถึงถ่วงหน้าเว็บ ไฟล์ไหนแก้ได้อย่างปลอดภัย หรือทำไมวิธีแก้ที่ดูชัดเจน บางครั้งทำให้เมนูบนมือถือพัง

บทความนี้อธิบายว่าเบราว์เซอร์สร้างหน้าเว็บอย่างไร หาไฟล์ที่บล็อกได้อย่างไร และวิธีแก้มาตรฐานจาก web.dev และ MDN พร้อมข้อแลกเปลี่ยนของแต่ละวิธี

คำตอบสั้น ๆ

render-blocking resources คือไฟล์ที่เบราว์เซอร์ต้องดึงมา และบางครั้งต้องรันด้วย ก่อนจะวาดพิกเซลแรกของหน้าเว็บ ผู้ต้องสงสัยประจำคือ

• สไตล์ชีตในส่วน head ของหน้า เบราว์เซอร์จะไม่วาดอะไร จนกว่าจะได้ CSS ที่ต้องใช้
• สคริปต์ที่ไม่มี defer หรือ async มันหยุดไม่ให้เบราว์เซอร์อ่าน HTML ต่อ จนกว่าจะรันเสร็จ
• เว็บฟอนต์ ไม่ได้บล็อกทั้งหน้า แต่ซ่อนข้อความได้

วิธีแก้คือ เลื่อนสคริปต์ที่หน้าจอแรกไม่ต้องใช้ ฝัง critical CSS เล็ก ๆ ไว้ในหน้า เลิกโหลด CSS ที่หน้านั้นไม่เคยใช้ และโหลดฟอนต์อย่างตั้งใจ เป้าหมายคือให้เหลือไฟล์ที่บล็อกน้อย ๆ และโหลดเร็ว ไม่ใช่ให้เหลือศูนย์

เบราว์เซอร์สร้างหน้าเว็บอย่างไร และรอตรงไหน

CSS บล็อกการแสดงผลครั้งแรกโดยตั้งใจ

เบราว์เซอร์อ่าน HTML เพื่อสร้าง Document Object Model หรือ DOM ซึ่งเป็นแผนที่ของหน้า และแปลง CSS เป็นโมเดลของสไตล์ที่คู่กัน (CSSOM) เมื่อมีครบทั้งสองอย่าง จึงจะจัดเลย์เอาต์และวาดหน้าได้

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

สคริปต์แบบ synchronous หยุดการอ่านไปเลย

แท็ก <script src="…"> แบบดั้งเดิมที่ไม่มีแอตทริบิวต์ จะบล็อก parser เบราว์เซอร์หยุดสร้าง DOM ดาวน์โหลดไฟล์ และรันมันก่อนทำงานต่อ เพราะสคริปต์อาจเปลี่ยนแปลงหน้าเว็บ

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

ฟอนต์ถ่วงข้อความ ไม่ใช่ทั้งหน้า

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

สิ่งที่ preload scanner มองไม่เห็น

เบราว์เซอร์บรรเทาปัญหานี้ด้วย preload scanner ซึ่งกวาดอ่าน HTML ล่วงหน้า และเริ่มดาวน์โหลดไฟล์ ระหว่างที่ parser หลักถูกบล็อก แต่มันมองไม่เห็นไฟล์ที่ถูกอ้างถึงภายใน CSS (เช่น @import รูปพื้นหลัง หรือฟอนต์) หรือไฟล์ที่ JavaScript เพิ่มเข้ามา ไฟล์เหล่านั้นจึงโหลดช้า และโหลดต่อกันเป็นทอด ๆ

หาไฟล์ที่บล็อกการเรนเดอร์บนเว็บไซต์ของคุณ

PageSpeed Insights และ Lighthouse ตั้งแต่ Lighthouse 13 ไฟล์เหล่านี้อยู่ในหัวข้อ “Render-blocking requests” ส่วนรายงานรุ่นเก่าแสดงไว้ใต้ “กำจัดทรัพยากรที่บล็อกการแสดงผล” บทความ วิธีอ่านรายงาน PageSpeed Insights อธิบายว่าควรเชื่อตัวเลขเวลาที่ประหยัดได้แค่ไหน และทำไม “element render delay” ที่สูงในรายละเอียดของ LCP มักชี้มาที่เรื่องนี้

Chrome DevTools แผง Performance บันทึกการโหลด และแจ้งคำขอที่บล็อกการเรนเดอร์ไว้ในแทร็ก Network แผง Coverage (อยู่ใน More tools) แสดงว่าหน้าใช้ไฟล์ CSS และ JavaScript แต่ละไฟล์ไปมากแค่ไหน ในแผง Network ให้คลิกขวาที่คำขอ บล็อกมัน แล้วโหลดใหม่ เพื่อดูว่าอะไรพังเมื่อไม่มีไฟล์นั้น

ตรวจผ่าน console ใน Chrome หรือ Edge คำสั่ง performance.getEntriesByType('resource').filter(r => r.renderBlockingStatus === 'blocking') จะแสดงรายการไฟล์ที่ถูกนับว่าบล็อก ณ เวลาที่เขียน รองรับเฉพาะเบราว์เซอร์ที่สร้างบน Chromium

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

แก้ JavaScript: defer, async หรือไม่ใช้ทั้งคู่

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

ให้ defer ใน head เป็นค่าตั้งต้น เพื่อให้ไฟล์ดาวน์โหลดเร็ว ขณะที่เบราว์เซอร์อ่าน HTML ต่อไป เก็บ async ไว้สำหรับสคริปต์ที่ไม่พึ่งอะไร และไม่มีอะไรพึ่งมัน โค้ดที่ถูก defer ยังรันบน main thread ซึ่งงานที่ยาว ๆ จะทำให้การแตะตอบสนองช้า และทำให้ค่า INP (ความเร็วในการตอบสนองต่อการโต้ตอบ) แย่ลง ตามที่บทความ อธิบาย Core Web Vitals เล่าไว้

เมื่อการ defer สคริปต์ทำให้อะไรพัง

โค้ดบางส่วนพึ่งจังหวะเวลาแบบเดิม

• inline script ที่เรียกไลบรารี jQuery(function () { … }) แบบ inline จะรันทันที เมื่อ jQuery ถูก defer แล้ว console จะแจ้ง jQuery is not defined การใส่ defer ให้ inline script ไม่มีผลอะไร
• ลำดับภายใต้ async สคริปต์ของปลั๊กอินที่รันก่อนไลบรารีจะมาถึง จะล้มเหลวเป็นบางครั้ง ซึ่งทำให้จำลองปัญหาซ้ำได้ยาก
• DOMContentLoaded ในสคริปต์แบบ async สคริปต์แบบ async อาจรันหลังอีเวนต์นั้นเกิดไปแล้ว โค้ดที่รออีเวนต์นั้นจึงไม่เคยรัน
• document.write MDN ระบุว่าเบราว์เซอร์ไม่สนใจคำสั่งนี้ ในสคริปต์แบบ defer และ async
• สคริปต์ที่บล็อกโดยตั้งใจ เช่น ตัวจัดการความยินยอม (consent manager) โค้ดกันหน้ากระพริบสำหรับการทดสอบ A/B และสคริปต์จิ๋วที่ตั้งธีมสีก่อนวาดหน้า ให้สคริปต์เหล่านี้เล็ก อยู่ลำดับแรก และมีให้น้อยที่สุด

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

ระวังการ “หน่วงไว้จนกว่าจะมีการโต้ตอบ”

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

แก้ CSS: critical CSS และ CSS ที่ไม่ได้ใช้

CSS บางส่วนต้องบล็อก จึงควรทำส่วนนั้นให้เล็ก

ฝัง critical CSS ไว้ในหน้า

critical CSS คือ CSS ขั้นต่ำที่ต้องใช้จัดสไตล์หน้าจอแรก ได้แก่ header, hero, ตัวอักษร และเลย์เอาต์ ใส่ไว้ในบล็อก <style> ใน head เพื่อให้มาถึงพร้อม HTML คำแนะนำบน web.dev เสนอให้เนื้อหาส่วนที่เห็นก่อนเลื่อน (above the fold) รวม CSS ที่ฝังไว้ มีขนาดไม่เกินประมาณ 14 KB หลังบีบอัด ซึ่งราว ๆ เท่ากับที่การเชื่อมต่อใหม่ ส่งได้ในการรับส่งรอบแรก

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

ถ้า CSS ทั้งหมดของเว็บไซต์มีแค่ไม่กี่กิโลไบต์ การฝังทั้งหมดไว้ในหน้ามักง่ายที่สุด ไม่มีอะไรบล็อก และไม่ต้องสร้างอะไร

โหลดส่วนที่เหลือแบบไม่บล็อก

รูปแบบที่ใช้กันทั่วไปคือ โหลดสไตล์ชีตเต็มด้วย rel="preload" หรือ media="print" แล้วเปิดใช้ด้วยตัวจัดการ onload และเพิ่ม <noscript> สำรองไว้ Content Security Policy ที่เข้มงวดจะบล็อกตัวจัดการแบบ inline เหล่านี้ จึงควรตรวจ header ของคุณก่อน

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

ลด CSS ที่ไม่ได้ใช้

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

1. เลิกโหลดในที่ที่ไม่ต้องใช้ โหลดสไตล์ของปลั๊กอินและคอมโพเนนต์ เฉพาะในเทมเพลตที่ใช้มัน นี่คือวิธีแก้ที่ปลอดภัยที่สุด และมักได้ผลมากที่สุด
2. ตัดออกด้วยเครื่องมือ ฟีเจอร์ “ลบ CSS ที่ไม่ได้ใช้” แบบอัตโนมัติ จะลบ selector ที่หาไม่เจอในหน้า รวมถึงคลาสที่ JavaScript เพิ่มเข้ามาทีหลัง จึงต้องมีรายการยกเว้น (safelist) และทดสอบทุกสถานะ

โหลดเว็บฟอนต์ให้ดี

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

• โหลดไฟล์ให้น้อยลง แต่ละตระกูล น้ำหนัก และสไตล์ มักเป็นไฟล์แยกกัน variable font ไฟล์เดียวแทนหลายน้ำหนักได้
• โฮสต์ WOFF2 เองเมื่อทำได้ บริการฟอนต์ภายนอกมักเพิ่มสไตล์ชีตของตัวเองอีกไฟล์ นั่นคือคำขอที่บล็อกการเรนเดอร์เพิ่มอีกหนึ่ง ไปยังอีกเซิร์ฟเวอร์ ก่อนจะถึงไฟล์ฟอนต์จริง
• แยกชุดอักขระตามระบบการเขียน บนเว็บไซต์หลายภาษา ให้แบ่งฟอนต์เป็นชุดย่อยที่ประกาศด้วย unicode-range เบราว์เซอร์จะดาวน์โหลดเฉพาะชุดย่อย ที่มีอักขระซึ่งหน้านั้นใช้จริง
• preload เฉพาะสิ่งที่หน้าจอแรกต้องใช้ ด้วย <link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin> แอตทริบิวต์ crossorigin จำเป็นแม้บนโดเมนของคุณเอง ไม่อย่างนั้นฟอนต์จะถูกดาวน์โหลดสองครั้ง ถ้า preload มากเกินไป รูป hero จะช้าลง
• เลือกค่า font-display

เมื่อใช้ font-display: swap ให้เลือกฟอนต์สำรองที่สัดส่วนใกล้เคียง และปรับด้วย descriptor size-adjust เพื่อให้ข้อความขยับน้อยลง เมื่อเว็บฟอนต์มาถึง

ทำไมเว็บไซต์ที่ใช้ page builder ต้องระวังเป็นพิเศษ

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

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

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

• ทุกเทมเพลต บนมือถือและเดสก์ท็อป ตอนออกจากระบบ และล้างแคชแล้ว
• เมนูมือถือ สไลเดอร์ แท็บ accordion และป๊อปอัป
• ทุกฟอร์ม รวมถึงข้อความผิดพลาดจากการตรวจข้อมูล และหน้าขอบคุณ
• แบนเนอร์ขอความยินยอม และ analytics ยังบันทึกการเข้าชมและ key event อยู่
• ตัวสลับภาษาบนเว็บไซต์หลายภาษา
• console ของเบราว์เซอร์ ว่ามีข้อผิดพลาดใหม่ไหม

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

ลำดับการทำงานที่ปลอดภัย

1. วัด LCP จากข้อมูลภาคสนามถ้ามี พร้อมค่าฐานจากแล็บที่รันสามครั้ง
2. ทำรายการไฟล์ที่บล็อก และดูว่าไฟล์ไหนโหลดโดยธีม ปลั๊กอิน หรือบริการภายนอก
3. ลบก่อนปรับแต่ง ไฟล์จากเครื่องมือที่ไม่มีใครใช้แล้ว คือวิธีแก้ที่ถูกที่สุด
4. defer สคริปต์ของคุณเอง และแก้การพึ่งพาแบบ inline
5. ตัดและแยก CSS แล้วฝัง critical CSS ในเทมเพลตสำคัญ
6. จัดการฟอนต์ ไฟล์น้อยลง preload หนึ่งหรือสองไฟล์ และเลือก font-display อย่างตั้งใจ
7. ทดสอบใหม่ แล้วเฝ้าดูข้อมูลภาคสนาม ซึ่งครอบคลุมช่วง 28 วันล่าสุด จึงควรเผื่อเวลาราวสี่สัปดาห์

ขั้นต่อไป

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

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