来，聊一聊性能优化

不管是应付前端面试还是改进产品体验，性能优化都是躲不开的话题。这里我们就简单聊一聊性能优化。传输快 vs 体验快

优化的目的是让用户有“快”的感受，那如何让用户感受到快呢？

加载速度真的很快，用户打开输入网址按下回车立即看到了页面

加载速度并没有变快，但用户感觉你的网站很快

传输快

所谓的真快就是网站资源以最快的速度到达用户浏览器，那如何去做呢？我们先粗略定一些原则：

传输的内容体积要小

传输的内容数量要少

网速要足够快

服务器响应要及时

能重复利用的资源要利用好

暂时不需要的资源先不要

将来需要的资源抽空要

下面就能顺藤摸瓜，做个细化

传输的内容体积要小

图片要压缩

图片根据支持情况选择体积更小的格式(如 webp)

css、js 内容压缩

服务端开启 Gzip，在传输数据之前再次压缩

传输的内容数量要少

图片图标合并（css sprite）、svg 图标合并（svg sprite）

css、js 文件打包合并

网速要足够快

服务器出口带宽要够

考虑到南北差异、运营商差异，在不同地区部署服务器

服务器响应要及时

接口响应速度要快(数据库优化、查询优化、算法优化)

cpu、内存、硬盘读写不要成为瓶颈；多加几台机器

重要页面(首页)静态化。服务端提前渲染后首页生成静态页面，用户访问首页直接返回静态页面，不需要像其他页面那样还需加载 css、js 再获取数据渲染展示

能重复利用的资源要利用好

服务器设置合适的静态资源缓存时间

前端文件打包时做合理的分块，让公共的资源缓存后能被多个页面复用

暂时不需要的资源先不要

图片懒加载

功能、模块、组件按需加载

将来需要的资源抽空先拿到

DNS 预解析

预连接

预获取

预渲染

体验快

所谓的体验快就是让用户觉得网站的交互是“流畅的”、“舒适的”。比如

滚动页面不要有迟滞感

1.对于短时连续大量触发的操作要做节流

一些常见操作不要感觉拖泥带水

DOM 的操作不要过于频繁

不要出现内存泄露

优化复杂运算

动画不要卡顿

多用 CSS 动画，少用 JS 动画

开启硬件加速

不要用 setTimeout/setInterval 去模拟动画

动画或者过渡的执行时间不要太久

性能优化的建议

臆想的优化不是优化，无明显成效的优化不是优化。浏览器的性能已经足够快，不要因为“过渡优化”牺牲代码的可读性

先做简单见效快的优化，再做复杂见效慢的优化。一张未压缩的大图片可能抵消辛辛苦苦做的全部其他技术优化

文章来源于网络，如有侵权请联系我们，将予以删除