减少 HTTP 请求次数或者减少请求数据的大小
页面中每发送一次 HTTP 请求, 都需要完成请求 + 响应这个完整的 HTTP 事务, 会消耗一些时间, 也可能会导致 HTTP 链接通道的堵塞, 为了提高页面加载速度和运行的性能, 我们应该减少 HTTP 的请求次数和减少请求内容的大小(请求的内容越大, 消耗的时间越长)
1, 采用 CSS 雪碧图 (CSS Sprit / CSS 图片精灵) 技术, 把一些小图合并在一张大图上, 使用的时候通过背景图片定位, 定位到具体的某一张小图上
- .pubBg{
- background:url('../img/sprit.png') no-repeat;
- background-size:x y; /* 和原图的大小保持一致 */
- }
- .box{
- background-position:x y; /* 通过背景定位, 定位到具体的位置, 展示不同的图片即可 */
- }
- ...
- <div class='pubBg box'></div>
2, 真实项目中, 我们最好把 CSS 或者 JS 文件进行合并压缩; 尤其是在移动端开发的时候, 如果 CSS 或者 JS 内容不是很多, 我们可以采取内嵌式, 以此减少 HTTP 请求的次数, 加快页面加载速度;
1)CSS 合并成一个, JS 也最好合并成一个 2)首先同过一些工具 (例如: webpack) 把合并后的 CSS 或者 JS 压缩成 xxx.min.js, 减少文件大小 3)服务器端开启资源文件的 GZIP 压缩 ... 通过一些自动化工具完成 CSS 以及 JS 的合并压缩, 或者再完成 LESS 转 CSS,ES6 转 ES5 等操作, 我们把这种自动化构建模式, 称之为前端 "工程化" 开发
3, 采用图片懒加载技术, 在页面开始加载的时候, 不请求真实的图片地址, 而是用默认图占位, 当页面加载完成后, 在根据相关的条件依次加载真实图片(减少页面首次加载 HTTP 请求的次数)
真实项目中, 我们开始图片都不加载, 页面首次加载完成, 先把第一屏幕中可以看见的图片进行加载, 随着页面滚动, 在把下面区域中能够呈现出来的图片进行加载
根据图片懒加载技术, 我们还可以扩充出, 数据的懒加载 1)开始加载页面的时候, 我们只把首屏或者前两屏的数据从服务器端进行请求 (有些网站首屏数据是后台渲染好, 整体返回给客户端呈现的) 2) 当页面下拉, 滚动到哪个区域, 在把这个区域需要的数据进行请求 (请求回来做数据绑定以及图片延迟加载等) 3) 分页展示技术采用的也是数据的懒加载思想实现的: 如果我们请求获取的数据是很多的数据, 我们最好分批请求, 开始只请求第一页的数据, 当用户点击第二页 (微博是下拉到一定距离后, 再请求第二页数据...) 的时候在请求第二页数据...
4, 对于不经常更新的数据, 最好采用浏览器的 304 缓存做处理(主要由服务器端处理)
例如: 第一次请求 CSS 和 JS 下来, 浏览器会把请求的内容缓存起来, 如果做了 304 处理, 用户再次请求 CSS 和 JS, 直接从缓存中读取, 不需要再去服务器获取了(减少了 HTTP 请求次数)
当用户强制刷新页面 (CTRL+F5) 或者当前缓存的 CSS 或者 JS 发生了变动, 都会从新从服务器端拉取
...
对于客户端来讲, 我们还可以基于 localStorage 来做一些本地存储, 例如: 第一次请求的数据或者不经常更新的 CSS 和 JS, 我们都可以把内容存储在本地, 下一次页面加载, 我们从本地中获取即可, 我们设定一定的期限或者一些标识, 可以控制在某个阶段重新从服务器获取
5, 使用字体图标代替一些页面中的位图(图片), 这样不仅做适配的时候方便, 而且更加轻量级, 而且减少了 HTTP 请求次数(类似于雪碧图)
6, 如果当前页面中出现了 AUDIO 或者 VIDEO 标签, 我们最好设置它们的
preload=none: 页面加载的时候, 音视频资源不进行加载, 播放的时候再开始加载
(减少页面首次加载 HTTP 请求的次数)
preload=auto: 页面首次加载的时候就把音视频资源进行加载了 preload=metadata: 页面首次加载的时候只把音视频资源的头部信息进行加载 ...
7, 在客户端和服务器端进行数据通信的时候, 我们尽量采用 JSON 格式进行数据传输
[优势] 1)JSON 格式的数据, 能够清晰明了的展示出数据结构, 而且也方便我们获取和操作 2)相对于很早以前的 XML 格式传输, JSON 格式的数据更加轻量级 3)客户端和服务器端都支持 JSON 格式数据的处理, 处理起来非常的方便
真实项目中, 并不是所有的数据都要基于 JSON, 我们尽可能这样做, 但是对于某些特殊需求(例如: 文件流的传输或者文档传输), 使用 JSON 就不合适了
8, 采用 CDN 加速
CDN: 分布式(地域分布式)
关于编写代码时候的一些优化技巧
除了减少 HTTP 请求次数和大小可以优化性能, 我们在编写代码的时候, 也可以进行一些优化, 让页面的性能有所提升(有些不好的代码编写习惯, 会导致页面性能消耗太大, 例如: 内存泄漏)
1, 在编写 JS 代码的时候, 尽量减少对 DOM 的操作(vue 和 REACT 框架在这方面处理的非常不错)
在 JS 中操作 DOM 是一个非常消耗性能的事情, 但是我们又不可避免的操作 DOM, 我们只能尽量减少对于它的操作
[操作 DOM 弊端] 1)DOM 存在映射机制 (JS 中的 DOM 元素对象和页面中的 DOM 结构是存在映射机制的, 一改则都改), 这种映射机制, 是浏览器按照 W3C 标准完成对 JS 语言的构建和 DOM 的构建(其实就是构建了一个监听机制), 操作 DOM 是同时要修改两个地方, 相对于一些其它的 JS 编程来说是消耗性能的 2) 页面中的 DOM 结构改变或者样式改变, 会触发浏览器的回流 (浏览器会把 DOM 结构重新进行计算, 这个操作很耗性能) 和重绘(把一个元素的样式重新渲染) ...
2, 编写代码的时候, 更多的使用异步编程
同步编程会导致: 上面东西完不成, 下面任务也做不了, 我们开发的时候, 可以把某一个区域模块都设置为异步编程, 这样只要模块之间没有必然的先后顺序, 都可以独立进行加载, 不会受到上面模块的堵塞影响(用的不多)
尤其是 AJAX 数据请求, 我们一般都要使用异步编程, 最好是基于 promise 设计模式进行管理(项目中经常使用 fetch,vue axios 等插件来进行 AJAX 请求处理, 因为这些插件中就是基于 promise 设计模式对 ajax 进行的封装处理)
3, 在真实项目中, 我们尽可能避免一次性循环过多数据(因为循环操作是同步编程), 尤其是要避免 while 导致的死循环操作
4,CSS 选择器优化
1)尽量减少标签选择器的使用 2)尽可能少使用 ID 选择器, 多使用样式类选择器 (通用性强) 3) 减少选择器前面的前缀, 例如:
- .headerBox .nav .left a{ }
- (选择器是从右向左查找的) ...
5, 避免使用 CSS 表达式
- /*CSS 表达式 */
- .box{
- background-color:expression((new Date()).getHours()%2?'red':'blue')
- }
6, 减少页面中的冗余代码, 尽可能提高方法的重复使用率:"低耦合高内聚"
7, 最好 CSS 放在 HEAD 中, JS 放在 BODY 尾部, 让页面加载的时候, 先加载 CSS, 在加载 JS(先呈现页面, 在给用户提供操作)
8,JS 中避免使用 eval
1)性能消耗大 2)代码压缩后, 容易出现代码执行错乱问题
9,JS 中尽量减少闭包的使用
1)闭包会形成一个不销毁的栈内存, 过多的栈内存累积会影响页面的性能 2)还会容易导致内存的泄漏
闭包也有自己的优势: 保存和保护, 我们只能尽量减少, 但是无可避免
10, 在做 DOM 事件绑定的时候, 尽量避免一个个的事件绑定, 而是采用性能更高的事件委托来实现
事件委托(事件代理) 把事件绑定给外层容器, 当里面的后代元素相关行为被触发, 外层容器绑定的方法也会被触发执行(冒泡传播机制导致), 通过事件源是谁, 我们做不同的操作即可
11, 尽量使用 CSS3 动画代替 JS 动画, 因为 CSS3 的动画或者变形都开启了硬件加速, 性能比 JS 动画好
12, 编写 JS 代码的时候尽可能使用设计模式来构建体系, 方便后期的维护, 也提高了扩充性等
13,CSS 中减少对滤镜的使用, 页面中也减少对于 FLASH 的使用
关于页面的 SEO 优化技巧
1, 页面中杜绝出现死链接(404 页面), 而且对于用户输入一个错误页面, 我们要引导到 404 提示页面中(服务器处理的)
2, 避免浏览器中异常错误的抛出
尽可能避免代码出错 使用 TRY CATCH 做异常信息捕获 ...
3, 增加页面关键词优化
来源: https://juejin.im/post/5afa6ad4518825426c68fbcb