没有404s
HTTP请求是昂贵的，所以提出一个HTTP请求并得到一个无用的响应（即404 Not Found）是完全没有必要的，并且会减慢用户体验而没有任何好处。
有些网站有帮助404s“你的意思是X？”，这对用户体验很好，但也浪费了服务器资源（如数据库等）。特别糟糕的是，当连接到外部JavaScript的错误，结果是404。首先，这个下载将阻止并行下载。接下来，浏览器可能会尝试解析404响应正文，就好像它是JavaScript代码一样，试图找到可用的东西。
减小Cookie大小
HTTP cookie由于各种原因（如身份验证和个性化）而被使用。有关cookie的信息在Web服务器和浏览器之间的HTTP标头中交换。尽可能降低cookies的大小，以尽量减少对用户响应时间的影响，这一点很重要。
欲了解更多信息，请 点击 Tenni Theurer和Patty Chi的“当cookie崩溃”。这项研究的结果：
消除不必要的cookie
尽可能降低Cookie大小，以尽量减少对用户响应时间的影响
请注意在相应的域级别设置Cookie，以便其他子域不受影响
适当地设置过期日期。较早的过期日期或不更早删除cookie，提高用户响应时间
为组件使用无Cookie域
当浏览器发出一个静态图像的请求，并将cookie与请求一起发送时，服务器对这些cookie没有任何用处。所以他们只是没有理由地创建网络流量。你应该确保静态组件被请求与无cookie的请求。创建一个子域，并在那里托管你所有的静态组件。
如果你的域名是www.example.org，你可以托管你的静态组件static.example.org。但是，如果你已经在顶级域名设置cookie example.org，而不是www.example.org，那么所有的请求， static.example.org将包括这些cookie。在这种情况下，您可以购买一个全新的域名，在那里托管您的静态组件，并保持此域名无cookie。雅虎 使用yimg.com，YouTube使用ytimg.com，亚马逊使用images-amazon.com等。
在无Cookie域上托管静态组件的另一个好处是，某些代理可能会拒绝缓存使用cookie请求的组件。在相关说明中，如果您想知道是否应将example.org或www.example.org用于您的主页，请考虑cookie的影响。省略www让你别无选择，只能写cookies *.example.org，所以出于性能原因，最好使用www子域名并将cookies写入该子域名。
最小化DOM访问
使用JavaScript访问DOM元素的速度很慢，所以为了获得更响应的页面，您应该：
缓存对访问元素的引用
更新节点“离线”，然后将它们添加到树中
避免使用JavaScript修复布局
有关更多信息，请查阅下载 Julien Lecomte 的YUI视频的 “高性能Ajax应用程序”。
开发智能事件处理程序
有时候，由于附加到DOM树的不同元素上的事件处理程序太多，页面的响应速度就会降低，而这些处理程序过于频繁地执行。这就是为什么使用事件代表是一个好方法。如果你在a里面有10个按钮div，那么只能把一个事件处理程序附加到div包装器，而不是每个按钮的一个处理器。事件冒泡，所以你可以捕捉事件并找出它起源于哪个按钮。
您也不需要等待onload事件才能开始使用DOM树。通常你所需要的是你想访问的元素在树中可用。您不必等待所有图像被下载。 DOMContentLoaded是您可能会考虑使用而不是onload的事件，但是直到它在所有浏览器中都可用，您可以使用YUI Event实用程序，该实用程序有一个onAvailable方法。
有关更多信息，请查阅下载 Julien Lecomte 的YUI视频的 “高性能Ajax应用程序”。
通过@import选择<link>
以前的最佳实践之一表明，CSS应该是最高的，以允许渐进式渲染。
在IE中的@import行为与<link>在页面底部使用的行为相同，所以最好不要使用它。
避免过滤器
IE专有的AlphaImageLoader过滤器旨在解决IE版本<7中的半透明真彩色PNG的问题。该过滤器的问题在于，在图像下载过程中，它会阻止渲染并冻结浏览器。这也增加了内存消耗，并应用于每个元素，而不是每个图像，所以问题倍增。
最好的办法是AlphaImageLoader完全避免使用PNG8而不是完美的降级，这在IE中是很好的。如果您绝对需要AlphaImageLoader，请使用下划线黑客_filter来惩罚您的IE7 +用户。
优化图像
在设计人员为网页创建图像之后，在将这些图像传输到Web服务器之前，仍然可以尝试一些操作。
您可以检查GIF并查看它们是否使用与图像中的颜色数相对应的调色板大小。使用imagemagick很容易检查使用
identify -verbose image.gif
在调色板中使用4色和256色“插槽”显示图像时，还有改进的空间。
尝试将GIF转换为PNG并查看是否有保存。往往不是，有。由于浏览器支持有限，开发人员经常不愿意使用PNG，但现在已经过去了。唯一真正的问题是真彩色PNG中的alpha透明度，但是再次，GIF不是真实的颜色，也不支持可变的透明度。所以GIF可以做的事情，调色板PNG（PNG8）也可以做（除了动画）。这个简单的imagemagick命令会产生完全安全的PNG：
convert image.gif image.png
“我们所说的只是：给PiNG一个机会！”
在所有PNG上 运行pngcrush（或任何其他PNG优化工具）。例：
pngcrush image.png -rem alla -reduce -brute result.png
在所有JPEG上运行jpegtran。该工具可以进行旋转等无损JPEG操作，也可以用来优化和删除图像中的注释和其他无用的信息（如EXIF信息）。
jpegtran -copy none -optimize -perfect src.jpg dest.jpg
优化CSS Sprites
在水平方向上将图像排列在水平方向而不是垂直方向通常会导致较小的文件大小。
在精灵中组合相似的颜色可以帮助您将颜色数量保持在较低的水平，理想情况下在256色以下，以适应PNG8。
“移动友好”，不要在精灵图像之间留下很大的差距。这不会影响文件大小，但需要较少的内存供用户代理将图像解压缩为像素图。100×100图像是10万像素，其中1000×1000是100万像素
不要在HTML中缩放图像
不要使用比您需要更大的图像，因为您可以在HTML中设置宽度和高度。如果你需要，
<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />
那么你的图像（mycat.jpg）应该是100x100px，而不是缩小的500x500px图像。
使favicon.ico小和缓存
favicon.ico是保留在服务器根目录下的映像。这是一个必要的罪恶，因为即使你不关心它，浏览器仍然会请求它，所以最好不要回应404 Not Found。另外，由于它在同一台服务器上，每次请求时都会发送Cookie。这个图像还会干扰下载顺序，例如在IE中，当您在onload中请求额外的组件时，会在这些额外的组件之前下载favicon。
所以要减轻有favicon.ico的缺点确保：
它很小，最好在1K以下。
设置过期标题与你感觉舒适（因为你不能重命名，如果你决定改变它）。您几乎可以在将来安全地设置Expires标题。你可以检查你当前的favicon.ico的最后修改日期做出明智的决定。
Imagemagick可以帮助你创建小图标
保持组件低于25K
这个限制与iPhone不会缓存大于25K的组件有关。请注意，这是未压缩的大小。这就是缩小比较重要的地方，因为gzip本身可能是不够的。
欲了解更多信息，请访问Wayne Shea和Tenni Theurer的“ 性能研究，第5部分：iPhone缓存 – 让它坚持下去 ”。
将组件打包成多部分文档
将组件打包成多部分文档就像带有附件的电子邮件一样，它可以帮助您用一个HTTP请求获取多个组件（请记住：HTTP请求是昂贵的）。当你使用这种技术，首先检查用户代理是否支持它（iPhone不）。
避免空的图像src
标签：服务器
具有空字符串src属性的图像会发生超过一个人的期望。它以两种形式出现：
直接的HTML
<img src =“”>
JavaScript的
var img = new Image（）;
img.src =“”;
两种形式都会产生相同的效果：浏览器向您的服务器发出另一个请求
Internet Explorer向该页面所在的目录发出请求。
Safari和Chrome向实际页面本身发出请求。
Firefox 3和更早版本的行为与Safari和Chrome相同，但版本3.5解决了此问题[错误444931]，不再发送请求。
遇到空的图像src时，Opera不会做任何事情。
为什么这种行为不好？
通过发送大量意外流量来瘫痪您的服务器，特别是对于每天获得数百万页面浏览量的页面。
浪费服务器计算周期，生成一个永远不会被查看的页面。
可能损坏的用户数据。如果您在请求中跟踪状态，无论是通过Cookie还是其他方式，都有可能销毁数据。即使图像请求没有返回图像，浏览器也会读取并接受所有标题，包括所有的Cookie。当其余的回应被抛弃时，损害可能已经完成。
这种行为的根本原因是在浏览器中执行URI解析的方式。此行为在RFC 3986 – 统一资源标识符中定义。当遇到一个空字符串作为URI时，它被认为是一个相对URI，并根据5.2节定义的算法解析。这个特定的例子，一个空字符串，在5.4节列出。Firefox，Safari和Chrome都按照规范正确解析了一个空字符串，而Internet Explorer解决了这个问题，显然符合RFC 2396 – 统一资源标识符（这已被RFC 3986废弃）的早期版本， 。所以从技术上讲，浏览器正在做他们应该做的事来解析相对的URI。问题是在这方面，
HTML5增加了对标签src属性的描述，以指示浏览器不要在4.8.2节中提出额外的请求：
src属性必须存在，并且必须包含引用非交互式（可选动画）图像资源的有效URL，该资源既不是页面也不是脚本。如果元素的基本URI与文档的地址相同，则src属性的值不能是空字符串。
希望浏览器将来不会有这个问题。不幸的是，<script src =“”>和<link href =“”>没有这样的条款。也许还有时间进行调整，以确保浏览器不会意外地执行此行为。
雅虎的JavaScript大师尼古拉斯·C·扎卡斯（Nicolas C. Zakas）启发了这个规则。欲了解更多信息检查他的文章“ 空图像src可以破坏您的网站 ”。