我認爲這是瀏覽器的錯誤,或至少是不必要的限制。
這是很容易進行測試。
我創建了一個簡單的例子,HTML文件,該文件下載相同的JavaScript文件的25份(以查詢參數,使它看起來像一個不同的資源):
<!DOCTYPE HTML>
<html>
<head>
<title>Test for Lots of JS files</title>
<meta name="robots" content="noindex">
<body>
</body>
<h1>This is a test for Lots of JS files</h1>
<script src="/assets/js/test.js?v=01"></script>
<script src="/assets/js/test.js?v=02"></script>
<script src="/assets/js/test.js?v=03"></script>
<script src="/assets/js/test.js?v=04"></script>
<script src="/assets/js/test.js?v=05"></script>
<script src="/assets/js/test.js?v=06"></script>
<script src="/assets/js/test.js?v=07"></script>
<script src="/assets/js/test.js?v=08"></script>
<script src="/assets/js/test.js?v=09"></script>
<script src="/assets/js/test.js?v=10"></script>
<script src="/assets/js/test.js?v=11"></script>
<script src="/assets/js/test.js?v=12"></script>
<script src="/assets/js/test.js?v=13"></script>
<script src="/assets/js/test.js?v=14"></script>
<script src="/assets/js/test.js?v=15"></script>
<script src="/assets/js/test.js?v=16"></script>
<script src="/assets/js/test.js?v=17"></script>
<script src="/assets/js/test.js?v=18"></script>
<script src="/assets/js/test.js?v=19"></script>
<script src="/assets/js/test.js?v=20"></script>
<script src="/assets/js/test.js?v=21"></script>
<script src="/assets/js/test.js?v=22"></script>
<script src="/assets/js/test.js?v=23"></script>
<script src="/assets/js/test.js?v=24"></script>
<script src="/assets/js/test.js?v=25"></script>
</html>
然後我也一樣,但再次但與defer屬性
<script src="/assets/js/test.js?v=01" async=""></script>
<script src="/assets/js/test.js?v=02" async=""></script>
....etc.
和相同:
加入異步屬性,如果Chrome會決定阻止下載在處理JavaScript的
/assets/js/test.js
文件爲空。所以不會有執行延遲,也不會有依賴性,除了那些瀏覽器添加的。
我看到了一些有趣的結果!這些都是Chrome 60.0.3112.78或60.0.3112.101,我使用的是Apache,但看到了與Nginx相同的結果。
隨着HTTP/2服務器我們看到以下結果:
隨着純script
標籤的所有腳本被並行加載(但據推測執行按順序)。有沒有6連接限制爲在HTTP/1.1:
隨着腳本加載在平行的6組異步script
標籤 - 完全按照您注意:
點擊它們顯示了他們通過HTTP/2下載。
使用推遲script
標記的腳本與使用異步標記的結果相同 - 一次限制6次下載。
這沒有任何意義 - Chrome會限制您的Javascript下載,但前提是您使用異步或延遲來改善您的下載阻止呈現!
正如sbordet所說,視口中的圖像不會發生同樣的情況 - 所以多重處理能夠在Chrome上工作,它似乎對異步或延遲模式的Javascript有不必要的限制。這是一個真正的限制,如果你正考慮不再使用HTTP/2捆綁腳本,許多人建議你不再需要這樣做。
不是發生在Firefox上,也不是Edge。雖然它確實發生在Opera(基於Chromium的瀏覽器)上。
所以這是個壞消息。好消息是他們「可能」修復了它。當我嘗試Chrome Canary(62.0.3190.0)時,我無法重複這種行爲。但是,當我使用金絲雀網頁測試(它給用戶代理字符串62.0.3190.1,所以應該幾乎相同),它是可重複,所以不是100%肯定他們已經修復了這一切...
都提出了與Chrome團隊對這個bug,因此會看到他們在說什麼:https://bugs.chromium.org/p/chromium/issues/detail?id=757191
總而言之,HTTP/2服務器和客戶端上,則在此刻顯得有點通量,因爲雙方調整和調整它們的實現,以便從這個相對較新的協議中獲得最佳使用。儘管如此,由於谷歌以其SDPY實施(HTTP/2嚴重依賴於此)開始實施,因此您可以預計Chrome會在這種情況下領先於此,令人驚訝,因此您可以預期它們將領先於未落後的曲線......
* *更新**
Chrome團隊回來並確認這是目前在Chrome中實施HTTP/2的限制。他們看到了性能問題,因爲HTTP/2允許一次性訪問許多資產,因此不會將重要項目(包括異步/延遲和項目在視口中不可見)限制爲HTTP/1.1的極限值爲6.
甚至儘管HTTP/2在發送請求後具有優先級請求的概念,但是在優先級和發送(例如,檢查緩存,cookie等等)之前就已經看到了性能問題,所以HTTP/2優先級在這裏沒有幫助。
他們希望在將來改善這一點。
所以,我猜對了,這是一個實施問題,因爲我們習慣了新的HTTP/2世界,不得不優化我們的瀏覽器和服務器!
您是否能夠通過您可以共享的最小示例重現此問題? –
@FrederikDeweerdt感謝您的回覆;我無法顯示當前的環境,但我會爲此設置另一個環境,只需檢查確認問題即可。 –