作者:Fenng|可以轉載, 轉載時務必以超連結形式標明文章原始出處及作者資訊及版權聲明網址:http://www.dbanotes.net/web/flickr_web_tech.html
Cal Henderson 是大名鼎鼎的Flickr網站的開發者之一．在一篇名為Serving JavaScript Fast的文章中，他介紹了用於Flickr 網站應用優化的技巧，讀罷感覺獲益良多． "嚼一下別人的饃"，概括一下該文的主要內容．
Flickr是Web 2.0 的代表網站。面對的網路問題除了一般Web 網站都會有的內容優化之外, 還有必須要靈活處理JavaScript 與CSS的頻繁變更後部署分發帶來的複雜性。
設定檔案大小的策略首先面臨的一個問題是把所有的JavaScript 與CSS放到一個文件中好呢，還是分割成多個文件? 從減少網絡請求的角度上考慮, 前者更好，後者差。但從並行的角度考慮,IE與Firefox 預設情況下都只能同時從一個網域請求兩個資源. 這會在很多情況下給用戶帶來不良的使用體驗--必須所有的文件都下載完畢才可以看到像樣的頁面. Flickr 採用了折衷的辦法--在保持文件數量盡可能少的情況下，把JavaScript 與CSS分成多個子文件. 這在開發上帶來了複雜性，但是對性能的收益是巨大的。
壓縮的最佳化問題毫無疑問，對網站內容進行壓縮是一個比較常用的Web 優化手段．但是不一定都能達到理想的效果．原因在於mod-gzip模組不但消耗伺服器端CPU資源，也消耗客戶端CPU資源. 而且, mod_gzip 壓縮檔案後創建的臨時檔案是放到磁碟上的，這也會為磁碟IO帶來嚴重的問題. Flickr採用的是Httpd 2.x 以後支援的mod_deflate模組．壓縮操作都在記憶體中進行． mod_deflate 在Httpd 1.x 是不可用的, 不過可以透過創建RAM盤的方式來間接提高性能．
當然, mod_gzip 到也不是一無是處, 對於預壓縮的文件, 還是有好處的. 而且, 採用壓縮的時候,也要注意策略. 圖片文件壓縮就沒什麼必要了(Flickr 上圖像多, 而且壓縮得不到什麼好處). Flickr 只對JavaScript 和CSS進行壓縮. mod_gzip 新一點的版本能夠自動通過配置mod_gzip_update_static 選項自動處理預壓縮的文件. Cal 也指出這個特性在一些舊版本的瀏覽器上會出問題.
壓縮的另一個主要手段是內容的壓縮. 針對JavaScript 可以進行通過減少註釋、合併空格、使用緊湊的語法等小技巧(Google 的所有腳本都非常難讀，而且非常緊湊，思想類似).當然，經過這樣處理的JavaScript 可能帶了很多括號不容易解析，Flickr使用了Dojo Compressor來建立解析樹。 Dojo Compressor 開銷很低，而且對於最終用戶是透明的. JavaScript 的處理方法介紹過，CSS 處理則相對簡單.通過簡單的正則表達式替換(比如把多個空格替換為一個空格符), 最高可以獲得50% 的壓縮比。
Caching 的最佳化Flickr的開發者充分利用了Http 1.1 規範定義的Etag 與Last-Modified 機制來提高Caching 的效率. 值得注意的是，Cal 介紹了一個在負載平衡條件下的e-Tag 小技巧. 即可以設定Apache 透過檔案調整時間與檔案大小獲得E-Tag ,而預設, Apache 是透過檔案節點取得e-Tag 的。當然，這也不是很完美，因為會影響if-modified-since 。
靈活運用mod_rewrite據說Flickr網站應用程式是進行每日建置的(Daily Build)。 如果沒有一個靈活的機制恐怕這是不可想的。而且，在Flickr 這樣的網站, 內容的修改同步的處理都是很讓人頭疼的難題. 他們的利器是mod_rewrite的靈活運用。透過配置URL重寫規則，很容易切換到不同的環境。聽起來很簡單, 但是沒有一定的Web 技術功力談何容易做到?!
透過這幾個主要方法的運用，我們看到瞭如夢幻一般高性能的Flickr.
BTW: 因為在Flickr 在國內沒有伺服器, 大陸用戶訪問的速度就別提了:(
--End.
這篇【Flickr 的開發者的Web 應用優化技巧】來自dbanotes.net