在线 -
搜索 AIGC编程网
← 返回题目列表

浏览器从输入 URL 到页面展示经历了什么？

高频 中等 第 3 / 30 题 更新于 2026/07/28
浏览器网络渲染流程性能

简化版

浏览器输入 URL 后，会经历 URL 解析、DNS 查询、建立连接、发送 HTTP 请求、服务器响应、解析 HTML、构建 DOM/CSSOM、生成渲染树、布局、绘制、合成，最后展示页面。如果页面有 JS、CSS、图片等资源，还会继续下载、解析和执行。

详细版

完整流程可以分为网络阶段和渲染阶段。

网络阶段：

  • 解析 URL，判断协议、域名、路径。
  • 查询缓存，命中则可能直接使用缓存。
  • DNS 解析域名得到 IP。
  • 按协议建立连接；HTTP/1.1、HTTP/2 通常基于 TCP，HTTPS 还涉及 TLS，HTTP/3 使用 QUIC。
  • 发送 HTTP 请求。
  • 服务端返回响应。

渲染阶段：

  • 解析 HTML 生成 DOM。
  • 解析 CSS 生成 CSSOM。
  • DOM 和 CSSOM 合成渲染树。
  • 计算布局。
  • 绘制图层。
  • 合成并显示。

JS 会影响这个过程，因为脚本可能修改 DOM 和 CSSOM，所以普通同步脚本可能阻塞 HTML 解析。

完整版教学

一、网络请求阶段

用户输入 URL 后，浏览器先判断它是搜索词还是合法地址。如果是 URL，会解析出协议、主机、端口、路径和查询参数。

随后浏览器会检查缓存。如果资源仍然新鲜，可能直接使用强缓存；如果需要验证，会向服务器发起协商缓存请求。

如果没有可用缓存，就要进行 DNS 解析，把域名转换成 IP 地址。拿到地址后按协议建立传输连接。HTTP/1.1、HTTP/2 通常基于 TCP，HTTPS 还要协商 TLS；HTTP/3 使用基于 UDP 的 QUIC，不能一概回答成 TCP。

连接建立后，浏览器发送 HTTP 请求，服务器返回 HTML 文档。

二、HTML 解析和资源发现

浏览器一边接收 HTML，一边解析。遇到标签会构建 DOM 树，遇到 CSS 会下载并解析 CSSOM，遇到图片、字体、脚本等资源会发起请求。

CSS 通常不会阻塞 HTML 解析，但会阻塞渲染，因为浏览器需要知道样式后才能正确绘制。同步 JS 可能阻塞 HTML 解析，因为 JS 可能执行 document.write 或修改 DOM。

所以工程中常把脚本放到页面底部，或使用 defer、async 控制加载执行时机。

三、渲染流水线

DOM 描述页面结构，CSSOM 描述样式规则。两者结合生成渲染树，只包含需要显示的节点。

之后浏览器进行布局，计算每个节点的位置和尺寸；再进行绘制，把文字、颜色、边框、阴影等绘制出来；最后由合成线程把图层合成到屏幕。

如果后续 JS 改变布局相关属性，可能触发重排；改变颜色等视觉属性，可能触发重绘；只改变 transform、opacity 等合成属性，通常成本更低。

四、面试追问与工程落地

面试官常追问：“如何优化首屏？”

核心是减少关键路径耗时：减少 DNS 和连接成本、启用缓存、压缩资源、拆分非关键 JS、内联关键 CSS、图片懒加载、服务端渲染或静态生成、合理使用 CDN。

回答时不要只背流程，要能把每个阶段和优化手段对应起来。比如 DNS 慢可以预解析，JS 阻塞可以 defer，资源大可以压缩和拆包。

五、连接复用与关键请求链

“DNS → TCP → TLS”是常见教学路径，但不是所有导航都从零开始。DNS、连接和 TLS 会话可能复用；HTTP/1.1 与 HTTP/2 通常基于 TCP，HTTP/3 则基于 QUIC/UDP 并集成 TLS 1.3，因此面试回答要说清协议和缓存前提。

场景可能省掉的工作仍可能发生的工作
强缓存命中网络请求本地读取、解析、渲染
复用 HTTP/2 连接新 TCP/TLS 握手请求排队与服务端处理
304 验证成功响应体传输往返和验证请求
HTTP/3 新连接TCP 握手QUIC/TLS 建连

假设 RTT 为 100ms，从零建立 TCP 约需 1 RTT，TLS 1.3 通常再需约 1 RTT，首个应用数据尚未计算 DNS 和服务端处理就可能消耗约 200ms。连接复用、预连接与 CDN 的价值，正是减少这些串行等待；具体耗时随协议、网络和会话恢复变化。

六、解析阻塞、优先级与首屏诊断

HTML 解析器会边收字节边构建 DOM，并由预加载扫描器提前发现部分资源。外部样式通常阻塞首次渲染；经典同步脚本会暂停 HTML 解析，而且脚本若依赖尚未完成的样式表，还可能等待 CSS。defer、module、资源优先级与代码拆分的目标是缩短首屏必须串行完成的关键链。

HTML ──> DOM ─┐
CSS  ─> CSSOM ├─> style/render tree ─> layout ─> paint ─> composite
JS ──修改两者─┘

排查首屏不能只看总加载时间。Network 瀑布图定位 DNS、连接、TTFB 和关键资源，Performance 面板定位解析、长任务、样式计算和布局，LCP 元素再把网络与渲染两边串起来。图片已经下载但主线程被 300ms 脚本占用时，LCP 仍会推迟。

记忆钩子：URL 到像素不是一条固定流水线，而是“网络关键链”和“主线程渲染链”汇合；优化要先找到当前最长的串行链。

首屏排查顺序

出现白屏或 LCP 变慢时，可按依赖链逐步排查：

  1. 确认导航是否卡在 DNS、连接、TLS 或 TTFB。
  2. 找出 HTML 发现 LCP 资源的时间，检查是否被 CSS/JS 间接隐藏。
  3. 检查资源下载后的主线程长任务、字体和图片解码。
  4. 对比首次访问、二次访问和弱网，区分缓存与冷启动问题。

这套顺序能避免一看到图片就只做压缩，也能把网络、发现、下载和渲染四段分别归因。

七、常见误区与追问

  • 误区：访问 HTTPS 页面一定先建立 TCP 再单独进行 TLS。 HTTP/3 使用 QUIC/UDP，连接步骤与 HTTP/1.1、HTTP/2 不同。
  • 误区：CSS 会停止 HTML 解析。 CSS 主要阻塞渲染，经典同步脚本才会暂停解析；脚本又可能等待样式表。
  • 误区：资源下载完成就会立刻显示。 还要经过解码、样式、布局、绘制和合成，主线程长任务也会延迟呈现。
  • 追问：为什么同步脚本会阻塞解析？ 脚本可能用 document.write 或 DOM API 改变解析结果，解析器必须保证执行顺序。
  • 追问：HTTP 缓存命中后还需要渲染吗？ 需要，缓存只减少网络成本，字节仍要解析并进入渲染流水线。
  • 追问：如何判断 LCP 慢在网络还是渲染？ 拆分 TTFB、资源加载延迟、下载时长和元素渲染延迟，并结合主线程火焰图。
  • 追问：SSR 为什么不必然让页面可交互更快？ 它可提前输出 HTML，但大量水合 JS 仍可能阻塞主线程和交互。

八、加强记忆

从 URL 到页面按“两条链”记：网络侧完成缓存判断、寻址、建连、请求响应，渲染侧把 HTML/CSS/JS 转成 DOM、CSSOM、布局、绘制和合成。协议、连接复用和缓存会跳过部分步骤，脚本与样式又会形成阻塞；面试时既要讲完整路径，也要能用瀑布图、主线程轨迹和 LCP 拆解真正瓶颈。