根據我淺薄的經驗，緩存、iframe、NoTalk 足矣
首先，是緩存，因為這個人人都會使，實施成本低，用了可以明顯加快訪問速度，降低數據庫負擔。
但是也存在以下幾個缺點：
1：難以監控命中率。
通常的緩存有.NET 自帶的cache、微軟企業庫的cache、memcached，數據庫級別的查詢緩存，一般小項目都是自帶的cache，發展到一定階段用微軟企業庫的cache，發展到分布式用memcached，緩存進一步精確細化會用到數據庫級別的查詢緩存，但是這些緩存都有難以監控命中率的缺點，開發團隊技術較弱的根本就不知道命中率還可以監控。
2：難以在項目中控制緩存時間和緩存大小
大家可能會用各種集中控制緩存時間的辦法和點子，但實際項目里面的緩存時間都是寫代碼時候拍腦子決定的，這里1分鍾，那里1小時，都無從考證為什么要緩存這么長時間，二不恰當的緩存時間又會影響命中率。
.NET 自帶的cache、微軟企業庫的cache 都無法限制要緩存的單個對象的大小，memcached默認1m，但是很人都把這個默認值改大了，因為大家無法控制自己要緩存的對象 到底有多大，也沒有相關的工具能夠測評要緩存的對象或實體有多大，所以經常出現加了緩存后cpu暴漲的的事（低命中率+反復序列化+讀寫緩存等待）==》高cpu
3：通常緩存是萬能方法，那里都可以使用
緩存這個退頭疼的問題就是他是萬能的，任何地方都可以使用，開發的時候加上了，看着他的確加快的第二次的訪問速度，項目里到處都是緩存，但是，我很少見，幾乎沒見過有人對整個項目的緩存做單元測試、壓力測試、計算命中率，最郁悶的是當項目里到處都是緩存了，網站cpu又高，你始終找不到到底哪里是系統的瓶頸，去掉緩存沒1分鍾整個系統就迅速掛掉。
緩存從而徹底蒙蔽了開發團隊的眼睛：數據庫設計到底合理不合理，需不需要做橫縱分拆、需不需要做主從鏡像，那些需要建索引那些不需要，那些需要緩存、緩存多長時間，站點需不需要拆分，需不需要把那些頁面單獨拎出來做虛擬目錄等等優化手段都需要找到系統瓶頸，但是現在你卻找不到了，不是你不找，而是你無法在真實環境收集有效的信息。
面對孱弱的數據庫，大家，大家只能增加web服務器和緩存服務器。。。
然后，是iframe。iframe就是嵌套頁，他有什么好處呢，就是做外面頁面的和做里面頁面的彼此在服務器端互不干涉，在客戶端也互不干擾，因此經常出現打開一個頁面卻發現頁面的某一模塊顯示404錯誤，iframe就是頁面補丁，當一支團隊無法控制整個頁面的質量的時候，就會才去給頁面打補丁的方式，來處理頁面的的展示，是一個隊伍不思進取、變懶的開始，當然，也是分工明確，職責分明的體現，一般情況下，喜歡用iframe的團隊做出的來動用戶體驗比較差，因為他們的js是在太弱了。
最后，NoTalk，將徹底讓這支隊伍在 沼澤中迷路，溝通表現在很多方面，代碼、注釋、文檔、集體討論。當一支隊伍只有項目上線時間表,卻NoTalk,NoTalk
NoTalk,NoTalk,NoTalk,NoTalk,NoTalk……………..我只能呵呵了