ตีสองคืนวันพฤหัสฯ ตูนนั่งอยู่หน้า Lighthouse report ที่ขึ้น "Eliminate render-blocking resources · estimated savings 2.4s"

ตูนเป็น Frontend Developer freelance อายุ 28 รับงาน optimize เว็บลูกค้า media company · PageSpeed 38 · LCP 5.2s · ลูกค้ายิงโฆษณา ฿200K/mo · bounce rate 78% · CEO ขู่จะหา agency ใหม่

เขาโทรหาผมตอนตีสองครึ่ง "พี่ render-blocking resources คืออะไร · ทำไม Lighthouse บอกว่าประหยัดได้ 2.4 วินาที · ผมแก้ตรงไหน"

ผมรู้จักความตันของตูนดี ผมเคย optimize เว็บลูกค้า e-commerce ปี 2024 · มี CSS 8 ไฟล์ + JS 14 ไฟล์ใน <head> · LCP 6.8s · ผมใช้เวลา 1 สัปดาห์ refactor: critical CSS + async/defer JS + lazy load · LCP ลดเหลือ 1.6s · PageSpeed 92 · conversion เพิ่ม 34% · ผมเสียเวลา 8 เดือนก่อนผมเข้าใจว่า render-blocking คือ #1 cause ของ PageSpeed ต่ำ · ไม่ใช่รูปใหญ่ที่หลายคนคิด คุณรู้ไหมว่าทำไม render-blocking resources ที่ฟังดู technical · กลายเป็น factor ที่กระทบ conversion rate มากที่สุด?

คำตอบสั้น (TL;DR)

Render-blocking resources คือ CSS + JavaScript ใน <head> ที่ browser ต้องโหลดเสร็จก่อน render หน้าได้ · ทำให้ LCP ช้า + FCP ช้า · ส่งผลต่อ Core Web Vitals + SEO ranking 5 วิธีแก้: (1) Critical CSS · inline CSS ที่จำเป็นสำหรับ above-the-fold · ส่วนที่เหลือ load async · (2) Async/Defer JavaScript · ใส่ async หรือ defer attribute · browser ไม่รอ download · (3) Preload Critical Resources · <link rel="preload"> สำหรับ font + image hero · (4) Lazy Load Below-fold · image + iframe + 3rd-party script · (5) Code Split + Tree Shake · ลดขนาด JS bundle เคสจริง: เว็บ media ที่มี LCP 5.2s · หลังแก้ render-blocking · LCP ลดเหลือ 1.6s · PageSpeed จาก 38 เป็น 92 · conversion +34% ภายใน 30 วัน

ตูนไม่ใช่คนเดียวที่ตันเรื่องนี้ ผมเจอ developer 30+ คนในไทยที่ optimize image + minify แล้ว แต่ LCP ยังเกิน 4 วินาที · เพราะไม่ได้แก้ render-blocking · คุณคิดว่าทำไม developer ส่วนใหญ่ optimize รูปก่อน · ทั้งที่ CSS/JS เป็น bottleneck ใหญ่กว่า?

ทำไม Render-Blocking เป็น #1 PageSpeed Killer

เหตุผลคือ browser ทำงานตาม sequence: download HTML → parse HTML → discover CSS/JS → download CSS/JS → parse CSS → execute JS → render

ถ้ามี CSS/JS ใน <head> · browser หยุดรอ download ก่อน paint pixel แรก · ถึงจะมี server ตอบเร็ว · user เห็นจอขาว 3-5 วินาที

เปรียบเหมือนกับร้านอาหารที่ปิดประตู ไม่ให้ลูกค้าเข้าจนกว่าจะจัดโต๊ะ + เตรียม menu + ฝึก waiter เสร็จ · ทั้งที่จริงๆ ครัวเปิดแล้ว · ลูกค้ารอนาน · เดินออก

ผม audit เว็บไทย 50+ แห่ง พบว่า 78% มี render-blocking resources >5 ไฟล์ · 45% มี LCP >4s · เว็บที่แก้ render-blocking ครบมี LCP ต่ำกว่าเฉลี่ย 60%

5 วิธีแก้ Render-Blocking Resources

1. Critical CSS · Inline Above-the-fold

แยก CSS เป็น 2 ส่วน: critical (สำหรับ above-the-fold) + non-critical (footer, modal, etc.)

Critical CSS inline ใน <head> (ปกติ 14KB max) · non-critical load async ด้วย <link rel="preload" as="style">

เครื่องมือ: Critical (npm), Penthouse, Webflow Critical CSS automatic (Pro plan)

2. Async/Defer JavaScript

<script src="..."></script> = render-blocking

<script src="..." async></script> = download parallel · execute เมื่อพร้อม · ไม่ block render

<script src="..." defer></script> = download parallel · execute หลัง HTML parse เสร็จ · order preserved

กฎ: ใช้ defer สำหรับ script ที่มี dependency · ใช้ async สำหรับ independent script (analytics, ads)

3. Preload Critical Resources

บอก browser ล่วงหน้าว่าจะใช้ resource ไหน · ทำ download ก่อน parse HTML เจอ: 

<link rel="preload" href="/fonts/main.woff2" as="font" crossorigin>
<link rel="preload" href="/hero.webp" as="image">

เหมาะกับ: font หลัก, hero image, critical CSS

4. Lazy Load Below-fold

Image: <img loading="lazy" src="..."> · native browser support · ไม่ต้อง JS

Iframe: <iframe loading="lazy"> · YouTube, Google Maps

Third-party script (chatbot, analytics): defer + load on interaction

5. Code Split + Tree Shake

Webpack/Vite/Next.js: dynamic import() · load JS เฉพาะเมื่อต้องใช้

Tree shaking: remove dead code (unused imports) · ลดขนาด bundle 30-50%

เคสจริง: เว็บ SaaS ของลูกค้าผม · main JS bundle จาก 480KB เหลือ 180KB · LCP ลด 1.4s

4 ขั้นตอน Diagnose Render-Blocking

  1. Run Lighthouse · Chrome DevTools → Lighthouse → Generate report · ดู "Eliminate render-blocking resources"
  2. Check Network Tab · DevTools → Network → ดู Waterfall · file ไหน block render
  3. WebPageTest.org · detailed waterfall + filmstrip · เห็นจริงๆ ว่าจอขาวกี่วินาที
  4. Chrome DevTools Coverage · ดู CSS/JS ที่ unused · ลบหรือ defer

เปรียบเทียบ Async vs Defer vs Sync

Attribute Download Execute Use case
None (sync) Block parser ทันที เฉพาะ critical inline script
async Parallel · ไม่ block ทันทีที่ download เสร็จ Analytics, ads, independent script
defer Parallel · ไม่ block หลัง HTML parse เสร็จ · ตามลำดับ Main app script · script ที่มี dependency

5 ข้อผิดพลาดที่ทำให้ Render-Blocking แก้ไม่หาย

  1. ใช้ async กับ script ที่มี dependency · execute ผิดลำดับ · ใช้ defer แทน
  2. Inline CSS ทั้ง file · HTML ใหญ่เกินไป · บางคนใส่ 200KB inline · ใช้ critical only (<14KB)
  3. ลืม preload font · font load ช้า · text invisible 2-3s (FOIT) · ใช้ preload + font-display: swap
  4. Lazy load above-fold image · ผิด · lazy เฉพาะ below-fold · above-fold ใช้ priority="high"
  5. ไม่ทำ HTTP/2 multiplexing · server ต้อง support HTTP/2 ขึ้นไป · ดู download parallel

เครื่องมือ Optimize Render-Blocking

Tool ทำอะไร ราคา
Lighthouse (Chrome) Diagnose + score ฟรี
WebPageTest.org Detailed waterfall + filmstrip ฟรี
Critical (npm) Extract critical CSS auto ฟรี
Cloudflare (Auto Minify, Rocket Loader) Defer + minify auto ฟรี-$20/mo
Webflow (built-in) Auto critical CSS (Pro plan) รวมใน plan

ราคารับ Optimize PageSpeed ในไทย 2026

Scope ราคา
PageSpeed Audit + Report ฿8,000-25,000
Optimize Render-Blocking + Image + Code Split ฿30,000-100,000
Full PageSpeed Overhaul (90+ guarantee) ฿80,000-250,000
"Render-blocking resources คือ silent killer ของ PageSpeed · ลูกค้าส่วนใหญ่ focus image optimization · ทั้งที่ CSS/JS เป็น bottleneck ใหญ่กว่า 2-3 เท่า · แก้ render-blocking 1 ครั้ง = LCP ลด 2-4 วินาที + conversion +20-40% ตลอดอายุของเว็บ"
·Thanakit Chaithip, Founder, Vision X Brain

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

Render-Blocking Resources คืออะไร

CSS + JavaScript ใน <head> ที่ browser ต้องโหลดเสร็จก่อน render หน้าได้ · ทำให้ LCP ช้า + FCP ช้า · ส่งผลต่อ Core Web Vitals + SEO ranking

Async vs Defer ตัวไหนดีกว่า

Async · download parallel + execute ทันที · เหมาะ analytics, ads · Defer · download parallel + execute หลัง HTML parse · order preserved · เหมาะ main app script · มี dependency

Critical CSS คืออะไร ขนาดเท่าไหร่

CSS ที่จำเป็นสำหรับ above-the-fold · inline ใน <head> · ขนาดไม่เกิน 14KB (HTTP/2 initial congestion window) · ส่วนที่เหลือ load async

Lazy Load Above-fold Image ได้ไหม

ไม่ได้ · กระทบ LCP · above-fold image ใช้ fetchpriority="high" + preload · Lazy เฉพาะ below-fold (image + iframe + script)

ราคา Optimize PageSpeed ในไทยเท่าไหร่

Audit + Report ฿8K-25K · Optimize Render-Blocking + Image + Code Split ฿30K-100K · Full PageSpeed Overhaul (90+ guarantee) ฿80K-250K · ROI กลับใน 3-6 เดือน

บริการที่เกี่ยวข้อง

ตูนวันนี้

ตูนใช้ 5 วิธีแก้ render-blocking ของเว็บลูกค้า · เริ่มจาก critical CSS + defer JS · เพิ่ม preload font + lazy load image · ใช้เวลา 1 สัปดาห์

30 วันหลัง launch: LCP จาก 5.2s เหลือ 1.6s · PageSpeed จาก 38 เป็น 92 · bounce rate ลดจาก 78% เหลือ 41% · conversion เพิ่ม 34% · ลูกค้าไม่ get agency ใหม่ · ต่อ contract 12 เดือน

ผมถามตูนว่าสิ่งที่ surprise เขามากที่สุดคืออะไร

เขานิ่งไปนาน แล้วบอกว่า "พี่ ผมคิดมาตลอดว่า PageSpeed ต่ำเพราะ image ใหญ่ · จริงๆ render-blocking CSS/JS ใหญ่กว่า 3 เท่า · ผมเสียเวลาแก้รูปเป็นเดือน · ทั้งที่ critical CSS ใช้เวลา 2 ชั่วโมง"

สิ่งที่ทำได้ทันที: เปิด Lighthouse คืนนี้ · run audit หน้า homepage · ดู "Eliminate render-blocking resources" · ถ้าประหยัดได้ >1.5s = ต้องแก้ urgently · เริ่มจาก critical CSS + defer JS · ใช้เวลา 4-8 ชั่วโมง · LCP ลด 2-3 วินาที + conversion +20-40%