摘要:單頁面應(yīng)用文件增多時存在輕微過多阻塞頁面加載的情況比如這樣對雖然可以考慮合并后調(diào)試但合并并不快還要再考慮想到的一個方案是的請求合并功能比如這里的例子沒有明顯的參考目前的瀏覽器支持我原來以為可以在開發(fā)環(huán)境嘗試的基于的服務(wù)器基本的配置是
單頁面應(yīng)用文件增多時, 存在輕微過多阻塞頁面加載的情況, 比如這樣:
(對雖然可以考慮合并后調(diào)試, 但 RequireJS 合并并不快, 還要再考慮)
想到的一個方案是 SPDY 的請求合并功能, 比如這里的例子, 沒有明顯的 Blocking
https://www.modspdy.com/world-flags/
參考目前 SPDY 的瀏覽器支持, 我原來以為可以在開發(fā)環(huán)境嘗試的
http://caniuse.com/spdy
基本的配置是這樣的, 具體步驟請參考其他文章,
測試的內(nèi)容是一個有 20 個左右 JS 文件的 HTML 的加載:
server { listen 443 ssl spdy; ssl on; ssl_certificate app.crt; ssl_certificate_key app.key; server_name app.app; location / { root /app/; autoindex on; } }
結(jié)果是:
單純 Nginx 使用 HTTP 的情況:
Nginx 里使用了 SPDY serve 靜態(tài)文件的情況:
這個是后面的 Node 服務(wù)器 serve 靜態(tài)文件的情況:
大致可以看到幾點, 可能不夠準(zhǔn)確..
SPDY 的請求是同時發(fā)出的, 不像是 HTTP 發(fā)出時間呈現(xiàn)階梯狀, 圖上不夠明顯
SPDY 中 blocking 的時間更長(但有上述的區(qū)別), 可能是 SSL 協(xié)議原因..?
使用 Node SPDY 服務(wù)器網(wǎng)上找到了另一個方案, 使用 Node spdy 模塊來加載文件
https://coderwall.com/p/2gfk4w
https://github.com/ericallam/spdy-with-server-push-tutorial
其中的策略是這樣的:
預(yù)先加載靜態(tài)資源文件, 當(dāng)然, 還有證書之類的..
第一個請求訪問 / 路徑時, 把靜態(tài)的 JS 等等文件 push 到服務(wù)端,
res.end 訪問 / 對應(yīng)的 HTML 文件,
然后, 等瀏覽器去取靜態(tài)資源時, 就可以直接命中緩存, 加快速度.
我仿照這個方案, 寫了一些代碼, 我們的項目開發(fā)環(huán)境存在上百個請求,
具體代碼不方便, repo 里只是 SPDY 相關(guān)的代碼:
https://github.com/jiyinyiyong/spdy-reload-server
注意使用命令去掉證書使用的密碼, 否則 Node 啟動時會提示的:
http://webmasters.stackexchange.com/a/1254/37858
另外這里我沒有走 Nginx, 而是 https://127.0.0.1:3000
這是不使用 SPDY 協(xié)議時的情況:
使用了 SPDY 協(xié)議之后的情況:
我遇到到的幾點, 圖上看到比較少:
SPDY 使用后的確加快了, 但效果不明顯, 還是有
靜態(tài)文件的 download 時間成了 0, 說明緩存起作用了
只有在 Chrome Canary 正常運(yùn)行, 低版本 Chrome 會因為 push 而 crash
Firefox 和 Safari 可能導(dǎo)致 Node 服務(wù)器報錯
另外我還注意到 Canary 訪問即便是 HTTP 也是比 Dev 版的 Chrome 快的... 不清楚為什么.
總結(jié)SPDY 能帶來速度的提升, 但是并不明顯, 反而改用 Canary 提升大一些
使用 Nginx SPDY 沒能加快, 而 Node 對文件做緩存取得一定的效果.
可惜目前難以在開發(fā)環(huán)境用...
上面是我的一些嘗試, 感覺不夠嚴(yán)謹(jǐn), 而且里邊細(xì)節(jié)也不有理解和不能解釋的...
等高人往深了挖一挖...
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/39060.html
摘要:通過或者協(xié)議請求的資源由統(tǒng)一資源標(biāo)識符,來標(biāo)識。標(biāo)準(zhǔn)于年月以正式發(fā)表,替換成為的實現(xiàn)標(biāo)準(zhǔn)。該系列協(xié)議由谷歌開發(fā),于年公開。主流的瀏覽器谷歌火狐也都早已經(jīng)支持,它已經(jīng)成為了工業(yè)標(biāo)準(zhǔn)。配合負(fù)載均衡有層和層協(xié)議負(fù)載。 HTTP/2 is the future of the Web, and it is here! 使用 HTTP/1.1 和 HTTP/2 在相同環(huán)境各加載 300 多張小圖片...
摘要:但在里,所有的文本數(shù)據(jù)默認(rèn)都會被壓縮目前的兼容性是所以說還是任重而道遠(yuǎn)開啟那如何開啟呢很簡單,使用的用戶,可以下載一個的模塊使用的用戶,可以下載一個的模塊最后說兩句其實,和域名收斂一直都是前端世界的優(yōu)化的重點。 話說天下大勢,分久必合,合久必分 其實域名也是一樣,分分合合, 不管是域名收斂還是域名發(fā)散,都有著自己獨特的應(yīng)用場景。目前, 在webs top 30,000 URLS 里面,...
摘要:模式,單實例多進(jìn)程,常用于多語言混編,比如等,不支持端口復(fù)用,需要自己做應(yīng)用的端口分配和負(fù)載均衡的子進(jìn)程業(yè)務(wù)代碼。就是我們需要一個調(diào)度者,保證所有后端服務(wù)器都將性能充分發(fā)揮,從而保持服務(wù)器集群的整體性能最優(yōu),這就是負(fù)載均衡。 showImg(https://segmentfault.com/img/remote/1460000019425391?w=1440&h=1080); Nod...
摘要:模式,單實例多進(jìn)程,常用于多語言混編,比如等,不支持端口復(fù)用,需要自己做應(yīng)用的端口分配和負(fù)載均衡的子進(jìn)程業(yè)務(wù)代碼。就是我們需要一個調(diào)度者,保證所有后端服務(wù)器都將性能充分發(fā)揮,從而保持服務(wù)器集群的整體性能最優(yōu),這就是負(fù)載均衡。 showImg(https://segmentfault.com/img/remote/1460000019425391?w=1440&h=1080); Nod...
閱讀 2737·2023-04-26 02:28
閱讀 2571·2021-09-27 13:36
閱讀 3141·2021-09-03 10:29
閱讀 2775·2021-08-26 14:14
閱讀 2115·2019-08-30 15:56
閱讀 847·2019-08-29 13:46
閱讀 2621·2019-08-29 13:15
閱讀 467·2019-08-29 11:29