摘要：現在有越來越多的人抱怨移動網絡的網速太慢。這是個永恒的話題，因為無論移動網絡網速多快也滿足不了日益增長的網速需求。在14.4K調制解調器下龜速上網的時代早已被人們遺忘，現在人們的要求是瞬間打開任何網頁。然而奇怪的是，現在人們抱怨的并不是網速，而是抱怨網絡本身。如果單說提高網速的話，可以通過提升網絡速度、降低網絡延遲、或者是直接提高瀏覽器的速度來解決。(谷歌AMP和百度MIP對SEO的影響)

但是抱怨網絡本身的話，恐怕只能把鍋甩給開創萬維網的人了吧。

網頁在數量上的擴張速度是非常驚人的。由HTTP Archive進行的調查研究結果顯示，在2012年1月，平均打開一個頁面所需加載的數據量為1239kB，共計86次請求；而到了2015年9月，數據量增長到了2,162kB，請求數增加到了103次。這些數字雖然并不直接與頁面加載和渲染所需的時間相掛鉤，但是卻是網頁所含信息量發生變化的一個重要指標。

而另一方面，隨著網絡的發展，本地移動應用也在更為迅猛地發展著。得益于移動設備性能的增強，應用的響應速度也越來越快。因此隨著時間的推移，應用程序的響應速度與移動網絡的加載速度之間的差距越來越顯著。至此，才引發了人們對于網速的抱怨。

這也就是為什么Facebook要開發交互式媒體內容創建工具Instant Articles，為什么蘋果開發新聞應用，為什么谷歌要開發Accelerated Mobile Pages（AMP）的原因所在。谷歌雖然慢了半拍，但是其開發AMP的目的與蘋果、Facebook是一致的，都像是想要使用戶瀏覽Web的體驗得到提升，使用戶感覺就像在使用本地應用程序一樣。

對于AMP而言，有兩個影響用戶體驗的關鍵點，那就是JavaScript和基于JavaScript的廣告。 AMP的優勢在于Google的強大服務器，劣勢則在于Google廣告。雖然聽起來比較可笑，但廣告的確是AMP的劣勢所在。因為谷歌擁有互聯網上最大的網絡廣告服務器。如果廣告是其中的問題根源，那Google為什么不直接從廣告的加載速度上解決問題呢？如果你想了解AMP，那么首先你需要了解Google新服務本身。

什么是AMP？

要了解AMP(Google AMP 是什么鬼？)，你還需要了解Facebook的Instant Articles。Instant Articles使用RSS和標準的HTML標簽來優化精簡所創建的項目。雖然Facebook會自動播放視頻或音頻片段來提供一些額外的內容，但Facebook聲稱Instant Articles的加載速度仍會比直接從開放網絡打開快10倍以上。快出來的這部分速度一些來自于優化精簡的內容，而另一些則可能得益于緩存。

但問題的關鍵是，Instant Articles只能查看與Facebook簽署過協議的網站內容。這意味著，從Facebook的Instant Articles上，只有在閱讀如美國國家地理（National Geographic），英國廣播公司（BBC），以及Buzzfeed等網站上的內容時才會比直接從網頁上看來的更快。蘋果的News的工作方式也大致相同，使用RSS標準，然后蘋果再對其中的內容加以優化。

所有這些應用程序都會對網絡中的內容加以削減優化。這就基本相當于變相改善了Web網頁日益臃腫的問題。

而AMP不同于Facebook的Instant Articles和蘋果的News的地方就在于，它并沒有用RSS或者HTML標準，而是使用了自己優化過的HTML標準。 AMP上的HTML看起來就跟原HTML一模一樣 ，一點也不花俏。事實上，如果你不去看頂部的AMP項目公告的話，你根本就不知道這個網頁已經被AMP優化過，看起來就跟Web上的對應的網頁一模一樣。

在AMP上用于標記使用的tag標簽非常有限，如表單標簽、音頻或視頻標簽、嵌入標簽、腳本標簽等全都沒有。只有在AMP的頂端會出現一個很短的HTML tag列表。遭受同樣命運的還有JavaScript，AMP中不會出現廣告和跟蹤腳本。但是，雖然禁了其他的跟蹤腳本，Google其實還是會跟蹤你的。

AMP自己也定義了一些標簽，像是amp-YouTube，amp-ad或是amp-pixel。這些tag標簽將有可能成為Web標準的一部分（也可能變成“ActiveX”的第二部分）。

AMP聽起來是一個非常棒的項目——更快的網頁加載，沒有任何跟蹤腳本，沒有任何JavaScript。不過，AMP上同樣也有一些設計上的缺陷。

AMP通過使用自定義組件amp-img重新設計了滾動圖并將原有的HTML內容替代，同理也用amp-audio替代了音樂內容，用amp-video替代了視頻內容。AMP的開發者認為這可以讓AMP只有在需要時才去調用這些加載項。然而，這卻造成了對Web瀏覽器自身的限制，而不是HTML本身。 AMP也很清楚這樣做所帶來的后果。你失去的不僅僅只是一些HTML標簽，還有基于CSS的動畫和滾動條。

不過好在AMP的開發者在聽取意見上做得非常好。在初期，一個關于AMP的代碼曾遭到了強烈反對——原因是這條代碼禁用了閱讀時的縮放功能。值得慶幸的是Google聽取了意見，消除了影響縮放的tag標簽。

AMP的標記語言只是其中的一部分。畢竟，如果AMP真正想做的事是去掉所有的Web增強功能，只呈現頁面的內容的話，它完全可以不必這么大費周章。提高加載速度對用戶來說是一個不錯的附帶好處，但從AMP的角度來看Facebook的Instant Article的話，看起來Facebook就像是把用戶鎖到了一個特定的網站、形式或者說服務中。

問題就在于廣告服務上(谷歌為什么要推出AMP計劃？)

Facebook開發Instant Article的目的是讓你在Facebook上就能看到其他網站上的內容，這個方向是非常正確。如果能夠在Facebook里享受到比在其他瀏覽器更加快的加載速度的話，用戶又何必再去用別的應用來看呢。

谷歌似乎是認識到了來自于Facebook的這種威脅——通過Instant Article，Facebook完全可以過濾掉Google的廣告服務。于是Google迅速動手開發了AMP項目，其目的實際上就是為了增強它在移動廣告服務領域的市場。至于為什么電腦用戶被拋棄掉了，那是因為谷歌已經掌握把廣告推送給你的能力了。

如果你看過AMP的演示視頻，那你就能知道它在明年將會如何集成到搜索結果中。AMP頁面在谷歌搜索頁的鋪設方式和在其他網頁中加載本地應用的方式是相通的。使得用戶能夠享受到非常快的響應速度。

為此Google需要把Web打造的和移動應用程序一樣快。而它也有信心能夠做到，因為Google有著世界頂尖的網絡工程師。Google也一直在鼓吹的移動網絡的優勢。但網頁的發展速度似乎總要比網速的增長更快，于是網速就相對上變得越來越慢了。

Google已經竭盡自己最大的努力來嘗試優化自家的瀏覽器，而Chrome也已經成為世界上最快的Web瀏覽器之一了。但是Google發現即使再優化也仍然是治標不治本。所以，在此基礎上再對Web進行深度優化也就變得順理成章了。

越來越多的用戶反映，過慢的加載速度已經成為了阻隔信息和用戶之間的一道壁壘。通常瀏覽器都會通過加載項控制來攔截不必要的內容，而這項功能雖然從出現到現在已經有十多年了，但一直被局限于桌面系統中。直到蘋果iOS 9的出現，才標志著終于把這一簡單的內容攔截工具移植到了移動系統中。

iOS的內容攔截以及News應用，再加上Facebook的Instant Article，你會突然發現——Google的廣告都不見了。而這才是Google真正關心的問題，也是開發AMP的核心意義。

靜態頁面需要Google的JavaScript

你可以在Web上建立的最基本的網頁就是一個包含一些基本的tag標簽的HTML文件。無論拿什么來加載這種網頁都會快如閃電。因為其中所含的信息量很少，而你所要做的只是套個模版，把信息放到網絡上而已。根本不需要JavaScript，甚至都不需要CSS。

AMP或多或少都希望你創建這種靜態頁面，不過AMP并不關心你的網頁實際上是靜態的還是那種可能需要從數據庫中調用的網頁，問題的關鍵是“什么呈現的是靜態的”。但隨后AMP就又要求每個頁面加載第三方腳本。直到這個腳本加載完畢前，AMP會故意將整個頁面的透明度設為0。只有這樣頁面才會被顯示出來。

這的確有點讓人摸不著頭腦，一名叫作Justin Avery的開發者寫道：“如果是這樣的話，那么很明顯直接加載這種頁面會來得更快啊。”

Pinboard.in的創作者Maciej Ceg owski就是這樣做的，他組建了一個演示頁面，復制了AMP為基礎的（并且AMP主頁上沒有的）JavaScript。通過3G連接，Ceg owski的頁面在1.9秒加載完畢，而AMP的網頁則需要9.2秒。JavaScript拖慢了頁面的加載時間，即使這個JavaScript本身也是Google計劃中加快Web部件的一部分。

諷刺的是，Google的本意是想鼓勵出版商對自己的頁面進行改良——將腳本內容壓縮，并合理利用緩存。但改良之后卻意味著網頁將會加載的更慢，也就是說網站如果真的照Google說的那么去做了的話，在AMP上可能反而會變得更慢了。

最終，對于出版商而言最好的做法仍然是進行常規的Web開發，而不依賴于從AMP獲得的資源。不幸的是，如今獨自建立網站的出版商現在是少之又少。大多數出版商有很多地方能夠獲得與AMP相當的加載速度。Google表示，AMP將能夠提高15％~85％的網頁加載速度。這么大的變動范圍很可能是根據網站上加載第三方腳本的多少而決定的。

對于JavaScript的依賴還會造成另一個不利影響。 AMP依賴于JavaScript，也就是說如果他們腳本由于某種原因無法加載，比如說你正在駛進了隧道之中的火車上，或是在信號比較微弱的地區來連接AMP的話，顯示的頁面將會是完全空白的。一旦AMP頁面失敗，將會導致整個頁面無法顯示。

Google自己心里很清楚，所以即使是它自己的Gmail中也仍然提供著基于HTML的備用版本。

為了出版商而開發的AMP

按照AMP的要求，各大媒體所必須要做的就是放棄自己的網絡廣告。還有交互式地圖，還有數據的可視化效果，以及評論系統。

用戶可以得到AMP精簡后的WordPress博客。WordPress在網絡上所有網站的覆蓋率高達24％，而且還有一個簡單的方法能夠迅速從WordPress來生成AMP文件，這對于AMP而言意義非常重大，將能夠極大的推動AMP的發展。這當然不是說去讓WordPress來建立，事實上如果這么做了的話其實會適得其反。因為WordPress插件往往對加載時間有很大的負面影響。我們經常能看到往往一個WordPress站點加載了多個外部的JavaScript庫，而這是由于用戶安裝了三個分別使用各自的庫的插件。AMP則能夠巧妙地通過優化這些部分而解決加載過慢的問題。

那么，為什么出版商希望使用AMP呢？因為它是Google的項目，而它的影響力已經滲透到各個行業，對流量有著強大的推動力。當谷歌決定發展某個項目，往往會牽動各大媒體的視線。

AMP不是想擺脫網絡，這我們都明白。它的初衷只是想要建立一個平行于Web的平臺。在這個系統下，出版商不會停止生成常規網頁，但他們通常也將在URL的末尾生成AMP文件（由早期采用者的例子來看）。 AMP的頁面和常規的Web網頁將通過標準的HTML標簽來實現相互轉換，用戶可以在兩者之間做出選擇。這也就是說，Google的網絡爬蟲可能會搶了AMP的頁面，但臺式機的Firefox也可能會把AMP頁面重新定向到常規網址上。

或許，多年后Web上將不會再有M標準的移動專用網站，而是amp標準的移動網站。而作為瀏覽者而言，我們希望的當然是看到干凈整潔，沒有其他亂七八糟的加載項的網頁。不要等待網頁緩慢的加載，只要一瞬間的清爽。

如今，我們基本都是在碎片化的時間中來獲取外界信息，獲取信息的方式也越來越多樣化。有些人喜歡在網上閱讀，有的通過Rss閱讀器來挑選自己喜歡的內容閱讀，有的人通過Facebook的Instant Article，有的通過在Twitter上的AMP網頁來閱讀，有的在自己的應用上閱讀。我們所希望的是，從一個單一的軟件上獲取到外界所有的信息，節省我們本來就不多的碎片時間。

AMP和開放的Web

雖然AMP可能會被強制設計為符合amp格式要求的頁面，但到目前為止，它似乎看起來比開放的Web或是Facebook的Instant Articles更加親民化。

如果往樂觀的方面想，作為Google一直在尋找的加快網絡加載速度的解決方案，其實AMP的前景是很美好的。正如Web開發人員（和AMP的樂天派一員）Jeremy Keith所說：“我希望這會是一種雙贏。在出版商通過創建AMP版本的網頁以安撫Google的同時，也許他們會開始問'為什么我們常規的網頁無法做到這樣快？ 這樣的疑問也會促使他們改善他們自己的Web網頁，從而一起進步。AMP項目將有可能成為推動整個Web前進的急先鋒。”

當然，AMP項目里的人也不都是那么樂觀的。開發者Tim Kadlec寫道：“AMP感覺并不像一些常規的瀏覽器那樣幫助加載網頁，而像是把自己所制定的精簡優化規范一點點拖到Web之中。Google通過用一個非常具體的工具來改善開放網絡。并向用戶展示他們自己定制后的頁面，吸引人們來使用AMP規范的網頁。”

AMP另一個重要的意義就是在于能夠幫助出版商加速他們的網頁：Google將會免費把他們的網頁緩存到Google自己的CDN中。“AMP就是緩存…如果符合規則，您將可以使用其中的緩存。” 在AMP項目中負責RSS的Dave Winer這樣寫道，“如果你不這樣做，你也可以使用自己的緩存，但這樣做將會嚴重影響到AMP的效果。”

這其實就是AMP最大的潛在問題。如果谷歌決定濫用其作為網絡的默認搜索服務提供商的權限，將AMP頁面設置為優先，那AMP將會對開放Web形成嚴重威脅。

到目前為止，谷歌已經表示，AMP的網頁不會在Web搜索結果頁面得到任何優先權。但是，這隨時可能會改變。Google為什么要自廢雙手呢？為什么Google在正式發布AMP后不去使用速度更快的網頁，而去將加載更慢的網頁優先呢？畢竟，加載速度現在已經成為了一個重要的衡量因素，AMP確實使網頁的速度變得更快了。

從長遠來看，很難說AMP將會以何種方式繼續發展壯大。Google經常會提出新項目。比如Gmail就對郵箱領域進行了再定義。其他項目也是一波接著一波。還記得Google Author嗎？這是Google為了幫助出版業而做的最后一次努力。

對于Web而言，我們希望Google能夠成功說服出版商使用AMP。在未來能夠真正幫助我們加快網頁加載速度。就像Ceg owski在他對AMP的評語上寫的那樣：“現在是2015年，網站應該主動提供只需更少資源，能夠快速加載的網頁給移動設備……對于移動設備而言，要求這些網站提供更加舒適的可讀版本是一個好主意。讓我們進一步提高加載速度，并使其成為唯一的移動網頁標準吧。”