借助性能優化促進用戶數增長

2015年上半年，Pinterest的工程師進行了一次實驗，借此將移動Web首頁的頁面加載性能提升了60%，同時移動注冊轉化率提升了40%。然而該實驗使用了一種極為煩瑣的解決方案，用到了大量“抄近道”的方法，例如提供預先生成的HTML頁面，而沒有使用內部模版渲染引擎或其他通用資源（JS、CSS）。為了將實驗學到的經驗實用化，整個前端引擎、所有頁面模版，以及通用元素都必須重寫。這是一項繁重的工作，為此我們首先需要構建一個強壯的指標，對整個系統各方面的實現進度進行追蹤。本文中我們將介紹提高Pinterest頁面性能的具體方法，以及這種方法如何在2016年幫助我們實現了用戶數量的最大化增長。

衡量

首先我們希望明確定義并實現我們希望改進的指標。2015年的實驗中使用的指標只是從整體上衡量頁面加載時間（PLT），這是指自從用戶輸入URL或點擊一個URL后，整個頁面渲染完成所需的時間。在 瀏覽器導航時限API 方面，navigationStart和domComplete事件之間是存在時間差的：

• navigationStart事件是由用戶點擊鏈接或在瀏覽器導航欄輸入URL并按下回車后發起的。
• domComplete事件是指頁面上所有元素的處理工作均已完成，所有資源（例如圖片、CSS、JS）均已完成下載。此時用戶將不再看到瀏覽器標簽頁上旋轉的圖標，而頁面上需要顯示的其他新的內容（例如onLoad javascript）將在此時開始執行。

(點擊放大圖像)

Copyright ? 17 December 2012 World Wide Web Consortium , (MIT, ERCIM, Keio, Beihang)

這個指標是個很好的起點，然而有一個重大的不足：無法反映出真實性能。這一點對用戶很重要，因為頁面上可見部分的加載速度要遠遠快于整個頁面的加載速度。

用戶察覺到的等待時間

為了解決這個問題，我們引入了另一個指標：用戶察覺到的等待時間（UPWT），這是指從用戶輸入URL或點擊URL后，頁面上對用戶可見的部分渲染完成所需的時間。這是一種基于圖片加載事件的自定義指標。我們會追蹤屏幕上包含的圖片，以及這些圖片完成加載的時間。UPWT始于navigationStart事件，終于domLoading和domComplete事件之間的某一刻：

• domLoading事件是指瀏覽器接收到整個文檔并開始渲染的時候。

(點擊放大圖像)

Copyright ? 17 December 2012 World Wide Web Consortium , (MIT, ERCIM, Keio, Beihang)

作為一種額外的收益，還可以為移動應用程序引入類似的指標，并用相同的方式進行衡量。

我們將這兩個指標（整體PLT和UPWT）以及其他一些性能指標（例如服務器端性能，以及更詳細的瀏覽器端性能）結合在一起，包含在公司最重要的儀表板和我們的實驗框架中。借此可以追蹤進度并快速了解哪些改進可以實現最大的收獲。

經驗：創建追蹤進度所需的正確指標，優先側重于可以獲得最大改進的指標。

優化

可優化的領域分為三個主要類別：前端、網絡，以及后端。

前端

頁面重量（CSS/JS/Images/HTML）

通過查看匯總后的測試結果，我們很快意識到頁面加載需要極大的帶寬。對于某些網絡基礎設施老舊的國際市場，這個問題尤為嚴重。為此我們對需要加載的內容進行了更細致的劃分。以前我們通常會直接獲取整個站點所需的CSS和JS，現在，我們只獲取渲染屏幕上內容所必需的CSS和JS，并在初始渲染完成后再延遲加載其他資源。此外我們還研究了所請求的圖片，并研究了這些圖片是否都是必須的，以及能否請求尺寸經過了優化的圖片。這兩項措施配合使用后，展示一個頁面所需下載的數據量減少了60%。

渲染（React）

在關注性能的同時，我們還將 網站端 從自行開發的框架遷移到 React 。我們團隊是Pinterest內部較早采用React的，這個渲染模型還讓我們進一步大幅改善了性能。通過使用React框架我們獲得了大量收益，從一種不受控制，任何東西都可以修改DOM的模式，轉變為React的影子DOM批量更新模式。

提前進行Flush/chunked傳輸編碼

為了優化客戶端和服務器之間的路徑，我們調查了服務器端的頁面渲染方式。借此可消除不必要的緩沖，確保瀏覽器可以提前收到頁面的部分，并立刻開始在獲取數據的同時，并行獲取框架級的JS和CSS資源以及進行服務器端的渲染。在渲染完成后，我們已經開始使用Chunked傳輸編碼方式發送頁面內容，但在仔細檢查過渲染頁面的服務以及最終用戶之間的基礎架構后，我們發現其中有好幾個步驟對響應進行了緩沖，而非直接流式傳輸。取消緩沖后數據可以更快速到達瀏覽器，同時頁面加載時間進一步獲得了改進。

傳輸

CDN/DSA

我們還對傳輸基礎架構進行了大量改進。我們在CDN中設置了多層緩存，啟用了IPv6，切換至CDN的更高服務層，同時在全球范圍內引入了SSL邊緣終結（DSA）。

后端

盡可能并行處理

頁面的渲染通常需要從不同來源請求大量數據。對我們來說，則是需要進行多次API調用。這些調用之間存在一種很自然的數據依賴性圖表，借此可以知道哪些調用可以并行處理，哪些因為數據之間的依賴性必須按順序處理。我們開始考慮使用GraphQL，該技術可以自動優化數據的并行獲取。與此同時，我們還對當前使用的調用圖表進行細致的審查，以確保所有對順序無要求的調用都已并行處理。

只返回需要的內容

我們還對所請求的數據進行了修剪，只返回界面所必須的數據。這樣不僅可以降低網絡負擔，而且避免了服務器端不必要的數據獲取操作，因為額外的內容通常需要對后端服務進行額外的調用。

盡可能緩存一切

我們還花了一些時間將使用數據“邊緣”緩存的頁面類型擴展到低基數（Cardinality）頁面（例如頁面數量約為幾百上千，而非數十億的頁面）。緩存方面還有待進一步完善，從考慮到頁面數量太多，為了顧及緩存的效率而只緩存頁面的“頭部”數據到觸發緩存在后臺自動刷新等，還有很多方面有待改善。

通過改善性能實現用戶數量的最大化增長

在為了改善性能而重寫頁面的時候，絕對不能考慮嘗試新的設計。如果用其他更快速的頁面設計和最初的頁面進行比較，就無法知道轉化率的變化到底是來自性能的改進還是設計方面的改進。我們需要構建完全相同的頁面來對比。此外為了充分理解對網頁性能的影響，整個實驗在設置上應該能衡量不同類型頁面的指標，以及分別衡量Web和移動Web的指標。隨著性能的改善，不同頁面會實現不同的轉化率和流量收益。對我們來說，將所有頁面匯總在一起查看整體轉化率是不夠的，我們希望能分別查看不同的轉化率，隨后發現桌面端Web轉化率增加了很多，但同時移動Web轉化率實際降低了，平均值其實是降低的。我們進一步研究了為什么移動Web轉化率降低，并發現在功能方面存在一些問題。

為了讓整體頁面改進幅度最大化，還需要非常注意，就算與轉化率有關的微不足道的功能也需要重新實現。我們最初的頁面包含大量此類功能，隨著不斷地發現并解決問題，我們的轉化率開始持續增長。這里學到的最重要的經驗是，按照頁面類型以及Web／移動Web對頁面進行劃分，借此更好地理解收益到底來自何處，并更清楚地發現不同劃分中可能存在的問題。如果作為整體查看匯總后的轉化率變化，這些問題可能會被遮掩起來。

有關轉化率的功能清單

• 完全相同的向上銷售（Upsell）機制
• 導航機制（彈出菜單？新標簽？）
• 注冊和表單機制（字段驗證信息、相同的字段和步驟）
• 自動身份驗證功能
• 移動Web和平板App的App向上銷售
• 移動Web深度鏈接（Deeplinking）

性能重寫過程中另一個重要的事情是對每個頁面類型進行SEO實驗。若想了解有關SEO實驗基本功的詳細信息，請查閱我們以前發布的博客文章 通過實驗認識SEO 。SEO實驗可以告訴我們頁面加載時間的改進是否真的能從搜索引擎帶來更多流量，在我們的實驗中，結論是肯定的。如果你的頁面流量很大，也許可以通過實現各類功能改善搜索引擎的評級。SEO實驗還可以告訴我們某些功能的實現是否存在問題。就算一些很小的細節，例如圖片尺寸或所用的HTML標簽也會對此產生影響，因此一定要對所有頁面類型進行必要的監視。我們用了幾周時間找出并修復了這些問題，SEO流量有了很大提升。

有關SEO的功能清單

• 重要的標簽（例如、hreflang、rel=canonical）
• 完全相同的圖片尺寸
• 描述性文字
• 首次頁面加載的內容數量

重要經驗

• 盡可能構建完全相同的頁面，不要重新設計頁面
• 針對不同類型頁面分別進行實驗，并區分對待Web和移動Web
• 同時別忘進行SEO實驗
• 針對劃分的不同類型查看是否缺少某些功能，導致降低轉化率或SEO效果

修復一個微小的轉化率功能讓轉化率指標有了大幅提升

結果和未來計劃

為了改善性能而重建頁面的做法讓我們用戶的等待時間縮短了40%，SEO流量增加了15%，注冊轉化率增加了15%。由于流量和轉化率之間存在倍增關系，因此對我們來說，在Web和應用注冊方面這是一個不菲的成績。這是我們在2016年贏得用戶過程中獲得的最大成果。此外我們網速慢的用戶也能獲得更好的體驗。多虧了這個項目，我們的團隊現在可以更自信地通過改善性能實現更大程度的用戶數增長。

 

 

來自：http://www.infoq.com/cn/articles/driving-user-growth-with-performance-improvements