iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 26
1
Software Development

來做個網路瀏覽器吧!Let's build a web browser!系列 第 26

再談影響行動裝置瀏覽器速度的因素

  • 分享至 

  • xImage
  •  

本系列目錄 《來做個網路瀏覽器吧!》文章列表

本系列下來我們看了不少論文,今天我想討論一下在用手機瀏覽器上網的情況下,彼此的關聯。

回顧一下,我們在為什麼手機上網速度比較慢呢?一文中,討論到 RTT(網路延遲)和資源載入是使瀏覽器很慢的主要原因,這篇中討論到計算的時間幾乎沒影響。

再來我們在Cache 並不會讓手機的瀏覽器更快?一文中提到,cache 對於手機加速沒有顯著效果,理由是因為 CPU 的效能把快取好處吃掉一些,此外快取不見得都剛好對關鍵路徑有幫助。

好了!光這兩篇論文就互相打架了。這邊我用「前者」與「後者」來表示兩者。

「前者」主張 RTT 最關鍵的,計算效能可以不考慮的,還是 2011 的論文。「後者」是 2016 的論文,說 CPU 在「現在」的情況下,會嚴重影響瀏覽器單頁載入時間(page loading time, PLT)。

前者那時候的手機比後者的時空背景效能不知道爛多少,卻有如此令人瞠目的結論。這邊我也不知道為什麼?

但是這邊我大膽假設,使用後者論文中提到的 PLT 模型,這邊我不用原始模型,直接簡化成:

PLT = C(計算延遲) + N(網路延遲)

2011 年的時候大家都還在使用 3G,雖然 CPU 也很慢,但是 C:N 是這邊的關鍵,可能因為那時候N比C大太多,導致「前者」得出 RTT 是關鍵的結論。

至於「後者」是 2016 的時候,已經有 4G 了,而且作者沒有特別聲明是用什麼方式連線,這邊我們假設 C:N 中,後者的N相較前者的N已經變非常小了,但是C可能沒有大幅變化。那麼後者在論文中說明 CPU 影響非常巨大就是合理的。

當然以上單純是我的猜測,能不能簡單用這樣模型估計都很難說。如果能實驗當然是最好,可以直接驗證我的想法對不對。雖然要還原前者時空背景可能比較難,但我們可以直接用 2018 的時空背景再做一次前者的實驗,也還是可以驗證我的猜想對不對。

接著我從「How Far Can Client-Only Solutions Go for Mobile Browser Speed?」取得一些資訊。這邊我用「新者」來表示這篇論文。

「新者」指出約八成的資源會在子網頁被再利用,這邊跟我在用網頁相似性來優化瀏覽器介紹的論文結論差不多。而因為資源容易被再利用,所以聽起來 cache 絕對有優勢對吧?然而我們在「後者」的論文中已經被顛覆這個想法。

不過「新者」還有其他論點,在他的研究中發現,手機瀏覽網站有 75%只會逛一次,這代表 cache 在這些只瀏覽一次的網站中沒有作用。此外手機瀏覽率前十名的網站中,在使用快取的情況下,載入網頁時有約7成的資源會需要重新取得,這個數據跟「後者」接近,「後者」指出一般網站快取再被利用的機率是 0.2。但是需要從新取得的數據當中,有將近一半的快取是因為過期,需要重新驗證,而重新驗證一樣會導致 RTT。

從「新者」論文中的這張圖可以發現:

Cache Hit with Revalidation 代表需要重新驗證,miss 代表沒有被快取

隨者快取量增加,比例幾乎沒有變動,這也說明了不管快取多寡,需要重新連線的比例沒有變化,也就是對 RTT 的減少沒有幫助。

不管是使用者在手機上的行為偏向不會用到快取,或是即使有很多快取,依舊有很大比例需要重新驗證,種種原因都傾向支持「後者」的結論,也許 Cache 真的對手機瀏覽器的影響,並不是真的如想像中重要!

如果大家有看到新的論文可以顛覆這些論點歡迎跟我討論!


希望有幫到大家,大家明天見!


關於作者

劉安齊

軟體工程師,熱愛寫程式,更喜歡推廣程式讓更多人學會


上一篇
Cache 並不會讓手機的瀏覽器更快?
下一篇
市面瀏覽器個案分析:隱私篇
系列文
來做個網路瀏覽器吧!Let's build a web browser!35
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言