Google+

摘要

Google+ 可以完全回應你的需求。

採取回應式

從殭屍貓到懷舊計算機，Google+ 就是人們志趣相投的好去處。直到最近，Google+ 有兩種不同版本的網站：一種是電腦版網站，另一種則是專為舊版瀏覽器設計的行動版網站。

挑戰

維護兩個網站也是一項獨特的挑戰。如果網站上有不同版本，就必須對每項功能執行兩次。進而產生大量重複的程式碼，而額外花費力為電腦版和行動版網站提供兩種體驗。隨著裝置之間的線條越來越模糊，電腦可支援具有更大的螢幕觸控操作的強大行動裝置，並針對電腦和行動裝置提供不同的設計，因此較不合常理。

我們推出新功能後，舊版電腦版網站的速度也變得緩慢且過於寬鬆。今年稍早，我們的首頁某個規模為 5 MB，並產生約 250 個 HTTP 要求。只是成效不佳。網站上的圖片數量過多且尚未最佳化， 導致網頁速度變慢。因此，即使網路連線速度緩慢且不穩定，使用者也幾乎無法觀看我們的串流，而這些使用者的使用體驗也大失所望。此外，由於支援行動版網站上的舊版瀏覽器，這讓我們無法在整個網站上依賴 JavaScript，也使得我們無法使用高度互動的功能。我們無法仰賴行動網路瀏覽器的進階功能。

解決方法

我們先從以回應式設計著手，一種是在行動裝置、平板電腦、桌上型電腦等裝置上都能順利運作的實作方式。我們徹底檢查了每項功能、網頁、JavaScript 程式庫和 CSS 類別我們希望建構一套系統，確保網站只會下載絕對必要的資料，除非使用者提出要求。難道是打造網站，能在搭載行動網路連線速度較慢的手機上正常運作，但在更快速的瀏覽器和大螢幕裝置上也能提供絕佳的沉浸式體驗。

這組限制意味著我們得逐一仔細審查日後的程式碼變更。為了達成這個目標，我們建立了 6^5 規則，確保在初次載入網頁時，我們未下載超過 60K 的 HTML、60K 的 JavaScript、60K 的 CSS，我們的動畫一律為 60fps，且平均延遲時間為 0.6 秒。

為此，我們選擇從一開始就建構模組化和延遲載入的 JavaScript 和 CSS 架構。因此，我們確保使用者實際使用需要的功能時，才會下載 JavaScript 和 CSS。這是透過範本驅動的方法，結合我們的建構和模組系統，讓開發人員幾乎無須投入任何心力。

隨著這個新架構，我們開始在網路上重新導入 Google+ 的原型。我們開始禁止「不良」的事物，並設定嚴格的開發規則。我們的主要規則之一，就是必須同時在伺服器端和用戶端轉譯所有頁面。透過伺服器端轉譯功能，我們可確保使用者能在 HTML 載入後立即開始讀取內容，而不需要執行 JavaScript 即可更新網頁內容。網頁載入且使用者點擊連結後，我們就不想執行完整的往返作業，再次轉譯所有內容。這時用戶端轉譯就變得十分重要，只需要擷取資料與範本，然後在用戶端算繪新頁面即可。這涉及很多的優缺點，因此我們採用了一個架構，讓伺服器端和用戶端可以輕鬆轉譯，而不需要在伺服器和用戶端上兩次實作所有元素。

其他規則則包括不允許使用高度和寬度動畫功能，該連結會導致瀏覽器改變版面配置，並對效能造成負面影響。對於 DOM 操作和動畫，我們排定的工作必須與瀏覽器的算繪重新整理頻率保持同步。我們也會將所有測量工作歸為一組，以免重複計算昂貴的樣式。此外，我們也倚重 Chrome 分析器工具，確保所有功能運作正常。此外，我們也建立了一些工具，用於計算程式碼變更對 JS-footprint 的影響，確保網頁大小不會大幅增加。

這項程序相當耗費時間，但如果我們在建構時無法找出並排除問題，將會更加困難。

我們已在 2015 年 2 月推出這個回應式實作的行動版網站版本。這使我們審查了新的設計和新程序。我們使用這次推出的資料，驗證哪些做法有效、哪些無效。我們進行了反覆測試，並著手擴充來支援更多裝置。我們在 2015 年 11 月針對所有裝置推出了這項新的實作方式。

成果

在不影響效能的情況下，Google+ 能夠建構具有豐富 UI 的複雜網頁應用程式。現今的網站速度更快，也變得更為精簡。

	使用前	使用後
首頁總權重，使用 gzip (含圖片)	22,600 KB	327 KB
要求數量	251	45
HTML (非 gzip 格式)	1,100 KB	362 KB
JavaScript 與 CSS (gzip 壓縮)	2,768 KB	111KB
平均完整頁面載入時間 (延遲)	12 秒 到第一個位元組 0.7 秒	每 3 秒 從 0.1 秒到第一個位元組