摘要:起源來源于公司解決主頁面加載速度慢而提出的一項改進技術(shù)。流水線方式降低了頁面整體的加載時間,而且,通過讓一部分頁面先顯示,讓用戶感覺頁面加載的更快了。將樣式表放在頂部,一般放在中,主要作用是避免裸奔,惡化用戶體驗。
前言
本文是對《BigPipe學習研究》的總結(jié)。昨晚刷Quora,看到一個類似的問題,然后今早百度了下,發(fā)現(xiàn)了這篇非常細致的額文章,所以精簡了下,對理解網(wǎng)頁性能優(yōu)化有很大幫助。
BigPipe起源BigPipe來源于facebook公司解決主頁面加載速度慢而提出的一項改進技術(shù)。《高性能網(wǎng)站建設(shè)指南》指出,從瀏覽器發(fā)出請求到頁面顯示網(wǎng)頁的過程中,只有10%~20%的時間花在服務(wù)器產(chǎn)生HTML頁面并傳回瀏覽器這個過程,80%~90%的時間花在瀏覽器解析渲染得到的HTML、CSS、JavaScript文件。所以,針對前端的性能優(yōu)化是減少加載時間最有效地方法。
傳統(tǒng)頁面加載模型加載大型網(wǎng)頁速度慢的根本原因在于,瀏覽器和服務(wù)器的工作是有先后順序的。一般,瀏覽器發(fā)送http請求到服務(wù)器,然后服務(wù)器返回響應(yīng)文件(CSS/HTML/JavaScript),瀏覽器解析并執(zhí)行響應(yīng)文件。服務(wù)器工作的時候瀏覽器在等待,反之,瀏覽器工作的時候服務(wù)器在等待。如果能夠打破這一桎梏,就可以極大改善頁面加載時間。
根據(jù)頁面位置不同,將整個頁面分為不同的pagelet,將眾多pagelet的加載過程像流水線一樣分布在瀏覽器和服務(wù)器上,這實現(xiàn)了服務(wù)器和瀏覽器的并行化。
facebook分區(qū)示意圖
BigPipe 中,用戶提出頁面訪問請求后,頁面的完整加載流程如下:
Request parsing:服務(wù)器解析和檢查http request
Datafetching:服務(wù)器從存儲層獲取數(shù)據(jù)
Markup generation:服務(wù)器生成html 標記
Network transport : 網(wǎng)絡(luò)傳輸response
CSS downloading:瀏覽器下載CSS
DOM tree construction and CSS styling:瀏覽器生成DOM 樹,并且使用CSS
JavaScript downloading: 瀏覽器下載頁面引用的JS 文件
JavaScript execution: 瀏覽器執(zhí)行頁面JS代碼
這個8 個流程幾乎與上文中提到現(xiàn)有的模式?jīng)]有區(qū)別,但這只是一個pagelet 的完整流程,而多個pagelet 的不同操作階段就可以像流水線一樣進行執(zhí)行了。流水線方式降低了頁面整體的加載時間,而且,通過讓一部分頁面先顯示,讓用戶感覺頁面加載的更快了。
限制這一技術(shù)的限制很明顯,由于不同pagelet是通過JavaScript動態(tài)加載的,這會導致爬蟲無法收錄,影響SEO結(jié)果;還有就是當客戶端禁用JavaScript時,這一功能就不能用了。所以要進行瀏覽器嗅探和JavaScript腳本檢測,然后決定使用原有模式或者是動態(tài)添加模式。
facebook的其他性能優(yōu)化技術(shù)1)資源文件的G-zip壓縮,使CSS和JS文件大小降低70%,這是頁面加載過程中傳輸?shù)闹饕募?br>2)JavaScript精簡,移除代碼中不必要的注釋和字符,精簡工具可以使用JSMin,精簡后得腳本會減少20%左右。
3)將CSS和JavaScript合并,減少HTTP請求次數(shù),尤其是對于用戶量巨大的facebook,這會極大地降低服務(wù)器壓力。
4)使用外部JavaScript和CSS,有利于文件復(fù)用和修改。由于瀏覽器緩存的作用,僅第一次加載會慢一點。
5)將樣式表放在頂部,一般放在
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/50230.html
摘要:起源來源于公司解決主頁面加載速度慢而提出的一項改進技術(shù)。流水線方式降低了頁面整體的加載時間,而且,通過讓一部分頁面先顯示,讓用戶感覺頁面加載的更快了。將樣式表放在頂部,一般放在中,主要作用是避免裸奔,惡化用戶體驗。 前言 本文是對《BigPipe學習研究》的總結(jié)。昨晚刷Quora,看到一個類似的問題,然后今早百度了下,發(fā)現(xiàn)了這篇非常細致的額文章,所以精簡了下,對理解網(wǎng)頁性能優(yōu)化有很大幫...
摘要:楊永林,人稱教主,八年前端開發(fā)經(jīng)驗,原新浪微博前端技術(shù)專家,現(xiàn)任鏈家網(wǎng)前端總架構(gòu)師。年年底,教主加入鏈家網(wǎng),負責前端的整體架構(gòu)工作。 楊永林,人稱教主,八年前端開發(fā)經(jīng)驗,原新浪微博前端技術(shù)專家,現(xiàn)任鏈家網(wǎng)前端總架構(gòu)師。長期研究Web訪問性能優(yōu)化和前端框架搭建。作為初始團隊成員,教主參與了新浪微博所有PC版本的開發(fā),其中4~6版以架構(gòu)師的身份設(shè)計了微博PC版的前端架構(gòu)。在新浪微博任職期間...
摘要:比如首頁是一個靜態(tài)頁面,不依賴什么接口列表頁涉及到價格日歷,篩選,一些提示信息模塊等,依賴不同的接口因為使用了,可以實現(xiàn)前后端模板共用。 說起網(wǎng)頁速度優(yōu)化,想必大家都能說上幾句,最知名的莫過于雅虎的23條了。這里有一系列的小建議和優(yōu)化策略,但是治病也得看癥狀,對癥下藥才是關(guān)鍵。 比如淘寶賣家中心首頁速度優(yōu)化的這個場景,就是一個很突出的例子。文章里針對首頁展示優(yōu)化策略做個一個全面的對比,...
摘要:當年的加載在沒有前端工程化之前,基本上是我們是代碼一把梭,把所需要的庫和自己的代碼堆砌在一起,然后自上往下的引用就可以了。而且對于前后端的技術(shù)要求較高,所以對于項目未必是最有效的方案。 當年的 js 加載 在沒有 前端工程化之前,基本上是我們是代碼一把梭,把所需要的庫和自己的代碼堆砌在一起,然后自上往下的引用就可以了。 那個時代我們沒有公用的cdn,也沒有什么特別好的方法來優(yōu)化加載j...
摘要:前端性能優(yōu)化的涉及點從服務(wù)器到協(xié)議再到宿主環(huán)境本身都要有比較深刻的認識,業(yè)界目前主要還是以雅虎總結(jié)出來條前端性能優(yōu)化的黃金軍規(guī)為參考。 歡迎大家前往騰訊云技術(shù)社區(qū),獲取更多騰訊海量技術(shù)實踐干貨哦~ 導語 : 從事前端有6年+的時間了,從最開始的美工到重構(gòu)再到偏向js邏輯開發(fā)的前端開發(fā),一直在前端這個行業(yè)里面摸索和學習,我現(xiàn)在將自己這些年的一個心得體會來個系統(tǒng)性的梳理寫成一篇關(guān)于性能優(yōu)化...
閱讀 2787·2021-11-17 09:33
閱讀 2169·2021-09-03 10:40
閱讀 522·2019-08-29 18:45
閱讀 2956·2019-08-29 16:21
閱讀 613·2019-08-29 11:11
閱讀 3394·2019-08-26 12:00
閱讀 2947·2019-08-23 18:19
閱讀 1094·2019-08-23 12:18