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

衡量

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

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

(點擊放大圖像)

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

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

用戶察覺到的等待時間

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

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

(點擊放大圖像)

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

作為一種額外的收益，還可以為移動應(yīng)用程序引入類似的指標(biāo)，并用相同的方式進(jìn)行衡量。

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

經(jīng)驗：創(chuàng)建追蹤進(jìn)度所需的正確指標(biāo)，優(yōu)先側(cè)重于可以獲得最大改進(jìn)的指標(biāo)。

優(yōu)化

可優(yōu)化的領(lǐng)域分為三個主要類別：前端、網(wǎng)絡(luò)，以及后端。

前端

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

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

渲染（React）

在關(guān)注性能的同時，我們還將 網(wǎng)站端 從自行開發(fā)的框架遷移到 React 。我們團(tuán)隊是Pinterest內(nèi)部較早采用React的，這個渲染模型還讓我們進(jìn)一步大幅改善了性能。通過使用React框架我們獲得了大量收益，從一種不受控制，任何東西都可以修改DOM的模式，轉(zhuǎn)變?yōu)镽eact的影子DOM批量更新模式。

提前進(jìn)行Flush/chunked傳輸編碼

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

傳輸

CDN/DSA

我們還對傳輸基礎(chǔ)架構(gòu)進(jìn)行了大量改進(jìn)。我們在CDN中設(shè)置了多層緩存，啟用了IPv6，切換至CDN的更高服務(wù)層，同時在全球范圍內(nèi)引入了SSL邊緣終結(jié)（DSA）。

后端

盡可能并行處理

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

只返回需要的內(nèi)容

我們還對所請求的數(shù)據(jù)進(jìn)行了修剪，只返回界面所必須的數(shù)據(jù)。這樣不僅可以降低網(wǎng)絡(luò)負(fù)擔(dān)，而且避免了服務(wù)器端不必要的數(shù)據(jù)獲取操作，因為額外的內(nèi)容通常需要對后端服務(wù)進(jìn)行額外的調(diào)用。

盡可能緩存一切

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

通過改善性能實現(xiàn)用戶數(shù)量的最大化增長

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

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

有關(guān)轉(zhuǎn)化率的功能清單

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

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

有關(guān)SEO的功能清單

• 重要的標(biāo)簽（例如、hreflang、rel=canonical）
• 完全相同的圖片尺寸
• 描述性文字
• 首次頁面加載的內(nèi)容數(shù)量

重要經(jīng)驗

• 盡可能構(gòu)建完全相同的頁面，不要重新設(shè)計頁面
• 針對不同類型頁面分別進(jìn)行實驗，并區(qū)分對待Web和移動Web
• 同時別忘進(jìn)行SEO實驗
• 針對劃分的不同類型查看是否缺少某些功能，導(dǎo)致降低轉(zhuǎn)化率或SEO效果

修復(fù)一個微小的轉(zhuǎn)化率功能讓轉(zhuǎn)化率指標(biāo)有了大幅提升

結(jié)果和未來計劃

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

 

 

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

 

標(biāo)簽： seo ssl 服務(wù)器 服務(wù)器端 搜索 搜索引擎 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。