前端一面基础知识 ⑥——性能优化、Web安全、Linux常用命令
1.性能优化
1.1 原则
- ①多使用内存、缓存、或其他方法
- ②减少CPU计算量,减少网络加载耗时
- ③适应于所有编程的性能优化——空间换时间
1.2 让加载更快
- ①减少资源体积:压缩代码
- ②减少访问次数:合并代码、SSR服务器端渲染,缓存
- ③使用更快的网络:CDN
1.3 让渲染更快
- ①CSS放在head,JS放在body最下面
- ②尽早开始执行JS,用DOMContentLoaded触发
- ③懒加载(图片懒加载、下滑加载更多、分页器)
- ④对DOM查询进行缓存
- ⑤频繁的DOM操作,合并到一起插入到DOM结构
- ⑥节流、防抖等常用性能优化方法
1.4 缓存
- ①静态资源加hash后缀,根据文件内容计算hash
- ②文件内容不变,则hash不变,则url不变
- ③url和文件不变,则会自动触发Http缓存机制,返回304
1.5 SSR
- ①服务器端渲染:将网页和数据一起加载,一起渲染
- ②非SSR(前后端分离):先加载网页,再加载数据,再渲染数据
1.6 懒加载
- 页面内容数据过多,可以做分页器,这样即可以节省某个页面加载时间
- 滑动懒加载,当滑到底部没数据的时候再加载新的内容
- 点击懒加载,点击按钮,类似加载更多触发加载新的内容
1.7 防抖及其封装
「防抖」
- 防抖,顾名思义,防止抖动,以免把一次事件误以为多次事件,敲键盘就是一个每天都会接触到的防抖操作
- 「【防抖重在清零】」 (看完防抖节流再体会一下这个重点)
「应用场景」(帮助你更好理解防抖)
- ①登录、发短信等按钮避免用户点击太快,以至于发送了多次请求,需要防抖
- ②调整浏览器窗口大小时,resize次数过于频繁,造成计算过多,此时需要一次到位
- ③文本编辑器实时保存,当无任何更改操作1秒后进行保存
- ④用户输入结束或暂停时,才会触发change事件,类似搜索框中输入信息停下来1秒后才会出现可能要搜索的内容
「手写防抖封装」
function debounce ( fn , delay = 500 ) { let timer = null // timer在闭包中,不对外暴露,以免不小心获取进行修改造成错误 return function () { if( timer ){ clearTimeout( timer ) } // 清空定时器 timer = setTimeout( () => { fn.apply( this , arguments ) timer = null } , delay ) } }
1.8 节流及其封装
「节流」
- 顾名思义,控制水的流量。控制事件发生的频率,如控制为1秒发生一次,甚至1分钟发生一次。与服务端及网关控制的限流类似
- 「【节流重在加锁】」
「应用场景」(帮助你更好理解防抖)
- ①scroll事件,控制每隔一秒计算一次位置信息
- ②浏览器播放事件,控制每隔一秒计算一次进度信息
- ③拖拽一个元素时,要随时拿到该元素的被拖拽的位置,直接用drag事件,会频繁触发,很容易导致卡顿。此时采用节流,无论拖拽速度多快,都控制在每隔100ms触发一次
「手写节流封装」
function throttle ( fn , delay = 100 ) { let timer = null return function (){ if( timer ){ return } timer = setTimeout( () => { fn.apply( this , arguments ) // 这里不能用fn(),会报错,无法获得事件源对象event timer = null } , delay ) // delay设置的时间内重复执行的定时任务会被清空 } }
1.9 为什么防抖的是clearTimeout(timer),而节流的是return?
- 防抖是触发间隔大于time触发,所以每次在小于间隔time要清除上个定时器,而节流是不管time内触发多少次,只会每隔time时间触发一次,所以用return
- 假设time=100ms,一个人每50ms输入一个字符,连续10次,即500ms后防抖只会触发一次,而节流会触发5次。为什么呢?因为防抖的意思即输入完停止100ms后触发事件,而节流是控制100ms触发一次事件,所以防抖触发一次,节流会触发五次。(结合「体会防抖重在清零,节流重在加锁」这两句话)
2.Web安全
2.1 XSS攻击
「XSS跨站请求攻击」
以下都是可能发生的XSS注入攻击
- 在 HTML 中内嵌的文本中,恶意内容以 script 标签形成注入
- 在内联的 JavaScript中,拼接的数据突破了原本的限制(字符串,变量,方法名等)
- 在标签属性中,恶意内容包含引号,从而突破属性值的限制,注入其他属性或者标签
- 在标签的 href、src 等属性中,包含 javascript: 等可执行代码
- 在 onload、onerror、onclick 等事件中,注入不受控制代码
- 在 style 属性和标签中,包含类似 background-image:url("javascript:..."); 的代码(新版本浏览器已经可以防范)
- 在 style 属性和标签中,包含类似 expression(...) 的 CSS 表达式代码(新版本浏览器已经可以防范)
- 「XSS攻击场景」
- 一个博客网站,我发表一篇博客,其中嵌入<script>脚本,脚本内容:获取cookie,发送到我的服务器(服务器配合跨域)阅读了的人的cookie就会被盗取
「XSS预防」
- ①替换特殊字符,如<变为<,>变为>
- ②那么<script>就会变为<script>,直接显示,而不会作为脚本执行
- ③前端要替换,后端也要做替换,双保险
- ④主流的前端框架已做好预防
2.2 XSRF攻击
「XSRF跨站请求伪装」
「XSRF攻击场景」
- 你正在购物,看中了某个商品,商品id是100。付费接口是xxx.com/pay?id=100,但没有任何验证(现在的付费都会有验证,这里作为讲解,所以假设没有验证)。我是攻击者,我看中了一个商品,id是200。我想你发送了一封电子邮件,邮件标题很吸引人。但其实邮件正文隐藏着<img src='xxx.com/pay?id=200'>(并附带有别的执行付费脚本)你点击查看了这封邮件,就帮我购买了id是200的商品。
「XSRF预防」
- 使用post接口
- 增加验证,例如密码、短信验证码、指纹等
3.描述从输入url到渲染出页面的整个过程
「加载过程」
- ①DNS解析:域名 -> IP地址
- ②浏览器根据IP地址向服务器发起Http请求
- ③服务器处理Http请求,并返回给浏览器
「渲染过程」
- ①根据HTML代码生成DOM Tree
- ②根据CSS代码生成CSSOM
- ③将DOM Tree 和 CSSOM 整合形成 Render Tree
- ④根据Render Tree渲染页面
- ⑤遇到<script>则暂停渲染,优先加载并执行JS代码(JS代码有可能改变DOM结构而重新渲染),完成再继续
- ⑥直至把Render Tree渲染完成
相关推荐
开心就好 2020-06-16
81417707 2020-10-30
89243453 2020-08-24
houdaxiami 2020-08-15
89253818 2020-07-30
89253818 2020-07-19
81264454 2020-07-17
iftrueIloveit 2020-07-04
ItBJLan 2020-06-28
Jaystrong 2020-06-16
iftrueIloveit 2020-06-11
QiHsMing 2020-06-08
webfullStack 2020-06-07
不知道该写啥QAQ 2020-06-06
fsl 2020-06-05
Carlos 2020-05-31
85231843 2020-05-31
curiousL 2020-05-27
85497718 2020-05-27