“作為一個用戶，是否有一個詞語（除了”特權“之外）來表達越來越恨網頁，但是作為一個開發人員，卻越來越喜歡呢？ 替一個朋友問"

— getify (@getify)

我想不出一個詞語給 Kyle， 但是我完全同意這種感受，在很大的社區網站也看到過這樣的抱怨。開發人員需要在模塊，應用安裝提示，移動網頁錯誤，廣告，移動鏈接跳轉，EU cookie 提示等等組件上創建網頁，實際上他們也是越來越痛恨網頁。

在這篇文章中，我將討論痛恨的原因，以及現在網頁面臨的最大問題--”復雜“：這個詞我統稱那些在一般的網頁上包含的，但是無益于用戶正在做的事情--如讀一篇文章，購買一個產品等等的東西。我也會討論這個復雜性的問題很大程度上是由網站所面臨的更大的錢的問題所引起的。

為了把這些都放在一個上下文里面，讓我們來看看一個例子。

復雜性實例

前幾天我在我的Twitter上看到這篇關于精神病的文章。 我用iOS上的Chrome打開這篇文章，我看到了：

這篇文章用來說明網頁的復雜性再合適不過。我想要做的無非是像其他人想的那樣閱讀這篇關于精神病的文章，但是在我開始閱讀之前,我不得不過濾掉許多我不關心的垃圾--像社交的按鈕，天氣，以及一個使用期限方式的提示，所有這些都伴隨著這篇只有2000字左右的文章出現。我甚至不能在我那超大的iPhone 6+的手機上看到文章的開頭。

加載這篇文章花費了200+HTTP請求，大約2M的數據量。使用我的WIFI的情況下，這篇文章花了3秒來加載. 網頁測試顯示使用普通的移動網絡，網頁加載需要花費13秒。

我不是想專挑CNN的毛病，說出來挺傷心的，這篇文章儼然是普遍網頁訪問體驗的一個代表。根據http archive機構統計，普通的網頁在5月份超過2M大小，達到了2.08M。找到一個更壞的例子并不難

為什么越來越繁雜？

我不是最先談及web繁雜問題的，Peter-Paul Koch最近還提及這個問題：

“web版本文章都會有一個額外繁雜的層加在上面，這是導致web頁面加載慢的直接原因。速度的原因并不是web固有的。這就是所謂現代web開發的結果，我們最終會戰勝這個繁雜的問題并徹底“干掉”它。（指web繁雜問題）”

之后他提出的問題我想研究一下:

“這個有趣的問題是：為什么所有的東西越來越繁雜？”

PPK繼續深入探討了這個由各種在線工具，特殊的庫，框架的使用激增導致的web繁雜問題。我非常同意這個觀點，一些不必要的web頁面上工具的使用會直接影響頁面大小和其加載速度，但是我認為是更加系統化的問題而導致的web繁雜問題。

讓我們來更深入地看看這篇 CNN 文章。這個頁面面向了 25 個不同的域名發起了 200 多個 HTTP 請求。

是的，你沒看錯。二~十~五~哦。它們之中的幾個明顯跟廣告有關 (例如. ad.doubleclick.net, pixel.moatads.com)， 一些提供了分析功能，還有許多的名字被故意混淆了以迷惑我們。

對我而言，你可以用一種不同的方式提出“所有這些多余的東西都是為了什么?”: 既然最少化 HTTP請求是眾所周知的 web 性能最佳實踐之一，為什么許多移動 web 站點會公然違反這一規則呢?

你可能會說部分原因在于工具，因為使用插入式廣告，社交媒體窗口，以及諸如此類的東西，會產生相比手工制造的內容更多的 HTTP 請求。不過我相信答案必然跟錢有關。

跟著錢走

為什么 CNN 要展示廣告？為了掙錢。為什么 CNN 要引入跟蹤服務? 為了更多地了解讀者，以展示更多地有針對性的廣告，從而掙更多的錢。為什么 CNN 要使用社交媒體按鈕？為了讓人們分享這篇文章，以獲取更多的頁面訪問，從而讓更多人看到廣告，掙更多的錢。為什么 CNN 要引入一個天氣窗口？好吧，我并不知道那是為啥，他們應該把這個小窗口去掉的。

同樣，我的意思并不是拿出 CNN 來作為”壞榜樣“，而是拿他們來展示一個對于 web 上的內容而言有些悲觀的模型的特殊例子。

我朋友 Brian Rinaldi 最近寫道 web 的內容模型已經被破壞了， 這位朋友聲稱作為 web 用戶的我們徹徹底底地貶低了內容和作者們。他聲稱因為我們拒絕為內容付費，產出內容的人必須采取日益激進的戰術來讓他們產出的內容掙到錢 — 某些別的目的才使得內容有可能產生出來。

（很大程度上）付費體系已經失敗了，這樣我們就會看到一大堆什么玩意兒都有的廣告，跟蹤腳本，彈出框，諸如此類，所有這些都是在一起為雜亂背后真正的內容提供足夠的回報。

在做什么?

很多人在和這個問題（繁雜）戰斗，但有趣的是成果大多數來自瀏覽器之外。

Flipboard 大概是解決網頁繁雜問題的第一個有大成果的嘗試。Flipboard 的原理是從網頁上獲取得內容，生成一個摘要，然后關閉原文章的連接。在你不需要加載全部文章時，這是個相當不錯的瀏覽體驗，而所有繁雜的問題也是來自這里，所以我們只需要獲取一個這篇文章的快照。如圖所示，這是一篇Flipboard 的 IOS 應用中的文章“Fanway Park（芬威公園）”：

但更有趣的是 Flipboard 不只有內容預覽這個功能，它現在已經和內容供應商合作，我們可以直接在 Flipboard 應用中使用這些文章——前面所說的全瀏覽器（browser entirely）。示例是一些來自Flipboard 的iSO 應用中的關于精神病患者的文章。

盡管不像瀏覽器版本，但我還是在這里看到了同樣的內容，Flipboard 版本的這篇文章明顯要復雜。它不像瀏覽器版本那樣，幾乎是瞬間加載，為什么在網絡上能那么快速顯示的原因呢：

瀏覽器的版本是從25個域名使用了200+的HTTP請求， 而Flipboard版本只從2個域名那兒使用4個HTTP請求：cdn.flipboard.com 和 ad.flipboard.com。

作為一家公司，Flipboard 是成功的，在 2014 年有一千萬以上的活躍讀者，還有接近百萬美元的估值，這清晰地說明閱讀移動設備上的文本已經超過在瀏覽器上閱讀文本。Flipboard 的成功是引人注目的，并且它的商業模式已經或多或少被其他公司所復制。

Flipboard 的競爭對手

今年五月份Facebook上線了Instant Articles服務，他們是這樣介紹它他們的服務的：

“越來越多的人開始在手機上看新聞了，我們希望Facebook對此有更快更豐富的體驗。人們在Facebook上共享大量的文章，尤其是在Facebook的手機應用上。到目前為止，這些文章平均需要8秒的時間來加載，遠遠慢于Facebook上單一內容類型文章的加載速度。Instant Articles的閱讀體驗比閱讀普通手機web上的文章體驗好上10倍。”

是不是聽起來特別像Flipboard ?如果你是一個出版商并且你打算讓Facebook來管理你發布的內容。做為回報，會讓你的讀者有更棒更快的閱讀體驗，同時還可能分享到一些分類廣告的收益。

讓我們看一看在實際操作中是什么樣的。BuzzFeed 參加了 Instant Article 計劃，他們最近發表了一篇名為13 steps to instantly improve your day的文章。 就跟你心里想的一樣，移動 web 版本的文章也加載了一大堆垃圾，還有 iOS App 插件、社交按鈕、廣告、還有別的。

就像我們早先看到的 CNN 文章一樣，BuzzFeed 的網站也加載了一大堆廣告腳本、跟蹤腳本和蕾絲的東西。最終整個頁面發出了200多個 HTTP 請求，下載了差不多 4MB 的數據：

讓我們與 Facebook 的 Instant Articles 做一個比較：

與之前的 Flipboard 例子比起來，盡管內容很相似，但這個 BuzzFeed 文章還是同樣的繁雜異常。它同樣加載得很快，而且在我的測試下，它僅僅發出了5個網絡請求（Facebook 同樣應用了幾個預加載算法，并且在你點擊之前就加載完畢了，這樣確實讓你感覺是『馬上』完成的）

現在引發了許多關于這是不是出版商的良好商業模式的爭論，這個爭論確實是目前大家討論的焦點。不過確實很難否認 Flipboard 和 Instant Articles 在移動設備上提供了非常優雅的閱讀體驗，這也正是之前移動瀏覽器急于解決的問題。

Flipboard 和 Facebook 并不是這場游戲的唯一玩家，科技界的最大玩家，也就是 Apple 公司，已經宣布進入這一領域——新發布的Apple News使用了在本質上和 Flipboard 和 Instant Article 一樣的商業模型。

這是 Web 的終點嗎？

不。重要的是一定要記住，不管 Flipboard，Facebook 和 Apple 提供了多么好的用戶體驗，它們依然是獨立公司提供的私有服務。這些公司可以控制內容如何被消費、也可以控制用戶去訪問內容。Apple 公司完全可以做到控制蘋果設備訪問什么內容。

再加上這些公司都要求與內容提供商的某種程度上的合作關系，也就是說這些 App 只提供了它們生態系統上的內容，也就是說這些 App 的內容只覆蓋了整個 Web 內容的一小部分。由于在 Web 上出版和分享非常容易，這給 Web 提供了戰勝這些 App 的巨大優勢。

話雖如此，但相比 Flipboard 和 Facebook 的 Instant Articles 在其本地 APP 中提供的服務，很難說瀏覽器閱讀體驗更好。John Gruber 在一篇回應 Facebook 的 Instant Article 的文章中的論述也許是說得最好的：

“我被對速度的強調吸引了。不僅僅是因為本地的移動代碼在 APP 開發中獲勝，更因為有了像Instant Articles 一樣的軟件，本地正在將以瀏覽器為基礎的網絡變得像一個遺跡，即使這個網絡只是為了發布文章。如果我是對的，我在 Daring Fireball 中寫的絕大多數文本（overwhelmingly-text）都可能會引發一個問題。Daring Fireball 的頁面加載速度快，但這些頁面我并不需要經常去連接它們。我擔心這會繼承 web 速度慢的問題，對過量產生網頁的這種考慮不周的設計趨勢，將會開始對 DF 的流量造成危害。”

需要采取什么措施嗎？

一些發展應該會對當前 Web 的發展現狀有所幫助。

HTTP/2

最近出版的 HTTP/2 規范提供以基本上減少通過單一的 TCP 連接，供應壓縮的 HTTP 標頭，和資源加載并聯在網絡上的延遲。一旦在瀏覽器中實現，HTTP/2 顯著降低依賴于大量的 HTTP 請求，如本文中所示的那些部位的加載時間。

最近出版的 HTTP/2 規范提供了一個從實質上減少網絡服務延遲的方法 - 壓縮 HTTP 頭，并使用單個 TCP 連接實現并行加載資源。一旦 HTTP/2 在瀏覽器中得以實現，它將會顯著降低那些依賴大量 HTTP 請求的網站的加載次數，例如本文前面部分已經展示的一些情況。

移動友好

去年，谷歌宣布他們將會在搜索結果中懲罰那些移動不友好的站點，并會在那些滿足他們搜索指南中要求的站點旁邊添加“移動友好”字樣。

這是一個小調整，卻可以刺激那些站點內容的開發者和發布者們（這些人的工作與搜索引擎的流量的關聯性非常高），將他們厭惡的內容控制在最低限度。早期的研究表明，這個做法看上去對搜索結果有著顯著的影響。

代理瀏覽器

Opera Mini 長久以來一直成功地飾演著代理瀏覽器的角色，它通過在自己的服務器上緩存資源來減少要發送給每一臺單個設備的數據量。安卓下的 Chrome 和 iOS 現在包含了一個相似的選項，盡管它們默認情況下都是關閉的，在用戶需要提升自己網絡速度時仍這個選項不失為一個選擇。

廣告攔截器

桌面設備上，許多廣告攔截器是攻擊網絡的主要工具，但是他們還沒有進入用戶的移動手機，很大程度上市因為手機系統供應商很積極的預防它們。

Google 有一個很好的理由去阻止廣告攔截器，因為他們80%-90%的收入來自在線廣告。新聞說 Google早在 2013 年之前廣告攔截器從 Google play 中刪除了。

從歷史上看，蘋果也阻止過廣告攔截器，但是即將改變。蘋果最近發表新聞，他們將要在 IOS 9 上的Safari 瀏覽器中開放廣告攔截器 API。不管這個是否是對 Google 的攻擊，還是一種對 Safari 用戶的友好姿態，最終都是減少 IOS 用戶繁瑣的去選擇廣告攔截器應用。

將來

盡管有種種的缺陷，我仍然認為在瀏覽器領域是成熟的創新。為什么文章的出版商真正的盈利是植入龐大的廣告而給每個人產生了很糟糕的體驗？

我沒有答案，比我更聰明的人花費了很多年的時間去解決這個問題。不過，似乎這是最好的，我們可以做的瘋狂事情。我仍然認為在開放的網絡中，它不會很快的遍布任何地方，但是我們真的需要開始思考怎么去清理這個爛攤子。