网站拜访速度优化历程

fny5jt9

带着问题继续：

那些方面容易引起网站打开慢页面打开时间多长属于正常此刻有打开速度为1.44秒还有无优化的空间全站https怎样实现优化网站的专业技巧有那些

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

从60秒到10秒

网站拜访速度慢有非常多种状况：

a> 拜访者自己硬件设备（硬盘、CPU、网口、运营商带宽）资源不足b> 服务器硬件设备（硬盘、CPU、网口、运营商带宽）资源不足c> 照片未做优化太大、太多引起资源加载太多而慢d> 应用程序代码质量差引起性能消耗大、响应速度慢e> 页面设计不恰当，引起资源整合太多（照片、css、js、前后端请求等）f> 其它DNS、安全入侵等问题

一般处理掉a b c能够帮咱们处理80%的问题只需要花费20%的精力，d e f能够帮咱们处理掉剩下的20%问题但需要花费80%的精力。

阿里云上查看了服务器性能消耗，虽然硬件1Core2GB内存配置不高，但常年负载0.01。

接下来的思路亦很简单，打开浏览器研发者工具（建设chrome）排查页面元素

imagemagick convert

a和b 的硬件设备问题不做咱们这次探讨内容。

c 照片未做优化，太多引起资源加载太而慢，咱们打开chrome的研发者工具排查。

有无发掘：

页面只展示了不到1/4的内容，但打开耗时已然9.99s。首页达592KB有非常多大于50KB的照片处理过程忘了保存现场，其实还有非常多大于150KB照片

对号入座，照片资源没做优化

无UI照片非常多，不可能一张张优化页面设计用的开源主题，无可设计空间

看起来能优化的仅有照片体积了。举荐linux下照片优化工具 imagemagick convert

功能测试经过后，简单粗暴处理了下网站照片问题。

# cat convert.sh #!/bin/bash ## >50k find /png/upload/path/ -regex .*\(jpg\|JPG\|png\|PNG\|jpeg\) -size +50k -execconvert -resize 350x350 -quality 65 {} {} \;## >100k find /png/upload/path/ -regex .*\(jpg\|JPG\|png\|PNG\|jpeg\) -size +100k -execconvert -resize 300x300 -quality 60 {} {} \; find /png/upload/path/ -regex.*\(jpg\|JPG\|png\|PNG\|jpeg\) -size +100k -exec convert -resize 80%x80% -quality 60 {} {} \; ## >200k find /png/upload/path/ -regex .*\(jpg\|JPG\|png\|PNG\|jpeg\) -size +200k -exec convert -resize 250x250 -quality 60 {} {} \; find /png/upload/path/ -regex .*\(jpg\|JPG\|png\|PNG\|jpeg\)-size +200k -exec convert -resize 70%x70% -quality 60 {} {} \;加入按时任务crontab -l 10 2 * * * bash /root/convert.sh

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

从10秒到1.44秒

这个时候起始求助网络了。

谷歌关键字搜索 “wordpress 速度”，看到知乎上有个技术帖（哈哈，知乎竟然有技术帖了，文艺少年都老了吗？）给出了以下几个意见：

a> 关闭Avatarb> 去掉google字体c> 关闭Emojid> 运用360云解析，自动加速e> 运用七牛免费加速f> 开启 WP Super Cache插件g> 开启lazyer loader瀑布流加载

咱们一项一项来尝试

a b c项早在建站就已然处理了d 经测试无效（这儿的无效指的是药不对症）e 好东西，但手持身份证的周期我放弃了，太麻烦了，况且还在机构不方便f 开启 测试无效。由于1> nginx 开启gzip 2> php开启opcache 3> 运用的主题有瀑布流布局异步加载的功能 因此再开启这个功能无效果g开启无效 同4过程的原由同样

细究服务器性能！！

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

开启php-fpm的慢日志开启myql的慢日志

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

求助前端朋友

这儿其实最大的疑问还是为何首页会这么大，而我看下来什么亦无，就一个框架结构而已。最后不得已求助前端朋友，经过排查后发掘。

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

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

首页这么大，出口又这么小，加载时间当然长了，时间当然长了。。。那样首页多大合适呢？

我的首页

淘宝的首页

体积差了20倍有余，最终找到问题所在了！~

那样首页到底地区大哪里了？

经过前端朋友的帮助排查发掘，页面大概有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 正好能处理这个问题。效益虽小，但却缺能积少成多。

其它更加多base64内容参考：http://www.cnblogs.com/coco1s/p/4375774.html

经过这次的细节优化后，再打开时候快感还是不错。

重点的瓶颈依然在照片，不外从我这个维度照片已然不可再做优化，这个时候UI的价值就凸显了。