We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
你好,看了bigpipe-on-node的相关介绍,给我的感觉bigpipe-on-node不仅不能改善页面加载性能,相反还会降低。 套用介绍里面的例子,假如后台需要做两个IO关联处理,A耗时3秒,B耗时5秒。 那么用node.js,理想情况下浏览器接受到response的时间是5秒(2者之间的最大值), 而并非8秒。 采用bigpipe分块发送,那么理想情况下,浏览器在第三秒末接受到A的response,第5秒后接受到B的response。 总时间是一样的,而bigpipe才用分块发送,传输效率应该会有点损耗,而且JS来渲染的效率肯定是远远低于服务端。 故,bigpipe-on-node想法会降低面加载性能。顶多只能说是改善了一下加载体验(用户在第3秒末就可以浏览到A相关信息) 如有错误请指正,谢谢!
The text was updated successfully, but these errors were encountered:
「JS来渲染的效率肯定是远远低于服务端」這不成立,如果請求量大,全都在服務器端處理不就給服務器更大壓力嗎?
並不能簡單比較最終 HTML 傳輸結束的時間。網頁加載過程涉及到太多因素,BigPipe 先發送的 HTML 片段可以讓瀏覽器(比如說,在第一秒的時候)去加載外部靜態文件,同時等待後續的 HTML 片段,而不用 BigPipe 的話至少到第 5 秒才開始加載靜態文件。
而「改善了一下加载体验」也是很重要的,即便是這樣,我們假設一種情況是第 3 秒顯示出一半,第六秒顯示出剩下一半,也要好過等待 5 秒後突然顯示完成。
Sorry, something went wrong.
@undoZen 渲染速度好慢
No branches or pull requests
你好,看了bigpipe-on-node的相关介绍,给我的感觉bigpipe-on-node不仅不能改善页面加载性能,相反还会降低。
套用介绍里面的例子,假如后台需要做两个IO关联处理,A耗时3秒,B耗时5秒。
那么用node.js,理想情况下浏览器接受到response的时间是5秒(2者之间的最大值),
而并非8秒。
采用bigpipe分块发送,那么理想情况下,浏览器在第三秒末接受到A的response,第5秒后接受到B的response。
总时间是一样的,而bigpipe才用分块发送,传输效率应该会有点损耗,而且JS来渲染的效率肯定是远远低于服务端。
故,bigpipe-on-node想法会降低面加载性能。顶多只能说是改善了一下加载体验(用户在第3秒末就可以浏览到A相关信息)
如有错误请指正,谢谢!
The text was updated successfully, but these errors were encountered: