合并 CSS 或 js 文件使要下载的文件数减少
使用图片精灵将大量的背景图片整合到一张图片,然后用
和
- background-image
控制背景图片的位置定位到要显示的图片,适用于数量多,体积小的图表等图片。
- background-position
将图片转化为
格式直接嵌入
- base64
内部
分离组件可以最大化并行下载,但要确保只用不超过 2-4 个域,因为存在 DNS 查找的代价。例如,可以把 HTML 和动态内容部署在
,而把静态组件分离到
- www.example.org
和
- static1.example.org
。
- static2.example.org
当在浏览器导航栏中输入网站地址时,浏览器会按照浏览器 DNS 缓存、计算机 DNS 缓存、DNS 服务器的顺序以此查找与域名相映射的 IP。
DNS 查找数与页面主机数相同,较少主机数就可以较少 DNS 查找数,但是减少主机数也减少了页面组件能够并行下载的数量。因此找到一个平衡值可以兼顾两者的需要。2-4 个主机名是同时减少 DNS 查找和允许高并发下载的折中方案。
重定向会拖慢用户体验,在用户和 HTML 文档之间插入重定向会延迟页面上的所有东西,页面无法渲染,组件也无法下载,直到新的文档被送到浏览器。
支持压缩的 Accept-Encoding HTTP 请求头。
Content-Encoding 响应头
尽可能多地用 gzip 压缩减少资源体积。
内容分发网络(CDN)是一组分散在不同地理位置的 web 服务器,用来给用户更高效地发送内容。
使用缓存可以避免重复下载资源,加快响应时间
Expires 头指定了一个日期 / 时间, 在这个日期 / 时间之后,HTTP 响应被认为是过时的;在这之前的时间都可以使用缓存。
可以指定多项配置控制缓存是否可用、以及可用时间、或者根据验证器判断缓存是否可用。可以覆盖 expires 的设置。
由于精确度比 ETag 要低,所以这是一个备用机制。指定服务器资源的下次更新时间,在这之前都可以使用缓存。
服务器接收到请求时根据 If-None-Match 的验证码判断资源是否已改变,如果给定 URL 中的资源更改,则一定要生成新的 Etag 值,然后返回给客户端。
JavaScript 是分隔 onload(资源加载完毕)事件之前和之后的一个理想选择。例如,如果有 JavaScript 代码和支持拖放以及动画的库,这些都可以先等会儿,因为拖放元素是在页面最初渲染之后的。其它可以延迟加载的部分包括隐藏内容(在某个交互动作之后才出现的内容)和折叠的图片。
通过预加载组件可以充分利用浏览器空闲的时间来请求将来会用到的组件(图片,样式和脚本)。用户访问下一页的时候,大部分组件都已经在缓存里了,所以在用户看来页面会加载得更快。
一个复杂的页面意味着要下载更多的字节,dom 数的生成也会受到影响,而且用 JavaScript 访问 DOM 也会更慢。
用外部文件可以让页面更快,因为 JavaScript 和 CSS 文件会被缓存在浏览器。
HTML 文档中的行内 JavaScript 和 CSS 在每次请求该 HTML 文档的时候都会重新下载。
这样做减少了所需的 HTTP 请求数,但增加了 HTML 文档的大小。 而且另一方面,如果 JavaScript 和 CSS 在外部文件中,并且已经被浏览器缓存起来了,那么我们就成功地把 HTML 文档变小了,而且还没有增加 HTTP 请求数。
从代码中去除不必要的字符以减少大小,从而提升加载速度。代码最小化就是去掉所有注释和不必要的空白字符(空格,换行和 tab)
浏览器的 POST 请求是通过一个两步的过程来实现的:先发送 HTTP 头,在发送数据。所以最好用 GET 请求,它只需要发送一个 TCP 报文(除非 cookie 特别多)。
把样式表放到文档的 HEAD 部分能让页面看起来加载地更快。这是因为把样式表放在 head 里能让页面逐步渲染。
用 CSS 表达式动态设置 CSS 属性,是一种强大又危险的方式。从 IE5 开始支持,但从 IE8 起就不推荐使用了。
舍弃
- <link>
- @import
@import 的导入方式相当于在文档底部引入 css 文件,不利于页面的加载体验
重复脚本会创建不必要的 HTTP 请求,执行无用的 JavaScript 代码,而影响页面性能。
用 JavaScript 访问 DOM 元素是很慢的,所以,为了让页面反应更迅速,应该:
有时候感觉页面反映不够灵敏,是因为有太多频繁执行的事件处理器被添加到了 DOM 树的不同元素上。事件能够冒泡,所以可以捕获事件并得知哪个按钮是事件源。
脚本会阻塞并行下载,HTTP/1.1 官方文档建议浏览器每个主机名下并行下载的组件数不要超过两个,如果图片来自多个主机名,并行下载的数量就可以超过两个。如果脚本正在下载,浏览器就不开始任何其它下载任务,即使是在不同主机名下的。
但是如果脚本是用 document.write 插入到页面内容中的,就没办法再往下移了。
用推迟(deferred)脚本,有 DEFER 属性的脚本意味着不能含有 document.write,并且提示浏览器告诉他们可以继续渲染。
尝试把 GIF 格式转换成 PNG 格式,看看是否节省空间。在所有的 PNG 图片上运行 pngcrush(或者其它 PNG 优化工具)
不要因为在 HTML 中可以设置宽高而使用本不需要的大图。如果需要
- <img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那么图片本身(mycat.jpg)应该是 100x100px 的,而不是去缩小 500x500px 的图片。
favicon.ico 是放在服务器根目录的图片,它会带来一堆麻烦,因为即便你不管它,浏览器也会自动请求它,所以最好不要给一个 404 Not Found 响应。而且只要在同一个服务器上,每次请求它时都会发送 cookie,此外这个图片还会干扰下载顺序,例如在 IE 中,当你在 onload 中请求额外组件时,将会先下载 favicon。
图片 src 属性为空会导致浏览器向服务器发送另一个请求。
发送 cookie 也会影响性能,所以保证 cookie 尽可能的小,以最小化对用户响应时间的影响。
当浏览器发送对静态资源的请求时,cookie 也会一起发送,而服务器根本不需要这些 cookie。所以它们只会造成没有意义的网络通信量,应该确保对静态组件的请求不含 cookie。可以创建一个子域,把所有的静态组件都部署在那儿。
有一点需要注意:如果不知道应该用 example.org 还是 www.example.org 作为主页,可以考虑一下 cookie 的影响。省略 www 的话,就只能把 cookie 写到 *.example.org,所以因为性能原因最好用 www 子域,并且把 cookie 写到这个子域下。
www 是一个主域的二级子域,但指向的还是主域。
这个限制是因为 iPhone 不能缓存大于 25K 的组件,注意这里指的是未压缩的大小。这就是为什么缩减内容本身也很重要,因为单纯的 gzip 可能不够。
把各个组件打包成一个像有附件的电子邮件一样的复合文档里,可以用一个 HTTP 请求获取多个组件(记住一点:HTTP 请求是代价高昂的)。用这种方式的时候,要先检查用户代理是否支持(iPhone 就不支持)。
来源: http://www.bubuko.com/infodetail-2275152.html