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

— getify (@getify)

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

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

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

復(fù)雜性實例

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

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

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

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

為什么越來越繁雜？

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

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

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

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

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

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

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

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

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

跟著錢走

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

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

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

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

在做什么?

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

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

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

盡管不像瀏覽器版本，但我還是在這里看到了同樣的內(nèi)容，F(xiàn)lipboard 版本的這篇文章明顯要復(fù)雜。它不像瀏覽器版本那樣，幾乎是瞬間加載，為什么在網(wǎng)絡(luò)上能那么快速顯示的原因呢：

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

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

Flipboard 的競爭對手

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

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

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

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

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

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

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

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

Flipboard 和 Facebook 并不是這場游戲的唯一玩家，科技界的最大玩家，也就是 Apple 公司，已經(jīng)宣布進(jìn)入這一領(lǐng)域——新發(fā)布的Apple News使用了在本質(zhì)上和 Flipboard 和 Instant Article 一樣的商業(yè)模型。

這是 Web 的終點嗎？

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

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

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

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

需要采取什么措施嗎？

一些發(fā)展應(yīng)該會對當(dāng)前 Web 的發(fā)展現(xiàn)狀有所幫助。

HTTP/2

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

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

移動友好

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

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

代理瀏覽器

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

廣告攔截器

桌面設(shè)備上，許多廣告攔截器是攻擊網(wǎng)絡(luò)的主要工具，但是他們還沒有進(jìn)入用戶的移動手機(jī)，很大程度上市因為手機(jī)系統(tǒng)供應(yīng)商很積極的預(yù)防它們。

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

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

將來

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

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