我從 4 年網頁監控中所學到的
本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃!
每半年我會看一看一些來自於HTTP Archive的關鍵統計資料——HTTP Archive是一個非常棒的歷史資料儲存庫,主要關於世界上訪問量最大的五十萬個網站的規模和構成。
正值Archive臨近四週年之際,我想盤點一下過去的四年時間裡發生了什麼變化,有哪些保持不變,以及我在觀看這些資料向上蠕變的過程中學到了哪些東西。
現在平均網頁2219 KB,而四年前只有991 KB
去年春天平均頁面就跨越了2 MB大關,達到2099 KB。現在的網頁平均比一年前大16%,比四年前大139%。
在過去的六個月時間裡,頁面的平均規模又增長了120 KB。對這樣的變化,我們很容易忽略不計。畢竟這又不是什麼大不了的事情,對吧?區區120 KB遠還沒有達到我們需要擔心的程度。不過,這個數值代表了:更多的頁面資源(如影像,CSS檔案,以及各種指令碼),更多的頁面複雜性,以及更多的效能故障風險。想要了解更多的話,請繼續往下看。
影像佔平均頁面重量的64%
這已經不是什麼不為人知的資訊了。自從我跟蹤了HTTP Archive之後,我就發現影像至少構成了平均網頁的60%。
讓人不可思議的是,影像的增長速度非常之快:總的影像負載在短短四年間增加了一倍都不止。更不可思議的是,現在光是影像的頁面重量就超過了兩年多前的平均整個網頁。
但是,規模並不代表一切
上個月,Nate Berkopec寫了一篇極好的部落格文章,在文中他犀利地點破了為什麼如果你只關注頁面重量的話,就會犯錯。他這樣寫道:
祕密就在於“頁面重量”——頁面重量被廣泛地定義為一個頁面的總檔案大小以及它所有的子資源(圖片,CSS,JS等)——但這並非問題的所在。雖然頻寬不是問題,但網頁效能不會隨著寬頻接入變得更加普遍而提高。
問題在於延遲。
我們大部分的網路協議都需要網路往返時延,每一個網路往返增強了網路延時的概率。網路延時受介質傳輸速度的制約,這意味著網路延時並不是在任何地方都會發生。
我曾經寫過一篇關於為什麼更多的頻寬並不是解決效能問題的萬能鑰匙的文章,我的文章聚焦於一個事實,即很多人不明白為什麼雙倍的頻寬不等於快一倍。
Nate的帖子突出了另一個問題:只要時延仍是一個效能問題(也就是說,趨向於永遠),主要的效能元凶將仍然是這樣一個事實——當前典型的網頁包含的一百個左右的資源被託管在幾十個不同的伺服器上。這些網頁中的許多資源都是未經優化的,不可測的,不受監督的——因此也無法預測。
作為一個偽例項,讓我們來看一看自定義字型的突然增加。通過HTTP Archive的跟蹤,我們可以看到,在短短的幾年時間裡,自定義字型已經從幾乎只佔網站的7%,到稱霸了網站的一半以上。
自定義字型對設計師而言一個巨大的福音。它能夠讓你完全控制品牌的視覺資本,這在市場中可不是一件微不足道的事情——品牌從未像現在這樣重要。但是,當你的自定義字型實施不佳或外部託管的時候,反而可能會引入效能陣痛——從會導致惱人輸出訊號(無樣式的文字閃爍)的緩慢字型,到會完全阻止頁面其餘部分載入的不響應的字型。
而自定義字型只是資源中的一種。此外還有樣式表,JavaScript,以及幾十個可能多餘的第三方標籤。最好的情況是,這些資源只是逐漸增加了總的延遲時間。最壞的情況是,它們會給你的網頁引入潛在的單點故障。
那麼……你能做些什麼呢?
1.為頁面設定效能預算
許多快速的網頁都有一個共同點,那就是:大小最多約1 MB(或更少)。並非巧合的是,1 MB正是許多公司正在建立的“效能預算”中為他們的網頁設定的最大值。這可不是為了讓頁面更小——而是為了強迫自己優化出現在網頁上的資源,並做一些戰略性的優勝劣汰,以便於讓網頁變得更簡單,從而減少延遲。如果你還不熟悉關於效能預算的思路,Tim Kadlec撰寫了一些非常棒的文章,指出了為什麼你需要效能預算以及你應該跟蹤什麼樣的指標。
2.首先處理影像
如果你想在效能上取得一些快速的勝利,那麼先從優化你的影像開始。下面是我建立的一個高層次的影像優化清單,以便於你介紹影像優化的重要性給貴組織中的每一個人(尤其是非技術人員)。想要了解更深的話,我強烈推薦Guy Podjarny寫的這篇文章——《High Performance Images: Beautiful Shouldn’t Mean Slow》。
3.優化字型
Ilya Grigorik寫過一篇關於web字型優化的文章,很精彩,設計人員和開發人員不可不讀。
4.得到有關第三方指令碼的控制程式碼
一個典型的web頁面可以包含75+第三方指令碼,並且當涉及到管理這些指令碼的效能的時候,簡直就如同群魔亂舞。許多網站所有者其實並不知道他們的第三方指令碼真實的執行情況,以及這些指令碼會如何影響他們的網頁。這裡有一個簡短的入門介紹,可以幫助你得到有關於你的第三方指令碼的控制程式碼。
5.教育接觸網頁的每一個人
有這麼多的人——從企業老闆到市場營銷人員——他們的決定會影響頁面的執行。所有這些人都需要知道,他們做的每一個決定——從實施新的第三方外掛到使用GIF動畫作為一個標誌性圖片——都是有影響的。
6.瞭解頁面大小和複雜性對你的業務的影響
你還必須瞭解頁面大小和複雜性對載入時間的影響。一旦你將頁面大小,複雜程度,速度和業務效能之間的點連線起來,那麼知道往哪裡投入優化的力量就會容易得多。如果你剛進入這個領域,那麼不妨讀一讀我寫的這篇關於web效能及其對業務指標的影響的簡短文章。當然如果你同我一樣,正瘋狂致力於案例研究,那麼Tim Kadlec和我最近還發布了WPO統計,一個顯示效能和業務成功之間相關性的研究型儲存庫。
譯文連結:http://www.codeceo.com/article/monitor-4-years-web-page.html
英文原文:What I’ve learned From Monitoring Four Years of Web Page Bloat
翻譯作者:碼農網 – 小峰
[ 轉載必須在正文中標註並保留原文連結、譯文連結和譯者等資訊。]
相關文章
- 我從Icon程式語言中所學到的
- 從錯誤中汲取經驗 - 我們在打造Buffer的過程中所學到的
- 從錯誤中汲取經驗 – 我們在打造Buffer的過程中所學到的
- 監控網頁中元素的事件 (轉)網頁事件
- 從監控到診斷:資料的力量
- 從網路文學到“網際網路文學+”的20年
- 我從Superfish事件中學到的事件
- 初探 performance – 監控網頁與程式效能ORM網頁
- 【效能監控】如何有效監測網頁靜態資源大小?網頁
- 從無到有<前端異常監控系統>落地前端
- mysql主從同步(4)-Slave延遲狀態監控MySql主從同步
- Dataguard從庫效能的監控
- 我從程式設計面試中學到的程式設計面試
- 我從Typora中學到的Clipboard妙用.md
- 從學生到遊戲開發者: 我學到的五件事遊戲開發
- Hystrix 監控視覺化頁面——Dashboard 流監控視覺化
- 端到端網路全鏈路監控方案
- changedetection:監控任何網站頁面變動的開源工具網站開源工具
- 我做自由開發者學到的 4 個教訓
- 我從Typoro中學到的Clipboard妙用(二).md
- AIX分頁(交換)空間的監控AI
- 面對網際網路對網民的監控,我們該怎麼辦
- 網站安全監控的方法講解,網站安全監控技術網站
- 一位程式設計師從業餘專案被收購中所學到的程式設計師
- 最佳實踐|從Producer 到 Consumer,如何有效監控 KafkaKafka
- 網站監控網站劫持,網站監控網站劫持有哪些需要注意的網站
- upptime:使用GitHub Actions監控你的網站健康監控Github網站
- 從入門到放棄,我用了五年
- OpManager:網路監控的利器
- 我從其他人的Shell指令碼中學到的指令碼
- prometheus 監控學習Prometheus
- Zabbix+Grafana從零設計自己的監控平臺-監控效果展示Grafana
- Mysql 主從延時監控MySql
- 我常用的主機監控Shell指令碼指令碼
- 如何監控前端頁面FPS前端
- 產品推薦-監控網頁內容變化的守夜人網頁
- 你的網頁有多快 — 從 DOMReady 到 Element Timing網頁
- 網頁渲染方式-從靜態頁面到服務端渲染網頁服務端