揭密 Google 秒開技術:如何讓網站瞬間下載完畢?

作者 | 發布日期 2015 年 11 月 09 日 9:30 | 分類 Google , 手機 , 網路 follow us in feedly

現在有越來越多的人抱怨行動網路的網速太慢。這是個永恆的話題,因為無論行動網路網速多快,也滿足不了日益增長的網速需求。在 14.4k 數據機下龜速上網的時代早已被人們遺忘,現在人們的要求的是瞬間打開任何網頁。



然而奇怪的是,現在人們抱怨的並不是網速,而是抱怨網路本身。如果單說提高網速的話,可以透過提升網路速度、降低網路延遲、或是直接提高瀏覽器的速度來解決。但是抱怨網路本身的話,恐怕只能把黑鍋丟給開創網際網路的人背了吧。

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

而另一方面,隨著網路的發展,本地行動應用也在更為迅猛地發展著。得益於行動裝置性能的增強,應用的反應速度也越來越快。因此隨著時間的推移,應用程式的反應速度與行動網路的下載速度之間的差距越來越顯著。至此,才引發了人們對於網速的抱怨。

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

AMP_leiphone1106

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

 

什麼是 AMP?

要了解 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 上的對應的網頁一模一樣。

Instant Articles_leiphone1106

在 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 就像是把用戶鎖到了一個特定的網站、形式或者說服務中。

 

問題就在於廣告服務上

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

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

如果你看過 AMP 的展示影片,那你就能知道它在明年將會如何整合到搜尋結果中。AMP 頁面在 Google 搜尋頁的鋪設方式和在其他網頁中下載本機應用程式的方式是相通的。使得用戶能夠享受到非常快的反應速度。

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

Google Web_leiphone1106

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 的專案,而它的影響力已經滲透到各個行業,對流量有著強大的推動力。當 Google 決定發展某個專案,往往會牽動各大媒體的視線。

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

Instant Everywhere_leiphone1106

或許,多年後 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 最大的潛在問題。如果 Google 決定濫用其做為網路的預設搜尋服務提供商的權限,將 AMP 頁面設置為優先,那 AMP 將會對開放 Web 形成嚴重威脅。

Google_leiphone1106

到目前為止,Google 已經表示,AMP 的網頁不會在 Web 搜尋結果頁面得到任何優先權。但是,這隨時可能會改變。Google為什麼要自廢武功呢?為什 麼 Google 在正式發表 AMP 後不去使用速度更快的網頁,而去將下載更慢的網頁優先呢?畢竟,下載速度現在已經成為了一個重要的衡量因素,AMP 確實使網頁的速度變得更快了。

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

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

(本文由 雷鋒網 授權轉載) 

發表迴響