Render Blocking Resources Checker - Free Tool

This render-blocking resources checker reads the HTML head you paste and lists every stylesheet and script that can hold up the first paint of your page. You get a count of potential blockers, a list of deferred or conditional files, and a suggested fix for each blocker. It is free and needs no sign-in.

What Are Render-Blocking Resources?

A render-blocking resource is a file the browser must download and process before it can show anything on screen. In practice that means CSS stylesheets and JavaScript files loaded in the head of the page without special loading attributes.

Browsers build the page in a fixed order. They read the HTML, construct the document tree, and need all applicable CSS before they can paint. A normal script tag also pauses HTML parsing until the file is fetched and run. While that happens, visitors see a blank or half-built page.

This delay feeds directly into Core Web Vitals, especially Largest Contentful Paint, and into the "Eliminate render-blocking resources" advice you may have seen in Lighthouse and PageSpeed reports. Google's web.dev guidance describes the same idea as the critical rendering path: the shorter the chain of files needed for the first paint, the faster the page appears.

Which files block and which do not?

• A stylesheet link with no media restriction blocks rendering.
• A stylesheet limited to print media does not block screen rendering.
• A script with a source and no defer or async blocks HTML parsing.
• A script with defer, async or a module type does not block parsing.

How to Use the Render-Blocking Resource Finder

You paste markup, press one button and read the report. The whole check takes a few seconds.

1. Open your page in a browser, view its source, and copy the head section. Copying the full document also works, because the tool looks at every stylesheet link and script source it finds.
2. Paste the code into the box labeled HTML Source Code (paste the head section).
3. Click Find Render-Blocking Resources. If the box is empty, you will see a prompt asking you to paste some HTML.
4. Read the three counters at the top: Potential blockers, Deferred / conditional, and Total Resources.
5. Open the Potential Render-Blocking Resources table. Each row shows the type (CSS or JS), the file URL and a recommended fix.
6. Check the second table for files that are deferred, disabled or conditional, and read the suggestion list below it.
7. Apply the fixes in your theme, template or optimization plugin, then paste the updated head and run the check again.

Worked Example: A Head With Five Resources

Suppose your head contains these five lines:

• <link rel="stylesheet" href="/css/main.css">
• <link rel="stylesheet" href="/css/print.css" media="print">
• <script src="/js/jquery.js"></script>
• <script src="/js/analytics.js" async></script>
• <script src="/js/app.js" defer></script>

The tool reports 2 potential blockers, 3 deferred or conditional resources and 5 total resources. The blockers are the main stylesheet and the jQuery file. The print stylesheet is marked as non-blocking because it applies only to printed pages. The async and defer scripts are marked non-blocking by their attributes.

For the main stylesheet, the suggested fix is to use critical CSS or load it with a print media swap. For jQuery, the fix is to add defer or async. If your inline code depends on jQuery running first, choose defer, because deferred scripts run in order after parsing finishes.

How Do You Read and Act on the Results?

The report separates files that can delay the first paint from files that cannot, so you know where to spend your time. A count of zero blockers is the goal, but a small number of blockers is normal, and one stylesheet is often unavoidable.

Potential blockers

Each row here is a stylesheet without a media restriction or a script without defer, async or a module type. Treat CSS rows and JS rows differently. Scripts are usually easy to fix by adding an attribute. Stylesheets need more care, because removing a needed stylesheet from the critical path can cause unstyled content to flash.

Deferred / conditional

These files should not hold up the first paint in the same way. The Status column tells you why each one was placed here.

Suggestions

The list under the tables changes with what was found. JavaScript blockers trigger advice to defer scripts or move them lower in the body. CSS blockers trigger advice to inline critical CSS and load the rest asynchronously. If nothing is found, you will see a message saying no render-blocking resources were detected in the provided HTML.

How Do You Eliminate Render-Blocking Resources?

You eliminate them by deferring what is not needed for the first screen and delivering what is needed as early and as small as possible. Work through the list in this order.

1. Defer scripts first. Add defer to scripts that do not need to run before the page is parsed. Use async only for independent scripts such as analytics.
2. Inline critical CSS. Place the small set of rules needed for above-the-fold content in the head, and load the full stylesheet without blocking.
3. Split large stylesheets. Use media attributes so print styles or large-screen styles do not hold up every visitor.
4. Remove unused files. A plugin script that loads on every page but is used on one is the cheapest fix of all.
5. Shrink what remains. Smaller files download faster, so confirm your server sends them compressed with a GZIP compression check.

WordPress and Elementor sites

On WordPress, most blocking files come from the theme, page builder and plugins, and you rarely edit the head by hand. Paste your rendered page head into the tool to see which files are involved, then use your caching or optimization plugin's delay, defer and critical CSS settings. Elementor pages often load several stylesheets and scripts, so test again after each setting change, because aggressive deferral can break sliders, menus and forms.

Who Should Use This Checker?

Anyone responsible for how fast a page appears will find it useful, especially when a speed report names render-blocking files without telling you which line of code is responsible.

• Site owners who got an "Eliminate render-blocking resources" warning and want a plain list of the files behind it.
• Developers reviewing a template before launch or checking that a new script was added with defer.
• SEO specialists preparing a technical audit or a Core Web Vitals recommendation for a client.
• Content teams who paste a head from a staging page to confirm that a new tracking tag is not blocking the page.

Because you paste the HTML yourself, you can test staging pages, templates and snippets that are not publicly reachable.

Best Practices and Troubleshooting

Treat the report as a prioritized to-do list and verify every change on the live page. A few habits prevent most mistakes.

• Paste the rendered head, not the template. Template files may show only placeholders. Use view source on the live page to capture the real tags a visitor receives.
• Keep script order in mind. If a deferred script needs a library, defer the library too and keep it listed first.
• Do not defer everything blindly. A script that builds the visible layout can cause a flash of empty content if deferred.
• A script near the end of the body still shows up. The tool flags any script source without a loading attribute. A script at the very bottom of the body is much less harmful, but adding defer is still a safe habit.
• Nothing found but the page is slow? The cause may be large images, slow server response or heavy third-party code. Check headers with an HTTP header analyzer and your protocol with an HTTP/2 and HTTP/3 checker.
• Expecting a file that is missing? Make sure the whole tag was copied, including the closing bracket and quotes around the rel and href values.

What This Tool Does Not Check

The checker reads the markup you paste. It does not load your page, measure download time or run Lighthouse, so it tells you which files can block rendering, not how many milliseconds each one costs. It looks at stylesheet links and scripts with a source file. Inline script blocks, inline style blocks, CSS imported inside other stylesheets, and web font requests are not listed.

The label "Potential blockers" is deliberate. A file may be flagged even though your setup handles it in a way the markup does not show. Use the list as a map, then confirm gains with a lab test. For a broader view of page weight, the code to text ratio checker shows how much of your HTML is markup rather than readable content, and the Website Audit and Performance tools cover related checks.

Paste your page head into the box above, run the check, and fix the blockers at the top of the table first. Every script you defer and every stylesheet you trim gets visitors to your content sooner.