304延遲vs內嵌javascript

似乎有一個普遍的結論浮在互聯網上，外部js文件更好。304延遲vs內嵌javascript

主要原因是緩存，維護和可調試性。

但是，對於304個http請求的開銷似乎沒有太多討論。我去了yahoo.com，並且注意到每個javascript文件的304都有大約每個文件30毫秒的開銷（主要是連接&響應開銷）。

我有單獨的JavaScript文件（解決維護問題）。我不需要太多的可調試性（自動化測試非常有用）。

我在考慮是否打包並將它們內聯到HTML文檔頂部的單個腳本標記中。我知道有一點，這是沒有意義的（當我的JavaScript非常大），我應該基準這一點。

我只是想知道，如果有人已經做了這方面的基準，他們得到了什麼樣的結果？

來源

2010-06-02 Brian Takita

我也沒有基準，它也取決於你的連接延遲。但主觀上我從未感覺到這種延遲太多。

仍然我會建議拆分動態內容（您在服務器上呈現的HTML）和靜態內容（CSS，JS）。首先，你的html的有效載荷要少得多（你節省了服務器渲染時間+有效載荷較低），而且更多的是它是一個乾淨的分離，並且從代碼角度來看更易於維護。

如果您希望避免條件GET（例如，通過Modified-Since或Etags標頭），還可以使用Expires標頭。一致的瀏覽器根本不會進行http調用。

來源

2010-06-02 20:39:34

有條件的GET迴避似乎很好。另外，還可以通過版本化JavaScript文件來使緩存過期。 http://stackoverflow.com/questions/2320500/forcing-cache-expiration-from-a-javascript-file – 2010-06-02 22:10:56

對不起，我沒有基準。我懷疑30ms會比擁有更大的HTML文檔更糟糕，並且必須在每次訪問時重新編譯JS（假設更新的JavaScript引擎可以或將來將保留並重用編譯的字節碼（如果JS文件被緩存））。

此外，這不取決於緩存策略？我開發的大多數網站甚至不會發出請求，如果JS文件被緩存，當然不是在瀏覽器會話期間，它會直接進入緩存（我知道這是因爲我偶爾會從需要按F5的客戶端獲得呼叫看到我的變化）。

另一個好處是有效性，將有效的JavaScript嵌入到XHTML + XML文檔中並不是微不足道的。如果這是一個因素，那麼擁有外部JS文件要容易得多。

您也可以分發您的JS文件並通過內容分發網絡提供這些文件，如果您選擇將JavaScript內聯到HTML中，您肯定會放棄這一機會來減少服務器負載。

來源

2010-06-02 19:43:56

它似乎總是有一個http請求（至少在Firefox中），使用expires頭。如果緩存仍然有效，服務器將以304響應。此外，每次都不需要重新解釋JS？我認爲高速緩存的節省將僅限於數據傳輸。 CDN和有效性的好處。 – 2010-06-02 21:45:44

對於基於解釋的引擎，是的，但V8例如將JavaScript編譯爲本地機器代碼。如果JS文件被緩存，瀏覽器沒有理由重新編譯它。您的HTML內的JS不太可能被緩存。我不知道這樣的瀏覽器是否會重新編譯JS，但如果他們今天做，他們可能不會在將來。 – 2010-06-03 11:12:44

前段時間我有一個類似的問題，並決定問兩位前端性能專家@getify和@zoompf。

什麼時候可以使用內嵌<script>元素？什麼時候使用單獨的.js文件更好？同樣的問題可以被問到關於內聯還是關聯CSS - 你在哪裏畫線？

查看http://mathiasbynens.be/notes/inline-vs-separate-file作爲他們的回答。

來源

2010-08-01 15:50:10

我認爲可以通過正確的緩存頭設置避免304請求。

緩存控制：公衆，最大年齡= 3600

只要我們將它設置爲公共就會讓瀏覽器在本地緩存文件。所以它甚至不會向服務器發送請求來驗證文件是否已經改變了一個小時。

如果我們只設置

緩存控制：最大年齡= 3600

看來，大多數瀏覽器會認爲他們可以不緩存文件，因此它會檢查每一次。

至於很多js文件真的會增加很多開銷。我會在構建時使用類似http://code.google.com/p/talifun-web/wiki/CrusherModule的東西來粉碎它們，並通過添加具有該文件的md5散列的查詢字符串來提供具有強etag的一個js文件。所以我們保證新文件即使在max-age過期之前發生變化。

來源

2012-02-01 15:16:09 Taliesin

304延遲vs內嵌javascript

回答

相關問題