Part of the Speed audit

Check your third-party scripts for blocking issues

Third-party scripts without async or defer stop your page from rendering while they download from servers you do not control. SiteCurl checks every external script.

No signup required. Results in under 60 seconds.

What this check does

SiteCurl finds every <script> tag with a src attribute on your page. It checks if the script is hosted on a different domain than your site (third-party). For each third-party script, it checks for async, defer, or type="module" attributes. Scripts without any of these are flagged as blocking.

The finding shows how many third-party scripts are blocking, the total number of third-party scripts on the page, and which external domains are involved. Up to 5 blocking domains are listed so you know exactly which scripts to fix.

First-party scripts (hosted on your own domain) are covered by the separate script count check. This check focuses specifically on third-party scripts because they add a risk you cannot control: how fast someone else's server responds.

How this shows up in the real world

When the browser encounters a <script src="..."> tag without async or defer, it stops everything. It stops reading the HTML. It stops building the page. It downloads the script, executes it, and only then continues. This is called render-blocking, and it exists because the browser cannot know if the script will change the page structure until it runs it.

For first-party scripts on your own server, this pause is usually short. Your server is close and fast. But for third-party scripts, you have no control over the response time. If a tracking service's CDN is slow, overloaded, or down, your entire page freezes while the browser waits for a response. Your visitors see a white screen because of a server you do not own.

The async attribute tells the browser to download the script in the background and run it as soon as it arrives, without blocking the page. The defer attribute downloads in the background but waits to run until the HTML is fully parsed. Both prevent the white-screen problem.

The choice between async and defer depends on the script. Analytics, ad scripts, and tracking pixels work fine with async because they do not depend on page structure. Widgets that need the DOM (chat boxes, embedded forms) should use defer so the page is fully built when they run.

Why it matters

Third-party scripts are the most common cause of confusing page slowdowns. Your site can be perfectly optimized, but one slow external script without async or defer stalls everything. This is a single point of failure for your entire page.

The risk is not hypothetical. CDN outages, DNS issues, and server overloads happen regularly. When they do, sites with blocking third-party scripts go white until the request times out (usually 30 seconds). Sites with async/defer scripts continue loading normally and just skip the broken script.

Google Lighthouse flags render-blocking scripts in its performance audit. Third-party blocking scripts are singled out because they represent external dependencies that the site owner cannot optimize. Adding async or defer is the only mitigation you have.

Who this impacts most

Marketing sites with multiple tracking and analytics tools are the most vulnerable. Each tool (Google Analytics, Facebook Pixel, heatmap, A/B testing) may add its own script. If any of them are loaded without async, one slow tool can freeze the entire page.

E-commerce sites using external review widgets, recommendation engines, and chat tools load scripts from multiple third-party domains. Each blocking script is a potential bottleneck in the checkout flow.

Agency-managed sites often accumulate third-party scripts over time as different team members add tools. A quarterly audit of external scripts catches ones that were added without async or defer and are silently slowing the site.

How to fix it

Step 1: Identify blocking third-party scripts. Run a SiteCurl scan. The finding lists which external domains have blocking scripts. Note the domain names so you know which scripts to target.

Step 2: Add async to independent scripts. Analytics, tracking, and ad scripts usually work fine with async: <script src="https://example.com/tracker.js" async></script>. The script downloads in the background and runs as soon as it arrives.

Step 3: Add defer to DOM-dependent scripts. Chat widgets, embedded forms, and scripts that modify the page need the DOM to be ready. Use defer: <script src="https://example.com/widget.js" defer></script>. The script downloads in the background but waits to run until the page is fully parsed.

Step 4: Check the vendor's documentation. Many third-party providers include async or defer in their recommended embed code. If you copied an older version, check the vendor's current installation guide for an updated snippet.

Step 5: Remove scripts you no longer use. Over time, sites accumulate tracking scripts for tools that are no longer active. If the tool's dashboard has not been checked in months, remove its script. Fewer third-party scripts means fewer potential slowdowns.

Common mistakes when fixing this

Adding both async and defer. If both are present, async takes priority. This is fine, but can be confusing. Pick one based on whether the script needs the DOM (defer) or can run independently (async).

Using async on scripts that depend on each other. If script B depends on script A, both with async, script B might run first and fail. Use defer for scripts with dependencies, because deferred scripts run in document order.

Moving the script to the bottom of the body instead. Placing a script at the end of the body reduces visible blocking, but the browser still pauses to execute it before firing the DOMContentLoaded event. Async and defer are better solutions because they allow parallel downloading.

Assuming the vendor's snippet is optimized. Many embed codes from third-party providers do not include async or defer. The vendor prioritizes ensuring their script runs, not your page speed. Add the attribute yourself unless the vendor specifically says not to.

How to verify the fix

After adding async or defer, run another SiteCurl scan. The finding should show zero blocking third-party scripts. You can also check in Chrome dev tools: open the Network tab, filter by 'JS,' and look for third-party domains. Their scripts should show as downloaded in parallel with other resources, not blocking the page render.

To confirm the page loads without blocking, open the Performance tab in dev tools, record a page load, and look for long gaps where the browser is waiting for a script. With async/defer, those gaps should disappear.

The bottom line

Third-party scripts without async or defer are a single point of failure for your page. One slow external server freezes your entire site. Add async to independent scripts (analytics, tracking) and defer to scripts that need the page built first (widgets, chat). This one-word fix protects your page from outages you cannot control.

Example findings from a scan

2 third-party scripts missing async/defer

5 third-party scripts, all non-blocking

No third-party scripts detected

Frequently asked questions

What is the difference between async and defer?

Both download the script in the background without blocking the page. Async runs the script as soon as it finishes downloading, regardless of page state. Defer waits until the HTML is fully parsed before running. Use async for independent scripts, defer for scripts that need the DOM.

Can adding async break a script?

Sometimes. If a script expects the page to be fully loaded when it runs, async may cause it to run too early. Try async first. If the script breaks, switch to defer. Defer guarantees the DOM is ready.

How many third-party scripts is too many?

There is no fixed limit, but each one adds a network request and execution time. Audit your scripts quarterly. If a tool's dashboard has not been checked in months, remove its script. Fewer scripts means faster pages and fewer external dependencies.

Can I check third-party scripts without signing up?

Yes. The free audit checks your home page for blocking third-party scripts as part of a full seven-category scan. No signup required.

What if the vendor says not to add async?

Some scripts genuinely need to run before the page renders (A/B testing scripts that change page content). In those cases, follow the vendor's guidance. But most analytics and tracking scripts work fine with async.

Does this affect Google Tag Manager?

Google Tag Manager's standard embed code already includes async. If you use GTM, the container script itself is non-blocking. But scripts loaded by GTM (triggers, tags) can still be blocking if configured that way inside GTM.

Check your site speed now