前端性能优化做了几年，真正觉得开窍，是在理解这件事之后：大部分性能问题，本质不是"算得慢"，而是"等得久"。打开一个页面，用户感受到的白屏、卡顿、点击没反应，绝大多数时间消耗在等待——等HTML解析、等CSS就绪、等脚本下载执行、等接口返回数据。而"异步加载"这个听起来很基础的概念，恰恰是打破这些等待链条的核心手段。这篇原理篇，我想把异步加载和性能优化之间的关系完整拆开讲一遍：从浏览器的底层机制，到资源加载策略，再到业务代码怎么写才能真正受益，以及最后用哪些指标验证优化有没有效果。适合刚接触前端性能优化的人建立完整认知，也适合做过一些优化但总感觉"差口气"的人查漏补缺。
1. 从点击到首屏渲染：一条时间线里藏着的异步机会
先说一个我经常在团队里问的问题：从用户在地址栏按下回车，到页面第一个有意义的画面出现，中间到底发生了什么？很多人能背出"DNS解析-建立连接-服务器响应-下载HTML-解析渲染"这套流程，但一旦问到"这个过程中哪些步骤是同步阻塞的、哪些可以异步化"，就说不清楚了。说不清楚的原因，是大家习惯把这些步骤当成一条笔直的流水线，但实际上，浏览器在解析文档的时候是边下载边解析的，而且每一类资源对渲染的阻塞程度完全不同。
1.1 关键渲染路径里，哪些环节在真正"卡住"用户时间
浏览器拿到HTML之后，解析器开始逐个处理标签。遇到CSS文件，它会发起下载，然后在下载完成之前，阻止页面渲染——因为布局需要完整的样式规则，浏览器拿不到CSS就没法计算元素的最终位置和大小。遇到普通的script标签，情况更严重：不仅阻塞渲染，还会阻断HTML解析器继续往下走。换句话说，一个放
