前端性能优化？

最新推荐文章于 2021-11-30 20:46:10 发布

maggie_live

最新推荐文章于 2021-11-30 20:46:10 发布

阅读量206

点赞数

分类专栏：前端文章标签：前端性能优化

本文链接：https://blog.csdn.net/maggie_live/article/details/80689817

版权

前端专栏收录该内容

31 篇文章 0 订阅

订阅专栏

content方面

减少HTTP请求：合并文件、css精灵、inline 图片；

合并文件是通过吧所有脚本放在一个文件中的方式来减少请求书的，当然，也可以合并所有的css。

css sprites是减少图片请求数量的方式，把背景图片都整合到一张图片中，然后用css中backround-image和background-position属性来定位要显示的部分。

图像映射可以把多张图片合并成单张图片，总大小是一样的，当减少请求数并加速了页面加载。图片映射只有在图像在页面中红连续的时候才有用，比如导航条。

行内图片（base64编码）用data:URL模式来把图片嵌入页面。这样会增加HTML文件的大小，把行内图片放在（缓存）样式表中是好办法，而且成功避免了页面变重。

2. 减少DNS查询：DNS查询完成之前浏览器不能从这个主机下载任何文件。

方法：DNS缓存、将资源分布到恰当数量的主机名，平衡并行下载和DNS查询。如果客户端的DNS cache是空的（包括浏览器和操作系统），DNS查找数等于页面上不同的主机名数，包括页面URL、图片、脚本文件、样式表、flash对象等等组件中的主机名，减少不同的主机名就可以减少DNS查找。减少不同主机名的数量同时也减少了页面能够并行下载的组件数量，避免DNS查找削减了响应时间，而减少并行下载数量却增加了响应时间。

3. 避免重定向：多余的中间访问

重定向需要的所有信息都在http头部，而响应体一般是空的，其实额外的http头，比如expire是和cache-control也表示重定向。除此之外还有别的跳转方式：refresh元标签和JavaScript。

重定向用301和302状态码，301永久性转移，302暂时性转移。

相同点：

也就是说浏览器在拿到服务器返回这个状态码会自动跳转到一个新的URL地址，这个地址可以从响应的location首部中获取（用户看到的效果就是她输入的地址A瞬间变成了另外一个地址B)——这是它们的共同点。

不同点：

301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），**[搜索引擎](http://lib.csdn.net/base/searchengine)在抓取新内容的同时也将旧的网址交换为重定向之后的网址**；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，**搜索引擎会抓取新的内容而保存旧的网址。**

4.使AJAX可缓存

ajax可以给用户提供及时反馈，因为它能够从后台服务器异步请求信心。然后，用了ajax就无法保证用户在等待异步JavaScript和XML响应返回期间长。ajax缓存后可以减缓异步响应时间。

5.非必须组件延迟加载

比如JavaScript代码和动画库，都是可以等onload结束之后在需要的时候加载。

6.未来所需组件预加载

比如图片网站，需要提前加载，在滚动页面的时候及时呈现；

7.减少DOM元素数量

8.将资源放到不用的域下：浏览器同时从一个域下载资源的数目有限，增加域可以提高并行下载量（跨域分离组件）

9.减少iframe数量

iframe的优点：

1）引入缓慢的第三方内容，比如标志和广告；

2）安全沙箱

3）并行下载脚本

iframe的缺点：

1）代价高昂，即使是空白的iframe；

2）阻塞页面加载

3）非语义

10.不要404

404请求是完全没有必要的，不利于用户的体验，同时也浪费了服务器资源（比如数据库等等）。最糟糕的链接到的外部JavaScript有错误而且结果是404，首先阻塞并行下载。其次，浏览器会尝试解释404响应体，因为是JavaScript代码，需要找出其中可用的部分。

server方面

使用CDN
添加expires或者Cache-Control响应头
对组件使用Gzip压缩
配置ETag
Flush Buffer Early
Ajax使用get请求
避免空的src的img标签

cookie方面

减少cookie大小，清除没有必要的cookie，以最小化对用户响应时间的影响
引入资源的域名不要包含cookie

css方面

将样式表放到页面顶部
不使用css表达式
不使用IE的Filter，IE专有的AlphaImageLoader虑镜可以用来修复IE7之前的版本中半透明PNG图片的问题。在图片加载过程中，这个滤镜会阻塞渲染，卡主浏览器，还会增加内存消耗而且是被应用到每个元素的，而不是每个图片。
选择<link>舍弃@import

JavaScript方面

将脚本放到页面底部

脚本会阻塞并行下载，HTTP1.1官方文档建议浏览器每个主机名下并行下载的组件数不要超过两个，如果图片来自多个主机名，并行下载的数量就可以超过两个。如果脚本正在瞎子啊，浏览器就不开始任何其他下载任务，即使是在不同主机名下。

如果脚本是用document.write插入到页面内容中的，就没办法再往下一了，还可能存在作用域问题，在多数的情况下，这些问题都是可以解决的。可以用的deferred脚本，有DEFER属性的脚本意味着不能含有document.write。并且提示浏览器就可以继续渲染

2.将JavaScript和css从外部引入

3.压缩JavaScript和css

4.删除不需要的脚本

5.减少DOM访问

1)缓存已访问过的元素的索引

2）先“离线”更新节点，再把他们添到DOM树上

3）避免用JavaScript修复布局问题

6.合理设计事件监听器

图片方面

优化图片：根据实际颜色需要选择色深、压缩
优化css精灵
不要在HTML中拉伸图片
保证favicon.ico小并且可缓存，设置合适的有效期HTTP头，把有效期设置为几个月后一般比较安全，可以通过检查当前的favicon.ico的最后修改日期来确保变更能让浏览器知道

移动端

1.保证所有组件都小于25k

2.把组件打包到一个复合文档里

服务器

1.gizp组件

HTTP1.1开始，web客户端就又支持压缩的Aceept-Encoding HTTP请求头。Accept-Encoding: gzip,deflate；web服务器看到这个请求头，它就会用客户端列出的一种方式来压缩响应。web服务器通过content-Encoding响应体来通知客户端Content-Encoding: gzip;

2.避免图片src属性为空；

3.配置ETags

实体标签（ETag是），是服务器和浏览器用来决定浏览器缓存中组件于源服务器中组件是否匹配的一种机制（“实体”也就是组件：图片，脚本，样式表等等）。添加ETags可以提供一种实体验证机制，比最后修改日期更加灵活。一个组件某一具体版本的唯一标识符。唯一的格式约束是字符串必须用引号括起来，源服务器用响应头中的ETag来置顶组件的ETag：

2.用过哪些前端性能优化的方法？

减少http请求次数：（1）css sprite，js 、css源码压缩、图片大小控制合适；（2）网页Gzip、CDN托管，data缓存，图片服务器
前端模板js+数据，减少由于HTML标签导致的带宽浪费
前端用变量保存ajax请求结果，每次操作本地变量，不用请求，减少请求次数
用innerHTML代替DOM操作，减少DOM操作次数，优化JavaScript性能。
当需要设置的样式很多时设置className而不是直接操作style
少用全局变量、缓存DOM节点查找的结果
减少IO读取操作
避免使用css Expression（css表达式）又称Dynamic properties动态属性
图片预加载，将样式表放在顶部
将脚本放在底部加上时间戳
避免在页面的主体布局中使用table，table要等其中的内容完全下载之后才会显示出来，显示比div+css布局慢

3.前端需要注意哪些SEO

合理的title、description、keywords：搜索对这三项的权重逐个减少；（1）title值强调重点即可，重要关键词出现不要超过2次，而且要靠前，不同的页面的title要有所不用；（2）description把页面内容高度概括，长度合适，不可过分堆砌关键词，不同页面description有所不同；（3）keywords列举出重要关键词即可；
语义化的HTML代码，符合W3C规范：
重要内容html代码放在最前：搜索引擎抓取HTML顺序是从上到下，有的搜索引擎对抓取长度有限制，保证重要内容一定会被抓取
重要内容不要用js输出，爬虫不会执行js获取内容
少用iframe：搜索引擎不会抓取iframe中的内容
非装饰性图片必须加alt
提高网站速度：网站速度是搜索引擎排序的一个重要指标