浏览器地址栏里敲下那串字符，输入按下回车，到页屏幕刷新。面加整个过程快到人根本来不及想中间发生了什么。载整但真拆开看，过程里头跑完了一套相当紧凑的分析流水线。

先从DNS说起。输入你输入的到页是域名，机器认的面加是IP。浏览器先翻自己的载整缓存，没有就问操作系统，过程操作系统再翻hosts文件，分析还没有才往外发请求。输入递归查询一路问到根域名服务器、到页顶级域服务器、面加权威服务器，最后拿到一个IP地址。这一步通常几十毫秒，但它是整条链路的第一环，卡住了后面全得等。我见过公司内网DNS配置出问题，页面转圈十几秒才出来，查半天以为是服务器挂了，结果根子在解析。

拿到IP，浏览器跟服务器建立TCP连接。三次握手：SYN、SYN-ACK、ACK。如果是HTTPS，还要再来一轮TLS握手，协商加密套件、验证证书、交换密钥。TLS 1.3把往返次数压到一次，比1.2快不少。这里有个容易被忽略的细节——证书链验证。浏览器不只看你服务器证书本身，还要顺着中间证书往上追到受信任的根CA。中间证书没配全，部分浏览器直接报错，部分浏览器偷偷去下载缺失的中间证书，表现就是“有的电脑能打开，有的打不开”。这种问题排查起来很折腾。

连接建好，浏览器发出HTTP请求。请求行、请求头、请求体，标准格式。服务器收到后开始处理——可能是Nginx转发给后端应用，可能是CDN直接返回缓存内容。响应回来，状态码200、301、304各有各的走法。304意味着“你本地缓存还能用”，浏览器直接读磁盘缓存，不下载新内容。这招省带宽，但缓存策略配错了也烦人，用户明明刷新了页面看到的还是旧版本。

HTML文档到达浏览器，真正的重头戏才开始。解析器从上往下扫，遇到CSS链接就发请求，遇到script标签就暂停解析去下载执行——除非加了async或defer。这就是为什么script标签的位置会影响首屏速度。把阻塞脚本扔到body末尾，或者加个defer，页面渲染能快出一截。DOM树和CSSOM树并行构建，两棵树合到一起算出每个节点的样式，然后进入布局阶段——计算位置和尺寸。再往后是绘制，把像素真正画到屏幕上。合成层在这一步发挥作用，transform和opacity动画能走GPU加速，不触发重排重绘，流畅度差别肉眼可见。

JavaScript在这条链路里的角色很特殊。它既能改DOM触发重排，也能发请求拿新数据。一个fetch调用背后又是完整的DNS→TCP→TLS→HTTP流程。所以页面上那些异步加载的内容，走的是跟主文档一样的路，只是发起时机晚了几百毫秒。

整条链路里任何一个环节慢，用户都能感知到。DNS解析慢、TCP握手慢、服务器响应慢、资源体积大、解析阻塞、布局抖动——每个点都有对应的优化手段，但前提是你知道问题出在哪一段。Chrome DevTools的Network面板把每个请求的耗时拆成DNS、连接、TLS、等待、下载几段，对着看，瓶颈在哪一目了然。

说到底，从URL到页面，本质就是一次跨网络的资源获取加本地渲染。理解这条链路，不是为了背八股，是出了问题知道往哪查。