Check your third-party scripts for blocking issues

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

The finding shows how many outside scripts are blocking, the total count, and which outside domains are involved. Up to 5 blocking domains are listed so you know which scripts to fix.

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

When the browser hits a <script src="..."> tag with no async or defer, it stops all work. It stops reading HTML. It stops building the page. It gets the script, runs it, and only then goes on. This is called render-blocking. It exists because the browser cannot know if the script will change the page until it runs it.

For scripts on your own server, this pause is often short. Your server is close and fast. But for outside scripts, you have no control over speed. If a tracking CDN is slow, flooded, or down, your whole page freezes while the browser waits. Your users see a white screen because of a server you do not own.

The async prop tells the browser to get the script in the background and run it as soon as it lands, without blocking the page. The defer prop gets it in the background but waits to run until the HTML is fully parsed. Both stop 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 need the page structure. Widgets that need the DOM (chat boxes, embed forms) should use defer so the page is fully built when they run.

Outside scripts are the top cause of strange page slowdowns. Your site can be fully tuned, but one slow outside script with no async or defer stalls all of it. This is a single point of failure for your whole page.

The risk is not just theory. CDN outages, DNS issues, and server floods happen often. When they do, sites with blocking outside scripts go white until the request times out (often 30 seconds). Sites with async/defer scripts keep loading and just skip the broken script.

Google Lighthouse flags blocking scripts in its speed audit. Outside blocking scripts stand out because they are risks the site owner cannot tune. Adding async or defer is the only fix you have.

Marketing sites with many tracking and analytics tools are most at risk. Each tool (Google Analytics, Facebook Pixel, heatmap, A/B test) may add its own script. If any of them load without async, one slow tool can freeze the whole page.

Online stores using outside review widgets, rec engines, and chat tools load scripts from many domains. Each blocking script is a likely choke point in the checkout flow.

Agency-run sites often pile up outside scripts over time as team members add tools. A quarterly audit catches scripts that were added without async or defer and are silently slowing the site.

Step 1: Find blocking outside scripts. Run a SiteCurl scan. The finding lists which outside domains have blocking scripts. Note the domains so you know which scripts to target.

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

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

Step 4: Check the vendor's docs. Many outside vendors include async or defer in their latest embed code. If you copied an older version, check the vendor's current install guide for a new snippet.

Step 5: Remove scripts you no longer use. Over time, sites pile up tracking scripts for tools no one uses. If the tool's dashboard has not been checked in months, cut its script. Fewer outside scripts means fewer likely slowdowns.

Adding both async and defer. If both are set, async wins. This is fine, but can be unclear. Pick one based on whether the script needs the DOM (defer) or can run on its own (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 linked scripts, because deferred scripts run in page order.

Moving the script to the end of the body instead. Placing a script at the end of the body cuts visible blocking, but the browser still stops to run it before firing DOMContentLoaded. Async and defer are better because they allow parallel loading.

Thinking the vendor's snippet is tuned. Many embed codes from outside vendors do not include async or defer. The vendor cares that their script runs, not your page speed. Add the prop yourself unless the vendor says not to.

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.

Third-party scripts without async or defer are a single point of failure for your page. One slow outside 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.