浏览器首屏加载：8 道面试题，从 URL 到第一帧

这篇文章用 8 道面试题走完整个链路。每题都回答四件事：输入是什么、输出是什么、依赖谁、容易慢在哪里。最后再把 FCP、LCP、DOMContentLoaded、load 和可交互分开，形成一段能直接用于面试的完整回答。

先把地图画出来：8 个阶段，不是 8 次串行等待

窄屏下八阶段图可横向滑动查看完整链路；下面的交互卡用上一站 / 下一站逐站展开完整说明。

切换场景后，用卡片头部的上一站 / 下一站逐站查看；输入、输出、依赖、瓶颈与面试考点都直接平铺在卡内。 RTT 只是建立数量级直觉的教学预算，不是性能基准。

八个阶段的交接关系可以先压成这张表，后面逐题展开：

Q1 · 输入网址后，一定会先做 DNS 吗

面试官： 在地址栏输入一个网址并回车，浏览器第一步做什么？随后一定进行 DNS 查询吗？

先给结论。 第一步是把输入文本解析成导航目标，不是立刻 DNS。浏览器先判断它是搜索词还是 URL，补全协议与路径，并应用 HSTS、安全策略等规则；真正发请求前，还可能被 bfcache、Service Worker 或 HTTP 缓存直接回答。

输入、输出与依赖。 输入是地址栏文本和浏览器状态，输出是一份规范化后的绝对 URL 与导航上下文。URL 中的 scheme、host、port 决定 origin；path + query 进入 HTTP 请求目标；#fragment 只留在浏览器，不会发给服务器。

常见瓶颈不在解析本身。 真正昂贵的是错误地址导致的二次导航、http → https → www 这类长重定向链，以及本可命中却没有命中的缓存。回答时要强调：「输入网址 → DNS」只是冷启动且未命中任何捷径的分支，不是唯一流程。

追问：no-cache 是不是完全不缓存？ 不是。no-cache 允许存储，但每次使用前必须验证；no-store 才是不允许存储。协商缓存命中 304 也发生过网络请求，只是没有重新下载正文。

Q2 · DNS、TCP/QUIC、TLS 分别解决什么问题

面试官： 域名解析之后发生了什么？TCP 三次握手、TLS 握手和 HTTP 请求是什么关系？HTTP/3 改变了什么？

先给结论。 DNS 解决「去找哪个 IP」，TCP 或 QUIC 解决「建立可传输数据的连接」，TLS 解决「确认对方身份并保护通信内容」，最后 HTTP 才在这条连接上表达「我要哪份资源」。

• DNS： 输入主机名，输出 A / AAAA 等记录与 TTL。浏览器、系统、递归解析器任一层的缓存命中，都能省去后续查询。
• TCP： 通过 SYN → SYN + ACK → ACK 建立连接，通常花费 1 个 RTT。它提供有序、可靠字节流，但不验证网站身份。
• TLS： 校验证书链与主机名、协商密钥，并通过 ALPN 确定应用协议。TLS 1.3 完整握手通常再花 1 个 RTT。
• QUIC： 把可靠流、拥塞控制和 TLS 1.3 合并进基于 UDP 的传输协议，首次握手通常 1 RTT；恢复会话可支持 0-RTT，但要处理重放风险。

冷启动网络预算（示意） ≈ DNS 1 RTT + TCP 1 RTT + TLS 1.3 1 RTT + 请求/响应 1 RTT

这是无缓存、无复用、串行且不计服务端处理时间的示意。DNS 的真实耗时取决于缓存层级与记录链；HTTP/3 把 TCP 与独立 TLS 两段合并为 QUIC 握手；真实页面还会并行、复用或重定向。

常见瓶颈： 高延迟网络会放大每一次 RTT；DNS 的 CNAME 链会追加查询；TCP 丢包会影响同一条连接上的所有 HTTP/2 流；证书链错误则不是「慢」，而是直接失败。浏览器会维护连接池，不是每个请求都重新握手。

追问：HTTP/2 已经多路复用了，为什么还要 HTTP/3？ HTTP/2 解决的是应用层队头阻塞，但多个流仍共享一条 TCP 连接，一个 TCP 段丢失可能让所有流等待重传。HTTP/3 的 QUIC 流在丢包恢复上彼此独立，不过仍共享网络拥塞，不代表永远更快。

Q3 · HTTP 请求与响应里，哪些信息会继续影响首屏

面试官： 浏览器发出的导航请求长什么样？200、301、304 分别把流程带到哪里？TTFB 慢就是后端慢吗？

先给结论。 请求把方法、路径、Cookie、可接受的编码和缓存验证器交给服务器；响应除了状态码与 HTML 正文，还通过响应头决定缓存、压缩、安全策略和后续资源行为。

GET /interview/browser HTTP/1.1
Host: example.com
Accept: text/html
Accept-Encoding: gzip, br
If-None-Match: "html-v2"

依赖关系要说到响应头之后。 Content-Encoding 决定如何解压，Content-Type 决定 MIME 与字符集，Cache-Control / ETag 决定下次能否复用，CSP 等策略会影响资源能否执行或加载。它们都是首屏流程的输入，不是与渲染无关的元数据。

TTFB 的口径容易答错。 DevTools 的 Waiting (TTFB) 通常从请求发出算到首个响应字节，不包含此前的 DNS、TCP 和 TLS。TTFB 高可能是后端计算，也可能是 CDN 未命中、回源、服务器排队或网络传输；需要结合 Server-Timing 与后端 trace 定位。

Q4 · HTML 还没下载完，CSS、JS 和图片会开始下载吗

面试官： 浏览器什么时候发现子资源？为什么有些图片很晚才出现在 Network 面板？

先给结论。 会，而且通常应该尽早并行。HTML 是流式解析的，不必等整份文档下载完成；主解析器构建 DOM 的同时，预加载扫描器会向前扫描字节流，提前发现 CSS、JS、部分图片等资源并发起请求。

输入与输出。 输入是持续到达的 HTML 字节，以及随后解析出的 CSS；输出是一组带优先级的子资源请求。资源发现的早晚取决于它写在哪里：

预加载扫描器不是第二个 DOM 构建器。 它只提前发现资源，不执行脚本，也不能理解所有由 JS 动态生成的依赖。<link rel="preload"> 可以显式提示「首屏关键但发现较晚」的资源，preconnect 则提前为关键第三方完成 DNS、连接与 TLS；两者都不能无差别滥用，否则会抢带宽和连接。

常见瓶颈的完整表达： 不只是「网速慢」，还包括发现晚、优先级低、连接排队、缓存未命中、压缩不足、第三方响应慢。优化前先确认是哪一段，不要看到资源大就只会开懒加载。

Q5 · HTML 如何变成 DOM，脚本为什么会卡住解析

面试官： DOM 是怎么构建的？普通 script、defer、async、module 的执行时机有什么区别？

先给结论。 响应先按 Content-Encoding 解压，再按字符集解码为文本；Tokenizer 将文本切成标签、文本与注释，Tree Construction 按 HTML 规则生成 DOM。解析是流式的，但经典脚本可能让主解析器暂停。

DOM 构建的输出不是「源代码的复制」，而是一棵可被 JS 实时修改的节点树。HTML 解析器会补隐式节点、容错和修复结构，所以「查看源代码」与 DevTools Elements 里的 DOM 不一定相同。

DOMContentLoaded 的边界： 它在 HTML 解析完成、deferred 脚本与默认 deferred 的模块脚本执行后触发，不等待普通图片全部下载。async 脚本不参与阻塞它，可能在事件之后才执行；它也不表示首帧已出现，更不保证 SPA 已完成水合。

常见瓶颈： 头部同步脚本会串联「脚本下载 → 执行 → 后续 HTML 解析」；过大的同步 JS 会形成长任务；庞大 DOM 又增加树构建、样式匹配与布局成本。defer 只移动执行时机，不会把执行成本变成零。

Q6 · CSS 和 JS 到底谁在阻塞谁

面试官： CSS 会阻塞 DOM 解析吗？什么是关键渲染路径？怎样减少首屏阻塞？

先给结论。 CSS 通常不直接阻塞 DOM 树构建，但会阻塞首屏渲染；已经解析且仍在加载的样式表，还可能阻塞后续脚本执行。经典脚本则可直接阻塞 HTML 解析，并通过 DOM 未就绪间接拖住首帧。

为什么脚本可能等 CSS？ 脚本可以调用 getComputedStyle() 或读取布局信息。如果它依赖的样式表尚未就绪，浏览器就无法给出可靠结果，因此会让相应脚本等待。于是可能出现「HTML 等 JS、JS 等 CSS、CSS 等网络」的串联。

切换普通 script / defer / async、首图 eager / lazy 与字体策略，观察 FCP、LCP、DOMContentLoaded 的相对位移。 模型只演示阻塞关系，不要把相对单位当成真实毫秒。

优化要对应依赖： 精简并拆分关键 CSS，避免用 @import 串行加载；有依赖顺序的脚本优先 defer 或模块；独立第三方脚本才考虑 async；首屏 LCP 图保持 eager，必要时提高优先级；字体用合适的 font-display 与后备字体尺寸匹配兼顾可见性和 CLS。

Q7 · 从 Render Tree 到屏幕，中间经过哪些步骤

面试官： 浏览器渲染流水线是什么？回流、重绘、合成有什么差别？

先给结论。 样式计算得到可见节点与计算样式，Layout 计算位置和尺寸，Paint 生成绘制指令，Raster 把绘制变成瓦片位图，Composite 将图层合并并交给 GPU 上屏。

Render Tree 不是 DOM 的镜像。 display: none 不进入渲染树，也不占布局空间；visibility: hidden 仍保留几何位置；伪元素会产生参与渲染的盒子。首帧只要求视口内的内容完成必要的样式、布局与绘制，不等整页资源加载完毕；但布局计算仍可能覆盖整个文档。

常见瓶颈有三类：

1. 强制同步布局与布局抖动。 在同一帧里交替读取 offsetHeight / getBoundingClientRect() 和修改几何样式，浏览器被迫反复布局。
2. 昂贵绘制。 大面积阴影、滤镜、复杂背景会增加 Paint 与 Raster 成本。
3. 图层失控。 给大量元素滥用 will-change 或 3D transform，会增加显存、栅格化与合成管理成本。

追问：transform 动画一定不触发布局和绘制吗？ 只能说通常可以走合成路径。元素是否升层、文字是否重新栅格化、滤镜与其他属性是否同时变化，都会影响真实流水线；要用 Performance 与 Layers 验证，不能把经验规则当保证。

Q8 · 什么时候才算「首屏加载完成」

面试官： 首屏时间用什么指标衡量？DOMContentLoaded 或 load 能代表加载完成吗？

先给结论。 「首屏加载完成」不是浏览器唯一标准事件，必须先定义产品目标：第一次出现内容看 FCP，主要内容出现看 LCP，布局稳定看 CLS，操作响应看 INP。DOMContentLoaded 和 load 是生命周期事件，都不能单独代表用户已经完成阅读或交互。

LCP 可粗略拆成：TTFB + 资源发现延迟 + 资源下载时长 + 元素渲染延迟

先定位时间花在哪一段，再决定优化缓存、资源发现、图片体积还是主线程；不要只靠一个「减少请求数」解释所有首屏问题。

SSR 也不是终点。 服务端返回的 HTML 可以很快可见，但如果框架还要下载并执行大量 JS、完成水合，页面仍然可能「看得见却点不动」。因此完整回答要从 FCP 继续说到 LCP、CLS 和 INP，并用真实用户监控的 p75 验证，而不是只报一次本地 Lighthouse 分数。

一页速查

30 秒版本的口头回答：

浏览器先把输入解析成绝对 URL，并检查 bfcache、Service Worker、HTTP 缓存与重定向；需要联网时，再通过 DNS 得到 IP，建立并复用 TCP 或 QUIC 连接，HTTPS 下完成 TLS，然后发送 HTTP 请求。响应字节到达后解压、解码并流式解析 HTML，同时预加载扫描器并行发现 CSS、JS、图片等资源。DOM 与 CSSOM 汇合形成渲染树，经布局、绘制、栅格化和合成提交首帧。这里 CSS 主要阻塞渲染，经典脚本阻塞解析，defer 和 async 改变脚本时机。最后要区分 FCP、LCP、DOMContentLoaded、load 与可交互，用 LCP、CLS、INP 和真实用户数据判断首屏体验，而不是说所有资源下载完才算结束。

面试官可能继续追问

参考

• MDN：How browsers work
• web.dev：Critical rendering path
• MDN：HTTP caching
• web.dev：Core Web Vitals
• WHATWG：URL Standard