關於yahoo軍規的詳細介紹
- 黄舟原創
- 2017-07-24 13:52:031124瀏覽
yahoo軍規一共分7類共35條：
1
分類 : 內容
80%的終端用戶回應時間都花在了前端上，其中大部分時間都在下載頁面上的各種組件：圖片，樣式表，腳本，Flash等等。減少組件數必然能夠減少頁面提交的
HTTP
請求數。這是讓頁面更快的關鍵。 減少頁面元件數的一種方式是簡化頁面設計。但有沒有一種方法可以在建立複雜的頁面同時加快回應時間呢？嗯，確實有魚和熊掌兼得的辦法。 合併文件是透過把所有腳本放在一個檔案中的方式來減少請求數的，當然，也可以合併所有的
CSS。如果各個頁面的腳本和樣式不一樣的話，合併文件就是一項比較麻煩的工作了，但把這個作為網站發布過程的一部分確實可以提高響應時間。
CSS Sprites是減少圖片請求數量的首選方式。把背景圖片都整合到一張圖片中，然後用CSS的
background-image
和 background-position 屬性來定位要顯示的部分。 圖像映射 可以把多張圖片合併成單張圖片，總大小是一樣的，但減少了請求數並加速了頁面加載。圖片地圖只有在圖像在頁面中連續的時候才有用，例如導航條。為image map設定座標的過程既無聊又容易出錯，用
image map
來做導航也不容易，所以不建議用這種方式。 行內圖片（Base64編碼）用 data: URL
模式 來嵌入頁面。這樣會增加
HTML檔案的大小，把行內圖片放在（快取的）樣式表中是個好辦法，而且成功避免了頁面變成「重」。但目前主流瀏覽器並不能很好地支援行內圖片。 減少頁面的HTTP請求數是個起點，這是提升網站首次存取速度的重要指導原則。就像Tenni Theurer
的部落格
Browser Cache Usage – Exposed! 站點時，快取都是空的。所以，加快頁面首次存取速度對提高使用者體驗是極為重要的。 2.使用CDN（Content Delivery Network）
用戶與伺服器的實體距離對回應時間也有影響。把內容部署在多個地理位置分散的伺服器上能讓使用者更快載入頁面。但具體怎麼做呢？
實現內容在地理位置上分散的第一步是：不要嘗試去重新設計你的web應用程式來適應分散式結構。這取決於應用程序，改變結構可能包括一些令人望而生畏的任務，例如同步會話狀態和跨伺服器複製資料庫事務（翻譯可能不準確）。縮短使用者和內容之間距離的提議可能被推遲，或者根本不可能通過，就是因為這個難題。 記住終端用戶80%到90%的響應時間都花在下載頁面組件上了：圖片，樣式，腳本，這就像黃金法則。最好先分散靜態內容，而不是一開始就重新設計應用程式結構。這不僅能夠大幅減少反應時間，也更容易表現出CDN的功勞。 CDN web伺服器，用來給使用者更有效率地傳送內容。典型地，選擇用來發送內容的伺服器是基於網路距離的衡量標準的。例如：選跳數（hop）最少的或回應時間最快的伺服器。 CDN CDN服務提供者是比較划算的，例如CDN服務提供者是比較划算的，例如CDN服務提供者是比較划算的，例如 level3 。對剛起步的公司和個人網站來說，CDN服務的成本是很高的，但如果你的用戶群卻越來越大，越來越全球化，那麼用CDN來換取更快的回應時間還是很必要的。在Yahoo!，把靜態內容從應用程式的web伺服器搬到CDN(包括上面提到的3rd part CDN )能夠提升終端用戶20%甚至更多的回應時間。換到CDN是一個相當簡單的程式碼變更，但這將急劇提升站點的反應速度。 3.添上Expires或 Cache-Control HTTP 頭 這條規則有兩個面向： 對於靜態組件：透過設定一個遙遠的將來時間作為 Expires 來實現永不失效 Cache多餘動態組件：用合適的 Cache-Control HTTP 網頁設計越來越豐富，這意味著頁面裡有更多的腳本，圖片和Flash。網站的新訪客可能還是必須提交幾個HTTP請求，但透過使用有效期能讓元件變得可緩存，這避免了在接下來的瀏覽過程中不必要的HTTP請求。有效期限HTTP頭通常被用在圖片上，但它們應該用在 所有 組件上，包括腳本、樣式和Flash組件。 瀏覽器（和代理）用快取來減少HTTP請求的數目和大小，讓頁面能夠更快載入。 web伺服器透過有效期限HTTP回應頭來告訴客戶端，頁面的各個元件應該被快取多久。用一個遙遠的將來時間做有效期，告訴瀏覽器這個回應在2010年4月15日前不會改變。 Expires: Thu, 15 Apr 2010 20:00:00 GMT 如果你用的是Apache指令，用相片如果你用的是Apache指令，用相片的有效日期。下面的範例設定了從請求時間起10年的有效期限： ExpiresDefault "access plus 10 years" 記住，如果你未來做一個遙遠的時間組件變更後及時修改組件的檔案名稱。在Yahoo!，我們經常把這一步驟當作建置過程的一部分：把版本號碼內嵌在元件的檔案名稱裡，例如：yahoo_2.0.6.js 的未來時間用一個遙遠的未來時間做有效期限HTTP頭，只有在使用者已經造訪過網站之後才會影響頁面視圖。如果是新訪客或瀏覽器的快取被清空時，對HTTP請求的數量並沒有影響。因此這種效能提升取決於已快取各個元件的使用者存取網站的頻率。我們 在Yahoo!測量了這個數據 ，發現已緩存各個組件的頁面訪問量（PV）佔75%到）佔75%到透過把一個遙遠的未來時間當作有效期限HTTP頭，增加了被瀏覽器快取的元件數量，在後續頁面存取量中不需要用Internet 4.Gzip元件 分類: 前端想移除網路 響應的大小來縮短反應時間。 從HTTP/1.1 客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。 Accept-Encoding: gzip, deflate 如果web伺服器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮回應。 web伺服器透過Content-Encoding相應頭來通知客戶端。 Content-Encoding: gzip Gzip是目前最常見的高效壓縮方法，由GNU唯一一個你可能會看到的其它壓縮格式是deflate，但它效率不高而且並不常見。 Gzipping 左右，目前大約90%的通過瀏覽器左右，目前大約90%的通過瀏覽器的網路傳輸瀏覽器的網路都支援。如果是Apache伺服器，設定gzip的模組取決於版本：Apache 1.3用mod_deflate 模組。 瀏覽器和代理的某些因素可能會引起瀏覽器所期望的和它收到的壓縮內容不符。幸運的是，隨著老舊瀏覽器的淘汰，這些極少遇到的情況正在逐漸減少，而且Apache模組可以透過自動添加合適的Vary響應頭來幫你搞定。 伺服器會根據檔案類型來決定要不要用gzip壓縮，但非常有限。大多數網站都用gzip壓縮 XML和JSON，而圖片和PDF不用壓縮，因為它們已經被浪費過，不僅再用PDF不用壓縮，因為它們已經被浪費過，不僅再用 CPU還可能會越壓越大。 盡可能地用gzip壓縮能夠給頁面減肥，這也是提升用戶體驗最簡單的方法。 5.把樣式表放在頂部 分類:文件的HEAD 裡能讓頁面逐步渲染。 關注效能的前端工程師想讓頁面逐步渲染。也就是說，我們想讓瀏覽器盡快顯示已有內容，這在頁面上有一大堆內容或用戶網速很慢時顯得尤為重要。給使用者顯示回饋（例如進度指標）的重要性已經被廣泛研究過，並且被 記錄 下來了。在我們的例子中，HTML頁面就是進度指標！當瀏覽器逐漸加載頁面頭部，導航條，頂部logo等等內容的時候，這些都被正在等待頁面加載的用戶當作反饋，能夠提高整體用戶體驗。 在許多瀏覽器（包括IE）中，把樣式表放在HTML渲染底部都會阻止頁面逐漸渲染。這些瀏覽器阻塞渲染過程，以避免因為樣式變動而重繪頁面元素，使用者這時就只能盯著空白頁面。 HTML官方文件清楚地描述了樣式表應該放在頁面的HEAD裡面：」Unlike A, [LINKough on only apple the HE appear any number of times.」（不像a標籤，link標籤可能只出現在HEAD標籤可能只出現在HEAD部分，雖然它能多次出現）。空白畫面或沒有樣式的falsh內容都是不可取的。理想方案就是遵循HTML官方文檔，把樣式表放在HTML文檔的 HEAD 部分。 6.
每個主機名下方並行下載的元件數不要超過兩個，如果圖片來自多個主機名，並行下載的數量就可以超過兩個。如果腳本正在下載，瀏覽器就不會開始任何其它下載任務，即使是在不同主機名稱下的。 有時候，並不容易把腳本移到底部。舉個例子，如果腳本是用 插入到頁面內容中的，就沒辦法再往下移了。也可能有作用域問題，在多數情況下，這些問題都是可以解決的。 一個常見的建議是用延遲（ ）腳本，有DEFER 屬性的腳本意味著您不能含有提示。不幸的是，Firefox不支援 DEFER 屬性。在IE中，腳本可能被推遲，但不盡如人意。如果腳本可以推遲，我們就可以把它放到頁面底部，頁面就可以更快地載入。 7.避免使用 : 用CSS表達式動態設定CSS屬性，是一種強大又危險的方式。從IE5開始支持，但 從IE8起就不推薦使用了 。例如，可以用CSS表達式把背景顏色設定成按小時交替的： 上面的程式碼中， expression CSS屬性會被設定成表達式的計算結果。 expression 方法會被其它瀏覽器忽略，所以只有想辦法實現跨瀏覽器的與IE一致的用戶體驗才有用。 CSS 10000多次重新計算。 CSS CSS表達式。如果必須使用CSS表達式，要記得它們可能會被重複計算上千次，從而影響整個頁面的效能。 把 JavaScript和CSS 很多效能原則都是關於如何管理外部組件的，然而，在這些顧慮出現之前你應該問一個更基礎的問題：應該把JavaScript和 CSS 放到外部文件中還是直接寫在頁面裡？ 實際上，使用外部檔案可以讓頁面更快，因為JavaScript和CSS檔案會被緩存在瀏覽器中。 HTML 文檔中的行內 JavaScript和CSS在每次請求該HTML文檔的時候都會重新下載。這樣做減少了所需的HTTP請求數，但增加了HTML文件的大小。另一方面，如果JavaScript和CSS在外部文件中，並且已經被瀏覽器緩存起來了，那麼我們就成功地把HTML文檔變小了，而且還沒有增加HTTP請求數。 關鍵因素是，外部檔案被快取的頻率和頁面被要求數量之間的關係。儘管這個因素很難量化，但我們還是可以用各種不同的指標來衡量。如果使用者的每個會話中都有多次頁面訪問，那麼相同的腳本和樣式表就可以被多個頁面重複使用，而快取的外部檔案就會帶來巨大的好處。 很多站點在測量中都處於中等水平，對這些站點來說，一般最好的解決方案就是把JavaScript和CSS部署為外部文件。唯一的例外是主頁上行內方式優先，例如 Yahoo!的首頁 和 My Yahoo! 。在每個會話中訪問量比較少的主頁會發現行內JavaScript和CSS能讓終端用戶的回應時間更快。 對典型的網站來說，首頁是眾多訪問量的開始，有很多技術可以對減少HTTP請求起到槓桿作用，就像用外部文件緩存的好處一樣。這樣的一種技術就是在首頁用行內JavaScript和CSS，但在頁面載入完成之後動態加載外部文件，這樣後續的頁面所需的外部文件就已經被放到瀏覽器的緩存裡了。 9.減少DNS查找 建立了主機名稱和IP位址間的映射，就像電話簿上人名和號碼的映射一樣。當你在瀏覽器輸入www.yahoo.com 的時候，瀏覽器就會聯絡 DNS解析器回傳伺服器的IP位址。 DNS是有成本的，它需要20到120毫秒去查找給定主機名的IP地址。在DNS查找完成之前，瀏覽器無法從主機名稱下載任何東西。 DNS查找緩存起來更有效率，由用戶的ISP（網路服務供應商）或本地網路存在一個特殊的快取伺服器上，但還可以快取在個人使用者的電腦上。 DNS 資訊被保存在作業系統的DNS cache(微軟Windows上的」DNS””大多數瀏覽器有獨立於作業系統的自己的cache。只要瀏覽器在自己的cache裡還保留著這條記錄，它就不會向作業系統查詢DNS。 IE預設快取DNS查找30分鐘，寫在 DnsCacheTimeout 註冊表設定中。 Firefox快取1分鐘，可以用 network.dnsCacheExpiration 設定項設定。 (Fasterfox把快取時間改成了1小時P.S. 如果客戶端的DNS cache是空的（包括瀏覽器的和操作系統的），DNS查找數等於頁面上不同的主機名數，包括頁面URL ，圖片，腳本文件，樣式表， Flash 物件等等元件中的主機名，減少不同的主機名稱就可以減少DNS查找。 減少不同主機名稱的數量同時也減少了頁面能夠並行下載的組件數量，避免DNS查找削減了響應時間，而減少並行下載數量卻增加了響應時間。我的原則是把組件分散在2到4 個主機名下，這是同時減少 DNS查找和允許高並發下載的折中方案。 10.壓縮JavaScript和CSS 壓縮具體來說就是從程式碼中移除不必要的字符以減少大小，從而提升載入速度。程式碼最小化就是去掉所有註解和不必要的空白字元（空格，換行和tab）。在JavaScript中這樣做能夠提高回應效能，因為要下載的檔案變小了。兩個最常用的JavaScript程式碼壓縮工具是 JSMin 和 YUI Compressor ，SS 混淆是一種可選的源碼最佳化措施，比壓縮更複雜，所以混淆過程也更容易產生bug。在美國前十名的網站調查中，壓縮可以縮小21%，而混淆能縮小25%。雖然混淆的縮小程度更高，但比壓縮風險更大。 除了壓縮外部腳本和樣式，行內的 <script> <span style="font-family: 宋体">和 </script> 11.避免重新導向 分類 302 狀態碼的HTTP頭： HTTP/1.1 301 Moved Type: text/html瀏覽器會自動跳到 Location 域所指明的 頭，例如 Expires 和 Cache-Control 也表示重定向。除此之外還有別的跳轉方式：refresh元標籤和JavaScript，但如果你必須得做重定向，最好用標準的3xxHTTP碼，主要是狀態碼為了讓返回按鈕能正常使用。 牢記重定向會拖慢使用者體驗，在使用者和HTML文件之間插入重定向會延遲頁面上的所有東西，頁面無法渲染，元件也無法開始下載，直到HTML 文件被送達瀏覽器。 web開發人員一般都意識不到這一點，就是URL尾部缺少一個斜線的時候。例如，跳到 的301響應（注意添在尾部的斜線）。在Apache中可以用 Alias ， mod_rewrite 或 DirectorySlash 或是 DirectorySlash 。 重定向最常見的用途是把舊站點連接到新的站點，還可以連接同一站點的不同部分，針對用戶的不同情況（瀏覽器類型，用戶帳號類型等等）做一些處理。用重定向來連接兩個網站是最簡單的，只需要少量的額外程式碼。雖然在這些時候使用重定向減少了開發人員的開發複雜度，但降低了使用者體驗。一個替代方案是用 Alias 和 mod_rewrite ，前提是兩個程式碼路徑都在相同的伺服器上。如果是因為網域變更而使用了重新導向，就可以建立一個CNAME（建立一個指向另一個網域的DNS記錄作為別名）結合Alias 。 12. 分類 在對美國前10 站點的評審中，發現只有2個站點含有重複腳本。兩個主要原因增加了在單一頁面中出現重複腳本的幾率：團隊大小和腳本數量。在這種情況下，重複腳本會建立不必要的HTTP請求，執行無用的JavaScript程式碼，而影響頁面效能。 IE會產生不必要的 Firefox不會。在IE中，如果一個不可快取的外部腳本被頁面引入了兩次，它會在頁面載入時產生兩個HTTP請求。即使腳本是可快取的，在使用者重新載入頁面時也會產生額外的HTTP請求。 除了產生沒有意義的HTTP 和IE中都會執行冗餘的JavaScript程式碼。 避免不小心把相同腳本引入兩次的一種方法就是在模版系統中實現腳本管理模組。典型的腳本引入方法是在HTML 標籤： 13.設定 ETags 類 實體標籤（ETags），是伺服器和瀏覽器用來決定瀏覽器快取中元件與來源伺服器中的元件是否相符的一種機制（「實體」也就是元件：圖片，腳本，樣式表等等）。新增ETags可以提供一種實體驗證機制，比最後修改日期更有彈性。一個ETag是一個字串，作為一個組件某一具體版本的唯一識別碼。唯一的格式限制是字串必須用引號括起來，來源伺服器用對應頭中的ETag 來指定元件的ETag： If-None- Match ETags配對成功，會回傳一個304狀態碼，這樣就減少了12195個位元組的回應體。 GET /i/yahoo.gif HTTP/1.1 Host:us.yimg.com Host:us.yimg.com If-None-Match : "10c24bc-4ab-457e1c1f" HTTP/1.1 304 Not Modified ETags web站點中又非常普遍。預設情況下，Apache和IIS會在ETag中嵌入數據，以大幅降低在多伺服器站點上有效性測試成功的幾率。 Apache 1.3和 ETag的格式是 中ETag的格式ino就算給定的檔案可能在多個伺服器的相同目錄下，而且檔案大小、存取權限、時間戳記等等全部相同，它的i節點（P.S. inode，P.S. inode，UNIXIXIX中的索引檔）在不同伺服器中也不一樣。 IIS5.0和6.0也都有類似的問題。 IIS中ETags的格式是 Filetimestamp:ChangeNumber ， ChangeNhangeNhangeNhange 。 一個站點在不同的IIS伺服器上的 ChangeNumber 是不可能相同的。 最終結果是Apache和IIS為完全相同的組件產生的ETags無法跨瀏覽器匹配，如果快的304響應設計的ETags。反而，他們將收到一個攜帶著組件所有資料的200正常回應。如果網站部署在單一伺服器上，就根本不存在這個問題。但如果網站部署在多個伺服器上，而且打算用Apache或IIS的預設ETags配置，使用者將看到緩慢的頁面，更負載，ETags配置，使用者將看到緩慢的頁面，負載更高，會消耗負載更高，還會消耗伺服器大的頻寬，而且代理也無法有效快取頁面內容。即使元件有「永久」 Expires HTTP頭，使用者點擊重新載入或重新整理的時候，還是會發出條件GET請求。 如果不想用ETags提供的靈活的驗證模型，最好把所有的Etag全都去掉，可以用基於戳記的時間的Etag全都去掉，可以用基於戳記的時間的Etag全都去掉，可以用基於戳紙的時間的 ，而且去掉ETag可以減少HTTP回應頭以及後續請求的大小。 Microsoft Support article 裡寫了怎麼移除ETags。在Apache中，可以簡單地透過在Apache 設定檔中加入如下程式碼來實現： 分類: 內容 Ajax的一個好處是可以給用戶提供即時回饋，因為它能夠從後台非同步請求資訊。然而，用了Ajax 就無法保證用戶在等待非同步 JavaScript和XML回應返回期間不會非常無聊。在許多應用程式中，使用者能夠一直等待取決於如何使用Ajax。例如，在基於web的電子郵件用戶端中，使用者為了尋找符合他們搜尋標準的郵件訊息，將會保持對Ajax請求回傳結果的關注。重要的是，要記得「非同步」並不意味著「即時」。 要提高效能，優化這些Ajax響應至關重要。最重要的提升 Ajax 效能的方法就是讓回應變得可緩存，就像在 添上Expires或Cache-Control HTTP頭 中討論的一樣。以下適用於Ajax的其它規則： Gzip組件 减少DNS查找 压缩JavaScript 避免重定向 配置ETags 我们一起看看例子，一个Web 2.0的电子邮件客户端用了Ajax来下载用户的通讯录，以便实现自动完成功能。如果用户从上一次使用之后再没有修改过她的通讯录，而且Ajax响应是可缓存的，有尚未过期的Expires或者Cache-Control HTTP头，那么之前的通讯录就可以从缓存中读出。必须通知浏览器，应该继续使用之前缓存的通讯录响应，还是去请求一个新的。可以通过给通讯录的Ajax URL里添加一个表明用户通讯录最后修改时间的时间戳来实现，例如 &t=1190241612 。如果通讯录从上一次下载之后再没有被修改过，时间戳不变，通讯录就将从浏览器缓存中直接读出，从而避免一次额外的HTTP往返消耗。如果用户已经修改了通讯录，时间戳也可以确保新的URL不会匹配缓存的响应，浏览器将请求新的通讯录条目。 即使Ajax响应是动态创建的，而且可能只适用于单用户，它们也可以被缓存，而这样会让你的Web 2.0应用更快。 15.尽早清空缓冲区 分类: 服务器 当用户请求一个页面时，服务器需要用大约200到500毫秒来组装HTML页面，在这期间，浏览器闲等着数据到达。PHP中有一个 flush() 函数，允许给浏览器发送一部分已经准备完毕的HTML响应，以便浏览器可以在后台准备剩余部分的同时开始获取组件，好处主要体现在很忙的后台或者很“轻”的前端页面上（P.S. 也就是说，响应时耗主要在后台方面时最能体现优势）。 比较理想的清空缓冲区的位置是HEAD后面，因为HTML的HEAD部分通常更容易生成，并且允许引入任何CSS和JavaScript文件，这样就可以让浏览器在后台还在处理的时候就开始并行获取组件。 例如： Yahoo!搜索 开创了这项技术，而且真实用户测试研究也证明了使用这种技术的诸多好处。 16.对Ajax用GET请求 分类: 服务器 Yahoo!郵箱 團隊發現使用 XMLHttpRequest 時，瀏覽器的POST請求是透過兩步驟的流程來實現的：先傳送所以最好用GET請求，它只需要發送一個TCP報文（除非cookie特別多）。 IE的URL長度最大值是2K，所以如果要發送的資料超過2K，所以如果要發送的資料超過2K就無法使用了。 POST請求的一個有趣的副作用是實際上沒有發送任何數據，就像 GET 請求一樣。如 HTTP說明文件 中所描述的，GET請求是用來檢索資訊的。所以它的語意只是用GET請求來請求數據，而不是用來發送需要儲存到伺服器的數據。 17. 分類 內容的頁面就開始見面 JavaScript是分隔 onload 事件之前和之後的一個理想選擇。例如，如果有 JavaScript 程式碼和支援拖放以及動畫的庫，這些都可以先等會兒，因為拖放元素是在頁面最初渲染之後的。其它可以延遲載入的部分包括隱藏內容（在某個互動動作之後才出現的內容）和折疊的圖片。 工具可幫助你減輕工作量： YUI Image Loader 可以延遲載入摺疊的圖片，還有YUI Get utility 主頁 就是一個例子，可以打開Firebug的網路面板仔細看看。 最好讓效能目標符合其它web開發最佳實踐，例如「漸進增強」。如果客戶端支援JavaScript，可以提高使用者體驗，但必須確保頁面在不支援JavaScript時也能正常運作。所以，在確定頁面運作正常之後，可以用一些延遲載入腳本來增強它，以支援一些拖放和動畫之類的華麗效果。 預載組件 分類: 內容 實際應用中有下列幾種預先載入的類型： 無條件 預先加載——盡快開始加載，獲取一些額外的組件。 google.com就是一個sprite圖片預先載入的好例子，這個sprite圖片不是 條件性 預先載入－根據使用者操作猜測使用者將要跳到哪裡並據此預先載入。在 search.yahoo.com 的輸入框裡鍵入內容後，可以看到那些額外元件是如何要求載入的。 提前 預先載入——在推出新設計之前預先載入。經常在重新設計之後會聽到：“這個新網站不錯，但比以前更慢了”，一部分原因是用戶訪問先前的頁面都是有舊緩存的，但新的卻是一種空緩存狀態下的體驗。可以透過在將要推出新設計之前預先載入一些元件來減輕這種負面影響，老站可以利用瀏覽器空閒的時間來要求那些新站所需的圖片和腳本。 19.減少DOM元素的數量 用 JavaScript訪問 500個DOM元素和5000元素和5000個元素和5000個 DOM元素是一種徵兆——頁面上有些內容無關的標記需要清理。正在用巢狀表格來佈局嗎？還是為了修復版面問題而添了一堆的 YUI CSS utilities grids.css針對整體佈局，fonts.css針對整體佈局，格式。這是個開始清理和思考標記的好機會，例如只在語義上有意義的時候使用 Firebug 的控制台裡輸入： DOM 元素才算是太多呢？可以參考其它類似的標記良好的頁面，例如 Yahoo! 主頁 是一個相當繁忙的頁面，但只有不到 700 個元素（HTML標籤）。 20.跨域分離組件 分離組件可以最大化並行下載，但要確保只用不超過2-4個域，因為存在DNS查找的代價。例如，可以把HTML和動態內容部署在 www.example.org ，而把靜態元件分離到 static1.example.org static1.example.org static1.example。 更多資訊請查看Tenni Theurer和 Maximinging Parall 盡量少用iframe 分類: 內容 用iframe可以把一個文件插入一個重要的文件是文件 是如何工作的並有效率地使用它。 引入緩慢的第三方內容，例如標誌和廣告 代價高昂，即使是空白的 非語意 22. 40443722. 請求代價高昂，完全沒有必要用一個HTTP請求去獲取一個無用的回應（例如404 Not Found ），只會拖慢使用者體驗而沒有任何好處。 有些站點用的是有幫助的 ——“你的意思是 xxx？”，這樣做有利於用戶體驗服務器，但也浪費資源（例如資料庫等了xxx？”，這樣做有利於用戶體驗服務器，但也浪費了資源（例如資料庫等了等）。最糟糕的是連結到的外部JavaScript有錯誤而且結果是 404響應體，因為它是JavaScript程式碼，需要找出其中可用的部分。 23.給Cookie減重 的原因有很多，例如授權和個人化。 HTTP 頭中cookie資訊在web伺服器和瀏覽器之間交換。重要的是保證 cookie 盡可能的小，以最小化對使用者回應時間的影響。 更多資訊請查看Tenni Theurer和Patty Chi的文章： When the Cookie Crumbles 。相關經驗原則可以總結如下： 清除不必要的cookie 保證cookie盡可能小，以最小化對用戶響應時間的影響 設定合適的有效期，更早的有效期或none cookie，提高用戶響應時間可以更快的刪除cookie，提高用戶響應時間 cookie的網域下 分類 當瀏覽器不需要這些 cookie。所以它們只會造成沒有意義的網路通訊量，應該確保對靜態元件的請求不含cookie。可以建立一個子網域，把所有的靜態元件都部署在那裡。 如果網域是 ，可以將靜態元件部署到 static.example.org 。然而，如果已經在頂級域example.org 或www.example.org 設定了cookie cookie。這時候可以再買一個新域名，把所有的靜態組件部署上去，並保持這個新域名不含cookie。 Yahoo!用的是 yimg.com ，YouTube是 .com 等等。 把靜態元件部署在不含cookie的網域下還有一個好處是有些代理程式可能會拒絕快取帶cookie的元件。有一點要注意：如果不知道應該用example.org還是www.example.org作為主頁，可以考慮一下 cookie 的影響。省略www的話，就只能把cookie寫到*.example.org ，所以因為性能原因最好用ookie 寫到這個子域下。 25.盡量減少DOM訪問 訪問 分類: javascript 用JavaScript訪問DOM元素是很慢索引 「離線」更新節點，再把它們添到 樹上避免用JavaScript Julien Lecomte的文章： High Performance Ajax Applications 26.用智慧的事件處理器 有時候感覺頁面反映不夠靈敏，是因為有太多頻繁執行的事件處理器被添加到了 樹的不同元素上，這就是推薦使用事件委託的原因。如果一個 div 裡面有10 個按鈕，應該只給 div容器添加一個事件處理器，而不是每個按鈕都添加一個。事件能夠冒泡，所以可以捕捉事件並得知哪個按鈕是事件來源。 不需要為了處理DOM樹而等待onload事件，通常只要目標元素在DOM的圖片可以考慮用 DOMContentLoaded 來代替 onload 事件，但為了讓它在所有瀏覽器中都可用，可以用 更多資訊請查看YUI影院裡Julien Lecomteations的文章：High Performance Ajajax App. 捨棄 @import : css 前面提到了一個最佳實踐：為了實現在頂部，CSS應該放在頂部，CSS。 IE中用 @import 與在底部用 與在底部用 避免使用濾鏡 : c 濾鏡可以用來修復IE7之前的版本中半透明PNG圖片的問題。在圖片載入過程中，這個濾鏡會阻塞渲染，卡住瀏覽器，還會增加記憶體消耗而且是被應用到每個元素的，而不是每個圖片，所以會存在一大堆問題。 最好的方法是乾脆不要用 AlphaImageLoader ，而優雅地降級到用在IE中支持性很好的PNG8圖片來代替。如果要用 AlphaImageLoader ，應該用下劃線hack： _filter 29. 分類 分類:FTP 伺服器之前，我們還可以做一些事情。 檢查GIF 如果4色圖片用了調色板中256色的“槽”，那就還有改進的餘地 ，看能不能縮減大小，往往可以。開發者通常不願意使用PNG圖片，因為瀏覽器支援有限，但這都是過去的事情了。真正的問題是PNG圖片完全支持 alpha透明度，而GIF圖片卻不支持透明度漸變，所以NG可以（除了動畫）。下面這個簡單的指令就能讓PNG圖片可以安全使用：convert image.gif image.png「我們強調的是：給PNG pngcrush （或其它的PNG最佳化工具）處理所有的PNG圖片，例如： pngrush rush 用 pegtran 處理所有JPEG JPEG圖片的無損操作例如旋轉，還可以用來去除註釋和其它無用資訊（例如EXIF。照片訊息，焦距光圈之類的）： jpegtran -copy none -optimize -perfect src.jpg dest.jpgjpegtran -copy none -optimize -perfect src.jpg dest.jpg 在Sprite圖片中橫向排列一般都比縱向排列的最終檔案小 組合Sprite圖片中的相似顏色可以保持低色數，最理想的是256色以下PNG8格式 圖片中留下太大的空隙。雖然不會在很大程度上影響圖片檔案的大小，但這樣做可以節省用戶代理把圖片解壓成像素映射時消耗的記憶體。 100×100的圖片是1萬個像素，而1000005 萬個像素了。 31.不要用HTML縮放圖片 點。 ML中可以設定寬高而使用本不需要的大圖。如果需要 那麼圖片本身（jp. 100x100px的，而不是去縮小 用小的可緩存的 favicon.ico （P.S. 圖片 favicon .ico是放在伺服器根目錄的圖片，它會帶來一堆麻煩，因為即便你不管它，瀏覽器也會自動請求它，所以最好不要給一個404 Not Found ，此外這個圖片還會幹擾下載順序，例如在IE中，當你在onload中請求額外組件時，將會先下載favicon 所以為了緩解favicon.ico 頭（以後如果想換的話就不能重新命名了），把有效期設定為幾個月後一般比較安全，可以透過檢查當前favicon.ico的最後修改日期來確保變更能讓瀏覽器知道。 Imagemagick 可以用來處理小收藏夾圖示 33.保證所有元件都小於25K33. 33. 这个限制是因为iPhone不能缓存大于25K的组件，注意这里指的是 未压缩的 大小。这就是为什么缩减内容本身也很重要，因为单纯的gzip可能不够。 更多信息请查看Wayne Shea和Tenni Theurer的文章： Performance Research, Part 5: iPhone Cacheability – Making it Stick 34.把组件打包到一个复合文档里 分类: 移动 把各个组件打包成一个像有附件的电子邮件一样的复合文档里，可以用一个HTTP请求获取多个组件（记住一点：HTTP请求是代价高昂的）。用这种方式的时候，要先检查用户代理是否支持（iPhone就不支持）。 35.避免图片src属性为空 分类: 服务器 Image with empty string src 属性是空字符串的图片很常见，主要以两种形式出现： straight HTML JavaScript 这两种形式都会引起相同的问题：浏览器会向服务器发送另一个请求。 IE 向页面所在目录发起一个请求 Safari和Chrome 想当前页面本身发送一个请求 Firefox 3及更早版本与Safari和Chrome处理方式一样，但3.5解决了这个问题 [bug 444931] ，不会再发送请求了 Opera 遇到有空src属性的图片不做任何处理 为什么图片src属性为空不好？ 意外发送大量的通信量对服务器来说是很伤的，尤其是在每天有几百万访问量页面的时候。 浪费服务器资源去生成一个根本不可能被看到的页面 可能会污染用户数据，如果追踪请求状态，要么通过cookie要么是其它方式，可能会破坏用户数据。即使图片请求并没有返回图片，整个HTTP头部也会被浏览器接受并读取，包括所有的cookie。虽然其余部分会被丢弃，但这可能已经造成破坏了。 問題的根本原因是各個瀏覽器在處理URI時的分歧，這在RFC 3986 – Uniform Resource Identifiers– Uniform Resource Identifiers– Uniform Resource Identifiers– Uniform Resource Identifiers– Uniform Resource Identifiers–文件中有明確定義。如果URI是一個空串，會被看作一個相對URI，並按照5.2節定義的演算法處理。實際情況是，Firefox、Safari和Chrome都是根據文件中5.4處理。據說在舊版規範文件RFC 2396 – Uniform Resource Identifiers（被RFC 3986（被RFC 3986 都是對的。問題是，在這種情況下，空串顯然是無心的（ P.S. 而不是什麼相對URI）。 HTML5的4.8.2 節有關於<?php insertScript("menu.js?1.1.11") ?>除了防止相同腳本被多次引入，這個函數還可以解決腳本相關的其依賴它問題，例如其依賴它性檢查和為腳本檔案名稱新增版本號碼來支援「永久」有效期限HTTP... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
<img src=””>
var img = new Image();img.src =
“”
;
標籤
標籤 The src attribute must be present, and must contain a valid URL referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. If the base URI of the element is the same as the doced. then the src attribute's value must not be the empty string.（P.S.非互動式的動畫或影像資源，不能分頁也不能含有腳本。
以上是關於yahoo軍規的詳細介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！