常见技巧
输出网址后浏览器的做了什么:
1.DNS 域名解析;
2. 建设 TCP 连贯;
3. 发送 HTTP 申请;
4. 服务器解决申请;
5. 返回响应后果;
6. 敞开 TCP 连贯;
7. 浏览器解析 HTML;
8. 浏览器布局渲染;
思路:尽量优化每一步。
优化:
- DNS 服务
- 自行配置 host,能够省去 DNS 查问这个步骤。
- 花钱进步带宽
- 后端优化 sql 语句的查问速度,使其更快的返回给前端数据.
- 连贯复用,后端设置 keep-alive
- 后端开启 gzip 代码压缩,浏览器会主动解压缩
- 先加载 css 再加载 JS,让用户先看到页面,再实现交互。
- 懒加载,先加载用户看到的第一页,再记录其余的页面。
- 预加载,比方看小说提前加载下一页
- http 缓存 css/js/ 图片,后端设置缓存工夫,应用 hash 值判断须要更新的文件。cache-control
- 应用 2 个以上但不超过 4 个的域名,因为域名限度最大并发申请数(CDN 域名)
- cookie-free,将须要 cookie 申请和不须要 cookie 申请的离开多个域名申请,放慢不须要 cookie 的申请速度。
以下为转载内容:
当聊起前端性能优化咱们要聊什么
背景
在前端的整个学习生涯中,咱们总是能一次次听到“性能”和“体验”这两个词。前端性能优化不仅是前端工程师工作中时刻须要关注的事实问题,也是前端面试中每每被问到的点。面试官之所以爱问,是因为偷懒。只需问这一个问题,就能在肯定水平考查面试者的常识广度、常识深度、总结能力、表达能力,还能沿着这条线持续问其余问题。
当被忽然问到性能这个问题时,大部分人会忽然一愣。总感觉有很多要说的货色,但又感觉横七竖八一下子不知从何说起。通过一番考虑,脑子里缓缓翻出早年面试刷题时看到的“雅虎性能优化 N 条军规”,抓耳挠腮说上七八条。面试官面无表情的问了句“还有吗?”,此刻又不得不把脑仁像挤海绵一样疯狂压迫,再多滴出两三条似是而非的油水。心里面满是苦恼,埋怨本人的记忆力不够好。
其实就算是全背下来一口气说个几十条,面试官也不见得多称心。起因之一是条目太多没有主次听着容易让人烦,面试官本人都记不住你说了什么。二是这种形式的答复显著给人一种死记硬背做题家的感觉。(面试官真欠抽)
咱们要聊什么
答复性能问题有两个思路。顺着这两个思路,不须要过多记忆就能自然而然的并且“很有见地”的答复十几条甚至几十条优化计划,当然前提是这些优化计划你平时真的用过。
思路一、从日常接触到的前端性能场景登程
性能瓶颈次要呈现在三个场景
- 在开发时每次批改代码打包须要几分钟,太慢(开发构建阶段)
- 关上网站,等了几十秒才看到页面,太慢(资源加载 和页面渲染 阶段)
- 页面展示后,页面上动画不晦涩。滚动页面或者拖拽元素卡顿感重大,甚至页面会解体(操作体验 阶段)
一、开发构建阶段(常见问题:如何让 Webpack 打包更快)
- 并发:应用多过程打包
- 缓存:打包时利用缓存
- 打包量要小:放大文件搜寻范畴,减小不必要的编译工作
二、资源加载阶段
外围思路是:传输量要小、间隔要近、并行传输、资源复用、事后加载。
传输量要小
- 构建时 HTML 压缩
- 构建时 CSS 压缩合并
- 构建时 JavaScript 压缩合并
- 构建时图片的压缩
- 应用 SVG sprite 或者字体图标代替图片 ICON
- 服务端开启 Gzip,数据在传输之前再次压缩
- 构建时是应用 TreeShaking,缩小不必要的代码引入
- 单页利用路由懒加载,缩小首次加载的资源体积
- 组件懒加载,缩小首次加载的资源体积
- 图片懒加载,缩小首次加载的资源体积
间隔要近
- 动态资源部署到 CDN
并行传输
- 降级到 HTTP2.0(常见问题:HTTP2.0 相比 HTTP1.x 做了哪些降级?多路复用;二进制分帧;服务端推送;数据流优先级;头部压缩)
资源复用
- 服务端配置动态资源缓存(常见问题:HTTP 缓存策略?Cache-Control?keep-alive?304?ETag?)
- 打包时候包复用
事后加载
- 浏览器在闲暇的工夫偷偷事后加载,<link rel=”prefetch” href=”url”>
三、页面渲染阶段
- CSS 在上、JS 在下
- 加载 CSS 举荐用 link 少用 @import
- 不重要的外置引入的 JS 应用 defer 或者 async 属性异步加载
四、操作体验阶段
- 动画晦涩
-
- 尽量应用 transition 和 animation 来实现 CSS 动画 , 而不是 JS 实现动画(运行在主线程对动画的晦涩度有影响)
- 动画尽量多用 transfrom 和 opacity(无需重绘和回流,性能最好)
- translateZ/translate3d 开启硬件加速
- JS 动画应用 requestAnimationFrame 少用 setInterval
- 滚动 / 挪动 / 操作晦涩
-
- DOM 增删操作要少(虚构长列表、DOM Diff)
- 高频操作应用防抖和节流
- 密集型计算
-
- 计算密集型操作能够交给 WebWorker 并发解决
来自若愚 @饥人谷
思路二、从生存角度聊前端性能
假如你是公司的 CTO,当初有一个产品须要在尽可能短的工夫内上线,在现有团队不加班不 996 的前提下如何做?计划无外乎是:
- 压缩需要,迭代开发——压缩
- 多用旧轮子 (代码、计划、架构) 少造新轮子——缓存
- 减少人手——并发
和前端性能优化做对应
- 压缩需要,迭代开发:动态资源的压缩合并、Gzip、各种懒加载、开发打包时的放大文件搜寻范畴
- 多用旧轮子 (代码、计划、架构) 少造新轮子:资源申请时 HTTP 缓存、开发打包时配置应用缓存、打包时配置分包复用
- 减少人手:资源申请时应用 HTTP2 实现并发申请、开发打包时配置应用并发能力、WebWorker
从以上两个思路动手,对于有教训的你来说天然才思泉涌,轻轻松松让本人和面试官兴奋起来,甚至能在肯定水平上左右后续的发问。
提到性能,大脑里须要浮现 6 字箴言:压缩 、 缓存 、 并发。前面的都交给小脑自由发挥吧。
一次性弄懂性能优化
www.yuque.com/hvvsva/xcxoqg/gugadx