Panduan Render-Blocking Resources
Apa render-blocking resources adalah, bagaimana CSS dan synchronous JavaScript delay critical rendering path, mengapa itu hurts Core Web Vitals (dan indirectly SEO), cara temukan them, dan cara perbaiki them dengan async, defer, critical CSS, dan media kueri.
Render-blocking resources adalah CSS dan synchronous JavaScript files sebuah browser harus download dan proses sebelum ini dapat paint apa pun. sebuah applicable stylesheet di head adalah render-blocking oleh default; sebuah <script> di head tanpa async atau defer adalah parser-blocking oleh default (sebuah related tetapi formally distinct mechanism dari HTML spec's jelas blocking="render" _(terjemahan)_ “render” attribute). async memuat di parallel dan berjalan ketika ready (unordered); defer memuat di parallel dan berjalan setelah parsing, di order; module scripts defer oleh default. mereka dapat delay pertama Contentful Paint dan Largest Contentful Paint, dan LCP adalah digunakan oleh Google's Core Web Vitals peringkat sistem — sebuah tiebreaker, tidak sebuah terdokumentasi dominant peringkat factor. semua eligible 200-status halaman enter Google's rendering queue regardless dari apakah JavaScript adalah present; Google fetches di sebagian besar 2 MB per non-PDF URL (including headers), secara terpisah untuk setiap referenced file, yang adalah sebuah fetch limit, tidak sebuah render-blocking-spesifik penalty. temukan them dengan saat ini Lighthouse 13 'Render blocking permintaan' Insight dan Chrome DevTools Coverage tab; perbaiki oleh deferring non-critical JS, inlining hanya critical CSS di mana sebuah trace menampilkan ini adalah bottleneck, dan menggunakan media attributes untuk conditional stylesheets — lalu re-test pada sebuah repeated trace.
Bukti untuk klaim ini Stylesheets participate in the critical rendering path and can block first render until CSS is processed. Cakupan: Current official or standards documentation. Tingkat keyakinan: tinggi · Diverifikasi: web.dev: Critical rendering path Bukti untuk klaim ini Classic scripts without async or defer can block HTML parsing while fetched and executed. Cakupan: Current official or standards documentation. Tingkat keyakinan: tinggi · Diverifikasi: MDN: script elementTL;DR — Render-blocking resources adalah CSS dan JavaScript files Anda browser memiliki untuk download dan jalankan sebelum ini dapat tampilkan apa pun pada screen. sebuah blank white halaman sementara itu files muat adalah symptom. CSS blocks oleh default; sebuah
<script>di<head>tanpaasyncataudeferjuga blocks. perbaiki adalah untuk muat non-essential stuff kemudian so halaman dapat paint sooner.
«## What “render-blocking” means » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian lima, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
Ketika seseorang opens Anda halaman, browser membaca HTML dari top untuk bottom. Along cara ini hits files ini perlu untuk draw halaman — mostly CSS stylesheets dan JavaScript. beberapa dari itu files membuat browser berhenti dan tunggu: ini tidak akan paint sebuah single pixel until mereka’re downloaded dan processed. itu adalah render-blocking resources.
itu’s mengapa sebuah slow halaman sering menampilkan sebuah blank white screen pertama, lalu semuanya muncul di setelah. browser memiliki HTML, tetapi ini adalah menunggu pada sebuah stylesheet atau sebuah script sebelum ini akan draw apa pun.
dua jenis
- CSS adalah render-blocking oleh default ketika browser discovers sebuah
<link rel="stylesheet">di<head>sementara parsing dan stylesheet sebenarnya applies (Tidak non-matchingmedia, Tidakdisabled). browser tidak ingin untuk tampilkan Anda unstyled konten dan lalu re-style ini (itu flash looks rusak), so ini menunggu untuk applicable CSS sebelum painting. - JavaScript pauses HTML parsing ketika ini adalah sebuah plain
<script>di<head>tanpaasyncataudefer— browser memiliki untuk berhenti reading HTML, go fetch script, jalankan ini, dan hanya lalu continue. (Technically ini adalah “parser-blocking” (terjemahan) “parser-blocking”; apakah ini juga formally counts sebagai “render-blocking” (terjemahan) “render-blocking” bergantung pada browser internals sebagian besar readers jangan perlu — see Advanced.)
mengapa ini penting
lebih lama browser menunggu, lebih lama Anda pengunjung stares di tidak ada apa pun. Google measures ketika berguna konten muncul (sebuah metric called Largest Contentful Paint), dan itu’s bagian dari Core Web Vitals — sebuah kecil sinyal peringkat. So render-blocking resources dapat hurt keduanya Anda pengunjung’ experience dan, indirectly, Anda SEO.
sederhana memperbaiki
- tambahkan
deferuntuk scripts so mereka download alongside halaman dan jalankan setelah ini adalah drawn. - jangan put lebih CSS atau JavaScript di
<head>daripada pertama screen sebenarnya perlu. - jika Anda’re pada WordPress, plugins like WP Rocket atau Autoptimize melakukan ini untuk Anda dengan sebuah checkbox.
ingin mechanics — async vs defer, critical CSS, crawl-budget angle, dan
apa Google sebenarnya says? Switch untuk Advanced tab.
Bukti untuk klaim ini Stylesheets participate in the critical rendering path and can block first render until CSS is processed. Cakupan: Current official or standards documentation. Tingkat keyakinan: tinggi · Diverifikasi: web.dev: Critical rendering path Bukti untuk klaim ini Classic scripts without async or defer can block HTML parsing while fetched and executed. Cakupan: Current official or standards documentation. Tingkat keyakinan: tinggi · Diverifikasi: MDN: script elementTL;DR — Render-blocking resources delay sebuah halaman’s pertama paint. sebuah applicable CSS stylesheet di
<head>blocks oleh default (non-matchingmedia,disabled, atau dynamic insertion dengan Tidak jelasblocking="render"jangan). sebuah parser-inserted classic<script>tanpaasync/deferadalah parser-blocking oleh default — pausing HTML parsing — yang adalah sebuah related tetapi distinct mechanism dari formal “render-blocking” (terjemahan) “render-blocking” attribute model.asyncmemuat di parallel dan executes ketika downloaded (unordered, dapat interrupt parsing);defermemuat di parallel dan executes setelah HTML adalah parsed (di order); module scripts defer oleh default. ini delays dapat push back FCP dan LCP, dan LCP adalah digunakan oleh Google’s peringkat sistem — tetapi ini adalah sebuah tiebreaker, tidak sebuah dominant factor, dan Google documents Tidak direct render-blocking peringkat weight. Google fetches di sebagian besar 2 MB per non-PDF URL (including headers), secara terpisah untuk setiap referenced JS/CSS file — sebuah truncation boundary, tidak sebuah render-blocking-spesifik penalty — dan semua eligible 200-status halaman enter Google’s rendering queue apakah atau tidak mereka gunakan JavaScript. temukan blockers dengan saat ini Lighthouse 13 “Render-blocking requests” (terjemahan) “Render-blocking permintaan” Insight dan DevTools Coverage tab; perbaiki dengandefer, critical CSS hanya di mana sebuah trace menampilkan ini adalah bottleneck,mediaattributes, dan menghapus unused code — lalu re-test dengan sebuah repeated, cocok trace.
critical rendering path
untuk draw sebuah halaman, sebuah browser berjalan sebuah fixed sequence: parse HTML ke DOM, parse CSS ke CSSOM, combine them ke sebuah render tree, lay ini out, dan paint. itu sequence adalah critical rendering path, dan apa pun itu stalls ini delays pertama pixel. sebagai Google’s Ilya Grigorik dibingkai ini, “optimizing itu critical rendering path refers untuk prioritizing itu display dari konten itu relates untuk itu saat ini user action.” (terjemahan) “optimizing critical rendering path refers untuk prioritizing display dari konten itu relates untuk saat ini pengguna tindakan.” Render-blocking resources adalah hal sitting di itu path dengan mereka hand up, membuat browser tunggu.
CSS adalah render-blocking oleh default — ketika ini adalah applicable
browser akan tidak paint styled konten until ini memiliki CSSOM dibangun dari setiap
applicable blocking stylesheet, dan MDN’s <link> reference adalah jelas tentang
cakupan: “hanya link elements di itu document’s <head> dapat possibly block
rendering. Oleh default, a link element dengan rel="stylesheet" di itu <head>
blocks rendering ketika itu browser discovers it during parsing.” (terjemahan) “hanya tidak terdefinisi elements di document’s tidak terdefinisi dapat possibly block
rendering. oleh default, sebuah tidak terdefinisi element dengan tidak terdefinisi di tidak terdefinisi
blocks rendering ketika browser discovers ini selama parsing.” dari web.dev’s
mengoptimalkan LCP guide: “Style sheets loaded from the HTML markup will block
rendering of all content that follows them.” (terjemahan) “Style sheets dimuat dari HTML markup akan block
rendering dari semua konten itu mengikuti them.” ini adalah intentional — painting
unstyled HTML pertama dan re-styling ini produces sebuah ugly flash — tetapi “oleh default” (terjemahan) “oleh default”
memiliki nyata edges:
- sebuah stylesheet dengan sebuah non-matching
mediaattribute (e.g.media="print"pada sebuah screen visit) adalah fetched tetapi tidak block. - sebuah stylesheet dengan
disabledset tidak dimuat atau applied until Anda jelas attribute. - sebuah stylesheet ditambahkan dynamically melalui script tidak render-blocking unless Anda juga
set
blocking="render"pada ini explicitly — dynamic insertion opts out dari default.
di dalam -nya applicable cakupan, sebuah bloated blocking stylesheet dapat masih hold seluruh halaman hostage: ketika ini takes lebih lama untuk muat daripada Anda LCP image itself, LCP element dapat’t render bahkan setelah -nya own resource memiliki finished downloading.
Scripts: parser-blocking oleh default, formally render-blocking pada permintaan
sebuah parser-inserted classic <script> di <head> tanpa async atau defer adalah
parser-blocking oleh default: browser berhenti membangun DOM, fetches
script, executes ini, dan hanya lalu resumes. Google’s legacy PageSpeed docs spell out
cost: “setiap kali itu parser encounters a script it memiliki untuk berhenti dan execute it
sebelum it dapat continue parsing itu HTML. Di itu case dari an external script itu
parser adalah juga forced untuk tunggu untuk itu resource untuk download, yang mungkin incur satu atau
lebih network roundtrips dan delay itu time untuk pertama render dari itu halaman.” (terjemahan) “setiap kali parser encounters sebuah script ini memiliki untuk berhenti dan execute ini
sebelum ini dapat continue parsing HTML. di case dari sebuah external script
parser adalah juga forced untuk tunggu untuk resource untuk download, yang dapat incur satu atau
lebih network roundtrips dan delay time untuk pertama render dari halaman.” sebagai
mengoptimalkan LCP guide puts ini bluntly, “it adalah hampir never necessary untuk add
synchronous scripts… untuk itu <head> dari Anda halaman.” (terjemahan) “ini adalah hampir tidak pernah necessary untuk tambahkan
synchronous scripts… untuk tidak terdefinisi dari Anda halaman.”
Worth menjadi precise di sini: parser-blocking dan HTML spec’s formal
render-blocking attribute model adalah related tetapi distinct mechanisms. Per MDN’s
<script> reference, blocking="render" token “explicitly indicates that
certain operations should be blocked until the script has executed,” (terjemahan) “explicitly indicates itu
certain operations seharusnya menjadi blocked until script memiliki executed,” dan “hanya
script elements di itu document’s <head> dapat possibly block rendering” (terjemahan) “hanya
tidak terdefinisi elements di document’s tidak terdefinisi dapat possibly block rendering” ini
cara — “jika such a script element adalah added dynamically melalui script, Anda harus set
blocking = "render" untuk it untuk block rendering.” (terjemahan) “jika such sebuah tidak terdefinisi element adalah ditambahkan dynamically melalui script, Anda harus set
tidak terdefinisi untuk ini untuk block rendering.” dalam praktik, sebuah default
parser-blocking <head> script sudah stalls pipeline cukup itu
pembedaan rarely perubahan apa Anda melakukan tentang ini; ini penting mainly untuk dynamically
inserted scripts, yang perlu jelas attribute untuk participate, dan browser
mendukung untuk blocking="render" adalah masih limited dan worth memeriksa sebelum Anda rely
pada ini.
Satu lebih default worth knowing: type="module" scripts defer oleh default (Tidak
defer attribute needed) unless async adalah ditambahkan untuk perubahan itu scheduling.
async vs defer — mereka adalah tidak yang sama
ini adalah single sebagian besar berguna pembedaan untuk memperbaiki render-blocking JS. Keduanya download script di parallel dengan HTML parsing, so neither adalah parser-blocking selama download. mereka differ di execution:
async— executes immediately ketika download finishes, yang dapat interrupt parsing, dan berjalan di Tidak guaranteed order. baik untuk truly independent ketiga-party scripts (analytics, ads) itu jangan touch Anda DOM atau bergantung pada setiap lainnya.defer— executes setelah HTML adalah fully parsed, di document order. baik untuk scripts itu bergantung pada DOM atau pada setiap lainnya (sebagian besar dari Anda own code).- Module scripts (
type="module") — deferred oleh default; tambahkanasyncjika Anda secara khusus ingin module-ready-order execution alih-alih.
jika Anda remember satu aturan: defer untuk apa pun ordered atau DOM-dependent, async
hanya untuk fire-dan-forget ketiga-party scripts.
Bagaimana ini memengaruhi SEO
chain adalah nyata tetapi memiliki nyata boundaries. jangan overstate ini di either direction:
«1. Render-blocking resources delay First Contentful Paint — when any content first appears. 2. They can delay Largest Contentful Paint — Google’s primary loading metric — though a flagged resource isn’t proof it’s the dominant field bottleneck, and removing it doesn’t guarantee a better LCP; the Lighthouse Insight reports a potential delay from one observed trace, not a guaranteed field effect. 3. LCP is a Core Web Vitals metric, measured at the 75th percentile of real field data over 28 days, and Google says Core Web Vitals “are used by our ranking systems.” The “good” LCP threshold is ≤2.5 s. 4. Google’s page-experience documentation doesn’t define a direct render-blocking ranking weight, chain, or tiebreaker, and gives no ranking guarantee from removing blockers — it says relevance still wins, but “having a great page experience can contribute to success in Search” when there’s lots of similarly helpful content to choose from. » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tiga puluh lima, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
pertahankan weighting honest. Martin Splitt’s line adalah right calibration: “a fast website adalah a little lebih helpful daripada a slow website,” (terjemahan) “sebuah fast situs web adalah sebuah little lebih helpful daripada sebuah slow situs web,” tetapi “content is still the king.” (terjemahan) “konten adalah masih king.” Memperbaiki sebuah resource itu’s genuinely delaying Anda LCP adalah worth melakukan untuk UX dan sebagai satu input among banyak Google’s sistem weigh — ini adalah tidak sebuah lever dengan sebuah terdokumentasi, dedicated peringkat multiplier.
crawl-efficiency angle — corrected
«I previously framed heavy render-blocking JavaScript as something that “pushes” or “forces” pages into Google’s rendering queue. That’s not accurate, and it’s worth correcting plainly: Google’s current JavaScript SEO documentation states that “all pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.” Every eligible page goes through that queue — render-blocking resources don’t create a special on-ramp into it.
Bukti untuk klaim ini Google's current guidance says all eligible pages returning HTTP 200 enter its rendering queue regardless of whether JavaScript is present, so render-blocking JavaScript should not be claimed to force a page into that queue. Cakupan: crawling, rendering, indexing Tingkat keyakinan: tinggi · Diverifikasi: Understand the JavaScript SEO basics» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tiga puluh delapan, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
Apa resource jenis melakukan perubahan adalah bagaimana banyak berfungsi happens setelah sebuah halaman reaches rendering. Onely’s experiment ditemukan Google needed 9× lebih lama untuk fully crawl JavaScript-dirender halaman daripada identical HTML halaman (313 hours vs. 36 hours) di mereka test setup, karena “halaman itu require rendering memiliki untuk tunggu di a rendering queue selain itu untuk itu crawl queue yang applies untuk all halaman.” (terjemahan) “halaman itu memerlukan rendering memiliki untuk tunggu di sebuah rendering queue di addition untuk crawl queue yang applies untuk semua halaman.” Treat itu sebagai evidence itu konten requiring rendering sisi klien carries sebuah nyata time-untuk-indeks cost di itu study — tidak sebagai proof itu sebuah spesifik render-blocking CSS atau JS file adalah apa triggers queueing.
pada file size: Google’s crawling documentation mendeskripsikan sebuah 2 MB fetch limit per
non-PDF URL, including header HTTP, applied secara terpisah untuk setiap individual
resource ini permintaan — so sebuah besar <head> script atau stylesheet mendapatkan -nya own 2 MB
counter, tidak sebuah shared budget dengan HTML. itu’s sebuah fetch/truncation boundary,
tidak sebuah “processing limit,” (terjemahan) “processing limit,” dan Google tidak document sebuah special crawl atau pengindeksan
penalty tied secara khusus untuk render-blocking resources beyond itu umum
truncation risk.
Worth debunking sementara kami’re di sini: Google’s renderer memiliki Tidak fixed timeout. sebagai I’ve terdokumentasi di my JavaScript SEO guide, “di sana adalah Tidak fixed timeout untuk itu renderer. It berjalan dengan a sped-up timer untuk see jika apa pun adalah added di a kemudian time.” (terjemahan) “tidak ada fixed timeout untuk renderer. ini berjalan dengan sebuah sped-up timer untuk see jika apa pun adalah ditambahkan di sebuah kemudian time.” concern tidak sebuah 5-kedua cutoff — ini adalah queueing delay sebelum rendering bahkan begins.
ini bahkan reaches AI crawler now. Gary Illyes argued di 2026 itu “jika sites digunakan relatively good HTML dan Tidak JavaScript (atau SSR), keduanya base model training, dan web dan agentic RAG akan menjadi a piece dari cake dari mentah data processing perspective.” (terjemahan) “jika situs digunakan relatively baik HTML dan Tidak JavaScript (atau SSR), keduanya base model training, dan web dan agentic RAG akan menjadi sebuah piece dari cake dari mentah data processing perspective.” Berat client-side JS adalah sebuah masalah well beyond Googlebot.
cara temukan them
- Chrome DevTools performa panel / Lighthouse 13 — saat ini “Render
blocking requests” (terjemahan) “Render
blocking permintaan” Insight (yang, sebagai dari Lighthouse 13, adalah di mana older
“Eliminate render-blocking resources” (terjemahan) “Eliminate render-blocking resources” audit moved) flags scripts di
<head>missingasync/deferdan stylesheets tanpa sebuahdisabledatau non-matchingmediaattribute, dan estimates ms Anda’d save dari satu observed trace. Connor Clark’s tulis-up puts ini plainly: “render-blocking requests adalah network requests itu cegah a halaman’s awal render, potentially delaying Largest Contentful Paint.” (terjemahan) “render-blocking permintaan adalah network permintaan itu mencegah sebuah halaman’s awal render, potentially delaying Largest Contentful Paint.” jika Anda’re reading older PageSpeed Insights output itu masih says “Eliminate render-blocking resources,” (terjemahan) “Eliminate render-blocking resources,” ini adalah yang sama underlying sinyal di bawah pre-Lighthouse-13 name. - Chrome DevTools Coverage tab — marks bytes green (critical — digunakan untuk pertama paint) atau red (unused di pertama paint). Lots dari red CSS/JS adalah Anda candidate list.
- WebPageTest waterfall — lihat semuanya sebelum Mulai Render line.
- Jalankan ini lebih daripada setelah — sebuah single trace reflects itu jalankan’s consent-manager state, ketiga-party tag muat, cache state, dan CSP perilaku. Repeat trace (cold dan warm) sebelum treating satu flagged resource sebagai sebuah fixed fact.
sebuah illustrative navigation berisi HTML dari 0 untuk 180 milliseconds, blocking CSS dari 120 untuk 420 milliseconds, synchronous JavaScript dari 210 untuk 610 milliseconds, sebuah non-blocking analytics permintaan dari 250 untuk 500 milliseconds, dan font memuat dari 420 untuk 610 milliseconds. pertama paint occurs di 610 milliseconds. contoh menjelaskan timing mechanics; ini adalah tidak sebuah langsung trace.
cara perbaiki them
JavaScript
defernon-critical scripts —<script src="app.js" defer></script>. Parallel download, ordered execution setelah parse. safe default untuk Anda own JS.asyncuntuk independent ketiga-party scripts —<script src="analytics.js" async></script>. hanya ketika order dan DOM-readiness genuinely jangan penting.- Move scripts untuk end dari
<body>— older fallback ketika Anda dapat’t tambahkan attributes; parser reaches them terakhir.
CSS — sebagai conditional decisions, tidak blanket patterns
- Inline critical CSS hanya ketika sebuah trace menampilkan CSS adalah sebenarnya bottleneck —
extract styles needed untuk di atas—fold konten ke sebuah inline
<style>block so pertama paint perlu Tidak round-trip. Google’s own caution applies: “inlining CSS adalah an advanced performance technique itu dapat improve performance, tetapi dapat juga lead untuk bugs jika tidak implemented properly.” (terjemahan) “inlining CSS adalah sebuah advanced performa technique itu dapat meningkatkan performa, tetapi dapat juga lead untuk bugs jika tidak implemented properly.” Inline hanya critical subset, name sebuah owner untuk regenerating ini ketika templates perubahan, dan periksa untuk drift di seluruh halaman status — sebuah critical-CSS snapshot itu goes stale silently reintroduces flashes dari unstyled konten atau missing styles. - Defer rest, matching permintaan persis — muat penuh stylesheet dengan
<link rel="preload" as="style" onload="this.rel='stylesheet'">pattern. sebuah preload hanya mendapatkan reused untuk eventual permintaan jika URL,as,type, dancrossorigin/CORS mode match — sebuah mismatched hint penyebab browser untuk fetch resource twice alih-alih skipping round-trip. mediaattributes —media="print"ataumedia="(min-width: 900px)"lets browser download sebuah stylesheet tanpa blocking render ketika kueri tidak match.- hapus unused CSS dan minify — lebih sedikit untuk block pada, lebih cepat downloads.
- Verify sebelum shipping — re-periksa untuk duplicate/unused fetches, FOUC, dan baru layout shift setelah apa pun critical-CSS atau preload perubahan, pada sebuah repeated trace, tidak sebuah single lucky jalankan.
Platform-spesifik (WordPress) — WP Rocket (delay/defer JS, mengoptimalkan CSS pengiriman),
Autoptimize (async/defer JS, inline critical CSS), dan Async JavaScript implement semua
dari di atas melalui plugin UI. mereka’re applying yang sama async/defer/critical-CSS
techniques — knowing apa setiap setting melakukan adalah bagaimana Anda hindari breaking Anda theme.
Related reading pada ini situs
- Core Web Vitals — parent metric set ini rolls up ke.
- Largest Contentful Paint — metric render-blocking resources hit hardest.
- pertama Contentful Paint — pertama hal mereka delay.
- Total Blocking Time — main-utas cost dari berat JS.
- PageSpeed Insights — alat itu surfaces audit.
- rendering dan anggaran crawling — crawl/render queue angle.
AI summary
sebuah condensed take pada Advanced versi:
- Render-blocking resources adalah CSS dan synchronous JavaScript pada critical
rendering path. sebuah applicable stylesheet (
<head>, matchingmedia, tidakdisabled, tidak dynamically inserted) adalah render-blocking oleh default; sebuah parser-inserted<script>tanpaasync/deferadalah parser-blocking oleh default, yang adalah related untuk tetapi formally distinct dari HTML spec’sblocking="render"attribute (head-hanya; diperlukan untuk dynamically inserted scripts/stylesheets). async= parallel download, executes ketika ready, unordered, dapat interrupt parsing — gunakan untuk independent ketiga-party scripts.defer= parallel download, executes setelah parse, di order — gunakan untuk Anda own/DOM-dependent code. Module scripts (type="module") defer oleh default.- SEO chain: mereka dapat delay FCP dan LCP (sebuah flagged resource tidak proof ini adalah dominant bottleneck); LCP adalah digunakan oleh Google’s Core Web Vitals peringkat sistem (baik ≤2,5 s). Google documents Tidak direct render-blocking peringkat weight atau jaminan — “a fast website adalah a little lebih helpful… konten adalah masih itu king.” (terjemahan) “sebuah fast situs web adalah sebuah little lebih helpful… konten adalah masih king.”
- crawl angle, corrected: semua eligible 200-status halaman enter Google’s rendering queue regardless dari JavaScript presence — render-blocking resources jangan buat special queue pada-ramp. Google fetches di sebagian besar 2 MB per non-PDF URL (including headers), per resource — sebuah fetch/truncation boundary, tidak sebuah render-blocking-spesifik processing penalty. Onely’s study ditemukan Google took 9× lebih lama untuk fully crawl JS-dirender halaman daripada HTML di mereka test — evidence dari sebuah rendering-langkah cost, tidak proof sebuah spesifik blocker triggers queueing. Tidak fixed renderer timeout — cost adalah queueing, tidak sebuah cutoff.
- temukan: Lighthouse 13’s “Render blocking requests” (terjemahan) “Render blocking permintaan” Insight (formerly “Eliminate render-blocking resources” (terjemahan) “Eliminate render-blocking resources”); DevTools Coverage tab (green = critical, red = unused); WebPageTest waterfall sebelum Mulai Render. Repeat trace — consent, ketiga-party, dan cache state dapat perubahan hasil jalankan untuk jalankan.
- Perbaiki:
defernon-critical JS,asyncindependent ketiga-party JS; inline critical CSS hanya di mana sebuah trace menampilkan ini adalah bottleneck (dengan sebuah owner untuk mempertahankan ini di sync) dan defer rest, matching preload’sas/type/crossoriginpersis;mediaattributes untuk conditional stylesheets; hapus unused CSS dan minify; verify dengan sebuah repeated, cocok trace sebelum shipping.
Dokumentasi resmi
Utama-sumber guidance dari Google dan Bing.
«Google / Chrome
- Render blocking requests (Chrome DevTools Performance Insights) — the current authoritative explainer (Connor Clark, Oct 2025), and the Lighthouse 13 Insight this topic now lives under: defer, inline, reduce payload.
- Eliminate render-blocking resources (legacy Lighthouse audit) — still live but carries a banner that it moved into the Insight above as of Lighthouse 13; kept here for readers on older reports.
- Optimize Largest Contentful Paint — how render-blocking CSS and synchronous scripts delay LCP (Philip Walton & Barry Pollard).
- Critical rendering path — the underlying parse → CSSOM → render-tree → paint sequence (Ilya Grigorik).
- Remove render-blocking JavaScript (legacy PageSpeed docs) — deprecated PSI v4, but the parser-blocking mechanics are still accurate.
- Core Web Vitals & Google Search — LCP thresholds and how CWV relate to ranking. » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian enam puluh tiga, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.) «- Understand the JavaScript SEO basics — confirms all eligible 200-status pages enter the rendering queue regardless of JavaScript presence.
- Understanding page experience in Google Search results — the current, bounded language on how Core Web Vitals relate to ranking (no direct render-blocking weight documented). » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian enam puluh tiga, bagian kecil dua: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
HTML / browser spec (mechanics)
<script>: Script element (MDN) —async/defersemantics, module default-defer, danblocking="render"attribute (head-hanya; diperlukan untuk dynamically inserted scripts).<link>: External Resource tautan element (MDN) — stylesheetmedia/disabledperilaku,blockingattribute, dan preload’sas/type/crossoriginpermintaan-matching requirements.- HTML Standard — script element (WHATWG) — formal parser-blocking dan render-blocking definitions ini artikel’s script bagian adalah berdasarkan.
Bing / Microsoft
- bingbot Series: JavaScript, Dynamic rendering, dan Cloaking — mengapa JS di scale adalah hard untuk Bingbot, dan dynamic rendering sebagai sebuah acceptable workaround (Fabrice Canel & Frédéric Dubut).
- Bing Webmaster Guidelines — kecepatan halaman sebagai sebuah peringkat factor; minimizing render-blocking JavaScript.
Quotes dari sumber
pada—record statements. setiap tautan deep-tautan untuk quoted passage di mana sumber halaman memungkinkan ini.
Google / Chrome — mechanics
«- “The goal is to reduce the impact of these render-blocking URLs by inlining critical resources, deferring non-critical resources, and removing anything unused.”
— Chrome Lighthouse docs.
Jump to quote
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “Render-blocking requests are network requests that prevent a page’s initial render, potentially delaying Largest Contentful Paint (LCP).”
— Connor Clark, Chrome DevTools Performance Insights.
Jump to quote
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil dua: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “Style sheets loaded from the HTML markup will block rendering of all content that follows them.”
— web.dev, Optimize LCP (Philip Walton & Barry Pollard).
Jump to quote
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil tiga: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “It is almost never necessary to add synchronous scripts (scripts without the async or defer attributes) to the head of your pages.”
— web.dev, Optimize LCP.
Jump to quote
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil empat: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “Optimizing the critical rendering path refers to prioritizing the display of content that relates to the current user action.”
— Ilya Grigorik, web.dev, Critical rendering path.
Jump to quote
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil lima: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “Avoid and minimize the use of blocking JavaScript, especially external scripts that must be fetched before they can be executed.”
— Google PageSpeed Insights docs (legacy).
Jump to quote
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil enam: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “All pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.”
— Google, Understand the JavaScript SEO basics.
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil tujuh: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
«- “Only script elements in the document’s <head> can possibly block rendering” and, for dynamic insertion, “you must set blocking = "render" for it to block rendering.”
— MDN, <script>: The Script element.
» (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh satu, bagian kecil delapan: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
Bing / Microsoft
«- “It is difficult for bingbot to process JavaScript at scale on every page of every website, while minimizing the number of HTTP requests.” — Fabrice Canel & Frédéric Dubut, Microsoft Bing. Jump to quote » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh tiga, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
Industry research — crawl-queue cost
«- “Pages that require rendering have to wait in a rendering queue in addition to the crawl queue which applies to all pages.” — Ziemek Bućko, Onely (Google needed 9× longer to crawl JS than HTML). Jump to quote » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh lima, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.) «- “You can do this by deferring the loading of non-critical CSS and JavaScript files needed for ‘below the fold’ content until later.” — Joshua Hardwick, Ahrefs. Jump to quote » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian tujuh puluh lima, bagian kecil dua: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
Note: Gary Illyes 2026 “JavaScript mess” (terjemahan) “JavaScript mess” quote dan Martin Splitt “a fast website is a little more helpful than a slow website” (terjemahan) “sebuah fast situs web adalah sebuah little lebih helpful daripada sebuah slow situs web” / “content is still the king” (terjemahan) “konten adalah masih king” lines digunakan di Advanced versi adalah relayed melalui sekunder coverage (ppc.land’s reproduction dari Illyes’ LinkedIn post; Dean panjang’s compilation). Konfirmasi terhadap originals sebelum treating them sebagai akhir.Render-blocking perbaiki checklist
berfungsi top untuk bottom — diagnose pertama, lalu perbaiki highest-savings items.
- Jalankan PageSpeed Insights / Lighthouse dan open saat ini “Render blocking requests” (terjemahan) “Render blocking permintaan” Insight (Lighthouse 13; older reports dapat masih label ini “Eliminate render-blocking resources” (terjemahan) “Eliminate render-blocking resources”); note estimated ms savings per resource sebagai sebuah lead, tidak sebuah jaminan.
- Open DevTools Coverage tab dan reload — flag stylesheets/scripts itu adalah mostly red (unused di pertama paint).
- tambahkan
deferuntuk setiap non-critical<script>itu bergantung pada DOM atau pada lainnya scripts. - gunakan
asynchanya untuk genuinely independent ketiga-party scripts (analytics, ads) — tidak pernah untuk ordered atau DOM-dependent code. - Konfirmasi Tidak synchronous
<script>sits di<head>tanpaasync/defer. - Inline hanya critical (di atas—fold) CSS; muat rest dengan
preload+onloadpattern — jangan inline semuanya. - tambahkan
mediaattributes untuk conditional stylesheets (print, breakpoint kueri) so mereka download tanpa blocking. - hapus unused CSS dan minify semua CSS/JS untuk shrink download time.
- pertahankan individual JS/CSS files well di bawah Google’s 2 MB per-URL fetch limit (mencakup header HTTP; ini adalah sebuah truncation boundary, tidak sebuah render-blocking penalty, tetapi sebuah truncated file dapat masih break behind scenes).
- Re-test pada sebuah repeated, cocok trace (cache/consent/ketiga-party state dapat shift hasil) dan periksa field LCP — aim untuk land LCP ≤2,5 s di 75th percentile.
- Sanity-periksa halaman visually setelah CSS inlining — ini adalah langkah sebagian besar mungkin untuk introduce bugs.
Render-blocking cheat sheet
async vs defer vs plain <script>
| Attribute | Blocks parser? | Download | Execution order | gunakan untuk |
|---|---|---|---|---|
none (sync <script>) | Ya | Pauses parsing untuk fetch | Immediately, blocks render | Hampir tidak pernah di <head> |
async | Tidak (selama download) | Parallel | Ketika ready — unordered, dapat interrupt parse | Independent ketiga-party scripts (analytics, ads) |
defer | Tidak | Parallel | setelah HTML parsed — di document order | Anda own / DOM-dependent code |
adalah ini resource render-blocking?
| Resource | Render-blocking? | cara un-block ini |
|---|---|---|
<link rel="stylesheet"> di <head>, applicable | Ya (default) | Non-matching media, disabled, atau preload+onload |
<link media="print"> (pada sebuah screen visit) | Tidak | (sudah non-blocking) |
| Stylesheet inserted dynamically melalui script | Tidak, unless blocking="render" set | tambahkan blocking="render" hanya jika Anda secara khusus perlu ini untuk block |
Sync <script> di <head> (Tidak async/defer) | Parser-blocking oleh default | tambahkan defer (atau async jika independent) |
<script defer> / <script async> / <script type="module"> | Tidak | — |
| Inline critical CSS | Tidak | (itu’s poin — pertahankan ini kecil) |
Fast facts
- LCP “good” (terjemahan) “baik” threshold: ≤ 2,5 s di 75th percentile dari data lapangan (28-day window).
- Google fetches di sebagian besar 2 MB per non-PDF URL (including headers), counted secara terpisah untuk setiap referenced JS/CSS file — sebuah fetch/truncation boundary, tidak sebuah terdokumentasi render-blocking-spesifik penalty.
- semua eligible 200-status halaman enter Google’s rendering queue regardless dari apakah JavaScript adalah present — render-blocking resources jangan buat special queue pada-ramp.
- Google’s renderer memiliki Tidak fixed timeout — cost adalah rendering queue, tidak sebuah cutoff.
- Lighthouse 13’s “Render blocking requests” (terjemahan) “Render blocking permintaan” Insight (formerly “Eliminate
render-blocking resources” (terjemahan) “Eliminate
render-blocking resources” audit) flags head scripts missing
async/defer, dan stylesheets tanpadisabled/ non-matchingmedia, dari satu observed trace — re-test untuk konfirmasi. - DevTools Coverage: green = critical, red = unused di pertama paint.
- Inlining CSS adalah advanced — inline hanya critical subset di mana sebuah trace menampilkan ini adalah bottleneck; inlining semua dari ini kills caching dan penyebab bugs.
- Preload hanya mendapatkan reused jika
as/type/crossoriginmatch eventual permintaan — sebuah mismatch penyebab sebuah duplicate fetch.
Diagnose render-blocking masalah oleh symptom
halaman tetap blank sebelum appearing semua di setelah
mungkin penyebab: sebuah stylesheet atau synchronous head script adalah holding pertama paint. Perbaiki: inspect document’s early permintaan chain, lalu defer non-critical JavaScript dan split atau reduce non-critical CSS. Konfirmasi: sebuah baru trace paints berguna konten sebelum itu non-critical files finish.
defer melakukan tidak meningkatkan pertama paint
mungkin penyebab: CSS atau lainnya synchronous script adalah masih critical blocker, atau deferred script adalah tidak bottleneck. Perbaiki: bandingkan sebelum/setelah permintaan chain dan main-utas activity alih-alih assuming setiap script blocks rendering. Konfirmasi: remaining critical path identifies berikutnya resource itu gates paint.
halaman flashes unstyled setelah deferring CSS
mungkin penyebab: styles needed untuk awal viewport adalah moved out dari critical path. Perbaiki: pertahankan truly critical CSS tersedia untuk pertama render dan defer hanya aturan tidak needed namun. Konfirmasi: sebuah throttled filmstrip menampilkan styled konten dari pertama painted frame.
sebuah perbaiki improves FCP tetapi membuat layout shifts
mungkin penyebab: deferred styles atau late component initialization perubahan geometry setelah paint. Perbaiki: pertahankan sizing dan layout-critical aturan di awal render. Konfirmasi: lebih cepat pertama paint tetap dan Layout Shifts track menampilkan Tidak baru instability.
audit flags sebuah berbeda resource pada berikutnya jalankan
mungkin penyebab: consent-manager gating, ketiga-party tag muat order, CSP, service-worker caching, atau plain cache state changed apa mendapat ditemukan atau executed antara berjalan — sebuah single trace tidak sebuah permanent classification. Perbaiki: repeat trace di seluruh status itu penting (pertama visit vs. cached, consent accepted vs. declined) sebelum treating satu jalankan’s flagged resource sebagai perbaiki target. Konfirmasi: yang sama resource masih menampilkan sebagai dominant blocker di seluruh cocok, repeated traces.
Simplified render-blocking contoh
«### Parser-blocking script versus deferred script » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian seratus tujuh, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
pertama script berhenti HTML parsing. kedua downloads di parallel dan menunggu until parsing adalah menyelesaikan.
<!-- Blocks the parser -->
<script src="app.js"></script>
<!-- Better for a script that depends on the parsed document -->
<script defer src="app.js"></script>Satu stylesheet untuk setiap viewport versus conditional CSS
media attribute mempertahankan sebuah print-hanya stylesheet dari blocking screen render.
<link rel="stylesheet" href="screen.css">
<link rel="stylesheet" href="print.css" media="print">Critical styles sebelum deferred bundle
ini simplified pattern membuat kecil awal layout tersedia immediately. Production implementations masih perlu testing untuk CSP, caching, dan flashes dari unstyled konten.
<style>
.site-header { min-height: 4rem; }
</style>
<link rel="stylesheet" href="site.css"> Prompt: classify critical resources
Paste sebuah DevTools Network export atau sebuah list dari document’s early CSS dan JavaScript permintaan.
Act as a web-performance reviewer. Classify each supplied CSS or JavaScript
resource as required for the first viewport, required after HTML parsing, or
non-critical. For every classification, cite the evidence present in my input.
Recommend only one of: keep blocking, defer, async, conditional media, split,
or remove. Flag anything you cannot decide without inspecting runtime behavior.
Do not assume that every stylesheet or script is safe to delay.
INPUT:
[paste the request list, initiators, timing, and what the resource controls]Prompt: review sebuah implementation diff
Review this HTML/CSS/JavaScript diff for render-path regressions. Check script
ordering, DOM dependencies, critical CSS coverage, flashes of unstyled content,
layout-shift risk, duplicate downloads, and failure when JavaScript is delayed.
Return a table with: finding, evidence from the diff, user-visible risk, test to
run, and safest correction. Do not invent page behavior not shown in the input.
DIFF:
[paste the diff] «## List potentially blocking head resources » (Terjemahan) (Ringkasan bahasa Indonesia untuk bagian seratus dua puluh lima, bagian kecil satu: teks sumber dipertahankan agar dapat diperiksa dalam tinjauan penutur asli.)
Paste ini ke DevTools Console. hasil adalah sebuah audit queue, tidak sebuah instruction untuk defer semuanya.
const headResources = [...document.head.querySelectorAll('link[rel="stylesheet"], script[src]')]
.map((element) => ({
type: element.tagName.toLowerCase(),
url: element.href || element.src,
async: element.tagName === 'SCRIPT' ? element.async : undefined,
defer: element.tagName === 'SCRIPT' ? element.defer : undefined,
media: element.tagName === 'LINK' ? element.media || 'all' : undefined,
}));
console.table(headResources);temukan resources itu finished sebelum pertama paint
const firstPaint = performance.getEntriesByName('first-contentful-paint')[0]?.startTime;
console.table(
performance.getEntriesByType('resource')
.filter((entry) => firstPaint && entry.responseEnd <= firstPaint)
.map((entry) => ({ name: entry.name, type: entry.initiatorType, end: Math.round(entry.responseEnd) }))
);Resources di ini list consumed time sebelum FCP, tetapi timing alone melakukan tidak prove itu sebuah resource blocked rendering. Konfirmasi dengan trace dan dependency chain.
alat untuk finding render blockers
- PageSpeed Insights dan Lighthouse: identify render-blocking permintaan opportunities di sebuah repeatable lab jalankan. Treat estimated savings sebagai sebuah lead alih-alih sebuah jaminan.
- Chrome DevTools performa panel: connect permintaan, HTML parsing, script execution, style calculation, dan pertama painted frame pada satu timeline.
- Chrome DevTools Network panel: inspect permintaan priority, initiators, timing, protocol, cache perilaku, dan order di yang critical files arrive.
- Chrome DevTools Coverage panel: temukan unused CSS dan JavaScript di recorded journey. Coverage dari satu route adalah tidak permission untuk delete code digunakan elsewhere.
- WebPageTest: bandingkan waterfalls dan filmstrips di bawah berbeda locations dan connection profiles.
berguna workflow adalah Lighthouse untuk clue, performa dan Network panels untuk penyebab, lalu sebuah throttled sebelum/setelah recording untuk proof.
Prove sebuah render-blocking perbaiki worked
Deferred-script test
Test untuk jalankan: record sebuah cold, throttled muat sebelum dan setelah menambahkan defer, lalu inspect parsing dan pertama paint. Yang diharapkan hasil: HTML parsing continues sementara script downloads dan halaman masih initializes correctly setelah parsing. Failure interpretation: script bergantung pada immediate execution atau ordering adalah changed incorrectly. Monitoring window: immediate di repeated traces. Rollback trigger: missing konten, JavaScript errors, atau rusak interactions.
Conditional-stylesheet test
Test untuk jalankan: muat setiap relevant viewport dan media mode sementara recording Network dan performa panels. Yang diharapkan hasil: non-matching CSS melakukan tidak delay screen’s pertama render, sementara matching layouts tetap styled. Failure interpretation: critical aturan adalah placed di wrong bundle atau media condition adalah incomplete. Monitoring window: immediate di seluruh didukung breakpoints. Rollback trigger: unstyled konten, incorrect print output, atau baru layout shifts.
Critical-path perbandingan
Test untuk jalankan: bandingkan yang sama halaman, device profile, dan cold-cache conditions sebelum dan setelah perubahan, dan repeat setiap side dari perbandingan alih-alih relying pada sebuah single trace. Yang diharapkan hasil: blocking chain dan FCP/LCP timing meningkatkan consistently di seluruh cocok, repeated berjalan alih-alih di satu lucky jalankan. Failure interpretation: variance, lainnya bottleneck, atau sebuah runtime-state perbedaan (consent state, ketiga-party tag timing, CSP, service-worker cache) menjelaskan apparent gain. Monitoring window: several controlled lab berjalan, diikuti oleh field monitoring. Rollback trigger: field LCP, CLS, errors, atau conversion perilaku worsens setelah rilis.
Uji pemahaman Anda: Render-Blocking Resources
Five quick pertanyaan pada render-blocking CSS dan JavaScript. Pick sebuah jawaban untuk setiap, lalu periksa.
Log perubahan
Diperbarui 27 Jul 2026.
Ringkasan editorial dan detail perubahan yang tercatat.Detail perubahan
-
Catatan perubahan terperinci saat ini tersedia dalam bahasa Inggris.
Perbandingan lengkap tidak tersedia — tidak ada cuplikan sebelumnya yang diarsipkan untuk revisi ini.
Diperbarui 18 Jul 2026.
Ringkasan editorial dan detail perubahan yang tercatat.Detail perubahan
-
Catatan perubahan terperinci saat ini tersedia dalam bahasa Inggris.
-
Catatan perubahan terperinci saat ini tersedia dalam bahasa Inggris.
-
Catatan perubahan terperinci saat ini tersedia dalam bahasa Inggris.
-
Catatan perubahan terperinci saat ini tersedia dalam bahasa Inggris.
-
Catatan perubahan terperinci saat ini tersedia dalam bahasa Inggris.
Perbandingan lengkap tidak tersedia — tidak ada cuplikan sebelumnya yang diarsipkan untuk revisi ini.