Best Practices for Speeding Up Your Web Site(4)

時間 2019-11-11

標籤 best practices speeding web site 欄目 HTML 简体版

原文原文鏈接

十4、

Make Ajax Cacheable

tag: content

使Ajax可緩存

標籤：內容

Ajax的顯著好處之一是對於用戶來講它提供了瞬間的反饋，由於它經過異步方式從後端服務器請求信息。然而，使用Ajax也不能保證用戶不翹起拇指來等待這些異步返回的Javascript和XML。在許多站點中，用戶是否要等待取決於Ajax的使用方式。例如，在一個基於web的郵件客戶端中，用戶會持續等待Ajax的請求結果來找到匹配其查詢條件全部郵件信息。重要的是要記住"異步"並不表明"瞬間"。

爲了提升性能，優化這些Ajax請求是很重要的。提升Ajax性能的最重要的方式是使響應可緩存的，正如在 Add an Expires or a Cache-Control Header所說的那樣。php

一些其它的原則一樣適用於Ajax：

Gzip Components

Reduce DNS Lookups

Minify JavaScript

Avoid Redirects

Configure ETags

讓咱們看一個例子，Web2.0的郵件客戶端可能使用Ajax來下載用戶的地址簿。若是在上次使用該web郵件應用時，用戶沒有編輯地址簿，以前的地址響應能夠從緩存中被讀出來，只要Ajax響應經過 Expires 或者 Cache-Control 頭設置爲可緩存的。相對於以前緩存過的地址簿，當用戶要使用新的地址簿時，必須顯示的通知瀏覽器。這能夠經過在請求地址簿信息的Ajax的URL後加一個時間戳指示用戶上次編輯地址簿的時間來完成。例如&t=1190241612。若是地址簿從上次下載後就沒有編輯過，時間戳會是相同的而且地址簿會從瀏覽器緩存中讀出，從而消除了額外的HTTP環回過程。若是用戶已經編輯了他的地址簿，時間戳會保證新的URL不會匹配已經緩存的響應信息，以後瀏覽器會請求更新後的地址簿實體。

儘管在Ajax響應是動態建立的，而且只能被用於單一用戶，它們仍舊能夠被緩存。作這些會加速你的Web2.0應用。

十5、

Flush the Buffer Early

tag: server

儘早清除緩存

標籤：服務器

當用戶請求一個頁面時，服務器可能會花費200-500毫秒來組裝HTML頁面。在這段時間內，瀏覽器是處於空閒狀態由於它在等待數據的到來。在PHP裏存在flush()函數。它容許你發送部分已經準備好的HTML響應到瀏覽器中以便瀏覽器可以獲取組件，而服務器此時正在忙於準備剩下的HTML頁面。這些好處常被當稱做是忙碌的後端或者是輕前端。

HEAD標籤後被認爲是是清除緩存的好的地方，由於HTML的head一般是容易準備的，而且容許瀏覽器併發下載HEADer中包含的任何CSS和Javascript文件，而此時後臺仍舊忙於處理的過程當中。

例子：

...

</head>

<?php flush(); ?>

<body>

...

Yahoo! search 先前的研究和實際用戶的測試證實了使用這項技術的好處。css

十6、

Use GET for AJAX Requests

tag: server

在AJAX請求中使用GET

標籤：服務器

Yahoo! Mail的團隊發如今使用XMLHttpRequest時，瀏覽器經過兩步處理來實現POST方法：首先發送請求頭，而後發送數據。因此最好使用GET方法，該方法只會發送一個TCP包（除非你有許多的cookies）。IE中URL的最大長度是2K，因此若是你要發送超過2K的數據時你可能不能再用GET方法。

一個有趣的負面效果是不帶有任何數據的POST方法的行爲就像GET同樣。基於HTTP詳細說明書，GET方法是爲了取回信息，因此當你真的只是請求數據時，使用GET是有有意義（語義上）的，相反的是發送數據到服務器端去存儲是無心義（語義上）的。

十7、

Post-load Components

tag: content

延遲加載組件

標籤：內容

當你進一步觀察你的頁面時，你問本身："在最初渲染頁面時，到底什麼是必須？"其它的內容和組件是能夠等待的。

Javascript是理想的候選者，能夠分散在加載事件以前或者以後。例如若是你有用於拖拽，拖放和動畫的Javascript代碼和庫，這些都是可等待的，覺得拖拽頁面上的元素是在初始渲染以後才能實施的。其它可選的可延遲加載的內容包括隱藏內容（在用戶動做以後纔出現的內容）和摺疊組件下的圖片。

能夠幫助你省事的工具： YUI Image Loader容許你延遲加載摺疊組件下的圖片，YUI Get utility 是聯機加載Javascript和CSS的好方法。做爲一個實例你能夠在開啓Firebug網絡面板的狀況下查看原生的Yahoo! Home Page來進行驗證。html

當性能目標和其它的最佳實踐方式保持一致時是好的。在這種狀況下，逐步加強的想法告訴咱們，在支持的狀況下，Javascript能夠提升用戶的體驗可是你也必須保證在沒有Javascript的狀況下頁面也能正常工做。因此在你肯定頁面已經正常工做以後，你能夠經過延遲加載的腳原本給你添加更多的花樣如拖拽，拖放和動畫。

十8、

Preload Components

tag: content

預加載組件

標籤：內容

預加載可能看起來與延遲加載是對立的，但實際上它是針對不一樣的目標的。經過預加載組件你能夠充分利用瀏覽器的空閒時間來請求你不久將要的組件（如圖片，樣式，腳本）。這樣當用戶瀏覽下一個頁面時，你可能已經緩存了多數的組件，對於用戶來講你的頁面將加載的更快。

如下有幾種預加載的方式：

無條件預加載—只要onload事件觸發，你就會前去抓取額外的組件。例如檢查google.com來了解一個精靈圖片是如何在onload中被請求的。 google.com並不須要該精靈圖片，可是在接下來接二連三的搜索結果頁面中倒是須要該圖片的。
有條件預加載—基於用戶動做你會對用戶接下來要去哪作一個有根據的猜想，從而進行相應的預加載。在search.yahoo.com你會發如今你在輸入框中輸入文字後，一些額外的組件是如何被請求的。
定期望的預加載————在再設計以前提早預加載。在再設計以後你常常會聽到"新的站點很cool，可是比以前的站點要慢"。問題的一部分多是用戶以前是在一個全緩存狀態下瀏覽你的舊站點，但在空緩存狀態下瀏覽你的新站點。你能夠在從新加載新頁面以前預加載其組件來緩解該反作用。你的舊站點能夠利用瀏覽器的空閒時間請求一些你的新站點會用到的一些圖片，腳本。

十9、

Reduce the Number of DOM Elements

tag: content

家少DOM元素的數量

標籤：內容

複雜的頁面意味着要下載更多的字節而且一樣會下降Javascript訪問DOM的速度。例如，一次經過500個DOM元素添加一個事件和一次經過5000元素添加一個事件處理，這之間是有很大差異的。

大量的DOM元素可能預示着在不去除必要內容的前提下，一些頁面內容應該獲得改善。你正在使用嵌套的表格做爲佈局用途嗎？你正在加入更多的<div>標籤而僅是爲了修復佈局問題嗎？可能存在更好的且更加語義化的方式來處理你的標籤。

YUI CSS utilities提供好的佈局幫助：grid.css能夠幫助你進行整體佈局，font.css和reset.css能夠幫助你去除瀏覽器的格式設置。從新開始考慮你的標籤存在着挑戰，例如只有在有語義時才使用<div>，而不是把它渲染爲一個新行。

DOM的數量能夠很容易的進行測試，只要在Firebug的console下鍵入：前端

document.getElementsByTagName('*').length。web

至於DOM的數量爲多少時才能算多？檢查一下相似的有較好標籤設計的頁面便可。例如 Yahoo! Home Page是一個複雜的頁面但仍舊只有少於700個的HTML元素（HTML 標籤）

二10、

Split Components Across Domains

tag: content

跨域分隔組件

標籤：內容

分隔組件讓你可以最大化並行下載。確保你使用的域名不要超過2-4個，因爲DNS查詢也會有損耗。例如，你在www.example.org 提供你的HTML和動態的內容，而且在static1.example.org 和 static2.example.org之間分隔你的靜態內容。

要獲取更多的信息，查看由 Tenni Theurer 和 Patty Chi.發表的 " Maximizing Parallel Downloads in the Carpool Lane"。

二11、

Minimize the Number of iframes

tag: content

減少iframes的數量

標籤：內容

iframes容許HTML文檔插入到它的父文檔中。理解iframes的工做方式是十分重要的，只有這樣咱們才能更高效的利用iframes。

<iframe> pros:

幫助減小相似於徽章和廣告這樣的第三方內容
安全沙盒
併發下載腳本

<iframe> cons:

儘管空白，但都是花費昂貴的。
阻礙頁面加載
非語義化Non-semantic

二12、

No 404s

tag: content

拒絕404s

標籤：內容

HTTP請求是寶貴的，因此產生一個HTTP請求而後得到一個無用的響應（例如：404沒有找到）是徹底沒必要要的而且這將在沒有任何益處的狀況降低低用戶體驗。

因此站點擁有一個有用的404s"Did you mean X?"，對於用戶體驗來講是極好的，但同時也浪費了服務器資源（如數據庫，等等）。尤爲糟糕的是當連接到外部Javascript的「連接「（link）壞掉，返回的結果是404。首先，這個下載會阻塞併發下載。緊接着瀏覽器可能嘗試着解析404響應體就好像它（響應體）是正常的Javascript代碼同樣，並嘗試發現響應體中有用的部分。

二十3、

Reduce Cookie Size

tag: cookie

減少Cookie的大小

標籤：cookie

HTTP Cookie用於多種緣由例如認證和個性化。在Web服務器和瀏覽器之間，關於cookie的信息是在HTTP頭部中進行交換的。保持cookies的大小盡量小是很重要這是爲了下降對用戶響應時間的影響。

要獲取更多信息，請查看Tenni Theurer 和 Patty Chi發表的 " When the Cookie Crumbles" 。該研究的精要是：