Safari中script标签是否会阻塞页面渲染？跨浏览器实测差异

Great question—let’s break this down based on your test case and the browser behavior differences you’ve observed.

First, let’s recap the expected behavior of defer scripts per web standards:

• defer scripts are designed not to block DOM parsing or initial page rendering. They download in the background and execute only after the entire DOM is parsed, right before the DOMContentLoaded event fires.

So why does Safari 11.1 act differently here? It comes down to a browser implementation bug in older Safari versions. Here’s the play-by-play:

• In Chrome and Firefox, once the parser finishes processing the <body> content (including the "works" text), the browser triggers a render update to show that content before running the deferred alert(). Since alert() blocks the browser’s event loop, you see the text first.
• In Safari 11.1, the deferred script executes before the browser gets a chance to render the already-parsed DOM content. The alert() immediately freezes the event loop, so the page stays blank until you dismiss the alert—at which point the browser finally renders the "works" text.

To answer your core question directly: Safari 11.1 doesn’t technically block rendering with defer scripts by spec, but its buggy execution timing causes an indirect block when the script runs a blocking operation like alert().

Quick way to confirm this is a bug: #

Replace the alert() with a non-blocking operation (like console.log('script ran')), and you’ll see "works" display immediately in Safari 11.1 too—no blank page. The issue is strictly tied to the deferred script running a blocking call before the initial render flush.

Fix/workaround for Safari 11.1: #

• Upgrade to a newer Safari version (this bug was fixed in releases like Safari 12+).
• If you need to support Safari 11.1, wrap your script logic in a DOMContentLoaded listener to guarantee it runs after the page has rendered:

document.addEventListener('DOMContentLoaded', () => {
  alert();
});

内容的提问来源于stack exchange，提问作者Tony