【前端開發】提升站點載入速度

版權聲明：轉載請註明出處 https://blog.csdn.net/a503921892/article/details/37355771

尊重原創：但是出處不明......

http://www.xahl.net.cn 或者 http://www.xahl.net.cn/ ，有人會問，有差異嗎？我明白的告訴你們。有！
server假設接收到的URL是沒有帶「/」的URL，它會本身主動又一次定向到帶有「/」，儘管最後都打開了阿里巴巴中文站的首頁，但是前者比後者多走了一步，重定向，顯然多多少少浪費了必定的時間。因此之後咱們加URL連接的時候，別忘了把最後的「/」給加上去。
　　12. Remove duplicate scripts 去除反覆的腳本
　　這個事實上沒有什麼好說的。你們都應該毫無條件的去遵照，但是越是明顯，越是簡單的事，咱們每每會作很差。固然。很是多理由的，項目時間太緊張了等等。致使代碼很是亂。很是多反覆的地方。
事實上誰都知道重負很差，只是還好，咱們的頁面反覆的腳本代碼很少（至少一個頁面裏面，呵呵）。
只是。我到是但願，咱們不只要作到一個頁面腳本不反覆，而且要作到N個頁面，腳本要重用。

　　13. Configure ETags 這個好像是server端配置的問題，我不太懂，也就不亂說了。怕把你們給誤導了。
　　總共13個。但是看了YAHOO的官方說明。好像另外一個AJAX CACHE（AJAX 緩存）。我卻是認爲這個很是重要。隨着咱們AJAX應用的普遍，AJAX 緩存這個概念必定要時刻在咱們腦子中。AJAX是個好東西，但是反覆的數據，無休止的向後臺申請，絕對是個錯誤（不只是速度上仍是對server壓力上來講），因此咱們就要對咱們已經申請到的數據進行緩存。當第2次用到的時候，就直接從緩存中取。不要在去訪問咱們寶貴的server資源了。事實上這個思想不只僅適合AJAX。在所有有數據複用的應用中都應該考慮到。
　　YSLOW就分析到這裏完成了。也許有些地方分析的不是很是正確，也許有人分析的比我更早，更好。但是這些的確是我從工做中去積累，發現的。並非常多都實際應用到工做中去了，順便說下，嘿嘿。LIST頁面進行優化後。在0.92版本號的YSLOW評分將達到76分，甚至80分，至關於0.8版本號的90分以上。只是評分畢竟是評分，關鍵仍是速度。
YSlow是yahoo美國開發的一個頁面評分插件。很是的棒，從中咱們可以看出咱們頁面上的很是多不足，而且可以知道咱們改怎麼卻改進和優化。 
　　細緻研究了下YSlow跌評分規則主要有12條：
　　1. Make fewer HTTP requests 儘量少的http請求。。
咱們有141個請求（當中15個JS請求。3個CSS請求，47個CSS background images請求），多的可怕。
思考了下，爲何把這個三種請求過多列爲對頁面載入的重要不利因素呢。而過多的IMG請求並無列爲不利因素呢？ 　　發現原來這些請求都是可以避免的。
 　　15個JS和3個CSS全然可以經過特殊的辦法進行合併（這個技術部已經幫咱們攻克了，實在是太感謝了，嘿嘿。）。這樣合併之後，普通狀況下頁面上僅僅會出現一個JS和一個CSS（對JS的封裝得有必定的要求）。 　　但是47個CSS background images請求改怎麼解決呢？爲何頁面上的純IMG請求時合理的。而CSS background images請求過多就是不利因素了呢。這個我想了很是久。總算明白，原來是這種： 　　通常頁面上的ICON。欄目背景啊，圖片button啊。咱們都會用圖片CSS背景來實現，而通常這個圖片CSS背景用到的圖片都是比較小的，因此全然可以把這些圖片合併成一個相對照較大的圖片，這樣頁面上僅僅會出現一個CSS background images請求，最多也就2-3個。
後來細緻看了下雅虎美國的頁面，他們的確也是這樣作的，儘管這樣作需要花必定的時間來有規則的合併這些ICON。欄目背景，圖片button，以方便CSS調用，但是這樣作絕對是合算的，而且是有必要的，YSlow也是極力推薦的。 　　2. Use a CDN這項咱們的評分是F級，最低。說實在的，我剛開始什麼是CDN都不知道。後來查了GOODLE才知道。CDN的全稱是Content Delivery Network。即內容分發網絡。其目的是經過在現有的Internet中添加一層新的網絡架構。將站點的內容公佈到最接近用戶的網絡」邊緣」，使用戶可以就近取得所需的內容，解決Internet網絡擁擠的情況，提升用戶訪問站點的響應速度。從技術上全面解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由所形成的用戶訪問站點響應速度慢的問題。
 　　看來上述的解釋後，基本上明白了CDN是怎麼回事，後來諮詢了下中文站點SA。得知咱們站點眼下的確尚未作CDN的優化，但是聽說咱們有更加先進的技術來解決類似的問題（詳細什麼技術那就保密了）。但是畢竟CDN也是個至關不錯的技術，因此在咱們先進技術的基礎上在作CDN優化，確定比方今更好，嘿嘿。
聽說SA明年會作幾個點的CND。 　　3. Add an Expires header設置過時的HTTP Header.設置Expires Header可以將腳本。 樣式表， 圖片， Flash等緩存在瀏覽器的Cache中。 　　事實上咱們站點也作了這個優化，至少圖片在這個上作過優化，但是沒有作全然。咱們的CSS和JS都尚未作過優化，卻是外部引入的一個廣告JS作了，呵呵。事實上設置過時的HTTP Header 更應該作在腳本。 樣式表， Flash上。只是聽說這個SA也是沒有作的。但是有必定的風險，因爲JS和CSS是有必定的邏輯，假設server端和client都存在緩存的話。萬一出了什麼問題，對咱們之後查找問題的所在和添加難度，只是我想二者中是可以權衡和並存的。 　　4. Gzip components 對咱們的頁面內容進行Gzip格式的壓縮，Gzip格式是一種很是廣泛的壓縮技術。差點兒所有的瀏覽器都有解壓Gzip格式的能力。而且它可以壓縮的比例很是大，通常壓縮率爲85%。就是說server端100K的頁面可以壓縮到25K左右的Gzip格式的數據發給client，client收到Gzip格式的數據後本身主動解壓縮後顯示頁面。 　　5. Put CSS at the top 把CSS外部連接放到頁面的頂部。 　　事實上這個原則咱們通常都遵照的，假設把CSS外部連接做爲邏輯的一部分出現在頁面頭部下面，我我的認爲這個自己就是個錯誤。還好。咱們的頁面基本上都作到了，但是有些頁面比方LIST頁面。仍是出現了和邏輯掛鉤的CSS連接，緣由是爲了解決一些原本就不合理的產品邏輯。
因此，咱們WEB前端project師有義務杜絕這些不合理的產品邏輯破壞咱們的頁面結果及頁面載入速度，不能爲了實現而實現。 　　6. Put JS at the bottom 把Javascript腳本儘可能放到頁面底部載入。 　　一開始爲覺得Javascript腳本儘可能放到頁面底部載入，是指所有的JS腳本都要放究竟部，後來才發現，並不全然是這樣，這裏所指的腳本是指那些在載入過程當中要執行的腳本，因此通常的處理辦法仍是頁面頭部引入JS連接。頁面底部執行JS腳本程序。爲何要這麼作呢？呵呵，事實上很是easy，爲了實現最大的下載並行，頁面載入初期作的事，最好僅僅有下載，HTML的下載。CSS的下載，JS的下載，等完成下載後再去實現頁面渲染。JS腳本執行。這個方面咱們還需要努力，很是多頁面咱們在載入過程當中執行了一部分腳本，也許是爲了實現一些功能，沒有辦法，只是也許有更好的辦法來替代呢。。。 　　7. Avoid CSS expressions 避免CSS表達式 　　事實上在CSS中執行表達式和頁面載入中執行大量的JS腳本幾乎相同，也許還更慢。而且還不兼容。儘管可以使咱們在頁面邏輯簡單很多，但是咱們全然可以拋棄之。這個點，咱們的頁面基本上都作到了。只是說實話，CSS表達式，嘿嘿，我曾經還不知道有這麼回事。羞愧。
哈哈。 　　9. Reduce DNS lookups 儘量少的DNS查找。 　　這項咱們作的不是很是好。D級。有9個域名，通常不要超過4個。只是這個主要是server架構上的問題，咱們也無能爲力，現在單單首頁的廣告域名就有好幾個。好耶的廣告域名。雅虎的廣告域名，淘寶店廣告域名，打點的域名。假設去掉這些。咱們事實上仍是夠用的，一個主域名，一個圖片的。一個STYLE的，最多加上IFREAM的恰好4個。
 　　10. Minify JS 對Javascript代碼進行壓縮。
 　　這點我很是早曾經就對此關注了。也找到了一個不錯的壓縮工具。yuicompressor，雅虎美國開發的JAVA壓縮包yuicompressor.jar。
壓縮的至關完美，不只把代碼間的空格換行給去除掉了，而且對變量名，北部方法名都進行的簡化，無心中實現了混淆腳本的做用。現在咱們僅僅作到了JS合併，並無對齊進行壓縮。假設我用yuicompressor手工的去壓縮，儘管實現了JS壓縮，但是給咱們本身的維護量添加了一倍。因爲咱們需要維護2套JS腳本，一套是壓縮前的（調試用的），一套是壓縮後（公佈到網上的），而且要保證2套代碼一致。因此最完美的作法是在公佈的時候實現JS腳本合併，並對其用yuicompressor進行壓縮。而後公佈到晚上，把關鍵點移到公佈的時候，這樣咱們僅僅需要關心一套JS腳本（公佈前的版本號）。而且我認爲這個方法全然是行動通的。
 　　11. Avoid redirects 避免重定向（跳轉） 　　怎麼理解這點呢？ 　　通常咱們頁面的連接都寫成： http://www.xahl.net.cn 或者 http://www.xahl.net.cn/ ，有人會問。有差異嗎？我明白的告訴你們，有。server假設接收到的URL是沒有帶「/」的URL。它會本身主動又一次定向到帶有「/」，儘管最後都打開了阿里巴巴中文站的首頁。但是前者比後者多走了一步，重定向。顯然多多少少浪費了必定的時間。
因此之後咱們加URL連接的時候，別忘了把最後的「/」給加上去。 　　12. Remove duplicate scripts 去除反覆的腳本 　　這個事實上沒有什麼好說的。你們都應該毫無條件的去遵照，但是越是明顯。越是簡單的事，咱們每每會作很差，固然，很是多理由的，項目時間太緊張了等等，致使代碼很是亂。很是多反覆的地方。事實上誰都知道重負很差，只是還好，咱們的頁面反覆的腳本代碼很少（至少一個頁面裏面，呵呵）。只是，我到是但願。咱們不只要作到一個頁面腳本不反覆，而且要作到N個頁面。腳本要重用。
 　　13. Configure ETags 這個好像是server端配置的問題。我不太懂，也就不亂說了。怕把你們給誤導了。 　　總共13個，但是看了YAHOO的官方說明，好像另外一個AJAX CACHE（AJAX 緩存）。
我卻是認爲這個很是重要。隨着咱們AJAX應用的普遍，AJAX 緩存這個概念必定要時刻在咱們腦子中。AJAX是個好東西，但是反覆的數據，無休止的向後臺申請，絕對是個錯誤（不只是速度上仍是對server壓力上來講），因此咱們就要對咱們已經申請到的數據進行緩存，當第2次用到的時候，就直接從緩存中取，不要在去訪問咱們寶貴的server資源了。事實上這個思想不只僅適合AJAX，在所有有數據複用的應用中都應該考慮到。
 　　YSLOW就分析到這裏完成了，也許有些地方分析的不是很是正確，也許有人分析的比我更早，更好，但是這些的確是我從工做中去積累。發現的，並非常多都實際應用到工做中去了，順便說下，嘿嘿，LIST頁面進行優化後，在0.92版本號的YSLOW評分將達到76分，甚至80分。至關於0.8版本號的90分以上。只是評分畢竟是評分。關鍵仍是速度。