如何给wordpress提速以及进行性能优化--初级入门版之1

来源:互联网 发布:java 防止js脚本注入 编辑:程序博客网 时间:2024/06/05 16:26
对于wordpress来说,进行性能优化,貌似主要的我们要做的,就是安装插件,所以,基本上,这个,不会很难....

我们所需要了解的,可以少到只了解一些应该了解的基本原理...

这几天在研究如何给blog.proudeng.com提速.

因为这个博客主机处在国外,距离在这里,整体上的速度肯定是不会很快,所以就想着能否采用减小图片尺寸阿,压缩网页大小等方式尽量的减小传输的数据的大小,这样优化,就有可能提高速度.

出于这个出发点,网上找了点资料,看了看.找了一些关于网站优化方面的文章看了看.

才发现原来,还真的有不少的方法,我们仅仅读到,就觉得可行的,且有道理的性能优化的方法.

整体而言,对网站的速度和性能进行优化的各种小方法有很多,看的时候,是看的比较的爽,觉得这个方法也好,那个方法也蛮不错的,但是到了总结的时候,就感觉很多的小方法,记忆起来,就比较的凌乱了.

还好,关于优化,是有分类的.从不同的几个角度出发进行优化,可以大体的分为下面的几类(其实就是YSlow和PageSpeed中的分类了,大差不差):

  1. 基于服务器端的优化,这部分的优化大体上来说涉及到动态语言以及数据库的优化,以及传输内容的压缩,缓存之类的内容.

  2. 基于网站内容的优化,这部分的优化其实因为涉及到网页的代码,所以小方法是很多的.涉及到一些HTTP方面的内容.

  3. 基于浏览器特性的优化,这部分的优化大体上基于浏览器的一些如并发特性,以及脚本加载特性,缓存特性等方面而做的优化.


其实上面分的三个类,都不是那么的互斥,不少的优化方法,看起来放到三个类中的每一个都很合适...所以,上面的分类只是给我们一个概念,就是我们考虑优化的话,可以从这几个方面来考虑,至于思考,讨论出的方法到底归于哪一类,就不要太过于纠结了.

归结下来的小方法估计有几十种,可以参见YSLOW和PageSpeed的网站优化的推荐方法.分别是一个长长的列表.

其中有不少是关于优化html代码和跟HTTP协议相关的,搞的我不是很清楚,毕竟不是很熟悉.不还好弄.

但是我们可以探讨一些很容易理解,效果也很明显,操作也不复杂(主要是因为插件已经存在,前人路已铺好,只要理解就行了,easey)的方法.

本来是想着基于上面的三个分类来小小总结一下,没个分类中的小方法的,但是觉得还是不是很直观,所以,画了一个简单的图,很简单,能够大体上描述浏览器是如何从服务器拿网页的.整个过程被分解成了几步,可以小小的探讨一下,在每一步中,是否藏着优化的可能性.见下图:

http connection

正常的采用Apache和PHP的系统中,浏览器连接上来的过程其实很简单,正如图上所示的那样,简单明了,不需要有过多的解释.

要说一句的是,图上看起来好像是有三台服务器,这个其实是刻意画出来的,是为了下面说明,内容分散能够促进并行下载,从而提高速度这一个目的而画出来的.正常的象我们这种小wordpress博客,内容都是放在一起,没必要分散到其他的服务器上.所有的图片阿,css阿,脚本阿,都是放在自己的主机上的.下面,就根据此图稍稍探讨一点wordpress优化入门.

1,服务器端使用cache:


正常的wordpress的处理流程是,当收到浏览器的请求时,Apache找到相应页面的php文件,然后从数据库中将文章的内容,评论的内容query出来,然后PHP程序会处理此php文件,将此动态文档转化为静态的html文档.然后回传给浏览器端.

虽然我手头上没有具体量化的数据,但是可想而见的是:

  • 从数据库中query出文章阿评论之类的内容是需要消耗系统资源,并且这个操作是需要一定的时间的,会引入一些延迟.

  • PHP处理而生成静态html文档,这个操作也是需要耗费系统资源,并且这个操作也是需要一定的时间的,会引入一些的延迟.


相对于全静态网页的网站的直接发送html页面的操作方式而言,动态网站由于有以上的延迟和操作的成本,反应速度的降低是不可避免的了.

那么如何来优化才能够弥补动态语言系统的这个问题呢?向静态化靠拢.这就是cache技术.

在服务器的优化方面,极为有效也极为广泛采用的方法就是采用cache,所谓的cache的概念,应该跟CPU里面的cache的作用一样,说白了就是动态网页的静态化.

文章一经发表后,正常情况下发生变更的可能性就比较少了,这是前提.那么,在服务器收到页面请求的时候,与其每次都读数据库,每次都用PHP生成同样的一个html文档的话,不如我们在后台直接就生成这样一个文档,保存下来,每次当有请求接入的时,就直接返回这个静态的html文档.这岂不快哉,岂不是又恢复到了原来的全静态网站?

所以,这是一个被广泛使用的技术.在wordpress上实现起来,其实就是简单的安装几个插件即可,操作简单,方便可行.

我使用了下面的几个插件,因为还没有使用很长的时间,不过网上的推荐的呼声还是蛮好的,分享出来:

  • WP Super Cache

  • WP Widget Cache

  • DB Cache Reloaded


各自插件的功能,参考它们插件的说明就够了.

其实一般用一个WP Super Cache插件也就够了.但是后来发现了下面的两个插件,号称能够在WP Super Cache的基础上plus一下,也就装上了.

WP Super Cache做的事情就给文章进行cache处理,在收到一次请求后,就将生成的html文档进行缓存,以便下次请求时直接使用.它还有一些其他的附加功能,如Gzip压缩,Preload之类.基本上,插件推荐的功能都勾上吧.

WP Widget Cache号称其功能是WP Super Cache功能的补充,因为Super Cache只对文章进行缓存,但是对左右边栏,其实因为很多情况下,左右边栏里的widget,如日历,链接表是不变的,也可以cache.由此得到此插件.

DB Cache Reloaded插件,号称能够对每一次数据库的Query进行缓存.因为查询数据库肯定是花时间的,如果我们将查询过的结果直接存下来,下次再有请求的时候,直接使用缓存的内容,不就省去了查数据库的时间和资源了么?(但是我很怀疑,在有WP Super Cache一经对全文进行了缓存的情况下,这个插件还有没有号称的功能,暂且先装上吧,再研究.)

基本上,上面的插件装上的话,已经能够明显的感觉到网站的速度的提升了.真简单.

使用cache的有一个不好的地方在于,如果我们对主题,图片什么的进行更改的话,因为有cache的存在,有可能不能够立即显示我们所做的更改.

2,降低http请求次数:


从上面图中1~7的流程图可以看出,浏览器发起一次请求,最终服务器返回给浏览器一个Html文档.但是过程到此还没有结束.现在的网页中,会使用很多的图像文件,而且现今的网页中广泛的使用了CSS和js,而这些一般都会存成一个很多个单独的文件,在html文档中只保留这些文件的链接.并没有随着html文档一起被传递给浏览器,所以,当浏览器发现得到html文档中还引用了其他的CSS文件或者js文件时,就会重新向服务器发起一次http请求,走的流程就是上图中的流程8了.可见,如果html文档中引用了很多的js脚本或者CSS文件的话,就需要建立起很多次的请求.下图是blog.proudeng.com在进行优化前的http请求数.

[caption id="" align="aligncenter" width="607" caption="原始的http连接数"]before_http_request[/caption]

如上图所示,在请求blog.proudeng.com的主页的过程中,除了进行http请求,得到最顶上的html文件之外,还有18次的额外请求,分别得到了3个CSS文件,3个js脚本,还有12个图形文件.每一次的请求均需要底层建立TCP连接(如果次文件处于不同的服务器上的话),然后进行HTTP交互.这么多次连接的协议的开销加上网络的延迟,就是一个不小的时间开销了.

所以,很有必要降低Http请求数量.

如何来做呢?有下面的方法:

  1. 尽量的将CSS文件合并成一个文件

  2. 尽量的将js文件合并成一个文件

  3. 将所有的图片拼合成为一个大背景图片,然后使用CSS sprite 找出没个图像的位置.(这个用在主题里面比较好吧,因为小图片比较多).


在wordpress中,我们怎么做呢?其实也很简单,使用插件么.

有一个叫做PHP Speedy的插件,是必不可少的,使用它,可以自动的合并所有的CSS文件,以及合并所有的js文件.至于CSS sprite,我到现在还没有采用,原因后述.

采用了PHP Speedy后的Http请求数的数据如下:

[caption id="" align="aligncenter" width="583" caption="优化之后http连接数"]after_potimization[/caption]

上图看起来很夸张,好像很多的http请求都没有了,效果很明显.其实可以看到有很多的图片没有请求,是因为我的浏览器已经把图片给缓存下来了,所以不需要再下载了.这个技术也是下面需要讨论的一个优化技术.

可以看到的是,原来的三个CSS文件,在开启了PHP Speedy插件后,被合并成了一个CSS文件.但是为什么三个js文件没有相应的合并呢?仔细看就能知道,这三个js文件分别是从三个不同的服务器上获取的,没法合并.如果是在运行wordpress的服务器上的多个js文件的话,那就应该会被合并了.上面这个图只是给一个大致的说明效果,可能拿来举例子,并不是很适合.

3,服务器压缩文件传输:


这个方法,说出来,不用想,就知道,肯定能够大幅压缩传输的规模.从而提高速度.使用的方法也很简答,使用插件么.

在我们前面装上的WP Super Cache和PHP Speedy插件里面,都有选项可以采用Gzip压缩这些数据(html,css,js).取其一即可.

但是在实际的系统中,有可能并不需要我们手动的使能这个选项,因为有些服务器本身就被配置成了默认采用gzip模式.

所以,我们此时手动的再次压缩一遍,并不能够提供更加好的效果,反而因为又多了一次压缩/解压缩的过程,结果会适得其反.

不过压缩/解压缩这个流程,本身就是一个费时间的过程,这个过程费时的程度,与因为压缩而节省下来的传输时间相比,到底哪个更省呢?这虽然是个疑问,但是一般情况下,还都是开启gzip压缩功能的.另外象我这样,wordpress的主机在国外的情况下,传输距离这么长,传输延迟随着数据量的大小变得很明显的情况下,还是开启此功能吧.在

我的blog.proudeng.com上的压缩后的数据比例(采用共享的主机,没法测试非gzip压缩下的网站反应时间,只能给个这个数据了)

gzip_file_size

由此可见,采用了gzip压缩,还是能节省很多的大小的,因为不管是html文档,还是CSS文档,Js文档,都是文本文档,压缩率还是比较高的.

over.