Web 前端工程师写的页面要跑在浏览器里面，所以面试中也会出现很多跟浏览器相关的面试题目。

#知识点梳理

• 浏览器加载页面和渲染过程
• 性能优化
• Web 安全

本小节会从浏览器的加载过程开始讲解，然后介绍如何进行性能优化，最后介绍下 Web 开发中常见的安全问题和预防。

#加载页面和渲染过程

可将加载过程和渲染过程分开说。回答问题的时候，关键要抓住核心的要点，把要点说全面，稍加解析即可，简明扼要不拖沓。

题目：浏览器从加载页面到渲染页面的过程

1. 加载过程

要点如下：

• 浏览器根据 DNS 服务器得到域名的 IP 地址
• 向这个 IP 的机器发送 HTTP 请求
• 服务器收到、处理并返回 HTTP 请求
• 浏览器得到返回内容

例如在浏览器输入https://test.com/timeline，然后经过 DNS 解析，juejin.im对应的 IP 是36.248.217.149（不同时间、地点对应的 IP 可能会不同）。然后浏览器向该 IP 发送 HTTP 请求。

server 端接收到 HTTP 请求，然后经过计算（向不同的用户推送不同的内容），返回 HTTP 请求，返回的内容如下：

其实就是一堆 HMTL 格式的字符串，因为只有 HTML 格式浏览器才能正确解析，这是 W3C 标准的要求。接下来就是浏览器的渲染过程。

2. 渲染过程

要点如下：

• 根据 HTML 结构生成 DOM 树
• 根据 CSS 生成 CSSOM
• 将 DOM 和 CSSOM 整合形成 RenderTree
• 根据 RenderTree 开始渲染和展示
• 遇到

  如果合并了，就只走一遍请求过程

  2. 静态资源缓存

  通过链接名称控制缓存

  只有内容改变的时候，链接名称才会改变

  这个名称不用手动改，可通过前端构建工具根据文件内容，为文件名称添加 MD5 后缀。

  3. 使用 CDN 让资源加载更快

  CDN 会提供专业的加载优化方案，静态资源要尽量放在 CDN 上。例如：

  4. 使用 SSR 后端渲染

  可一次性输出 HTML 内容，不用在页面渲染完成之后，再通过 Ajax 加载数据、再渲染。例如使用 smarty、Vue SSR 等。

  5. CSS 放前面，JS 放后面

  上文讲述浏览器渲染过程时已经提过，不再赘述。

  6. 懒加载

  一开始先给为 src 赋值成一个通用的预览图，下拉时候再动态赋值成正式的图片。如下，preview.png是预览图片，比较小，加载很快，而且很多图片都共用这个preview.png，加载一次即可。待页面下拉，图片显示出来时，再去替换src为data-realsrc的值。

  另外，这里为何要用data-开头的属性值？—— 所有 HTML 中自定义的属性，都应该用data-开头，因为data-开头的属性浏览器渲染的时候会忽略掉，提高渲染性能。

  7. DOM 查询做缓存

  两段代码做一下对比：

  var pList = document.getElementsByTagName('p')  // 只查询一个 DOM ，缓存在 pList 中了
  var i
  for (i = 0; i < pList.length; i++) {
  }
  

  var i
  for (i = 0; i < document.getElementsByTagName('p').length; i++) {  // 每次循环，都会查询 DOM ，耗费性能
  }
  
  

  总结：DOM 操作，无论查询还是修改，都是非常耗费性能的，应尽量减少。

  8. 合并 DOM 插入

  DOM 操作是非常耗费性能的，因此插入多个标签时，先插入 Fragment 然后再统一插入 DOM。

  var listNode = document.getElementById('list')
  // 要插入 10 个 li 标签
  var frag = document.createDocumentFragment();
  var x, li;
  for(x = 0; x < 10; x++) {
      li = document.createElement("li");
      li.innerHTML = "List item " + x;
      frag.appendChild(li);  // 先放在 frag 中，最后一次性插入到 DOM 结构中。
  }
  listNode.appendChild(frag);
  
  

  10. 事件节流

  例如要在文字改变时触发一个 change 事件，通过 keyup 来监听。使用节流。

  var textarea = document.getElementById('text')
  var timeoutId
  textarea.addEventListener('keyup', function () {
      if (timeoutId) {
          clearTimeout(timeoutId)
      }
      timeoutId = setTimeout(function () {
          // 触发 change 事件
      }, 100)
  })
  
  

  11. 尽早执行操作

  window.addEventListener('load', function () {
      // 页面的全部资源加载完才会执行，包括图片、视频等
  })
  document.addEventListener('DOMContentLoaded', function () {
      // DOM 渲染完即可执行，此时图片、视频还可能没有加载完
  })
  
  

  12. 性能优化怎么做

  上面提到的都是性能优化的单个点，性能优化项目具体实施起来，应该按照下面步骤推进：

  1. 建立性能数据收集平台，摸底当前性能数据，通过性能打点，将上述整个页面打开过程消耗时间记录下来
  2. 分析耗时较长时间段原因，寻找优化点，确定优化目标
  3. 开始优化
  4. 通过数据收集平台记录优化效果
  5. 不断调整优化点和预期目标，循环2~4步骤

  性能优化是个长期的事情，不是一蹴而就的，应该本着先摸底、再分析、后优化的原则逐步来做。

  #Web 安全

  题目：前端常见的安全问题有哪些？

  • Web 前端的安全问题，能回答出下文的两个问题，这个题目就能基本过关了。开始之前，先说一个最简单的攻击方式 —— SQL 注入。
  • 上学的时候就知道有一个「SQL注入」的攻击方式。例如做一个系统的登录界面，输入用户名和密码，提交之后，后端直接拿到数据就拼接 SQL 语句去查询数据库。如果在输入时进行了恶意的 SQL 拼装，那么最后生成的 SQL 就会有问题。但是现在稍微大型一点的系统，都不会这么做，从提交登录信息到最后拿到授权，要经过层层的验证。因此，SQL 注入都只出现在比较低端小型的系统上。

  1. 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 的内容。

  2. CSRF（Cross-site request forgery，跨站请求伪造）

  CSRF 是借用了当前操作者的权限来偷偷地完成某个操作，而不是拿到用户的信息。

  • 例如，一个支付类网站，给他人转账的接口是http://buy.com/pay?touid=999&money=100，而这个接口在使用时没有任何密码或者 token 的验证，只要打开访问就直接给他人转账。一个用户已经登录了http://buy.com，在选择商品时，突然收到一封邮件，而这封邮件正文有这么一行代码，他访问了邮件之后，其实就已经完成了购买。
  • 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也是很重要的。