脚本加载优化的核心在于减少阻塞以提升页面渲染速度，常用策略包括async异步加载、defer延迟加载、动态创建脚本标签和模块化加载。1. async用于独立性强、不依赖dom的脚本，下载时不阻塞解析且执行顺序不确定；2. defer用于需操作dom或存在依赖关系的脚本，下载时不阻塞解析且按顺序执行；3. 动态创建<script>标签实现按需加载，适用于用户交互后才需要的功能；4. 模块化加载（如es modules）通过代码拆分和按需加载提升性能与可维护性。此外，还可结合cdn、资源预加载、http/2、代码分割和内联关键脚本进一步优化。选择策略时需根据脚本特性、依赖关系和业务需求综合判断，配合<a style="color:#f60; text-decoration:underline;" title= "工具" href="https://www.php.cn/zt/16887.html" target="_blank">工具测试验证效果，持续迭代优化。</script>
HTML脚本加载优化，核心在于减少其对页面渲染的阻塞，让用户更快看到页面内容。这通常通过改变脚本的加载和执行时机来实现，常用的四种策略是异步加载（async）、延迟加载（defer）、动态创建以及利用现代模块化加载机制。
解决方案
策略一：利用 async 属性实现异步加载
async 属性告诉浏览器，这个脚本可以与HTML解析并行下载，下载完成后会立即执行，但不会阻塞HTML的解析。它的一个特点是，脚本的执行顺序是不确定的，哪个先下载完就哪个先执行。
立即学习“前端免费学习笔记（深入）”；
对我来说，async 是处理那些独立性强、不依赖其他脚本、也不被其他脚本依赖的第三方脚本的利器，比如各种统计代码、广告脚本或者一些独立的埋点脚本。它们通常不需要操作DOM，或者操作DOM的时机并不那么关键。我经常看到有人把Google Analytics的代码直接放在里，如果加上async，对页面渲染速度的提升是立竿见影的，因为它不再是那个“必须等我”的家伙了。
策略二：利用 defer 属性实现延迟加载
与 async 类似，defer 也允许脚本与HTML解析并行下载，但它的执行时机有所不同：脚本会在整个HTML文档解析完成后、DOMContentLoaded 事件触发之前执行。最关键的是，带有 defer 属性的脚本会按照它们在HTML中出现的顺序依次执行。
我觉得 defer 是一个非常优雅的解决方案，尤其适用于那些需要操作DOM，或者脚本之间存在依赖关系的场景。例如，你的业务逻辑脚本，或者依赖jQuery的脚本，都可以考虑使用 defer。它既避免了阻塞页面渲染，又能确保脚本的执行顺序和DOM的完整性。在我看来，对于大部分前端业务逻辑代码，defer 往往是比 async 更稳妥的选择。
策略三：动态创建 <script></script> 标签
这种方式是通过JavaScript代码在运行时动态创建并插入 <script></script> 元素到DOM中。这样做的好处是你可以完全控制脚本的加载和执行时机，实现真正的“按需加载”。
比如，只有当用户点击某个按钮时才加载某个特定功能的JS文件，或者在页面滚动到某个区域时才加载对应的组件脚本。这种方式提供了极大的灵活性，但管理起来也更复杂一些，特别是当项目规模变大时，需要一套完善的加载机制来避免混乱。我个人在处理一些大型单页应用（SPA）的路由切换时，会倾向于使用这种方式来按需加载对应的组件脚本，以减少初始加载的包体积。
策略四：采用模块化加载（如ES Modules、Webpack/Rollup）
现代前端开发已经离不开模块化。无论是原生的ES Modules（<script type="module"></script>）还是通过构建工具（如Webpack、Rollup）实现的模块化，都能带来显著的优化。模块化允许我们将代码拆分成更小、更独立的单元，并且可以配合构建工具实现代码分割（Code Splitting），只加载当前页面或当前视图所需的代码。
ES Modules本身就具有 defer 的行为特性，不会阻塞HTML解析。而通过Webpack等工具，我们不仅能实现按需加载（import() 动态导入），还能进行Tree Shaking（摇树优化），移除未使用的代码。在我看来，这不仅仅是脚本加载的优化，更是整个前端工程化和代码架构层面的提升。虽然初期学习成本可能高一些，但对于中大型项目而言，它带来的性能和可维护性收益是巨大的。
为什么脚本加载会阻塞页面渲染？理解其核心机制
这其实是浏览器为了确保页面内容的正确性和交互的即时性而做出的一个权衡。当浏览器解析HTML文档流，遇到一个普通的 <script></script> 标签时，它会假定这个脚本可能会修改或查询DOM结构，甚至通过 document.write() 这种方式直接改变HTML内容。为了避免在DOM结构不完整或不确定的情况下执行脚本导致错误，浏览器会暂停HTML解析，转而去下载并执行这个脚本。只有当脚本执行完毕后，HTML解析才会继续。
你可以把它想象成一条流水线：HTML解析器在高速运转，突然遇到一个需要外部协助的工序（加载脚本）。这条流水线就得停下来，等待外部的工具（脚本）到位并完成它的工作，才能继续往下走。如果这个工具很大，或者网络传输很慢，那么停工的时间就会很长，用户就会看到一个空白或者不完整的页面。这是导致“白屏时间”过长的一个常见原因。CSS文件也会阻塞渲染，但那通常是为了避免“闪烁无样式内容”（FOUC），逻辑上略有不同。
除了异步与延迟，还有哪些“隐藏”的脚本优化技巧？
仅仅是调整 script 标签的属性，远不足以涵盖所有的脚本加载优化。在我看来，还有一些非常重要但有时容易被忽视的策略：
利用CDN（内容分发网络）： 将你的静态资源（包括JS文件）部署到CDN上。CDN会在全球各地部署服务器节点，用户访问时会自动从离他们最近的节点获取资源。这能显著减少网络延迟，特别是对于跨地域的用户。我每次部署新项目，CDN都是必选项，它带来的速度提升是实实在在的。
-
资源预加载（
preload,prefetch）：-
rel="preload"：告诉浏览器，这个资源在当前页面是必需的，但现在不需要立即执行，请尽快下载。比如，你可以在里preload字体文件或关键的JS/CSS文件，让它们在页面渲染前就开始下载。 -
rel="prefetch"：告诉浏览器，这个资源可能在下一个页面或用户接下来的操作中会用到，可以在浏览器空闲时下载。这是一种非常前瞻性的优化。 这些指令能让浏览器更智能地管理资源加载，避免用户等待。
-
代码分割（Code Splitting）： 这通常与模块化加载工具（如Webpack）结合使用。它将你的应用代码拆分成多个小的块（chunks），只在需要时才加载对应的代码块。例如，你的网站有A、B、C三个页面，用户访问A页面时，只加载A页面的代码，B和C页面的代码则在用户导航到对应页面时再动态加载。这极大地减小了初始加载的JS文件大小。
HTTP/2 或 HTTP/3： 现代的HTTP协议版本提供了多路复用（Multiplexing）等特性，允许在单个TCP连接上并行发送多个请求和响应。这意味着浏览器可以同时下载多个JS文件而不需要建立多个连接，减少了网络开销和延迟。如果你还在用HTTP/1.1，升级到HTTP/2或HTTP/3能带来整体性能的提升。
内联关键脚本： 对于非常小且对首屏渲染至关重要的脚本（比如一些用于初始化CSS变量或检测浏览器特性的脚本），可以考虑直接将其内容内联到HTML文件中。这样可以省去一次HTTP请求的开销。当然，这要权衡缓存和HTML文件大小，不宜滥用。
如何在实际项目中选择合适的脚本加载策略？兼顾性能与开发体验
选择合适的脚本加载策略，从来都不是“一刀切”的问题，它需要你像一个经验丰富的老兵，根据每个脚本的特性、它与DOM的关系、它对其他脚本的依赖，以及它在业务中的重要性来做出判断。
首先，没有所谓的“银弹”策略。我通常会这样思考：
-
对于那些完全独立、不依赖DOM、不影响其他脚本、也不被其他脚本影响的脚本（比如第三方统计代码、广告SDK），我会毫不犹豫地加上
async。这是最简单直接的优化。 -
对于那些需要操作DOM，或者脚本之间存在明确执行顺序，但又不希望阻塞HTML解析的业务逻辑脚本，
defer是我的首选。它既能保证顺序，又不影响首屏渲染。 -
如果某个功能只有在用户触发特定交互后才需要，或者某个组件只在特定路由下才渲染，那么动态创建
<script></script>标签或者配合Webpack等工具进行动态import()（即代码分割）就是非常好的选择。这能让你的初始加载包体积尽可能小。 - 对于大型、复杂的单页应用，或者需要大量模块化协作的项目，一套完善的模块化加载方案（ES Modules配合构建工具）是不可或缺的。它不仅优化了加载，更提升了代码的可维护性和开发效率。
在实践中，我还会结合一些工具来辅助决策和验证效果。比如，使用 Lighthouse、WebPageTest 或者 Chrome DevTools 的 Performance 面板来分析页面加载瀑布流，看看哪些脚本是阻塞的，哪些脚本下载和执行耗时过长。这些数据会告诉我，我的优化是否真的有效，或者还有哪些地方可以进一步改进。性能优化很多时候都是一个迭代的过程，需要不断测试、调整，才能找到最适合你项目的平衡点。
