有了頁面緩存，Rails 就可以不再介入。在某種程度上，這是件好事，因為您的確可以獲得優秀的性能。Rails 只需創建 HTML 頁面，將其放入目錄，之后，就可以置之于腦后。從那時起，就由應用服務器管理這些頁面，且頁面進入應用服務器無需任何循環。從性能的角度而言，頁面緩存真是天賜之福。

我也鐘愛頁面緩存，Rails 使之簡單利落。只需使用一行代碼就可以啟用緩存。如果再加入一些代碼，就能通過簡單地刪除文件操作或使用 Rails 較高層的 API 終止緩存。這里存在一個問題。并不是每個網站都能使用頁面緩存。如果頁面上的數據會根據訪問它的用戶而改變，那么就不能進行頁面緩存。而且，如果很難判斷頁面何時到期終止，就會發現頁面緩存的要求太過苛刻。

比如，幾乎在每個頁面上，ChangingThePresent.org（參閱 側欄）都有某些用戶數據是根據當前登錄的用戶而變化的。圖 1 顯示了我們最新主頁的一部分。（我們一直在努力完善它，所以它有可能會改變。）這個頁面呈現出的問題相對簡單。如果能判斷用戶是否已經登錄，就可以用 Flash、JavaScript、DHTML 或任何其他基于瀏覽器的代碼動態定制視圖。您會發現已登錄的用戶可以登出系統或查看其配置文件，而已登出的用戶則可以注冊或再次登錄。
圖 1. ChangingThePresent.org 上的登錄和登出視圖

圖 2 顯示了稍微有些高級的用戶數據視圖，我們的站點就使用了這個視圖。圖 2 中的兩個視圖有極大的不同。為了處理頁面緩存，我必須先解決所有的差異。對于每個已登錄的用戶，我都必須替換掉頁面的登出內容，使之顯示登錄用戶的登錄 ID 和用戶圖片。緩存這些內容會帶來另一層面的挑戰，因為每個用戶的數據都不盡相同。
圖 2. 兩個截然不同的視圖

這種情況并非 ChangingThePresent.org 所獨有。如果需要個性化用戶體驗，那么不可修改的 Rails 頁面緩存的使用就會受到限制。但如果定制不多，那么實際上還是能很容易地緩存這些頁面的。

解決這些問題的方法很多。我更傾向于使用如下這些技巧：