谈到网站优化，我们必须知道一次交互的过程中都经过哪几个阶段,然后在对应的阶段采取优化措施
一次交互大概经历以下几部分时间：
1.数据在网络中传输的时间（响应时间：发送数据的传输时间+返回数据的传输时间）
2.站点服务器接收到请求并生成回应数据的时间
3.浏览器计算并在本地渲染的时间
根据上述三个时间段，我在这简单的列举一下常用的优化方案
1.增加带宽：
当网页或组件下载速度变慢的话，一些架构师可能会采取增加带宽，因为他们认为是服务器带宽不够用了，这是最省事的一种方法，但是这对于提供下载服务为主的站点来说也许是这样的，对于其他服务的站点未必是好的解决方案
2.减少HTTP请求：
我们知道几乎每一个页面都包含了多个组件，每个组件都需要计算，下载，渲染，这些都是需要时间的，如果我们减少这些行为，那么就可以加快网页的执行速度，但是我们往往需要在优雅的网页以及网页的表现性能之间进行取舍，常见的优化方法是：
1.设计简单的网页，里面包含较少的图片和脚本，但是这可能牺牲了美观和用户交互
2.将多个图片文件合成一个图片文件，利用CSS偏移技术来呈现网页，这样可以避免多个图片下载
3.合并js脚本和css样式表
4.利用浏览器缓存策略,避免重复下载
可见这一块属于网页的前端优化
3.加快服务器的脚本执行计算速度
我们大多数涉及到性能的站点中都使用的各种各样额后台脚本语言：PHP,jsp,python,asp.net等等这行脚本都需要相应的解释器进行解释生成中间代码，然后依托解释器的运行环境中运行,所以生成中间代码这段时间又成为我们为获取性能提升瞄准的一大目标,对于一些较强的商业支持的语言比如ASP.net，JSP均有内置的优化方案（比如解释器第一次执行，然后将结果缓存下来）,而对于开源的脚本语言则依靠第三方组件来提供类似功能 比如PHP的APC组件
4.使用动态内容缓存
动态内容缓存是指将动态生成HTML页给缓存起来,在以后一段时间内当有用户访问的时候直接跳过计算阶段而直接输出缓存中的内容,听起来的确很好,但是好的东西往往都会有些难度,我们必须考虑：成千上万的缓存文件如何存储，缓存的命中率如何,缓存的过期侧略如何设计,在应用在多台web服务器的分布式站点上我们需要考虑什么？
5.使用数据缓存
动态内容缓存是将数据与表现一起打包缓存，这有时候并不是我们想要的效果,例如一个页面中有一部分是不经常变的（顶部ogo），而所以另外我们可以发现有时候一些动态计算总是消耗在对于一些特殊数据处理上，这些数据更新过于频繁,甚至占用大量的IO时间,如果我们想要提高缓存利用率，提高灵活性,以及性能的需求,所以引入了数据缓存
更加细粒度的缓存似乎可以避免网页的整体更新。有些内容是需要实时更新的（关系型数据的读取）,如果采取动态内容缓存的话,如果页面有更新，那么我们必须重新生成缓存，这对网页中不变的内容似乎有点不公平.
我们需要考虑的问题是：如何协调数据缓存和网页缓存,能否将二者结合在一起呢,数据缓存存放在哪？
6.动态内容静态化
在动态网页的内容中虽然避免了可观的重复计算,但是需要每次调用动态脚本解释器判定缓存是否过期以及读取缓存,这似乎有点多余，关键是消耗了不少时间,直接让浏览器访问缓存不是更好么？这种情况下缓存直接暴漏给HTML页,我们普遍称之为静态化。
7.更换web服务器软件
8.页面组件分离
9.合理的部署web服务器
我们知道访问的主机离我们的站点服务器距离越远,那么经过的路由节点越多,如果不在同一个互联网运营商的互联网中,还要经过运行商的*节点和骨干网络,可想而知这样要经过多少次存储转发,而且还要受不同运行商的出口带宽限制,显然我们希望我们的用户和站点服务器位于同一个互联网运营商的网络内,怎样实现呢？
10.使用负载均衡
如果我们已经最大程度上的发挥了单台服务器的处理能力，还不能满足现实需要,那么就需要更多的服务器一起分摊工作,为此我们需要想各种不同的办法实现web负载均衡,可能是简单的HTTP重定向,或是基于DNS的轮回解析,或者通过反向代理服务器来实现负载均衡调度,还可以通过LVS组件服务器集群等方法.
11.优化数据库
如果我们忽略了数据库的优化,如果我们的表结构一塌糊涂,那么可以说前面的工作白干了,web服务器与数据库服务器交互通信一般是基于TCP协议,即便他们是在同一台主机上也是如此，在数据库设计的时候你需要考虑：
1.你是否合理的运用这种类型的索引？
2.你了解数据库存储引擎的特性么？
12.考虑可扩展性
可扩展性对于我们来说是我们山穷水尽的时候被指引得一条星光大道,一旦扩展无法进行，那就是死路一条
13.减少视觉等待
有时候用户的要求的是你不要不理我，实在不行的话给用户一些提示吧