Web性能优化包括哪些？？

负载均衡？？分布式？？CDN？？缓存？？

web性能包含很多方面，不仅仅是以上几种。我们先看一张图：

从上图看可以总结出，页面的加载时间包括dom结构加载和页面的渲染。

用户响应时间分布：

10%～20%——从服务器端获取HTML文档上（后端数据）

80%～90%——下载页面中的所有组件上（页面渲染）

在web项目有一个性能测试原则：“二八原则”，也就是说：前端为八，后端为二。

所以性能优化，不仅仅在后端，前端的优化往往能起到立竿见影的效果。下面根据我的一些经验分两块说一下一些优化点。

一、尽量减少前端HTTP请求

浏览器并发线程数有限，所以针对资源文件的优化，一般有：

1、 合并脚本文件和CSS文件
2、 CSS Sprites利用CSS background相关元素进行背景图绝对定位,把多个图片合成一个图片。

二、浏览器缓存

在用户浏览网站的不同页面时，很多内容是重复的，比如相同的JS、CSS、图片等。如果我们能够建议甚至强制浏览器在本地缓存这些文件，将大大降低页面产生的流量，从而降低页面载入时间。
1、添加Expires头和Cache-Control
Expires头，浏览器端根据过期时间选择是否加载最新的版本。缺点是：需要服务器和客户端时间的严格同步，
HTTP1.1引入了Cache-Control头来克服Expires头的限制。Cache-Control使用max-age制定组件被缓存多久，使用秒为单位，例如Cache-Control：max-age=3600；表示组件将被缓存60分钟。如果max-age和Expires同时出现，则max-age有更高的优先级，浏览器会根据max-age的时间来确认缓存过期时间。
2、Last-Modified
在上次传输中，服务器给浏览器发送了Last-Modified或Etag数据，再次浏览时浏览器将提交这些数据到服务器，验证本地版本是否最新的，如果为最新的则服务器返回304代码，告诉浏览器直接使用本地版本，否则下载新版本。一般来说，有且只有静态文件，服务器端才会给出这些数据。

三、页面压缩

• 1、GZIP
  • IE和Firefox浏览器都支持GZIP解码。后端服务器容器对数据GZIP压缩之后在传输到客户端，浏览器拿到数据后根据 Content-Encoding：gzip 进行解压，这样虽然稍微占用了一些服务器和客户端的CPU，但是换来的是更高的带宽利用率。对于纯文本来讲，压缩率是相当可观的。
• 2，HTML压缩
• 3，JS压缩 混淆
• 4，CSS压缩
• 5，图片压缩，展示尺寸和图片尺寸吻合

四、HTML代码结构优化

1，正确布置行内脚本

• 尽可能使用外部脚本和样式文件
• 脚本尽可能移到底部
• 脚本放在顶部带来的问题，
  1） 使用脚本时，对于位于脚本以下的内容，逐步呈现将被阻塞
  2） 在下载脚本时会阻塞并行下载
  放在底部可能会出现JS错误问题，当脚本没加载进来，用户就触发脚本事件。所以要综合考虑情况。
• Script延迟加载 defer属性(IE & FF3.1+)、setTimeout
• 风险：行内(内联)脚本在样式表后面。
  所有主流浏览器都会保持CSS和JavaScript的顺序。在样式表完全下载、解析及应用之后，内联脚本才能执行。同时，必须在内联脚本执行后，剩余资源才能下载。
  CSS的下载解析可以和其他资源并发执行。
  

2，少用iframe

优点：可以和主页面并行加载
缺点： iframe会阻塞onload事件 解决：onload事件后设置iframe的src，或者JS创建iframe节点
和主页面使用同一个连接池
避免src为空—为空默认为主页面地址

3，减少DOM结构的层级
DOM层级越深会增加 CSS rule Tree 和 Dom Tree 匹配构造的性能
4，减少Cookie的大小

5，尽量用div取代table，或者将table打破成嵌套层次深的结构
table会影响页面呈现的速度，只有table里的内容全部加载完才会显示。

五、组件分成多个域

主要的目的是提高页面组件并行下载能力。但不要跨太多域名，建议采用2个子域名。

六、图片懒加载

七、图片，脚本，数据 预加载

八、图片base64

九、根据业务实际情况优化，保证首屏加载时间。

前端优化可以避免我们造成无谓的服务器和带宽资源浪费，但随着网站访问量的增加，仅靠前端优化已经不能解决所有问题了，后端程序处理并发请求的能力、程序运行的效率、硬件性能以及系统的可扩展性，将成为影响网站性能和稳定的关键瓶颈所在。

评价指标：

一般有下面几个：

• 吞吐率：单位时间内服务器处理的请求次数（requests per second）
• 用户平均请求等待时间：每个用户发起一次请求->得到回应的耗时
• 服务器平均请求处理时间：服务器处理一条请求的耗时
• 系统负载：一般包括CPU使用率、CPU Load、内存使用情况、磁盘I/O、网络I/O等

优化建议和方法：

一、程序环境的优化

1、Tomcat，jvm，apache，mysql等软件环境安装配置参数的优化

2、应用程序预编译

二、web访问的负载均衡
比较流行用Nginx做代理服务器实现负载均衡

三、数据库的优化

索引优化，sql优化，分库分表，读写分离。
mysql的并发和性能依赖缓存和磁盘IO。磁盘io限制比较大，目前主流的SD硬盘读写速度约500MB/s

四、计算外包

为了保证较高的请求吞吐率以及处理单次请求的效率，业务逻辑代码中不适合出现特别耗时的操作（比如图像处理、群发邮件、推荐算法等），所以把这些耗时的计算过程从业务代码中外包出去，交给独立的计算模块完成。计算外包（也就是分布式计算）可以有2种策略：异步计算、并行计算。

五、缓存

页面缓存，服务端数据缓存，客户端数据缓存，数据库查询缓存等；

本地内存，本地文件，分布式缓存（分布式共享内存缓存memcache，可持久化redis）；

六、算法优化

七、服务模块化、服务拆分、动静分离

1、将服务按功能、实现逻辑等 分成若干个低耦合甚至不耦合的模块，拆分到不同的节点（服务器）。

2、页面 动态部分和静态部分分离，动态的程序采用apache，tomcat等后端服务容器，静态的部分如js，css，图片可以用轻量级的web server。也可以使用业内比较热门的CDN缓存技术

八、多个模块的优化

1、模块的分级。优先保证重要模块的执行和数据。

2、对各个模块根据不同的模块场景，可以选择异步执行（比如：日志上报，Log输出，等不影响业务流程的模块）或者 多线程并发执行（多个低耦合的模块）。

九、后端策略优化

以更优雅的交互策略达到用户一致的体验。

最常用的一种策略：用户操作触发时候处理，将集中处理改为分散处理。其他：懒加载，预加载。

借用一下JavaEye中别人讨论过的例子：某个系统要求在某个时间将用户积分清零的需求。

最直接的方案： 定时将系统中所有的用户积分清零。其弊端在于：如果系统用户量特别大，则在一小段时间内用户将不可进行积分操作。

优化后的策略：用户进行积分操作是分散的，同一时间进行积分操作的压力是很小。因此可以考虑在用户进行积分操作时才考虑是否进行积分清零。

十、日志输出的规范化

日志格式的规范、日志等级的问题、减少无用日志的输出、合理控制单次请求的日志条数。

首先规范化，没什么可说的，利人利己。

其次，日志输出太多，反而会影响性能。因为日志的输出会对日志文件加锁，如果日志并发大的太多，并发量高了反而会消耗cpu资源。所以应该颗粒控制日志的输出，减少不必要的日志输出。

十一、页面静态化

用一些模板组件，将不经常更新的页面内容静态化。例如58同城pc首页、大类页等。

十二、资源的复用（后端）

1、一次请求里，某一数据不要重复取

2、连接池（Http连接池，数据库连接池等等）

十三、编码优化

再牛X的策略也挡不住白菜一样的代码

性能优化，没有最好只有更好，它好，我也好。

任何一种优化都要以实际业务场景来适配，脱离业务场景谈优化真的是耍流氓。

除了做好这些优化点之外，各种性能监控也是必不可少的，包括：前端页面加载时间监控，首屏监控，页面语义监控，日志监控，后端响应时间监控，后端程序处理模块化时间监控等等。做好监控，也能辅助我们对系统更好的优化。