【正文】 reach ($files as $file){ echo script type=\text/javascript\ SOURCE=\/javascript/$file\/script\n。想更進(jìn)一步的話(huà)，可以把合并過(guò)程（merge process）寫(xiě)在php里，然后使用同一個(gè)（合并文件的）配置去執(zhí)行。為了做的更加完美，我們還可以分析 css和js文件在頁(yè)面中同時(shí)出現(xiàn)的幾率，以此決定合并哪些文件最合理（幾乎總是同時(shí)出現(xiàn)的文件是合并的首選）。一個(gè)主樣式表控制應(yīng)用的所有樣式表，多個(gè)子樣式表控制不同的應(yīng)用區(qū)域。對(duì)沒(méi)有太多css和js資源的應(yīng)用來(lái)說(shuō)，這個(gè)方法在第一次請(qǐng)求時(shí)可能比單個(gè)大文件慢，但如果保持文件數(shù)量很少的話(huà)，你會(huì)發(fā)現(xiàn)其實(shí)它更快，因?yàn)槊總€(gè)頁(yè)面的數(shù)據(jù)量更小。壓縮談到資源壓縮，大多數(shù)人馬上會(huì)想到mod_gzip（但要當(dāng)心，mod_gzip實(shí)際上是個(gè)魔鬼，至少能讓人做惡夢(mèng)）。就像這樣：?php AcceptEncoding: gzip,deflate 服務(wù)器遇到這樣的header請(qǐng)求時(shí)，就用gzip或deflate壓縮內(nèi)容發(fā)往客戶(hù)端，然后客戶(hù)端解壓縮。也算差強(qiáng)人意。在高容量的系統(tǒng)中，由于磁盤(pán)io問(wèn)題，很快就會(huì)達(dá)到極限。它采用更合理的方式：在內(nèi)存里做壓縮。雖然沒(méi)有純內(nèi)存方式快，但也不會(huì)比往磁盤(pán)上寫(xiě)文件慢。如果把壓縮添加在build過(guò)程，它就很透明了。配置選項(xiàng)會(huì)告訴mod_gzip去哪里找到預(yù)壓縮過(guò)的文件。不過(guò)在此之前，必須確認(rèn)apache有正確的權(quán)限去創(chuàng)建和覆蓋壓縮文件。某些Netscape 4的版本（）認(rèn)為自己能夠解釋壓縮內(nèi)容（它們發(fā)送一個(gè)header這么說(shuō)來(lái)著），但其實(shí)它們不能正確的解壓縮。所以要在服務(wù)器端探測(cè)代理類(lèi)型，（如果是Netscape 4，就要）讓它們得到未壓縮的版本。ie（版本46）有些更有意思的問(wèn)題：當(dāng)下載壓縮的javascript時(shí)，有時(shí)候ie會(huì)不正確的解壓縮文件，或者解壓縮到一半中斷，然后把這半個(gè)文件顯示在客戶(hù)端。在某些情況下，可它們會(huì)忽略這個(gè)文件的 etag header，不緩存它。這些過(guò)時(shí)的瀏覽器還能不能在現(xiàn)在流行的windows或unix環(huán)境下面安裝都存在不小的問(wèn)題）既然gzip壓縮有這么多問(wèn)題，我們不妨把注意力轉(zhuǎn)到另一邊：不改變文件格式的壓縮。它們做的不外乎幾件事：去掉注釋?zhuān)瑝嚎s空格，縮短私有變量名和去掉可省略的語(yǔ)法。由于對(duì)解析樹(shù)的理解不完整，壓縮器很難區(qū)分一句注釋和一句看似注釋的引用字符串。還好有個(gè)壓縮器能避免這些問(wèn)題：dojo壓縮器（現(xiàn)成的版本在這里）。它能很好的減小代碼體積，僅用很小的成本：因?yàn)橹辉赽uild時(shí)壓縮一次。（既然壓縮沒(méi)有問(wèn)題了，）我們可以在源代碼里隨心所欲的添加空格和注釋?zhuān)槐負(fù)?dān)心影響到產(chǎn)品代碼。由于css語(yǔ)法里不會(huì)有太多引用字符串（通常是url路徑跟字體名），我們可以用正則表達(dá)式大刀闊斧的干掉空格（htmlor注：這句翻的最爽，哈哈）。這樣的話(huà)，一個(gè)簡(jiǎn)單的perl腳本就夠了：?php !/usr/bin/perl my $data = ‘‘。$data .= $_ while F。$data =~ s!/*(.*?)*/!!g。 壓縮空格 $data =~ s!} !}\n!g。 刪除最后一個(gè)換行 $data =~ s! { ! {!g。 }!}!g。然后，就可以把單個(gè)的css文件傳給腳本去壓縮了。這帶來(lái)了更快的用戶(hù)體驗(yàn)。這下HTTP緩存知識(shí)派上用場(chǎng)了。緩存時(shí)間的長(zhǎng)短取決于兩個(gè)因素：代理的配置和服務(wù)器的緩存控制header。為了不讓瀏覽器緩存改動(dòng)頻繁的頁(yè)面，你很可能已經(jīng)發(fā)送過(guò)header不緩存動(dòng)態(tài)內(nèi)容。header(CacheControl: nocache, false)。要確保瀏覽器不緩存文檔，應(yīng)該更強(qiáng)硬一些：?php 讓它在過(guò)去就“失效” header(Expires: Mon, 26 Jul 1997 05:00:00 GMT)。 HTTP/ header(CacheControl: nostore, nocache, mustrevalidate)。 HTTP/ header(Pragma: nocache)。但對(duì)于那些不會(huì)每次請(qǐng)求時(shí)都有改動(dòng)的內(nèi)容，應(yīng)該鼓勵(lì)瀏覽器更霸道的緩存它。如果客戶(hù)端在請(qǐng)求中發(fā)送一個(gè)“IfModifiedSince”header， apache（或其他服務(wù)器）會(huì)以狀態(tài)代碼304（沒(méi)改過(guò)）響應(yīng)，告訴瀏覽器緩存已經(jīng)是最新的。嗯，再想想。在apache環(huán)境下，每個(gè)對(duì)靜態(tài)文件的響應(yīng)都會(huì)發(fā)出一個(gè)“ETag”header，它包含了一個(gè)由文件修改時(shí)間、文件大小和inode號(hào)生成的校驗(yàn)和（checksum）?？蒃Tag跟IfModifiedSince 有同樣的問(wèn)題：客戶(hù)端仍舊需要執(zhí)行HTTP請(qǐng)求來(lái)驗(yàn)證本地緩存是否有效。在兩臺(tái)負(fù)載平衡的服務(wù)器環(huán)境下，對(duì)一個(gè)代理（瀏覽器）來(lái)說(shuō)，一個(gè)資源可以這次從A服務(wù)器得到，下次從B服務(wù)器得到（htmlor注：lvs負(fù)載平衡系統(tǒng)就是個(gè)典型的例子）?？墒?，如果兩臺(tái)服務(wù)器給同一個(gè)文件生成了不同的etag或者文件修改日期，瀏覽器就無(wú)所適從了（每次都會(huì)重新下載）?？梢允褂胊pache的配置選項(xiàng)關(guān)掉它：?php FileETag MTime Size 使用這個(gè)選項(xiàng)，apache將只用文件修改日期和文件大小來(lái)決定etag。既然etag依賴(lài)于修改時(shí)間，就得讓時(shí)間同步。這樣一來(lái)，兩臺(tái)服務(wù)器生成的 etag還是不一樣。這可不行。（現(xiàn)在的問(wèn)題是，）這些可能的緩存策略導(dǎo)致了一件事情反復(fù)發(fā)生，那就是：客戶(hù)端向服務(wù)器查詢(xún)本地緩存是否最新。其實(shí)，也不盡然。這時(shí)候就可以用服務(wù)器的響應(yīng)來(lái)通知客戶(hù)端這些文件有了改動(dòng)。假如能確定一個(gè)資源永不更改，我