前端从哪些方面优化网站

前端优化的目的是什么 ?

1. 从用户角度而言，优化可以让页面加载得更快、对用户的操做响应得更及时，可以给用户提供更为友好的体验。

2. 从服务商角度而言，优化可以减小页面请求数、或者减少请求所占带宽，可以节省可观的资源。

1、页面级优化
　　1. 减小 HTTP请求数

       (1). 从设计实现层面简化页面

       (2). 合理设置 HTTP缓
　　缓存的力量是强大的，恰当的缓存设置能够大大的减小 HTTP请求。以有啊首页为例，当浏览器没有缓存的时候访问一共会发出 78个请求，共 600多 K数据 (如图 1.1)，而当第二次访问即浏览器已缓存以后访问则仅有 10个请求，共 20多 K数据 (如图 1.2)。 (这里须要说明的是，若是直接 F5刷新页面的话效果是不同的，这种状况下请求数仍是同样，不过被缓存资源的请求服务器是 304响应，只有 Header没有Body ，能够节省带宽 )怎样才算合理设置 ?原则很简单，能缓存越多越好，能缓存越久越好。

      (3). 资源合并与压缩
　　若是能够的话，尽量的将外部的脚本、样式进行合并，多个合为一个。另外， CSS、 Javascript、Image 均可以用相应的工具进行压缩，压缩后每每能省下很多空间。

      (4). CSS Sprites
　　合并 CSS图片，减小请求数的又一个好办法。
　　(5). Inline Images
　　使用 data: URL scheme的方式将图片嵌入到页面或 CSS中，若是不考虑资源管理上的问题的话，不失为一个好办法。若是是嵌入页面的话换来的是增大了页面的体积，并且没法利用浏览器缓存。使用在 CSS中的图片则更为理想一些。

       (6). Lazy Load Images（本身对这一块的内容仍是不了解）
　　这条策略实际上并不必定能减小 HTTP请求数，可是却能在某些条件下或者页面刚加载时减小 HTTP请求数。对于图片而言，在页面刚加载的时候能够只加载第一屏，当用户继续日后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。 有啊首页 曾经的作法是在加载的时候把第一屏以后的图片地址缓存在 Textarea标签中，待用户往下滚屏的时候才 “惰性” 加载。

   2. 将外部脚本置底（将脚本内容在页面信息内容加载后再加载）
　　前文有谈到，浏览器是能够并发请求的，这一特色使得其可以更快的加载资源，然而外链脚本在加载时却会阻塞其余资源，例如在脚本加载完成以前，它后面的图片、样式以及其余脚本都处于阻塞状态，直到脚本加载完成后才会开始加载。若是将脚本放在比较靠前的位置，则会影响整个页面的加载速度从而影响用户体验。解决这一问题的方法有不少，在 这里有比较详细的介绍 (这里是译文和 更详细的例子 )，而最简单可依赖的方法就是将脚本尽量的日后挪，减小对并发下载的影响。  

　3. 将 CSS放在 HEAD中
　　若是将 CSS放在其余地方好比 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了，这就致使页面由无 CSS状态跳转到 CSS状态，用户体验比较糟糕。除此以外，有些浏览器会在 CSS下载完成后才开始渲染页面，若是 CSS放在靠下的位置则会致使浏览器将渲染时间推迟。

  二.代码级别

　

做者：斯迪
连接：https://www.zhihu.com/question/21658448/answer/18903129
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

1. Javascript
　　(1). DOM
　　DOM操做应该是脚本中最耗性能的一类操做，例如增长、修改、删除 DOM元素或者对 DOM集合进行操做。若是脚本中包含了大量的 DOM操做则须要注意如下几点：
　　a. HTML Collection（HTML收集器，返回的是一个数组内容信息）
　　在脚本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection类型的集合，在平时使用的时候大多将它做为数组来使用，由于它有 length属性，也可使用索引访问每个元素。不过在访问性能上则比数组要差不少，缘由是这个集合并非一个静态的结果，它表示的仅仅是一个特定的查询，每次访问该集合时都会从新执行这个查询从而更新查询结果。所谓的 “访问集合” 包括读取集合的 length属性、访问集合中的元素。
　　所以，当你须要遍历 HTML Collection的时候，尽可能将它转为数组后再访问，以提升性能。即便不转换为数组，也请尽量少的访问它，例如在遍历的时候能够将 length属性、成员保存到局部变量后再使用局部变量。
　　b. Reflow & Repaint
　　除了上面一点以外， DOM操做还须要考虑浏览器的 Reflow和Repaint ，由于这些都是须要消耗资源的，具体的能够参加如下文章：
如何减小浏览器的repaint和reflow?
Understanding Internet Explorer Rendering Behaviour
Notes on HTML Reflow

　　(2). 慎用 with
with(obj){ p = 1}; 代码块的行为其实是修改了代码块中的 执行环境 ，将obj放在了其做用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，若是没有再依次按做用域链向上查找，所以使用 with至关于增长了做用域链长度。而每次查找做用域链都是要消耗时间的，过长的做用域链会致使查找性能降低。
　　所以，除非你能确定在 with代码中只访问 obj中的属性，不然慎用 with，替代的可使用局部变量缓存须要访问的属性。
　　(3). 避免使用 eval和 Function
　　每次 eval 或 Function 构造函数做用于字符串表示的源代码时，脚本引擎都须要将源代码转换成可执行代码。这是很消耗资源的操做 —— 一般比简单的函数调用慢 100倍以上。
　　eval 函数效率特别低，因为事先没法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器没法优化上下文，所以只能有浏览器在运行时解释代码。这对性能影响很大。
　　Function 构造函数比 eval略好，由于使用此代码不会影响周围代码 ;但其速度仍很慢。
　　此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。
　　(4). 减小做用域链查找（这方面设计到一些内容的相关问题）
　　前文谈到了做用域链查找问题，这一点在循环中是尤为须要注意的问题。若是在循环中须要访问非本做用域下的变量时请在遍历以前用局部变量缓存该变量，并在遍历结束后再重写那个变量，这一点对全局变量尤为重要，由于全局变量处于做用域链的最顶端，访问时的查找次数是最多的。
　　低效率的写法：
// 全局变量
var globalVar = 1;
function myCallback(info){
for( var i = 100000; i--;){
//每次访问 globalVar 都须要查找到做用域链最顶端，本例中须要访问 100000 次
globalVar += i;
}
}
　　更高效的写法：
// 全局变量
var globalVar = 1;
function myCallback(info){
//局部变量缓存全局变量
var localVar = globalVar;
for( var i = 100000; i--;){
//访问局部变量是最快的
localVar += i;
}
//本例中只须要访问 2次全局变量
在函数中只须要将 globalVar中内容的值赋给localVar 中区
globalVar = localVar;
}
　　此外，要减小做用域链查找还应该减小闭包的使用。
　　(5). 数据访问
　　Javascript中的数据访问包括直接量 (字符串、正则表达式 )、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问须要更大的开销。当出现如下状况时，建议将数据放入局部变量：
　　a. 对任何对象属性的访问超过 1次
　　b. 对任何数组成员的访问次数超过 1次
　　另外，还应当尽量的减小对对象以及数组深度查找。
　　(6). 字符串拼接
　　在 Javascript中使用"+" 号来拼接字符串效率是比较低的，由于每次运行都会开辟新的内存并生成新的字符串变量，而后将拼接结果赋值给新变量。与之相比更为高效的作法是使用数组的 join方法，即将须要拼接的字符串放在数组中最后调用其 join方法获得结果。不过因为使用数组也有必定的开销，所以当须要拼接的字符串较多的时候能够考虑用此方法。

　　关于 Javascript优化的更详细介绍请参考：
Write Efficient Javascript(PPT)
Efficient JavaScript
　　2. CSS选择符
　　在大多数人的观念中，都以为浏览器对 CSS选择符的解析式从左往右进行的，例如
#toc A { color: #444; }
　　这样一个选择符，若是是从右往左解析则效率会很高，由于第一个 ID选择基本上就把查找的范围限定了，但实际上浏览器对选择符的解析是从右往左进行的。如上面的选择符，浏览器必须遍历查找每个 A标签的祖先节点，效率并不像以前想象的那样高。根据浏览器的这一行为特色，在写选择符的时候须要注意不少事项，有人已经一一列举了， 详情参考此处。

　　3. HTML
　　对 HTML自己的优化现现在也愈来愈多的受人关注了，详情能够参见这篇 总结性文章 。

　　4. Image压缩
　　图片压缩是个技术活，不过现现在这方面的工具也很是多，压缩以后每每能带来不错的效果，具体的压缩原理以及方法在《 Even Faster Web Sites》第10 章有很详细的介绍，有兴趣的能够去看看。

（转载来源于前端大牛，因为被转次数过多，原始出处未知https://www.zhihu.com/question/21658448）