Why render-blocking scripts hurt speed
When the browser meets a script in the head without async or defer, it stops building the page, downloads and runs the script, and only then continues. Every blocking script delays the first paint and can push back Largest Contentful Paint. Heavy third-party scripts such as ad tags, chat widgets and trackers also compete for the main thread, which is a common reason pages feel slow to respond to taps and clicks.
What this scan reports
- Every external script in the HTML, whether it sits in the head or body, and whether it uses async, defer or type=module.
- Which scripts are render-blocking: head scripts with none of those attributes.
- Third-party scripts grouped by host, with a label for well-known analytics, advertising, chat and library services.
- Stylesheets that block rendering, and how much inline script the page carries.
- Whether the page uses preconnect or preload hints.
How to fix what it finds
Each blocking script in the results has a Copy defer tag button that gives you the same tag with defer added. Test the page after switching, because a few scripts depend on running in a fixed order or before the page content.
Add defer to scripts that need the DOM and async to independent ones such as analytics. Move non-critical scripts to the end of the body or load them after interaction. Remove tags you no longer use, since each one costs time. Self-host or lazy-load third-party widgets where you can, and use preconnect for hosts you must call early. After changes, re-scan to confirm the blocking count dropped.
What it does not measure
This is a static read of your HTML, so it does not run the page and cannot measure LCP, INP or exact script cost. Scripts that a tag manager injects after load will not appear. Use it to find candidates, then confirm the real impact with PageSpeed Insights or the Performance panel in Chrome DevTools.