武汉SEO教你如何将网站打开速度从60S+优化到1.44S的方法

哪些方面容易导致网站打开慢？页面打开时间多长属于正常？现在有打开速度为1.44秒还有没有优化的空间？全站https如何实现？优化网站的专业技巧有哪些？全站https，打开速度60s+，终于有一天忍不住这屎一样的打开速度，决定优化下！原以为近10年的经历速度优化应该轻松搞定，做的时候发现技能欠缺太多。涉及到的知识到不仅仅是运维能力，还有前端、算法、DB、PHP语言开发等能力。最终在公司热心前端小哥的前端帮助下将站的打开速度从60S+优化到1.44s, 提高了41倍访问速度。

 

 

通常解决前面80%的问题需要花20%的精力，解决剩余的20%的问题需要共80%的精力。网站的优化其实我从60S优化到10S的时候，已经进行不下去了。但10S的打开速度对一个站点来讲依然是致命的，速度太慢了，正常网站打开速度最久不能超过3S，每增加1s，用户的耐心都指数级被考验，10s的访问速度几乎不会有用户驻留，12306这种霸王站点除外。从10s到1.44s是在前端同学的帮忙下，才得以继续。我们一步一步来看。

 

 

网站访问速度慢有很多种情况：

1.访问者自己硬件设备（硬盘、CPU、网口、运营商带宽）资源不足；

2.服务器硬件设备（硬盘、CPU、网口、运营商带宽）资源不足；

3.图片未做优化太大、太多导致资源加载太多而慢；

4.应用程序代码质量差导致性能消耗大、响应速度慢；

5.页面设计不合理，导致资源整合过多（图片、css、js、前后端请求等）；

6.其它DNS、安全入侵等问题。

通常解决掉硬件设备、服务器、图片大小可以帮我们解决80%的问题只需要花费20%的精力，应用程序、页面设计、DNS、安全入侵等问题，可以帮我们解决掉剩下的20%问题但需要花费80%的精力。

阿里云上查看了服务器性能消耗，虽然硬件1Core2GB内存配置不高，但常年负载0.01。接下来的思路也很简单，打开浏览器开发者工具（建设chrome）排查页面元素，服务器和硬件设备问题不做我们这次探讨内容。

图片未做优化，太多导致资源加载太而慢，我们打开chrome的开发者工具排查。

有没有发现页面只展示了不到1/4的内容，但打开耗时已经9.99s。首页达592KB，有很多大于50KB的图片，处理过程忘了保留现场，其实还有很多大于150KB图片。对号入座，图片资源没做优化，没有UI。图片很多，不可能一张张优化。

页面设计用的开源主题，没有可设计空间，看起来能优化的只有图片大小了。推荐linux下图片优化工具imagemagick convert功能测试通过后，简单粗暴处理了下网站图片问题。

这番简单粗暴的处理后，整体页面图片虽然变的模糊，但加载速度好在从60s优化在10S了。但对普通用户来讲，依然难以接受，3s以上的访问速度我们都无法接受。

从10秒到1.44秒，这个时候开始求助网络了。

谷歌关键字搜索“wordpress速度”，看到知乎上有个技术帖给出了以下几个建议：

1.关闭Avatar

2.去掉google字体

3.关闭Emoji

4.使用360云解析，自动加速

5.使用七牛免费加速

6.开启WP Super Cache插件

7.开启lazyer loader瀑布流加载

我们一项一项来尝试，关闭Avatar、去掉google字体、关闭Emoji这几项早在建站就已经解决了。使用360云解析，自动加速经测试无效（这里的无效指的是药不对症）

使用七牛免费加速，但手持身份证的阶段我放弃了，太麻烦了，而且还在公司不方便。

开启WP Super Cache插件开启测试无效。因为1.nginx开启gzip 2.php开启opcache 3.使用的主题有瀑布流布局异步加载的功能所以再开启这个功能没有效果。开启lazyer loader瀑布流加载无效同4步骤的原因一样，细究服务器性能。

转了一圈无果后，思路再回过来，到目前为止还没有具体定位到原因所在，就在瞎摸索，这是不对的！！不对的！！不对的！！重要的事情说三遍！！！

开启php-fpm的慢日志

开启myql的慢日志

经排查php，nginx，mysql均没有异常请求。php-fpm有慢请求，但不构成威胁，这次没有思路了。

求助前端同学，这里其实最大的疑问还是为什么首页会这么大，而我看下来什么也没有，就一个框架结构而已。最后不得已求助前端同学，经过排查后发现。

我的首页达714KB,加上出口只能1Mb，简单换算下：

首页的加载时间=714KB/1MB~=714KB/100KB~=7.14S

首页这么大，出口又这么小，加载时间当然长了，时间当然长了。那么首页多大合适呢？首页到底地方大哪里了？经过前端同学的协助排查发现，页面大概有5个地方有图片被转换为base64格式，导致页面变大。

那为什么我当时看不出来问题呢？因为我对base64不了解，看到source view里有一大堆字符串，没有安全问题，所以就自认为这是页面应该有的信息。而且又想当然认为字符串不会占据太多空间。我们来做个简单的数学题：

首先：1个英文字母占1个字节=1Byte

其次：1024个英文字母=1Byte*1024=1KB

然后1024*1000个英文字母=1KB*1000=1MB

接着：这么一大坨英文字母有多少个呢？约5290个字母，占多大空间呢？约为5.92KB。而这样的一大陀字母一屏显示不完。。。。。一个页面5个。共占用空间约700KB。

最后：前面有介绍过，我们很穷，所以宽带口只有1Mb约等于100KB

所以：懂了吧。我们单下载700KB的东西就需要700KB/100KB=7S

base64为什么会让首页变大呢？

说起来有点复杂，简单讲：Base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于{displaystyle 2^{6}=64}{displaystyle 2^{6}=64}，所以每6个比特为一个单元，对应某个可打印字符。3个字节有24个比特，对应于4个Base64单元，不足3个字节补足4个可打印字符来表示。因此可以估算编码后数据长度大约为原长的135.1%。

而优化后的页面是什么样子呢？几乎0KB，为什么会差别这么大呢？这是因为图片不采用base64加密，页面将不再镶嵌图片具体信息，而只会保留链接地址，即页面从原始图片大小x 135.1%变为一个链接地址的大小。

base64图片加密除此问题外，还会有浏览器兼容性、构建工具支持度要求等问题。base64既然让图片变大，为什么前端开发还要使用base64呢？

图片的base64编码就是可以将一副图片数据编码成一串字符串，使用该字符串代替图像地址。这样做有什么意义呢？我们知道，我们所看到的网页上的每一个图片，都是需要消耗一个http请求下载而来的，没错，不管如何，图片的下载始终都要向服务器发出请求，要是图片的下载不用向服务器发出请求，而可以随着HTML的下载同时下载到本地那就太好了，而base64正好能解决这个问题。效益虽小，但却缺能积少成多。

经过这次的细节优化后，你再打开时候快感还是不错。主要的瓶颈依然在图片，不过从我这个维度图片已经不能再做优化，这个时候UI的价值就凸显了。

本文地址：网站优化频道 http://www.hkm168.com/youhua/1148.html，武汉易企推网络公司，是一家专业的武汉网络推广，网络营销，品牌营销策划，品牌推广公司，提供一站式全网营销推广服务：小程序开发，网站建设，SEO百度排名，SEM竞价托管，品牌营销推广、360搜狗百度竞价开户、百度地图标注、百科词条创建修改、新媒体引流加粉、公司负面公关处理等；另外，转载本文请保留本文地址，谢谢！