Blocking Scripts: Why Your Site Freezes on Load
Test #07 analyzes <script> tags and checks whether they block the first render. A common problem, easy to fix, that changes everything for the user.
- A script without defer or async blocks page rendering: the visitor sees a white screen during download.
- Orilyt counts external scripts and calculates the non-blocking percentage. ≥ 50% = score 100, 0% = score 30.
- The fix is simple: adding defer (or async) to each <script src="..."> tag is enough in most cases.
When a browser encounters a <script src="..."> tag, it stops, downloads the file, executes it, then resumes rendering the page. During that time, the visitor sees nothing — or worse, a half-built page.
This is the default HTML behavior. Without explicit instructions, every external script is "blocking." The more scripts in the <head>, the longer the rendering delay.
Orilyt test #07 detects this issue and measures the proportion of non-blocking scripts. Let's see how it works and how to leverage its results.
Why Are Blocking Scripts a Problem?
A typical WordPress site loads 5 to 15 external JavaScript files: analytics, cookie banners, sliders, forms, various plugins. If none use defer or async, the browser loads them one by one before displaying anything.
The impact on Core Web Vitals is direct: LCP (Largest Contentful Paint) and FCP (First Contentful Paint) are delayed. Google penalizes slow sites in its rankings.
For users, the effect is immediate: the site appears "frozen" for 2 to 5 seconds on a mobile connection. In 2026, that's a deal-breaker.
How Does Test #07 Work?
Orilyt analyzes the page's HTML code and extracts all <script> tags with a src attribute (external scripts). Three pieces of information are collected for each script:
- Presence of the defer attribute — the script is downloaded in parallel and executed after HTML parsing.
- Presence of the async attribute — the script is downloaded in parallel and executed as soon as it's ready.
- Position in the <head> — a blocking script in the <head> is the worst case.
The score is calculated based on the percentage of non-blocking scripts (defer or async):
If no external scripts are detected, the score is automatically 100/100 — no blocking risk.
The report also shows "head offenders": blocking scripts located in the <head>, those with the most impact on first render.
defer vs async: What's the Difference?
Both attributes allow the browser to download the script without blocking rendering. The difference is when execution happens:
defer: the script executes after the HTML is fully parsed, in order of appearance. Ideal for most scripts (analytics, UI, plugins).
async: the script executes as soon as it's downloaded, without waiting for HTML or other scripts. Useful for independent scripts (tracking, A/B testing).
When in doubt, use defer — it's the safest choice because it preserves execution order.
How to Use This Test in Your Proposals
Blocking scripts make a particularly effective pre-sales argument: the problem is invisible to the site owner (they have a fast connection) but critical for their mobile visitors.
Here's how to structure your recommendation using the FIA method:
- Fact: "Your site loads X JavaScript files without defer or async. They block rendering for Y seconds."
- Impact: "On mobile, visitors see a white screen during loading. Google penalizes slow sites in search results."
- Action: "Add the defer attribute to each <script> tag. Estimated time: 30 minutes (theme + plugins)."
The Orilyt report lists blocking scripts by URL — you can show the client exactly which files cause the problem.
Integrating This Test Into Your Workflow
Test #07 complements other performance tests for a complete diagnosis:
- Run the Orilyt audit → the "Script loading" score appears in the Performance section.
- If the score is red or orange, open the details: you'll see the number of blocking scripts, "head offenders," and the overall percentage.
- After the fix (adding defer/async), re-run the audit and use the before/after comparison to show the improvement.
Combined with TTFB (#16), compression (#04), and browser caching (#03) tests, this test forms the foundation of a solid performance diagnosis.
Conclusion
Blocking scripts are one of the most common causes of slowness on WordPress sites. The problem is invisible to the naked eye but measurable: that's exactly the kind of finding that justifies a professional audit.
Orilyt test #07 gives you a precise diagnosis: number of scripts, non-blocking percentage, list of offenders. A concrete, data-driven argument ready to include in your proposal.
Test a client site right now — you'll likely be surprised by the number of blocking scripts.