Skip to content
Raptor home
Menu

Render-blocking script

javascript.js_render_blocking
Priority
Low
Severity
Warning

What we look for

These pages load a script file in <head> without async, defer or type="module", so the browser stops drawing the page until the script has downloaded and run.

Why it matters

Visitors look at a blank screen for longer, which hurts first impressions and the loading measures Google uses.

How to fix

Add defer to the script tag (or async if no other script depends on it), or move the tag to the end of <body>. If the script is not needed on every page, load it only where it is used.

Seen in a real crawl

From a crawl of the js-heavy fixture, a test site from Raptor’s fixture suite.

Low

2 pages wait for a script before showing anything

  • /1 render-blocking script(s): /assets/app.js
  • /about/1 render-blocking script(s): /assets/app.js
Paths on http://127.0.0.1:8004raptor 0.3.0, 17 Oct 2026

Open this finding in that crawl’s report

Where you’ll see it

The id is stable, and every surface uses it, so it’s the thing to search for or hand to an agent.

Terminal
When it is one of the five findings under Fix first, raptor crawl prints the id under it.
Check: javascript.js_render_blocking
crawl.json and the CSV
The crawl JSON names the finding by this id, and so do the CSV and raptor_query.
"check_id": "javascript.js_render_blocking"
The HTML report
This link opens the finding in the report, and each finding shows its id.
crawl.html#finding=javascript.js_render_blocking
MCP
raptor_findings with this check_id returns the finding in full, with a fix brief ready to paste into a task. If it didn’t fire, it says why.
raptor_findings {
  "job_id": "...",
  "check_id": "javascript.js_render_blocking"
}