本篇篇幅不長,主要是講清楚兩件小事。這兩件小事,基本上涵蓋80%網頁性能優化體系(不敢說所有),讓你們看到一些現象後面的本質。前端
事情都要從我買的那個狗屁服務器提及,便宜是挺便宜的,99 塊,可是隻有 1 M 的帶寬。瀏覽器
今天給你們扯一個 網絡帶寬 (如下簡稱「帶寬」)的知識,你可能以爲我作前端的,關我屁事。可是這件屁事,總有一天會跟你產生微妙 🤏 的關係。本文主旨是經過講解 帶寬 的知識,結合瀏覽器併發請求數有限 特性 ,來分析那些如雪碧圖、減小 HTTP 請求、路由異步加載、圖片轉 CDN、壓縮靜態資源等等等等前端優化性能的作法,作這些事情最終是爲了什麼。緩存
我想着本身硬扯,可能不夠準確,因而我去搜了百度看看有什麼好的定義。嚯喔~~~唧唧歪歪長篇大論 。這裏我經過百科裏的一個例子簡單總結一下。性能優化
「把城市交通道路比做網絡,道路會出現單車道、雙車道、四車道、八車道。你開着一輛車,在路上行駛,途徑單車道、雙車道、四車道、把車道,最後到達目的地。」服務器
上述場景中出現了幾個關鍵詞:markdown
而 帶寬 是用來傳輸信息的,信息確定有一個具體的量值,咱們稱它爲 數字信息流 。 數字信息流 的單位是 bit
(比特),時間單位是 s
(秒),因此描述 帶寬 的單位是 bit/s
(比特/秒)。想象一下每秒 1 bit/s 的下載速度,是否是要親媽爆炸 💥 。如今的電信寬帶上網,速度在 512 K bit/s (千比特每秒) 至 10 M bit/s (兆比特每秒) 之間。以太網就更快了,速度在 10 M bit/s (兆比特每秒) 以上。網絡
KB 和 Kb 其實是不同,不少資料都沒有嚴格區別,實際上這是不嚴謹的。大寫 B 和小寫 b 不一樣,大寫 B 表明 Byte,字節;小寫 b 表明 bit,比特。1 B = 8 b併發
也就是說咱們平時辦理的 100 M寬帶,換算一下的話就是:負載均衡
100 M b/s = (100 * 1024) K b/s = (100 * 1024 / 8) KB/s = 12800 KB/s = 12.5 MB/s前端優化
吹牛逼呢,我家辦理的就是 100 M 的寬帶,我咋沒發現有 12.5 MB/s 的網速呢(直接閉氣,中國移動你給我出來)。
後來發現,誤會一場 😂 。上面一頓算,只是理想狀態下的,而現實是,受「用戶計算機性能、網絡設備質量、資源使用狀況、網絡高峯期、網站服務能力、線路損耗,信號衰減」等多種因素的影響,會形成實際網速並無理想的那麼快。
一段操做猛如虎,腚睛一算,我可憐的 1 M 帶寬服務器,傳輸數據的速度是 128 KB/s(理想狀態下)。
說完帶寬,咱們來了解一下,一個瀏覽器,同域 下能併發多少個網絡資源請求。 咱們以谷歌瀏覽器爲例子,是 6 個。我找到一份 2008 年的權威數據😱(驚了):
圖片來自:地址
注意我上面說了一個關鍵詞 同域 下的併發數。你要問我 同域 是什麼,你能夠放棄前端了(不會還不去查!!)。
瞭解完上面兩個知識點,我就開始點題了。
爲何要作雪碧圖?一張雪碧圖裏,圖標多的狀況下,有幾十個小圖標。若是把這些圖標都換成單圖加載,假設首頁須要 100 個這樣的小圖標,同時加載 100 張圖片。谷歌瀏覽器併發請求是 6 個,你說炸不炸(固然沒有這麼誇張,我就是說得誇張一點,嚇唬嚇唬你)。
爲何要減小 HTTP 請求?還不是 服務器帶寬大小 和 瀏覽器併發數 擺在那兒。若是頻繁的併發請求,在某一時刻同時有多人完成大量的併發請求,服務器帶寬不大(車道很窄)的狀況下,會形成交通擁堵現象。(固然,負載均衡和啓動多進程能解決這個問題)。
異步加載的目的,就是減小首次加載的靜態資源大小,在不須要其餘頁面資源的狀況下,就無需在首頁加載。而減小靜態資源的體積的目的,一個是網速慢,加載會很慢;另外一個是靜態資源太大,服務器帶寬小的狀況下,響應時間也會變長。
圖片資源轉 CDN,目的就是不和網站 主域 搶資源。前面提到了谷歌瀏覽器 同域 下的併發請求數是 6 個,敲黑板!!!你把圖片資源放在 主域 下,它會去搶網絡資源啊。因此你會看到不少網站,就好比掘金,會把圖片放在另一個域下的 CDN 連接。甚至還會放在多個不一樣的域下。
壓縮靜態資源和分包操做,就是考慮到服務器 帶寬 傳輸信息的量在單位時間內是有限的,因此壓縮完以後,單次請求的資源體積變小了,天然速度就會變快。
還有不少,我不舉了(別瞎想),去掘金搜索框內輸入「性能優化」,多如牛毛。
網頁性能優化博大精深,我也只是站在個人角度去分析這個問題,有更深看法的大佬,能夠在評論區指教一二,不要陰陽怪氣的那種,若是說了陰陽怪氣的話,我特麼直接懟你(逃)。