标签:
图片地图允许你在一个图片上关联多个URL,目标URL的选择取决于用户点击了图片上的哪个位置。
比如导航栏菜单有五个选项,为了美观,我们将菜单对应的超链接关联到图片上,可以使用五个分开的图片分别关联五个分开的超链接,此时加载这个导航菜单就要通过五次HTTP请求下载五张图片,如果将五个单独的图标合成一张图片,使用图片地图就可以将HTTP请求减少到一次。具体HTML代码如下:
<map name="map1" id="map1">
<area shape="rect" coords="0,0,31,31" href="javascript:alert(‘Home‘)" title="Home">
<area shape="rect" coords="36,0,66,31" href="javascript:alert(‘Gifts‘)" title="Gifts">
<area shape="rect" coords="71,0,101,31" href="javascript:alert(‘Cart‘)" title="Cart">
<area shape="rect" coords="106,0,136,31" href="javascript:alert(‘Settings‘)" title="Settings">
<area shape="rect" coords="141,0,171,31" href="javascript:alert(‘Help‘)" title="Help">
</map>
在<img>标签中我们中加载了一张包含所有图标的图片,在<map>标签中定义了一个客户端图像映射,图像映射(image-map)指带有可点击区域的一幅图像。area 元素永远嵌套在 map 元素内部,定义了图像映射中的区域。<img>的 usemap 属性可引用 <map> 中的 id 或 name 属性(取决于浏览器),所以我们最好同时向 <map> 添加 id 和 name 属性。
这些标签的具体用户可以参考w3cschool<map>、<area>
缺点:
图片地图上的区域坐标比较难确定
图片地图中的图片要按次序并且连续
和图片地图一样,CSS SPrites也可以合并图片,要使用CSS SPrites也需要将多个图片合并到一个单独的图片中,但是其对图片的次序、排列方向、是否连续没有硬性要求,因此推荐实际开发过程中采用此方法。任何支持背景图片的HTML元素,使用CSS的background-position属性,可以将HTML元素放置到背景图片中期望的位置(或者说,可以选取图片中期望的位置区域作为元素的背景)。关于background-position属性的用法可以参考background-position
<div id="navbar" style="background-color: #F4F5EB; border: 2px ridge #333; width: 180px; height: 32px; padding: 4px 0 4px 0;">
<a href="javascript:alert(‘Home‘)" title="Home"><span class="home"></span></a>
<a href="javascript:alert(‘Gifts‘)" title="Gifts"><span class="gifts"></span></a>
<a href="javascript:alert(‘Cart‘)" title="Cart"><span class="cart"></span></a>
<a href="javascript:alert(‘Settings‘)" title="Settings"><span class="settings"></span></a>
<a href="javascript:alert(‘Help‘)" title="Help"><span class="help"></span></a>
</div>
<style>
#navbar span {
width: 31px;
height: 31px;
display: inline;
float: left;
background-image: url(/images/spritebg.gif?t=1462159036);
/*加载的图片仍为上面例子中的图片
}
.home {
background-position: 0 0;
margin-right: 4px;
margin-left: 4px;
}
.gifts {
background-position: -32px 0;
margin-right: 4px;
}
/*比较多,后面的就省略了*/
</style>
JS具有阻塞特性,每次遇到<script>,页面都必须停下来等待脚本下载并执行,这会停止页面绘制,分散过多的js和css文件会导致HTTP请求增加。因此建议合理的合并脚本和样式表文件,从而减少请求次数。
内容分发网络(Content delivery network或Content distribution network,缩写:CDN)是指一种通过互联网互相连接的电脑网络系统,利用最靠近每位用户的服务器,更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户,来提供高性能、可扩展性及低成本的网络内容传递给用户。CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户请求。对于前端开发来说,可以将CDN用于发布静态内容,如图片、脚本、样式表。
浏览器(和代理)使用缓存来减少HTTP请求的数量,并减小HTTP响应的大小,使页面加载的更快。缓存的实现是Web服务器在相应中添加Expires头来告诉客户端它可以使用一个组件直到过期为止。
/*从服务器发送到客户端*/
Expires:Mon, 15 Apr 2024 20:00:00 GMT
这个响应头告诉浏览器该响应的有效性持续到2014年4月15日为止。需要指出的是使用Expires头要求服务器和客户端的时钟严格同步并且要经常检测过期时间。在HTTP1.1中引入了Cache-Control头来克服Expires头的限制,它使用max-age指令指定组件被缓存多久,单位为秒,为了兼容低版本的HTTP协议,可以同时使用上述两个响应头,HTTP规范规定max-age指令将重写Expires头
/*从服务器发送到客户端*/
Expires:Mon, 15 Apr 2024 20:00:00 GMT
Cache-Control: max-age=315360000
从HTTP1.1开始,Web客户端可以通过添加HTTP请求头Accept-Encoding来表示对压缩的支持
/*从客户端发送到服务器*/
Accept-Encoding: gzip, deflate
/*从客户端发送到服务器*/
Content-Encoding: gzip
p{
/*IE浏览器会识别这一项,忽略min-width,其他浏览器则相反*/
width: expression(document.body.clientWidth<600?"600px":"auto");
min-width: 600px;
border: 1px solid;
}
一般情况下内联Javascript和CSS(通过<script>和<style>标签定义的)的页面加载速度会比使用外部Javascript和CSS文件快,这是因为使用外部文件增加了HTTP的请求量,但是外部文件所带来的收益是 JavaScript 和 CSS 文件有机会被浏览器缓存起来。 HTML文档,至少是那些包含动态内容的HTML文档通常不会被配置为可以进行缓存,当遇到这种情况时文档没有被缓存每次请求 HTML 文档都要下载内联的 JavaScript和 CSS另一方面,如果 JavaScript和 CSS 是外部文件,浏览器就能缓存它们, HTML文档的大小减小,而且不会增加 HTTP 请求的数量。
这条规则也不是绝对的,关键因素是,与 HTML 文档请求数量相关的、外部 JavaScript 和 CSS 组件被缓存的频率。这个因素尽管难以量化,但可以通过下面几个基准衡量。
1.页面浏览量
毎个用户产生的页面査看越少,内联 JavaScript 和 CSS 的论据越强势。如果用户访问页面频率较低,即使缓存了外部文件也可能过期。
2.空缓存VS完整缓存
如果你的网站的本质上能够为用户带来髙完整缓存串,使用外部文件的收益就更大。 如果不大可能产生完整缓存,则内联是更好的选择。
对于作为多次页面査看中的第一次的主页,我们希望为主页内联 JavaScript 和 CSS, 但又能为所有后续页面査看提供外部文件。这可以通过在主页加载完成后动态下载外部组件来实现(通过 onload 亊件 ),这能够将外部文件放到浏览器的缓存中以便用户接下来访问其他页面。
<script>
function doOnload() {
// Do the downloading awhile AFTER the onload.
setTimeout("downloadComponents()", 1000);
}
window.onload = doOnload;
// Download external components dynamically using JavaScript.
function downloadComponents() {
downloadCSS("http://stevesouders.com/hpws/testsm.css?t=1462242339");
downloadJS("http://stevesouders.com/hpws/testsma.js?t=1462242339");
downloadJS("http://stevesouders.com/hpws/testsmb.js?t=1462242339");
downloadJS("http://stevesouders.com/hpws/testsmc.js?t=1462242339");
}
// Download a stylesheet dynamically.
function downloadCSS(url) {
var elem = document.createElement("link");
elem.rel = "stylesheet";
elem.type = "text/css";
elem.href = url;
document.body.appendChild(elem);
}
// Download a script dynamically.
function downloadJS(url) {
var elem = document.createElement("script");
elem.src = url;
document.body.appendChild(elem);
}
</script>
如果主页服务器知道一个组件是否在浏览器的缓存中,它可以在内联或使用外部文件之间做出最佳的选择。尽管服务器不能査看浏览器缓存中有些什么,但可以用 cookies 做指示器。如果 cookie不存在,就内联 JavaScript 和 CSS。如果 cookie 出现了 ,则有可能外部组件位于浏览器的缓存中 ,并使用了外部文件。
由于每个用户开始的时候都没有 cookie, 因此必须有一种途径来引导这一过程。这可以通过使用前一个例子中的加载后下载技术来完成。当用户第一次访问页面时,服务器发现没有 cookie, 于是生成一个内联了组件的页面。然后服务器添加 JavaScript 来在页面加载后动态下载外部文件 并设置 cookie),下一次访问页面时,服务器看到了 cookie就会生成一个使用外部文件的页面。
当客户端的 DNS 缓存为空(浏览器和操作系统都是)时, DNS査找的数量与 Web页面中唯一主机名的数量相等。这包括页面URL、图片、脚本文件、样式表、 Flash 对象等的主机名。 减少唯一主机名的数量就可以减少 DNS 査找的数址。But减少唯一主机名的数量会潜在地减少页面中并行下载的数量。 避免 DNS 査找降低了响应时间 ,但减少并行下载可能会增加响应时间。 正如规则6中“并行下载”中介绍的那样, 一定数量的并行下载是好的,因此建议是将这些组件分別放到至少 2 个,但不要超过 4 个主机名下。这是在减少 DNS 査找和允许高度并行下载之间作出的很好的权衡。另外,使用 Connection:Keep-Alive 也能带来好处,它可以通过重用现有连接,既能避免重复的DNS查找,也能避免 TCP/IP 开销来减少响应时间。
精简是从代码中移除不必要的字符以减小其大小,进而改善加载时间的实践。在代码被精简后,所有的注释以及不必要的空白字符(空格、换行和制表符)都将被移除。对于 JavaScript 而言,这可以改善响应时间效率,因为需要下载的文件大小减小了。
精简 CSS 能够带来的节省通常要小干精简 JavaScript, 因为通常 CSS 中的注释和空白比JavaScript少。最大的潜在节省来自于优化 CSS——合并相同的类、移除不使用的类等。CSS的依赖顺序的本质决定了这将是一个复杂的问题。这个领域还需要进一步研究和工具开发。最佳的解决方案还是移除注释和空白 ,并进行一些直观的优化,比如使用缩写(用 “#606” 代替 “#660066”和移除不必要的字符串 (用 “0”代替 “Opx”)。
在线 JS/CSS/HTML压缩工具
http://tool.oschina.net/jscompress
重定向用于将用户从一个 URL 重新路由到另一个URL。重定向有很多种301 和 302 是最常用的两种。通常针对 HTM文档进行重定向 ,但也可能用在请求页面中的组件(图片、脚本等) 时。实现重定向可能有很多不同的原因, 包括网站重新设计、跟踪流世、记录广告点击和建立易于记忆的URL,但主要要记得的是重定向会使你的页面变慢。
在开发大型网站的业务中,各个团队负责不同的业务功能,很容易产生相同的脚本被添加多次的情况。
重复脚本损伤性能的方式有两种:不必要的 HTTP请求和执行JavaScript所浪费的时间,
在熟悉这条规则之前,最后看一下http协议中关于缓存的知识。
实体标签(ETag)是 Web 服务器和浏览器用于确认缓存组件的有效性的一种机制,在进入 ETag的细节之前,我们先回顾一下组件是如何被缓存和确认有效性的。
当请求一个组件时,服务器会根据其选项在响应中返回一个Expires头,浏览器会缓存该组件
/*从服务器发送到客户端*/
Expires:Mon, 15 Apr 2017 20:00:00 GMT
如果缓存的组件过期了(或者用户明确地重新加载了页面 浏览器在重用它之前必须首先检査它是否仍然有效)
服务器在检测缓存的组件是否和原始服务器上的组件匹配时有两种方式
/*客户端请求*/
GET /i/yahoo.gif HTTP 1.1
Host: us.yimg.com
/*服务器应答*/
HTTP 1.1 200 OK
Last-Modified:tue, 12 Dec 2006 03:03:59 GMT
Content-Length: 1195
下一次请求时浏览器会使用 If-Modified-Since 头将最新修改日期传回到原始服务器以进行比较。如果原始服务器上组件的最新修改日期与浏览器传回的值匹配,会返回一个304 响应。
/*客户端请求*/
GET /i/yahoo.gif HTTP 1.1
Host: us.yimg.com
If-Modified-Since:Tue,12 Dec 2006 03:03:59 GMT
/*服务器应答*/
HTTP 1.1 304 Not Modified
实体标签:
ETag 提供了另外一种方式,用于检测浏览器缓存中的组件与原始服务器上的组件是否匹配。ETag 在 HTTP1.1中引入。 ETag是唯一标识了一个组件的一个特定版本的字符串。唯一的格式约束是该字符串必须用引号引起来。原始服务器使用 ETag 响应头来指定组件的 ETag。
/*客户端请求*/
GET /i/yahoo.gif HTTP 1.1
Host: us.yimg.com
/*服务器应答*/
HTTP 1.1 200 OK
Last-Modified:tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 1195
/*客户端请求*/
GET /i/yahoo.gif HTTP 1.1
Host: us.yimg.com
If-Modified-Since:Tue,12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
/*服务器应答*/
HTTP 1.1 304 Not Modified
ETag 的问题在于,通常使用组件的某些属性来构造它, 这些属性对于特定的、寄宿了网站的服务器来说是唯一的。 当浏览器从一台服务器上获取了原始组件,之后,又向 另外一台不同的服务器发起条件 GET 请求时, ETag 是不会匹配的 而对于使用服务器集群来处理请求的网站来说,这是很常见的一种情况。默认情况下,对于拥有多台服务器的网站,Apache 和 IIS 向 ETag 中嵌入的数据都会大大地降低有效性验证的成功率。
Apache 1.3 和 2.x 的 ETag 格式是 inode-size-timestamp文件系统使用 inode 来存储诸如文件类型、所有者、 组和访问模式等信息。尽管在多台服务器上一个给定的文件可能位于相同的目录、具有相同的文件大小、权限、时间截等,从一台服务器到另一台服务器,其 inode 仍然是不同的。
IIS5.0 和 6.0 在 ETag 上有着类似的问题。IIS上 ETag 的格式是 Filetimestamp:ChangeNumber. ChangeNumber 适用于路踪 IIS 配罝变化的计数器。 对于一个网站背后的所有IIS服务器来说, ChangeNumber 不大可能相同。
IIS5.0 和 6.0 在 ETag 上有着类似的问题。IIS上 ETag 的格式是 Filetimestamp:ChangeNumber. ChangeNumber 适用于路踪 IIS 配罝变化的计数器。 对于一个网站背后的所有IIS服务器来说, ChangeNumber 不大可能相同。
最后的结果是,对于完全相同的组件,从一台服务器到另一台, Apache 和 IIS产生的 ETag是不会匹配的。如果 ETag 不匹配,用 户就不会按照 ETage 的设计计划那样接收到更小更快的 304 响应,相反,它们会收到普通的 200 响应以及组件的所有数据。如果你只在一台服务器上寄宿网站,这不是什么问题,但如果你使用了服务器集群, 则组件的下载次数可能会比必须进行下载的次数多得多 ,这将导致性能的下降。ETag 还降低了代理缓存的效串.代理后面的用户缓存的 ETag 经常和代理缓存的 ETag 不匹配, 这导致不必要的请求被发送到原始服务器。用户和代理之间不会出现 304 响应,而是会产生两个又慢又大的200 响应—一个是从原始服务器到代理的, 另一个是从代理到用户的。并且 If-None-Match 比 If-Modified-Since 具有更髙的优先级。
鉴于ETag带来的缓存性能问题,有两种办法绕过它:一种使对ETag进行配置,Apache 1.3.23 版和之后版本支持FileETag指令,使用这一指令,可以从ETag中移除 inode, 只留下大小和时间截作为组件的 ETag? 类似地,在 IIS 中可以为所有服务器设置相同的 ChangeNumber, 保留文件的时间戳作为 ETag 中仅有的另一块信息。另一种办法是直接移除ETag。
使用Ajax会生成动态响应,只包含与这世界上的一个用户相关的信息。 缓存这些数据看上去没有任何意义。要记得的很重要的一点是,一个用户可能每天或毎周进行很多次请求(比如用户查看自己的邮箱中的邮件)。如果你可以为他缓存响应, 就会看到缓慢的和快速的用户体验之间的差距。
使这些 Ajax 请求可缓存,除了改变 HTTP 头之外(添加Expires头)还需要进行更多的工作, 响应的个性化和动态本质必须被反映到缓存中。可供采用的最好的方式是使用査询字符串参数。例如
/ws/mail /vl / formrpc?m=GetMessage&yid=steve_souders
标签:
原文地址:http://www.cnblogs.com/star91/p/5459364.html