`window.load` 事件在文档所有资源（包括图片、css、js）加载完毕后触发，但它不保证所有“非延迟javascript脚本”在此事件触发前已完全执行完毕。html living standard 定义其触发时机为“文档加载完成”，强调的是资源加载的终结，而非所有脚本执行的绝对终结，特别是对于异步脚本而言。
window.load 事件概述
在Web开发中，理解页面加载事件的时序对于优化用户体验和确保脚本正确执行至关重要。window.load 是一个核心的浏览器事件，它标志着一个页面及其所有依赖资源（如图片、样式表、字体、<iframe>等）都已完全加载。当这个事件触发时，理论上DOM结构已经构建完成，并且所有视觉元素都已准备就绪。
然而，关于 window.load 事件是否在所有“非延迟JavaScript脚本”执行完毕后才触发，存在一些常见的误解。为了清晰地定义“非延迟JavaScript脚本”，我们将其定义为任何由HTML页面加载的JavaScript代码（包括内联脚本、外部脚本、异步脚本、动态生成脚本或模块脚本），但不包括 onload() 事件处理器内部的代码，以及等待用户输入的其他处理器内部的代码。
HTML Living Standard 的权威解释
根据 WHATWG 维护的 HTML Living Standard 规范，load 事件的触发条件是“当文档完成加载时”（"when the document has finished loading"）。这一表述侧重于文档及其所有关联资源的加载状态，而非JavaScript脚本的执行状态。这意味着，浏览器在判断“文档完成加载”时，主要考虑的是DOM树的构建、样式表的解析应用、以及所有外部媒体资源（如图片、视频、字体）的下载和渲染完成。
规范并未明确指出 load 事件会等待所有“非延迟JavaScript脚本”的执行彻底结束。特别地，对于带有 async 属性的脚本，它们会在下载完成后立即执行，并且不会阻塞HTML解析或 load 事件的触发。这意味着一个较大的 async 脚本即使在 window.load 事件触发后仍在执行其逻辑，也是完全符合规范的。
立即学习“Java免费学习笔记（深入）”；
DOMContentLoaded 与 window.load 的区别
为了更好地理解 window.load，有必要将其与另一个重要的加载事件 DOMContentLoaded 进行对比：
- DOMContentLoaded 事件： 当HTML文档被完全加载和解析完成，不等待样式表、图片、子框架等其他资源加载时触发。它比 window.load 更早触发，通常用于对DOM进行操作的脚本。
- window.load 事件： 当页面上所有资源（包括图片、样式表、脚本、<iframe>等）都已加载完毕后触发。它确保所有内容都已可用，适合执行需要所有资源都已就绪的操作。
JavaScript 脚本的执行时序与 load 事件
不同类型的JavaScript脚本对 load 事件的触发有不同的影响：
- 同步脚本（无 async 或 defer）： 这些脚本会阻塞HTML解析。它们通常在 load 事件之前执行完毕，因为它们是页面渲染和资源加载的瓶颈。
- defer 属性脚本： 带有 defer 属性的外部脚本会在HTML解析完成后，但在 DOMContentLoaded 事件之前执行。它们通常也会在 window.load 事件之前执行完毕。
- async 属性脚本： 带有 async 属性的外部脚本会在下载完成后立即执行，并且不阻塞HTML解析或 load 事件的触发。因此，一个 async 脚本的执行完成时间可能在 window.load 之前，也可能在其之后，这取决于其下载和执行所需的时间。
- 动态生成脚本： 使用 document.createElement('script') 并添加到DOM中的脚本，其执行时机取决于其添加方式和是否设置 async 属性。
示例代码：
以下示例展示了不同脚本和事件的触发时序：
<!DOCTYPE html>
<html>
<head>
<title>Load Event and Script Execution</title>
<script>
console.log("1. Head blocking script execution started.");
</script>
<!-- 外部阻塞脚本，模拟耗时操作 -->
<script src="blocking-script.js"></script>
<!-- 异步脚本，可能在load事件之后完成 -->
<script async src="async-script.js"></script>
</head>
<body>
<h1>页面加载事件测试</h1>
<img src="large-image.jpg" alt="Large Image">
<script>
console.log("2. Body blocking script execution started.");
document.addEventListener('DOMContentLoaded', () => {
console.log("3. DOMContentLoaded event fired.");
});
window.addEventListener('load', () => {
console.log("4. window.load event fired.");
// 在这里，large-image.jpg 和所有其他资源都已加载完成
// 但 async-script.js 可能仍在执行中
});
</script>
<!-- 延迟脚本，在DOMContentLoaded前执行 -->
<script defer src="defer-script.js"></script>
<script>
// 模拟一个可能在load事件之后完成的动态脚本
setTimeout(() => {
const dynamicScript = document.createElement('script');
dynamicScript.textContent = "console.log('5. Dynamically loaded script executed after a delay.');";
document.body.appendChild(dynamicScript);
}, 100); // 100ms后动态加载
</script>
</body>
</html>blocking-script.js 内容 (模拟耗时)：
console.log("Blocking script loaded and executing...");
// 模拟一些计算
for (let i = 0; i < 10000000; i++) {}
console.log("Blocking script finished.");async-script.js 内容 (模拟异步耗时)：
console.log("Async script loaded and executing...");
// 模拟一些异步操作或耗时计算
setTimeout(() => {
console.log("Async script finished after a delay.");
}, 500); // 500ms后完成defer-script.js 内容：
console.log("Defer script loaded and executing.");在上述示例中，async-script.js 中的 setTimeout 模拟了其执行可能晚于 window.load 事件。window.load 触发时，浏览器只保证了所有资源（包括 large-image.jpg）的加载，但 async-script.js 内部的异步逻辑可能尚未完成。
注意事项与最佳实践
-
不要过度依赖 window.load 确保所有脚本完成： 如果你的应用逻辑依赖于所有“非延迟JavaScript脚本”的绝对完成，特别是那些带有 async 属性的脚本，那么 window.load 事件可能不是最可靠的触发点。你可能需要：
- 在 async 脚本内部添加回调机制。
- 使用 Promise.all() 或其他异步控制流模式来管理多个异步脚本的完成状态。
- 如果脚本只是进行DOM操作，DOMContentLoaded 通常是更早且更合适的时机。
-
优化脚本加载策略：
- 将不阻塞渲染的关键脚本放在 <head> 中。
- 使用 defer 属性加载不影响初始渲染但需要DOM准备就绪的脚本。
- 使用 async 属性加载独立、不依赖DOM或不阻塞渲染的脚本，但要警惕其执行时机可能晚于 load 事件。
- 将非关键脚本放在 </body> 标签之前，以避免阻塞页面渲染。
- 理解“文档完成加载”的含义： 核心在于所有 资源 都已加载完毕。脚本执行是资源加载的一部分，但对于 async 脚本，其执行完成不必然与 load 事件同步。
总结
window.load 事件在Web开发中扮演着重要的角色，它标志着页面所有资源的完全加载。然而，我们必须明确，window.load 并不保证所有“非延迟JavaScript脚本”的执行已绝对完成，特别是对于那些带有 async 属性的脚本。开发者应根据脚本的特性和对页面状态的依赖，选择最合适的事件（如 DOMContentLoaded 或 window.load），并结合现代异步编程模式来管理脚本的执行时序，以确保应用程序的健壮性和性能。
