前端性能优化方案?
减少页面体积，提升网络加载
- 静态资源的压缩合并（JS 代码压缩合并、CSS 代码压缩合并、雪碧图）
- 静态资源缓存（资源名称加 MD5 戳）
- 使用 CDN 让资源加载更快
优化页面渲染
- CSS 放前面，JS 放后面
- 懒加载（图片懒加载、下拉加载更多）
- 减少DOM 查询，对 DOM 查询做缓存
- 减少DOM 操作，多个操作尽量合并在一起执（DocumentFragment）
- 事件节流
- 尽早执行操作（DOMContentLoaded）
- 使用 SSR 后端渲染，数据直接输出到 HTML 中，减少浏览器使用 JS 模板渲染页面 HTML 的时间...
传送门！
多域名的好处？
- 让不同用户可以根据自己喜欢记忆的域名找到网站
- 技术上或者可以通过不同域名达到区分不同访客的目的（比如分国内和国外、省内和省外等）
- 不浪费老域名的流量（比如以前已经用一个域名做了推广，现在新增了品牌域名）
HTTP和HTTPS的基本概念？
HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
HTTP与HTTPS有什么区别？
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。
简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
浏览器缓存有哪些？通常缓存有哪几种方式？
cookie
cookie 本身不是用来做服务器端存储的（计算机领域有很多这种“狗拿耗子”的例子，例如 CSS 中的 float），它是设计用来在服务器和客户端进行信息传递的，因此我们的每个 HTTP 请求都带着 cookie。但是 cookie 也具备浏览器端存储的能力（例如记住用户名和密码），因此就被开发者用上了。
使用起来也非常简单，document.cookie = ....即可。
但是 cookie 有它致命的缺点：
- 存储量太小，只有 4KB
- 所有 HTTP 请求都带着，会影响获取资源的效率
- API 简单，需要封装才能用
locationStorage 和 sessionStorage
后来，HTML5 标准就带来了sessionStorage和localStorage，先拿localStorage来说，它是专门为了浏览器端缓存而设计的。其优点有：
- 存储量增大到 5MB
- 不会带到 HTTP 请求中
- API 适用于数据存储 localStorage.setItem(key, value) localStorage.getItem(key)
- sessionStorage的区别就在于它是根据 session 过去时间而实现，而localStorage会永久有效，应用场景不同。例如，一些需要及时失效的重要信息放在sessionStorage中，一些不重要但是不经常设置的信息，放在localStorage中。
另外告诉大家一个小技巧，针对localStorage.setItem，使用时尽量加入到try-catch中，某些浏览器是禁用这个 API 的，要注意。...
前端常见的安全问题有哪些？请简述xss原理及防范
Web 前端的安全问题，能回答出下文的两个问题，这个题目就能基本过关了。开始之前，先说一个最简单的攻击方式 —— SQL 注入。
XSS（Cross Site Scripting，跨站脚本攻击）
这是前端最常见的攻击方式，很多大型网站（如 Facebook）都被 XSS 攻击过。
举一个例子，我在一个博客网站正常发表一篇文章，输入汉字、英文和图片，完全没有问题。但是如果我写的是恶意的 JS 脚本，例如获取到document.cookie然后传输到自己的服务器上，那我这篇博客的每一次浏览都会执行这个脚本，都会把访客 cookie 中的信息偷偷传递到我的服务器上来。
其实原理上就是黑客通过某种方式（发布文章、发布评论等）将一段特定的 JS 代码隐蔽地输入进去。然后别人再看这篇文章或者评论时，之前注入的这段 JS 代码就执行了。JS 代码一旦执行，那可就不受控制了，因为它跟网页原有的 JS 有同样的权限，例如可以获取 server 端数据、可以获取 cookie 等。于是，攻击就这样发生了。...
- XSS的危害
XSS 的危害相当大，如果页面可以随意执行别人不安全的 JS 代码，轻则会让页面错乱、功能缺失，重则会造成用户的信息泄露。
比如早些年社交网站经常爆出 XSS 蠕虫，通过发布的文章内插入 JS，用户访问了感染不安全 JS 注入的文章，会自动重新发布新的文章，这样的文章会通过推荐系统进入到每个用户的文章列表面前，很快就会造成大规模的感染。
还有利用获取 cookie 的方式，将 cookie 传入入侵者的服务器上，入侵者就可以模拟 cookie 登录网站，对用户的信息进行篡改。...
- XSS的预防
那么如何预防 XSS 攻击呢？—— 最根本的方式，就是对用户输入的内容进行验证和替换，需要替换的字符有：
& 替换为：&
< 替换为：<
> 替换为：>
” 替换为："
‘ 替换为：'
/ 替换为：/
替换了这些字符之后，黑客输入的攻击代码就会失效，XSS 攻击将不会轻易发生。
除此之外，还可以通过对 cookie 进行较强的控制，比如对敏感的 cookie 增加http-only限制，让 JS 获取不到 cookie 的内容。
CSRF（Cross-site request forgery，跨站请求伪造）
CSRF 是借用了当前操作者的权限来偷偷地完成某个操作，而不是拿到用户的信息。
例如，一个支付类网站，给他人转账的接口是http://buy.com/pay?touid=999&money=100，而这个接口在使用时没有任何密码或者 token 的验证，只要打开访问就直接给他人转账。一个用户已经登录了http://buy.com，在选择商品时，突然收到一封邮件，而这封邮件正文有这么一行代码<img src="http://buy.com/pay?touid=999&money=100"/>，他访问了邮件之后，其实就已经完成了购买。
CSRF 的发生其实是借助了一个 cookie 的特性。我们知道，登录了http://buy.com之后，cookie 就会有登录过的标记了，此时请求http://buy.com/pay?touid=999&money=100是会带着 cookie 的，因此 server 端就知道已经登录了。而如果在http://buy.com去请求其他域名的 API 例如http://abc.com/api时，是不会带 cookie 的，这是浏览器的同源策略的限制。但是 —— 此时在其他域名的页面中，请求http://buy.com/pay?touid=999&money=100，会带着buy.com的 cookie ，这是发生 CSRF 攻击的理论基础。
预防 CSRF 就是加入各个层级的权限验证，例如现在的购物网站，只要涉及现金交易，肯定要输入密码或者指纹才行。除此之外，敏感的接口使用POST请求而不是GET也是很重要的。
HTTP协议的状态消息都有哪些?(如200、302对应的描述)
- 200 OK
请求正常处理完毕
- 204 No Content
请求成功处理，没有实体的主体返回 - 206 Partial Content
GET范围请求已成功处理 - 301 Moved Permanently
永久重定向，资源已永久分配新URI - 302 Found
临时重定向，资源已临时分配新URI - 303 See Other
临时重定向，期望使用GET定向获取 - 304 Not Modified
发送的附带条件请求未满足 - 307 Temporary Redirect
临时重定向，POST不会变成GET - 400 Bad Request
请求报文语法错误或参数错误 - 401 Unauthorized
需要通过HTTP认证，或认证失败 - 403 Forbidden
请求资源被拒绝 - 404 Not Found
无法找到请求资源（服务器无理由拒绝） - 500 Internal Server Error
服务器故障或Web应用故障 - 503 Service Unavailable
服务器超负载或停机维护
请简述一个页面从输入url到页面加载显示完成，这个过程都发生了什么？
- 浏览器根据 DNS 服务器得到域名的 IP 地址
- 向这个 IP 的机器发送 HTTP 请求
- 服务器收到、处理并返回 HTTP 请求
- 浏览器得到返回内容
例如在浏览器输入https://juejin.im/timeline，然后经过 DNS 解析，juejin.im对应的 IP 是36.248.217.149（不同时间、地点对应的 IP 可能会不同）。然后浏览器向该 IP 发送 HTTP 请求。
server 端接收到 HTTP 请求，然后经过计算（向不同的用户推送不同的内容），返回 HTTP 请求，返回的内容如下：
其实就是一堆 HMTL 格式的字符串，因为只有 HTML 格式浏览器才能正确解析，这是 W3C 标准的要求。接下来就是浏览器的渲染过程。
