关于前端:jsliang-求职系列-16-从输入-URL-到页面呈现

不折腾的前端，和咸鱼有什么区别

目录
一目录
二前言
三整体过程
四 DNS 解析
五 TCP 连贯
六发送 HTTP 申请
七服务器响应
八浏览器解析渲染页面
九其余问题及优化
9.1 渲染过程碰到 JS 文件怎么解决？
9.2 为什么操作 DOM 慢

这是一道经典面试题：

从输出 URL 到页面出现产生了什么？

如果你还不懂，那么能够来看看。

在用户输出 URL，按下回车之后，走过的步骤：

DNS 解析
TCP 连贯
发送 HTTP 申请
服务器响应
浏览器解析渲染页面

当然，这是整体过程，理论面试过程中会进一步具体问，前面会逐步完善，让小伙伴们对这个系列的问题不在纠结。

DNS 解析过程就是通过网络查找哪台机器有你须要的资源的过程。

浏览器输出 github.com 并不是真正意义上的去查找这个，而是查找这个域名解析到的 IP 地址。

互联网上每一台计算机的惟一标识是它的 IP 地址，然而 IP 地址并不不便记忆，所以互联网设计者为了不便，才会搞出 github.com 这样的域名。

DNS 解析过程：

查问 www.baidu.com
拜访客户端 DNS 缓存：浏览器缓存 -> 零碎缓存（host） -> 路由器缓存
拜访 ISP DNS 服务器（ISP，互联网服务提供商，有联通电信挪动等。如果你是电信网络，则进入电信的 DNS 缓存服务器，以下简称本地），如果本地服务器有，则间接返回；如果没有，让本地 DNS 服务器去征询查找。
本地去征询 DNS 根服务器，DNS 根服务器发现是 .com 区域 治理的，通知本地去征询它。
本地去征询 .com 顶级域名服务器，.com 顶级域名服务器不太分明，通知本地去征询 baidu.com 主区域 的服务器。
本地去征询 baidu.com 主域名服务器，baidu.com 域服务器查找到对应的 IP 地址，返回给本地。
本地服务器告诉用户，baidu.com 对应的 IP 地址，同时缓存这个 IP 地址，下次就间接拜访了。

这个过程能够看看，具体的就不一一解说了，不懂的去看 jsliang 的文章：

浏览器 – 浏览器缓存
计算机网络 – DNS

当然，这两篇文章后续也会公布，能够先疏忽。

建设连贯阶段：3 次握手。建设客户端和服务器之间的连贯。
传输数据阶段
断开连接阶段：4 次挥手。断开客户端和服务器之间的连贯。

如果 3 次握手和 4 次挥手你不懂过程，具体能够看 jsliang 的文章：

计算机网络 – TCP

这里也能够先疏忽，后续进一步跟进了解。

发送 HTTP 申请的过程就是构建 HTTP 申请报文，并通过 TCP 协定发送到服务器指定端口（HTTP 协定默认端口 80/8080，HTTPS 协定默认端口 443）。

HTTP 申请报文由 3 局部组成：申请行 、 申请报文 和 申请注释。

申请行：罕用办法有：GET、POST、PUT、DELETE、OPTIONS、HEAD。
申请报头：容许客户端向服务器传递申请的附加信息和客户端本身的信息。
申请注释：通过 POST、PUT 等办法时，通常须要客户端向服务器传递数据，这些数据就贮存在申请注释中。

当然，HTTP 申请须要留神是否跨域，如何解决跨域问题：

浏览器 – 跨域

服务器解决申请结束后，会返回 HTTP 报文。

HTTP 响应报文也是由 3 局部组成：状态码 、 响应报头 和 响应报文。

状态码 ：1xx 批示信息 - 示意申请已接管；2xx 申请胜利 - 示意申请胜利接管并解析；3xx 重定向 - 示意要实现申请须要更进一步操作；4xx 客户端谬误 - 申请有语法错误或者申请无奈实现；5xx：服务端谬误 - 服务端未能实现非法的申请。 常见状态码：200（胜利）、304（申请内容有缓存，不须要更新）、404（网页或者文件找不到）、500（服务器 - 后端处理错误）。
响应报头：常见的响应报头字段 Server、Connection 等。
响应报文：服务器返回给浏览器的文本信息，通常 HTML、CSS、JS、图片等文件就放在这一部分。

综上，URL 解析过程的步骤 3 和步骤 4 是 HTTP 申请和服务器响应，所以这一块会问到 HTTP 状态码、HTTPS 等知识点，后续咱们会进一步跟进学习，这里先做概念性了解。

如上图，浏览器的渲染过程为：

解析 HTML，生成 DOM 树
解析 CSS，生成 CSS 规定树（CSS Rule Tree）
将 DOM Tree 和 CSS Rule Tree 相结合，生成 渲染树（Render Tree）
从根节点开始，计算每一个元素的大小、地位，给出每个节点所应该呈现的屏幕准确坐标，从而失去基于渲染树的 布局渲染树（Layout of the render tree）。
遍历渲染树，将每个节点用 UI 渲染引擎来绘制，从而将整棵树绘制到页面上，这个步骤叫 绘制渲染树（Painting the render tree）

在解析渲染过程中，可能会产生回流和重绘：

重绘 (repaint)：当元素款式的扭转不影响布局时，浏览器将应用重绘对元素进行更新，此时因为只须要 UI 层面的从新像素绘制，因而 损耗较少。
回流(reflow)：又叫重排（layout）。当元素的尺寸、构造或者触发某些属性时，浏览器会从新渲染页面，称为回流。此时，浏览器须要从新通过计算，计算后还须要从新页面布局，因而是较重的操作。

那么：

什么操作会重绘和回流？
如何优化？

具体可看：

浏览器 – 回流和重绘

后续跟进文章学习也是能够的，这里先贴链接。

在下面步骤中，其实能够挖掘很多优化点：

DNS 缓存
浏览器缓存
缩小回流和重绘
……

如果你过程都理解了，那么优化根本不是问题。

当然，为了加深印象，能够看 jsliang 整顿的文章：

浏览器 – 性能优化

JavaScript 的加载、解析和执行会阻塞 DOM 的构建。

也就是说：在构建 DOM 的时候，HTML 解析器如果碰到 JavaScript，那么就会进行构建 DOM，将控制权交给 JavaScript 引擎，等 JavaScript 运行结束，浏览器再从中断的中央复原 DOM 构建。

也就是说：首屏渲染越快，就越不应该在首屏的时候加载 JS 文件，这也就是倡议将 script 标签放到 body 标签底部，或者给 script 标签增加 defer/async 属性的起因。

波及 JS 引擎和渲染引擎两个线程间的通信，损耗性能。
操作 DOM 可能会反复回流，加剧性能损耗。

一 目录

二 前言

三 整体过程

四 DNS 解析

五 TCP 连贯

六 发送 HTTP 申请

七 服务器响应

八 浏览器解析渲染页面

九 其余问题及优化

9.1 渲染过程碰到 JS 文件怎么解决？

9.2 为什么操作 DOM 慢

一目录

二前言

三整体过程

六发送 HTTP 申请

七服务器响应

八浏览器解析渲染页面

九其余问题及优化