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

— getify (@getify)

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

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

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

復(fù)雜性實(shí)例

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

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

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

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

為什么越來越繁雜？

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

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

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

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

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

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

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

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

你可能會(huì)說部分原因在于工具，因?yàn)槭褂貌迦胧綇V告，社交媒體窗口，以及諸如此類的東西，會(huì)產(chǎn)生相比手工制造的內(nèi)容更多的 HTTP 請(qǐng)求。不過我相信答案必然跟錢有關(guān)。

跟著錢走

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

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

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

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

在做什么?

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

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

但更有趣的是 Flipboard 不只有內(nèi)容預(yù)覽這個(gè)功能，它現(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個(gè)域名使用了200+的HTTP請(qǐng)求， 而Flipboard版本只從2個(gè)域名那兒使用4個(gè)HTTP請(qǐng)求：cdn.flipboard.com 和 ad.flipboard.com。

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

Flipboard 的競(jìng)爭(zhēng)對(duì)手

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

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

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

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

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

讓我們與 Facebook 的 Instant Articles 做一個(gè)比較：

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

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

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

這是 Web 的終點(diǎn)嗎？

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

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

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

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

需要采取什么措施嗎？

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

HTTP/2

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

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

移動(dòng)友好

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

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

代理瀏覽器

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

廣告攔截器

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

Google 有一個(gè)很好的理由去阻止廣告攔截器，因?yàn)樗麄?0%-90%的收入來自在線廣告。新聞?wù)f Google早在 2013 年之前廣告攔截器從 Google play 中刪除了。

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

將來

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

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