技巧
技巧 16：在開始長時間的任務之前先使用 Response.IsClientConnected
如果使用者失去耐心，他們可以在開始執行他們的請求之前放棄 ASP 頁。如果他們單擊了 Refresh 或跳轉到伺服器的其他頁上，在 ASP 請求隊列的末尾將有一個新的請求，而在隊列的中間有一個中斷連線的請求。這通常發生在伺服器處於高負荷的情況下（它有一個很長的請求隊列，相應的回應時間也很長），這隻能使情況更糟。如果使用者不再串連，將沒有執行 ASP 頁的點（特別是低速、重量級的 ASP 頁）。可以使用 Response.IsClientConnected 屬性檢查這種情況。如果它返回 False，則應調用 Response.End 並放棄該頁的剩餘內容。實際上，每當 ASP 要執行新的請求時，IIS 5.0 便將該方法編碼，來檢查隊列中的請求有多長。如果在那裡超過了 3 秒鐘，ASP 會檢查客戶是否仍然串連著，如果客戶已中斷連線，就立即結束該請求。您可以使用 metabase 中的 AspQueueConnectionTestTime 設定，調整這 3 秒的逾時時間。
如果有某頁執行了很長時間，您可能還想按一定的時間間隔檢查 Response.IsClientConnected。在啟用響應緩衝之後，按一定的時間間隔執行 Response.Flush，告訴使用者進行中的是哪些事情，是個好辦法。
注意 在 IIS 4.0 中，Response.IsClientConnected 將不能正常工作，除非首先執行 Response.Write。如果啟用了緩衝，也需要執行 Response.Flush。在 IIS 5.0 中則不必如此 - Response.IsClientConnected 工作得很好。在任何情況下，Response.IsClientConnected 都要有些開銷，所以，只有在執行至少要用 500 毫秒（如果想維持每秒幾十頁的輸送量，這是一個很長的時間了）的操作前才使用它。作為通常的規則，不要在緊密迴圈的每次迭代中調用它，例如當繪製表中的行，可能每 20 行或每 50 行調用一次。
技巧 17：使用 <OBJECT> 標記執行個體化對象
如果需要引用不能在所有代碼路徑中使用的對象（尤其是伺服器 - 或應用程式 - 範圍的對象），則使用 Global.asa 中的 <object runat=server id=objname> 標記來聲明它們，而不是使用 Server.CreateObject 方法。Server.CreateObject 立刻建立對象。如果以後不使用那個對象，就不要浪費資源。<object id=objname> 標記聲明了 objname，但實際上 objname 此時並沒有建立，直到它的方法或屬性第一次被使用時才建立。
這是遲緩計算的另一個例子。
技巧 18：使用 ADO 對象和其他組件的 TypeLib 聲明
當使用 ADO 時，開發人員經常包含 adovbs.txt 來獲得對 ADO 不同常量的訪問權。該檔案必須包含在要使用這些常量的每一頁中。該常量檔案非常大，給每個 ASP 頁增加了很多編譯時間和指令碼大小方面的開銷。
IIS 5.0 提供了綁定到組件類型庫的能力。允許您在每個 ASP 頁上引用一次類型庫並使用它。每頁不需要為編譯常量檔案付出代價，並且組件開發人員不必為在 ASP 中的使用而產生 VBScript #include 檔案。
要訪問 ADO 類型庫，請將下列語句之一放入 Global.asa 中。
<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library" TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}" -->
或者
<!-- METADATA TYPE="TypeLib" FILE="C:\Program Files\Common Files\system\ado\msado15.dll" -->
技巧 19：利用瀏覽器的驗證能力
流行的瀏覽器具有對以下功能的進階支援，例如 XML、DHTML、Java Applet以及遠端資料服務。請盡量利用這些功能。所有這些技術，都可以通過執行用戶端的驗證和資料緩衝，減少了與 Web 服務器之間的往返。如果您正在運行智能瀏覽器，該瀏覽器可以為您進行一些驗證（例如，在運行 POST 之前檢查信用卡的校正和否有效）。重申一次，請盡量使用這些功能。由於削減了用戶端到伺服器的往返路程，將減少對 Web 服務器的壓力，並且削減了網路通訊量（雖然發送給瀏覽器的初始頁面可能更大），伺服器訪問的所有後端資源也削減了。而且使用者不必經常提取新頁，使使用者的感受好一些。這並不減輕對伺服器端驗證的需要。還是應該經常進行伺服器端的驗證。這樣能夠防止由於某些原因從用戶端來的壞資料，例如駭客，或者不運行用戶端驗證程式的瀏覽器。
許多網站由獨立於瀏覽器建立的 HTML 組成。這一點經常阻礙開發人員利用可以提高效能的流行瀏覽器功能。對於真正高效能的、必須關心瀏覽器的網站，良好的策略是針對流行的瀏覽器最佳化您的頁面。在 ASP 中使用“瀏覽器效能組件”，很容易檢測到瀏覽器的功能。諸如 Microsoft FrontPage 等工具，能協助您設計使用所希望的目標瀏覽器和 HTML 版本的代碼。更詳細的討論，請查看 When is Better Worse? Weighing the Technology Trade-Offs（英文）。
技巧 20：在迴圈中避免字串串聯
許多人在迴圈中建立類似這樣的字串：
s = "<table>" & vbCrLf
For Each fld in rs.Fields
s = s & " <th>" & fld.Name & "</th> "
Next
While Not rs.EOF
s = s & vbCrLf & " <tr>"
For Each fld in rs.Fields
s = s & " <td>" & fld.Value & "</td> "
Next
s = s & " </tr>"
rs.MoveNext
Wend
s = s & vbCrLf & "</table>" & vbCrLf
Response.Write s
這種方法有幾個問題。首先，重複連接字串所花費的時間，以二次方曲線的速率增長；粗略地計算，運行迴圈所花費的時間，與記錄數乘以欄位數的平方成正比。舉一個簡單的例子，便能清楚地說明這一點。
s = ""
For i = Asc("A") to Asc("Z")
s = s & Chr(i)
Next
在第一次迭代中，得到一個字元的字串“A”。在第二次迭代中，VBScript 必須重新分配字串並複製兩個字元“AB”到 s。在第三次迭代中，它必須再次重新分配 s，並複製三個字元到 s。在第 N 次（26 次）迭代中，它必須重新分配並複製 N 個字元到 s。就是 1+2+3+...+N 的和，為 N*(N+1)/2 次複製。
在以上記錄集的例子中，如果有 100 條記錄和 5個欄位，則內部的迴圈將執行 100*5 = 500 次，並且完成所有複製和重新分配所花費時間，將與 500*500 = 250,000 成正比。對一個大小適度的記錄集，將有很多次複製。
在該例子中，代碼可以改進：字串的串連將被 Response.Write() 或內嵌指令碼 (<% = fld.Value %>) 所替代。如果開啟響應緩衝，這個操作將會很快，因為 Response.Write 僅僅將資料添加到響應緩衝的末尾。不再重新分配，因而非常有效。
特別是在將 ADO 記錄集轉換到 HTML 表時，請考慮使用 GetRows 或 GetString。
如果用 JScript 連接字串，強烈建議使用 += 操作符；即用 s += "某字串"， 而不是 s = s + "某字串"。
