Skip to main content

前端进阶知识2

性能​

前端性能优化手段​

前端性能优化手段从以下几个方面入手：加载优化、执行优化、渲染优化、样式优化、脚本优化

加载优化​

加载优化: 减少HTTP请求、缓存资源、压缩代码、无阻塞、首屏加载、按需加载、预加载、压缩图像、减少Cookie、避免重定向、异步加载第三方资源。

  1. 减少HTTP请求：尽量减少页面的请求数(首次加载同时请求数不能超过4个)，移动设备浏览器同时响应请求为4个请求(Android支持4个，iOS5+支持6个)
    • 合并CSS和JS
    • 使用CSS精灵图
  2. 缓存资源：使用缓存可减少向服务器的请求数，节省加载时间，所有静态资源都要在服务器端设置缓存，并且尽量使用长缓存(使用时间戳更新缓存)
    • 缓存一切可缓存的资源
    • 使用长缓存
    • 使用外联的样式和脚本
  3. 压缩代码：减少资源大小可加快网页显示速度，对代码进行压缩，并在服务器端设置GZip
    • 压缩代码(多余的缩进、空格和换行符)
    • 启用Gzip
  4. 无阻塞：头部内联的样式和脚本会阻塞页面的渲染，样式放在头部并使用 link 方式引入，脚本放在尾部并使用异步方式加载
  5. 首屏加载：首屏快速显示可大大提升用户对页面速度的感知，应尽量针对首屏的快速显示做优化
  6. 按需加载：将不影响首屏的资源和当前屏幕不用的资源放到用户需要时才加载，可大大提升显示速度和降低总体流量(按需加载会导致大量重绘，影响渲染性能)
    • 懒加载
    • 滚屏加载
    • Media Query加载
  7. 预加载：大型资源页面可使用 Loading ，资源加载完成后再显示页面，但加载时间过长，会造成用户流失
    • 可感知Loading：进入页面时Loading
    • 不可感知Loading：提前加载下一页
  8. 压缩图像：使用图像时选择最合适的格式和大小，然后使用工具压缩，同时在代码中用srcset来按需显示(过度压缩图像大小影响图像显示效果)
    • 使用TinyJpg和TinyPng压缩图像
    • 使用CSS3、SVG、IconFont代替图像
    • 使用img的srcset按需加载图像
    • 选择合适的图像：webp优于jpg，png8优于gif
    • 选择合适的大小：首次加载不大于1014kb、不宽于640px
    • PS切图时D端图像保存质量为80，M端图像保存质量为60
  9. 减少Cookie：Cookie会影响加载速度，静态资源域名不使用Cookie
  10. 避免重定向：重定向会影响加载速度，在服务器正确设置避免重定向
  11. 异步加载第三方资源：第三方资源不可控会影响页面的加载和显示，要异步加载第三方资源

执行优化​

  • CSS写在头部，JS写在尾部并异步
  • 避免img、iframe等的src为空：空src会重新加载当前页面，影响速度和效率
  • 尽量避免重置图像大小：多次重置图像大小会引发图像的多次重绘，影响性能
  • 图像尽量避免使用DataURL：DataURL图像没有使用图像的压缩算法，文件会变大，并且要解码后再渲染，加载慢耗时长

执行优化​

  • 设置viewport：HTML的viewport可加速页面的渲染
  • 减少DOM节点：DOM节点太多影响页面的渲染，尽量减少DOM节点
  • 优化动画
    • 尽量使用CSS3动画
    • 合理使用requestAnimationFrame动画代替setTimeout
    • 适当使用Canvas动画：5个元素以内使用CSS动画，5个元素以上使用Canvas动画
  • 优化高频事件：scroll、touchmove等事件可导致多次渲染
    • 函数节流
    • 函数防抖
    • 使用requestAnimationFrame监听帧变化：使得在正确的时间进行渲染
    • 增加响应变化的时间间隔：减少重绘次数
  • GPU加速：使用某些HTML5标签和CSS3属性会触发GPU渲染，请合理使用(过渡使用会引发手机耗电量增加)
    • HTML标签：video、canvas、webgl
    • CSS属性：opacity、transform、transition

执行优化​

  • 避免在HTML中书写style
  • 避免CSS表达式：CSS表达式的执行需跳出CSS树的渲染
  • 移除CSS空规则：CSS空规则增加了css文件的大小，影响CSS树的执行
  • 正确使用display：display会影响页面的渲染
    • display:inline后不应该再使用float、margin、padding、width和height
    • display:inline-block后不应该再使用float
    • display:block后不应该再使用vertical-align
    • display:table-*后不应该再使用float和margin
  • 不滥用float：float在渲染时计算量比较大，尽量减少使用
  • 不滥用Web字体：Web字体需要下载、解析、重绘当前页面，尽量减少使用
  • 不声明过多的 font-size：过多的font-size影响CSS树的效率
  • 值为0时不需要任何单位：为了浏览器的兼容性和性能，值为0时不要带单位
  • 标准化各种浏览器前缀
    • 无前缀属性应放在最后
    • CSS动画属性只用-webkit-、无前缀两种
    • 其它前缀为-webkit-、-moz-、-ms-、无前缀四种：Opera改用blink内核，-o-已淘汰
  • 避免让选择符看起来像正则表达式：高级选择符执行耗时长且不易读懂，避免使用

脚本优化​

  • 减少重绘和回流
    • 避免不必要的DOM操作
    • 避免使用document.write
    • 减少drawImage
    • 尽量改变class而不是style，使用classList代替className
  • 缓存DOM选择与计算：每次DOM选择都要计算和缓存
  • 缓存.length的值：每次.length计算用一个变量保存值
  • 尽量使用事件代理：避免批量绑定事件
  • 尽量使用id选择器：id选择器选择元素是最快的
  • touch事件优化：使用tap(touchstart和touchend)代替click(注意touch响应过快，易引发误操作)

安全​

提高网站的安全性​

前端常见安全问题
  1. iframe
  2. opener
  3. CSRF（跨站请求伪造）
  4. XSS（跨站脚本攻击）
  5. ClickJacking（点击劫持）
  6. HSTS（HTTP严格传输安全）
  7. CND劫持

XSS：跨站脚本攻击​

就是攻击者想尽一切办法将可以执行的代码注入到网页中。

存储型（server端）。场景：见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
攻击步骤：

  1. 攻击者将恶意代码提交到目标网站的数据库中
  2. 用户打开目标网站时，服务端将恶意代码从数据库中取出来，拼接在HTML中返回给浏览器
  3. 用户浏览器在收到响应后解析执行，混在其中的恶意代码也同时被执行
  4. 恶意代码窃取用户数据，并发送到指定攻击者的网站，或者冒充用户行为，调用目标网站的接口，执行恶意操作

反射型（Server端） 。与存储型的区别在于，存储型的恶意代码存储在数据库中，反射型的恶意代码在URL上。 场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。
  2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

Dom 型(浏览器端） 。DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。 场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。
  2. 用户打开带有恶意代码的 URL。
  3. 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
  4. 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

预防方案：（一是防止攻击者提交恶意代码，二是防止浏览器执行恶意代码）

  1. 对数据进行严格的输出编码：如HTML元素的编码，JS编码，CSS编码，URL编码等等
    • 避免拼接 HTML；Vue/React 技术栈，避免使用 v-html / dangerouslySetInnerHTML
  2. CSP HTTP Header，即 Content-Security-Policy、X-XSS-Protection
    • 增加攻击难度，配置CSP(本质是建立白名单，由浏览器进行拦截)
    • Content-Security-Policy: default-src 'self' 所有内容均来自站点的同一个源（不包括其子域名）
    • Content-Security-Policy: default-src 'self' *.trusted.com 允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
    • Content-Security-Policy: default-src https://xxx.com 该服务器仅允许通过HTTPS方式并仅从xxx.com域名来访问文档
  3. 输入验证：比如一些常见的数字、URL、电话号码、邮箱地址等等做校验判断
  4. 开启浏览器XSS防御：Http Only cookie，禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
  5. 验证码

CSRF：跨站请求伪造​

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

攻击流程举例：

  1. 受害者登录 a.com，并保留了登录凭证（Cookie）
  2. 攻击者引诱受害者访问了b.com
  3. b.com 向 a.com 发送了一个请求：a.com/act=xx浏览器会默认携带a.com的Cookie
  4. a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
  5. a.com以受害者的名义执行了act=xx
  6. 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

攻击类型:

  • GET型：如在页面的某个 img 中发起一个 get 请求
  • POST型：通过自动提交表单到恶意网站
  • 链接型：需要诱导用户点击链接

预防方案： CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

  1. 同源检测：通过Header中的Origin Header 、Referer Header 确定，但不同浏览器可能会有不一样的实现，不能完全保证
  2. CSRF Token 校验：将CSRF Token输出到页面中（通常保存在Session中），页面提交的请求携带这个Token，服务器验证Token是否正确
  3. 双重cookie验证
  4. Samesite Cookie属性

iframe 安全​

嵌入第三方 iframe 会有很多不可控的问题，同时当第三方 iframe 出现问题或是被劫持之后，也会诱发安全性问题。

点击劫持：攻击者将目标网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，诱导用户点击。

禁止自己的 iframe 中的链接外部网站的JS

预防方案：

  1. 为 iframe 设置 sandbox 属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则
  2. 服务端设置 X-Frame-Options Header头，拒绝页面被嵌套，X-Frame-Options 是HTTP 响应头中用来告诉浏览器一个页面是否可以嵌入 <iframe> 中
    • SAMEORIGIN: iframe 页面的地址只能为同源域名下的页面
    • ALLOW-FROM: 可以嵌套在指定来源的 iframe 里
    • DENY: 当前页面不能被嵌套在 iframe 里
  3. 设置 CSP 即 Content-Security-Policy 请求头
  4. 减少对 iframe 的使用

错误的内容推断​

说明： 文件上传类型校验失败后，导致恶意的JS文件上传后，浏览器 Content-Type Header 的默认解析为可执行的 JS 文件 预防方案： 设置 X-Content-Type-Options 头

第三方依赖包​

减少对第三方依赖包的使用，如之前 npm 的包如：event-stream 被爆出恶意攻击数字货币；

HTTPS​

描述： 黑客可以利用SSL Stripping这种攻击手段，强制让HTTPS降级回HTTP，从而继续进行中间人攻击。 预防方案： 使用HSTS（HTTP Strict Transport Security），它通过下面这个HTTP Header以及一个预加载的清单，来告知浏 览器和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信。这里的“强制性”表现为浏 览器无论在何种情况下都直接向务器端发起HTTPS请求，而不再像以往那样从HTTP跳转到HTTPS。另外，当遇 到证书或者链接不安全的时候，则首先警告用户，并且不再 用户选择是否继续进行不安全的通信。

本地存储数据​

避免重要的用户信息存在浏览器缓存中

静态资源完整性校验​

使用内容分发网络 (CDNs) 在多个站点之间共享脚本和样式表等文件可以提高站点性能并节省带宽。然而，使用CDN也存在风险，如果攻击者获得对 CDN 的控制权，则可以将任意恶意内容注入到 CDN 上的文件中 （或完全替换掉文件），因此可能潜在地攻击所有从该 CDN 获取文件的站点。

预防方案：将使用 base64 编码过后的文件哈希值写入你所引用的 <script> 或 标签的 integrity 属性值中即可启用子资源完整性能。

网络劫持​

描述：

  • DNS劫持（涉嫌违法）：修改运行商的 DNS 记录，重定向到其他网站。DNS 劫持是违法的行为，目前DNS 劫持已被监管，现在很少见 DNS 劫持
  • HTTP劫持：前提有 HTTP 请求。因 HTTP 是明文传输，运营商便可借机修改 HTTP 响应内容（如加广告）。

预防方案：全站 HTTPS

sql 注入​

通过把 SQL 命令插入到 Web 表单递交或输入域名或页面请求的查询字符串，最终达到欺骗数据库服务器执行恶意的 SQL 命令,从而达到和服务器 进行直接的交互

预防方案：

  1. 后台进行输入验证，对敏感字符过滤。
  2. 使用参数化查询，能避免拼接SQL，就不要拼接SQL语句。

url的加密解密​

JavaScript中有三个可以对字符串编码的函数

escape, encodeURI and encodeURIComponent

  • escape()除了 ASCII 字母、数字和特定的符号外，对传进来的字符串全部进行转义编码,因此如果想对URL编码，最好不要使用此方法
  • encodeURI() 用于编码整个URI,因为URI中的合法字符都不会被编码转换。
  • encodeURIComponent() 方法在编码单个URIComponent（请求参数）应当是最常用的，它可以讲参数中的中文、特殊字符进行转义，而不会影响整个URL。