Render-blocking checker. CSS + JS that blocks paint.
Enter a URL. We pull PSI's render-blocking-resources audit and list every stylesheet or script that blocks initial paint, with file size, time savings if eliminated, and per-file fix recommendation.
Enter a URL. We pull Google PSI's render-blocking-resources audit and list every CSS or JS file that blocks initial paint, with byte size + estimated time savings if eliminated.
Sources used
- Google PSI v5 API — render-blocking-resources audit source
- web.dev render-blocking guide — fix patterns + critical CSS approach
- MDN script async vs defer
- web.dev LCP guide — render-blocking impact on LCP
URL is sent only to Google PSI. Digital Heroes does not log queries.
Privacy: URL is sent only to Google PSI.
The critical path is the LCP path.
Render-blocking resources are CSS or JS in the head that the browser must download + parse + execute before painting the first pixel. Each blocking resource adds round-trip latency to LCP (Largest Contentful Paint) — typically the difference between a 2.0s LCP (passing Google's threshold) and a 3.5s LCP (failing). The checker above pulls PSI's render-blocking-resources audit and shows every offending file with byte size + estimated time savings if eliminated.
Three fix patterns ranked by impact. Critical CSS — extract above-the-fold styles, inline them in head, async-load the rest via rel="preload" as="style" onload="this.rel=stylesheet". async / defer attributes on JS — async for independent scripts, defer for DOM-dependent. Move non-essential scripts out of head — analytics, chat widgets, A/B testing tools belong before </body> or lazy-loaded on interaction. The web.dev render-blocking guide is the canonical reference.
Tools in the same cluster: Page Weight Analyzer for the byte breakdown by type. JavaScript Size Checker for the JS-only deep dive. Core Web Vitals Checker for the LCP impact view.
Five answers.
What are render-blocking resources?
Render-blocking resources are CSS or JS files in the HTML head that the browser must download, parse, and execute before it can render the first pixel. Synchronous <link rel=stylesheet> tags block render until the CSS is fetched + parsed. Synchronous <script> tags (no async, no defer attribute) block until fetched + parsed + executed. Each blocking resource adds round-trip + processing latency to LCP, often the difference between a 2.0s LCP (passing) and a 3.5s LCP (failing).
How do I un-block a CSS file?
Three options. One, inline critical CSS — extract the above-the-fold styles, inline them in the head, and load the rest asynchronously via media-print toggle (rel=preload then onload swap to stylesheet). Two, defer non-critical stylesheets — move them out of head into the body, or use rel=preload with media query so they fetch but don't block. Three, eliminate unused CSS via PurgeCSS at build time. Tailwind CSS's JIT mode handles this automatically.
How do I un-block a JS file?
Add async or defer to <script> tags in the head. async fetches in parallel and executes as soon as ready (order not guaranteed; use for independent scripts like analytics). defer fetches in parallel and executes in document order after parse (use for scripts that depend on DOM). Move non-essential scripts out of the head entirely. Lazy-load heavy libraries (chat widgets, video players) only when needed via Intersection Observer or user interaction trigger.
Why does this matter for Core Web Vitals?
Render-blocking resources directly impact LCP (Largest Contentful Paint) and FCP (First Contentful Paint). LCP is one of three Core Web Vitals (along with INP and CLS) that Google uses as ranking signals. Pages with render-blocking critical paths over 1.5 seconds typically fail LCP's 2.5s good threshold. Eliminating render-blocking resources is the single highest-impact performance work for most sites.
Does this tool save my data?
The URL is sent only to Google's public PageSpeed Insights API. Nothing is logged on Digital Heroes servers.
Critical path over 1.5s?
Our web development engagements ship critical-CSS extraction, async/defer JS audit, and third-party script lazy-loading — typically a 30-50% LCP improvement in 2 weeks.
Published · Last updated .