网页加载是环环相扣的时序链路，依次经历DNS查询（含缓存优先级与预解析）、TCP/TLS握手（受RTT影响显著）、TTFB（含后端处理与优化手段）、DOM构建与渲染（含Render Tree生成及避免强制重排）。
网页加载不是一气呵成的动作，而是一套环环相扣的时序链路。理解每一步发生什么、谁在等谁、哪里容易卡住，是定位性能问题的基础。
DNS 查询：第一个关键延迟点
DNS 是整个加载流程的起点，它把域名变成 IP 地址。这个过程有明确的优先级顺序：浏览器缓存 → 系统 hosts 文件 → 操作系统 DNS 缓存 → 递归 DNS 服务器。Chrome 自带 DNS 缓存（约 1 分钟，最多 1000 条），命中时几乎为 0ms；未命中则可能耗时 20–100ms，弱网下更高。频繁跨域请求会触发多次独立 DNS 查询，拖慢首屏速度。
- 用 chrome://net-internals/#dns 可实时查看和清空浏览器 DNS 缓存
- 对已知域名，可在 HTML 中添加 <link rel="dns-prefetch" href="//cdn.example.com"> 提前解析
- 减少不同子域名数量（如 static.example.com、api.example.com），合并到同一主域可复用 DNS 结果
TCP 与 TLS：连接建立不可跳过的握手
DNS 完成后，浏览器需与目标 IP 建立 TCP 连接（三次握手），HTTPS 还需额外进行 TLS 协商（通常 1–2 个 RTT）。这两步耗时高度依赖网络往返延迟（RTT），而非带宽。例如，200ms RTT 的网络中，仅 TCP+TLS 就可能占去 600ms 以上。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 启用 HTTP/2 或 HTTP/3 能复用连接，避免重复握手；HTTP/3 更直接基于 UDP，绕过 TCP 队头阻塞
- 使用会话复用（Session Resumption）和 OCSP Stapling 可显著缩短 TLS 时间
- 避免混合内容（HTTP 资源嵌在 HTTPS 页面中），否则部分浏览器会拒绝加载或降级连接
HTTP 请求与响应：TTFB 决定“等待感”强弱
TTFB（Time to First Byte）是从发出请求到收到第一个字节的时间，包含服务器排队、业务逻辑处理、数据库查询、模板渲染等全部后端耗时。用户感知的“白屏时间”主要由 DNS + TCP/TLS + TTFB 构成——这三段加起来，就是页面开始“动起来”的临界点。
- 前端可通过 preload 提前声明关键资源（如首屏 CSS、字体），让浏览器更早发起请求
- 服务端开启 Gzip/Brotli 压缩、合理设置缓存头（Cache-Control）、启用服务端渲染（SSR）或边缘预渲染（ESI），能直接压低 TTFB
- 避免阻塞渲染的同步脚本放在
<head>中；改用 async 或 defer，或移至<body>底部
DOM 构建与渲染：从字节流到可视内容
HTML 文本下载完成后，浏览器开始词法分析、构建 DOM 树；CSS 下载并解析后生成 CSSOM；两者结合形成 Render Tree，再经历布局（Layout）、绘制（Paint）、合成（Composite）。JS 执行可能修改 DOM/CSSOM，触发重排重绘，进一步拉长渲染时间。
- DOMContentLoaded 触发表示 HTML 解析完成、DOM 树就绪，但图片、视频等非关键资源未必加载完
- 避免在 JS 中频繁读写 offsetTop/clientWidth 等触发强制同步布局（forced reflow）
- 大量 DOM 操作应批量进行：先用 document.createDocumentFragment() 组装节点，再一次性挂载
