HTTP响应头

　　要检查HTTP响应头，需要使用负载生成工具、网络分析工具或者是浏览器插件。如果你没有这些工具，一个助手网站可以帮到你。我推荐Peter Forret的网站“View and analyze HTTP headers” （http：//web.forret.com/tools/analyze.aspx），你只需输入页面的URL，网站就会获取到web服务器返回的一系列HTTP头，这样就可以检查页面过期和缓存等配置了。至于具体哪些是合适的、哪些是不不要的性能损失，这是和很多内容息息相关的，如网页和对象变化的频率、用户访问网站的频率、还有用户看到过时内容的相对风险。但是不管怎样，下面的这些是永远值得检查的：

　　1、过期时间是否恰当。如果一个对象的HTTP响应中没有过期时间这行，每次用户请求包含这个对象的页面时，都会向服务器发送一个请求，来判断缓存的这个版本是否“新鲜”。如果你有一些不易过期的对象（如公司的Logo），你可以通过设置一个未来很远的日期来避免这种有效性检查。过期时间最多应用在图片上，但在脚本、样式表、AJAX和FLASH等内容上也经常是适用的。检查一下没有过期时间的对象吧，看看是不是有不合适的。

　　2、ETags是否恰当。ETags是一种web服务器和浏览器使用的认证手段，用来判断客户机器上缓存的对象是否和服务器上的匹配。使用ETags的问题在于，它们对于一个特定的服务器通常是唯一的，这意味着如果网站有多个web服务器，ETags是会出现问题的。如果你确定只有一个web服务器，那么使用ETags是个不错的主意。如果是多个服务器，你就必须查明是否考虑到了这点，或者干脆建议不使用ETags。

　　3、其他缓存控制。你可能会看到类似的内容，Cache-Control、Last-Modified、Pragma、Set-Cookie、Age。如果你看到了，那么确保这些配置是有意义的。如果没有找到，而你又觉得应该有这些东西，那么找人看一下吧。

　　说到底，其实本质内容就是你要检查HTTP响应头，来判断网站是否已被合理配置来利用浏览器的缓存。通常，判断这些配置是否恰当的唯一方法，是同管理员和架构师探讨网站是如何使用的、以及是如何设计的，尤其是和浏览器缓存有关的地方。

　　源文件和其他对象

　　最后，如果你没以前没做过这些，你需要手工检查HTML源文件、css、脚本、图片以及其他对象。到现在，我还没发现任何一款能够节省我们的时间、对各种情况做出充分检查、并对前端性能提出建议的工具，虽然一些网站使用的HTML、脚本、图片的编辑器还是有一些帮助的。最后，关于前端性能测试，我的建议是：

　　1、确保脚本和CSS没有写在HTML源文件中。将脚本和CSS直接写在HTML中来提高性能，几乎是不可能的。原因很简单：网页的主HTML是更新最为频繁的部分之一，因此从缓存中受益最少。既然HTML很可能每次都要下载，只有尽量减小大小才是上策。将脚本和CSS与HTML分离，以便利用缓存，是肯定会提高性能的。

　　2、确保样式和脚本不重复。样式和脚本包含重复内容是非常恶心的。有时，不同的文件中有重复内容，有时在同一个文件中就会重复。你可能不想花费时间去做一个全面检查，那么只需快速的扫描一遍源文件，经常就能发现是否存在明显的重复。

　　3、检查代码最小化。最小化，指压缩和优化代码，让相关功能使用最少的代码行数。当检查HTML源文件、外部脚本和样式表时，需要注意过多的注释、空格、换行、变量名长度、以及其他能够增加文件大小的内容。

　　4、检查图片的大小和压缩。虽然大家都明白，仍然还有很多网页设计者使用这样一些图片格式，要么有不必要的文件大小、要么是同显示尺寸不同的尺寸、要么就是超过了所需要的品质。通常，GIF格式的图片是被压缩成64位甚至更少颜色的，它们完全满足大部分的图片和缩略图；JPG格式的图片被压缩成256位或者更少，对于照片来说也完全够用；通过HTML的height/width属性来缩放图片，不如创建再一个新的大小的图片。

　　这些内容，靠常识判断即可。例如，一些网站将所有的文件、目录以及变量的名字减少到两个甚至更少的字符，将这作为一种减小文件大小的策略。从纯粹的性能角度来看，这是好的；但是，对大多数网站来说，维持这些东西所产生的工作量完全抹杀了它的价值。你需要同团队一起，在去重、最小化、压缩和实用性之间找到一个平衡点。

　　总结

　　本文介绍了几种测试，可以用来判断网站是否可能会出现前端性能问题。检查这些可能的性能优化，可能会让用户感受到的响应时间提升50%甚至更多。我确信，一旦你有了自己的工具箱、插件和助手网站，并且实际的练过几次之后，你只需花费比读这篇文章更少的时间，就能检查一个网站是否有这些问题了。有了这么大性能优化的可能性，又在时间和工具上投入这么少，我实在是找不到任何不进行这些测似的理由。