What it is
When a browser meets a normal script tag while building the page, it stops and waits for that script to download and run before it carries on. A few scripts loaded this way hold up nothing you would notice. A dozen of them, each pausing the build, mean the shopper looks at a blank or half-drawn page while the browser works through the queue. Marking a script defer or async lets the page keep drawing while it loads.
How common it is
Just under three in five audited stores (58%) keep this under control. The audit counts the external scripts on the page and how they load, and passes only when no more than three of them block rendering. Sites built from stacked plugins and tracking tags fail most often, since each addition tends to drop in one more blocking script.
Why it costs you
Render-blocking scripts hit the part of speed a shopper actually feels: how soon the page becomes something they can look at. The server can respond fast and the images can be light, but if ten scripts each have to finish before the content paints, the first usable view still arrives late. The frustrating part is that most of these scripts, analytics, chat widgets, marketing tags, do not need to run before the page appears at all. Letting them load in the background removes the freeze without removing the feature.
Check it in 30 seconds
Run a page through PageSpeed Insights and look for “eliminate render-blocking resources” in the list. It names the exact scripts holding up the first view. A long list there means the page is waiting on code that could just as easily load after it.
Read next: Ecommerce Site Speed: Convert More of Your Traffic
Run the free audit to see how many scripts your pages wait on before showing anything.