June 16, 2026·6 min read·performance · render blocking · core web vitals

Render-blocking scripts: the three you almost certainly have

Render-blocking scripts stall your first paint while the browser waits. Here are the three most sites carry without knowing, and how to fix each one.

A render-blocking script is any JavaScript the browser must download, parse, and execute before it can paint the page. While that work happens, your visitor stares at a blank screen. The browser is not being slow on purpose. It found a <script> tag without instructions to defer it, so it stopped everything to deal with it first.

Most sites carry at least one of these without anyone choosing to. They arrive through a theme, a plugin, a tag manager snippet pasted into the <head>, or a third-party widget that promised to be lightweight. The three below show up again and again, and each one has a clean fix.

How a script blocks rendering in the first place

When the browser parses your HTML and hits a plain <script src="..."> tag in the <head>, it does three things in order: pause HTML parsing, fetch the script, then run it. Only after the script finishes does parsing resume. If that script lives on a slow third-party server, your page waits on a connection you do not control.

The fix is almost always one of two attributes. defer tells the browser to download the script in the background and run it after the document is parsed, in order. async downloads in the background too but runs the moment it arrives, without guaranteeing order. The MDN documentation on the script element lays out exactly when each applies. The short version: use defer for anything that touches the DOM or depends on other scripts, and async for independent, fire-and-forget code.

Knowing that, here are the three offenders you are most likely hosting right now.

One: the analytics and tag manager snippet

Google Tag Manager and analytics snippets are the most common render-blocking scripts on the web, partly because the install instructions tell you to paste them "as high in the <head> as possible." People take that literally and drop a synchronous loader above everything else.

The modern GTM snippet is actually written to load asynchronously, but two things still go wrong. First, older installs copied from years-old tutorials use a blocking pattern. Second, the tags GTM fires can themselves inject blocking scripts, so even an async container becomes a doorway for synchronous third-party code.

What to do:

Confirm your tag manager loader uses async. If you pasted it long ago, recheck the current snippet against the official install code.
Audit what fires inside the container. A heat-mapping tool, an A/B testing library, or an old remarketing pixel can each add blocking work that the container itself does not reveal.
Move anything that does not need to run before paint to fire on page load or user interaction instead of immediately.

Analytics should never cost you a visible delay. If it does, the measurement tool is hurting the thing it measures.

Two: jQuery and other synchronous libraries

A surprising share of sites still load a full JavaScript library synchronously in the head, most often jQuery, pulled in by a theme or a plugin that was built around it. The library downloads and executes before the page paints, even though almost nothing on the page needs it during the first render.

This is especially common on CMS-based sites. A theme bundles jQuery, three plugins each enqueue their own copy or depend on the bundled one, and the result is a chain of blocking requests in the head before a single pixel appears.

What to do:

Check whether your scripts can carry defer. Most library code that runs on DOMContentLoaded or later works fine deferred.
Look for duplicate copies. Two plugins loading two versions of the same library is both a performance cost and a conflict risk.
Question whether you need the library at all. Many interactions that once required a helper library are now native browser features. Removing the dependency removes the request entirely.

Be careful with ordering. If a plugin's inline script calls the library, deferring the library without deferring the inline call breaks the page. Test interactive elements after any change.

Three: the cookie consent and chat widgets

Consent management platforms are designed to load early and block, because they are supposed to run before any tracking fires. That goal is reasonable. The execution often is not. Many consent banners ship a heavy synchronous script in the head that delays paint for every visitor on every page, including visitors who have already made their choice.

Live chat and support widgets are the close cousin. They frequently inject a synchronous loader that pulls in a large bundle, fonts, and an iframe, all before the page is interactive. The widget you added to answer questions faster is making people wait longer to see the page that prompts the question.

What to do:

For consent tools, check whether the vendor offers an async loading mode. Many do, and the blocking version is just the default.
For chat and support widgets, defer loading until the page is idle or until the user shows intent, such as scrolling or hovering near the launcher.
Measure the real cost. Open your browser developer tools, go to the Network tab, and sort by which requests block the main thread before first paint. The widget's true weight is usually larger than its marketing suggests.

Google's web.dev guidance on render-blocking resources treats deferring non-critical third-party scripts as one of the highest-leverage changes you can make to your first paint.

How to find yours without guessing

You can locate render-blocking scripts by hand. Open developer tools, load a page, and watch the Network tab and the performance trace for scripts that execute before the first contentful paint. It works, but it covers one page at a time and assumes you already know what you are looking at.

A faster path is to let a scan flag them for you. The AcuityScan performance tool checks your page for render-blocking scripts and stylesheets, reports which resources delay your first paint, and notes where defer or async is missing. Because third-party widgets often arrive alongside extra HTTP headers and redirects, it pairs naturally with the HTTP Headers tool when you are tracing where a slow third-party request actually goes.

For the full picture across performance, security, accessibility, and email authentication, run a complete scan at acuityscan.com. It runs 350+ checks across 8 modules and returns specific findings with plain-English fixes, so you see not just that a script blocks rendering but which one and what to change.

TL;DR

A render-blocking script forces the browser to stop, download, and run JavaScript before it paints the page.
The fix is usually defer (for ordered, DOM-dependent code) or async (for independent code).
The three you most likely have: an analytics or tag manager snippet pasted high in the head, a synchronous library like jQuery bundled by your theme, and a consent or chat widget that loads blocking by default.
Test interactive elements after deferring anything, since broken script ordering can silently break features.
Measure each script's real cost in the Network tab, or run a scan that flags render-blocking resources for you.

Scan your own site

See what 350+ checks find on your domain.

Free, no signup, 60 seconds. Email auth · DNS · SSL · Performance · SEO · Accessibility · Privacy · Mobile.