武漢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.piojosa.com/youhua/1148.html，武漢易企推網絡公司，是一家專業的武漢網絡推廣，網絡營銷，品牌營銷策劃，品牌推廣公司，提供一站式全網營銷推廣服務：小程序開發，網站建設，SEO百度排名，SEM競價托管，品牌營銷推廣、360搜狗百度競價開戶、百度地圖標注、百科詞條創建修改、新媒體引流加粉、公司負面公關處理等；另外，轉載本文請保留本文地址，謝謝！