導讀：商業落地頁除了內容展現外，還承載了服務營銷能力以及客服-用戶聯通等能力，落地頁的加載性能密切關係到用戶體驗、客戶轉化。開展性能優化工做必然離不開數據，咱們從數據開始，分析落地頁加載性能對用戶體驗的影響狀況，同時建設整個大商業的落地頁性能指標，拆解關鍵加載路徑，用數據指導優化方向，再介紹商業端到端性能優化的主要技術手段。css
全文2842字，預計閱讀時間6分鐘。html
1、落地頁加載性能的重要性
移動落地頁加載速度是影響用戶搜索體驗的重要因素，直接影響到商業的轉化能力。用戶點擊搜索結果後進入移動頁面，不滑動屏幕即看到的全部內容，稱爲首屏，首屏加載時間對用戶體驗和轉化的影響尤其明顯。前端
「百度移動搜索落地頁體驗白皮書」持續關注頁面首屏對用戶行爲特徵的影響。白皮書4.0研究發現，頁面首屏的加載時間在「1.5秒」之內的網站，會帶給用戶流暢快捷的極速體驗。白皮書將這一體驗問題在5.0中又進一步更新爲，頁面首屏的加載時間在「1秒」之內的站點或小程序，用戶的留存率會越高，更符合用戶對快捷搜索體驗的期待。web
同時，統計商業側的用戶轉化數據顯示，隨着廣告落地頁首屏首圖加載時長變慢，表單提交、電話撥打、諮詢客服會話等商業轉化能力有所降低。加載速度在1秒先後呈現出較爲明顯不一樣的降幅程度：算法
-
接近1秒前，轉化率降低幅度約在5%；小程序
-
超過1秒後，轉化數據存在4%的降低幅度，並在1.3秒左右出現較爲明顯的拐點。後端
2、商業落地頁性能衡量和關鍵路徑拆解
商業廣告從流量類型上，主要區分爲搜索廣告、品牌廣告、原生信息流廣告、APP開屏廣告，各流量下又有不一樣的細分廣告位，及展現各異的廣告樣式。點擊廣告進入的商業落地頁，從建站渠道上，區分爲託管和非託管落地頁：使用基木魚製做的託管落地頁，廣告主搭建的第三方落地頁，建站形式各異。瀏覽器
爲了衡量完整的端到端的落地頁加載時長，並覆蓋以上全部商業流量、頁面類型，商業側和手百端合做，經過手百APP內核採集從廣告點擊到頁面的上屏時間（渲染的頁面內容高度大於等於屏幕高度）。緩存
從廣告點擊到頁面加載完，主要經歷容器初始化、頁面跳轉、頁面資源加載、頁面繪製幾個環節。對手百端到端耗時埋點數據進行拆解，統計各階段耗時佔比。數據狀況如圖所示。性能優化
△各階段耗時佔比
對於不一樣的廣告渠道，耗時存在誤差，較突出的是APP開屏廣告，受APP啓動時資源緊張影響，容器初始化耗時較長。
3、核心優化手段
結合移動用戶體驗研究和速度對商業轉化影響的調研，啓動了整個大商業落地頁加載速度優化專項，針對性能耗時的關鍵路徑，及各廣告渠道/落地頁的特徵，進行定向優化，來打造良好用戶體驗，提高落地頁轉化能力。
主要的優化思路仍是想辦法解決並行遇到的各類問題來實現任務串行改並行，能提早的事情儘可能提早作，能在服務端實現的不推遲到客戶端作。
1.容器初始化優化
前期各業務開發過程當中，快速迭代上線，堆功能，只考慮自身業務最優解，未充分考慮對總體的影響，埋下不少性能債。容器初始化耗時優化，主要針對APP開屏廣告，進行資源競爭優化：
-
拆解大任務爲小任務，並行初始化，加快關鍵邏輯的執行速度。
-
對於耗時長、優先級低的任務後置，下降沒必要要的資源競爭。
-
在其餘任務執行完成以後，廣告點擊以前，對於容器進行提早預建立，提早準備好容器。
2.計費優化
以前用戶點擊一個廣告須要先通過計費，計費完成後纔開始加載落地頁，徹底串行執行。而廣告計費請求在創建網絡鏈接、服務端進行業務處理時都會消耗時間，且因爲客觀條件的不肯定性，偶現計費耗時長、用戶看到白屏時間久、影響加載落地頁晚的狀況，很傷用戶體驗。
針對這個狀況，咱們開始探索並行化計費，計費請求和落地頁加載同時發起，並行執行。並行計費也是後面能作端預渲染的一個依賴條件。
這個過程當中須要爲落地頁補充Referer等，來保證落地頁原有的處理邏輯不受影響。
3.資源加載優化
落地頁中的靜態資源，主要包括html主文檔、js、css，以及落地頁中所含圖片等。這些資源的加載，與用戶的網絡環境、資源大小、服務器響應情況均相關，直接影響了落地頁的渲染速度。
爲了可以在加載落地頁時下降影響因素，咱們對廣告落地頁進行了資源預加載。在廣告展示階段，適當的加載落地頁關鍵資源，並利用瀏覽器緩存，實如今廣告點擊時無需與服務端交互，從而縮短用戶感知到的落地頁上屏耗時。
在拉取資源時，也要注意處理header等參數，保證商業邏輯不受影響。對於第三方落地頁，資源預加載會須要服務器扛住更多的流量，而且可能對商業統計邏輯產生影響。當前優先在商業託管落地頁流量上實施此方案。
4.頁面繪製優化
基木魚託管落地頁，在複雜的營銷訴求下，業務迭代快，JS業務邏輯複雜，頁面繪製時間較普通靜態頁面要更長。託管側結合自身能力及端能力，進行了服務端預渲染、端預渲染的優化。
4.1服務端預渲染
基木魚頁面嚴重依賴JS執行才能將頁面繪製出來，服務端預渲染提早想辦法將頁面的dom和style取出，寫入頁面源碼中，並控制先顯示這層預渲染內容，在這層內容之下JS按原來邏輯繪製頁面，待底層頁面繪製完成後再移除預渲染的內容。
服務端預渲染將頁面由動態變靜態後面臨更新問題：JS邏輯更新，DOM節點和樣式須要同步變化。在廣告落地頁複雜的業務場景下，一方面廣告託管落地頁的業務升級頻率很高，業務升級單週發佈；另外一方面，廣告託管落地頁建立量很大，頁面數量級過千萬。而服務端預渲染的原理須要使用無頭瀏覽器打開頁面，速度受限，每次升級JS後更新上千萬的頁面，存在很大挑戰。所以，這裏針對熱點頁面進行服務端預渲染，來兼顧除長尾以外的頁面加載性能，和較爲頻繁的更新訴求。同時，在服務端預渲染以後，建設頁面的自動化測試，對比服務端預渲染出來的頁面和原來頁面的一致性。
最終，來保證在用戶拉取服務端預渲染的主文檔後，就能儘早看到首屏內容，提升用戶體驗。
4.2端預渲染
想要實現頁面更快的加載體驗，點擊廣告時可以秒開，聯合端上嘗試了端預渲染的方案：在廣告展示時，建立隱藏的webview提早加載頁面，阻塞視頻播放、頁面打點等操做，廣告點擊後，展示並激活頁面。並在退出頁面時，將頁面切到後臺，若二次點擊相同廣告，再次直接切出頁面作展現。
端預渲染方案下，落地頁的加載體驗最佳，也要考慮長尾低端機的承受能力，評估機器卡頓狀況決定可進行端預渲染的設備。與此同時，伴隨的研發、迴歸測試成本也較高。安卓、iOS雙端、落地頁及其關聯sdk，在廣告展示階段、點擊階段、切後臺階段，均需定製化預渲染的邏輯。
4、總結
端到端的落地頁加載速度影響因素衆多，以上優化手段的收益都較爲明顯，可是均屬於橫向優化，覆蓋全部產品線，須要兼容已有的商業業務邏輯，成本和週期均較高，尤爲服務端預渲染、端預渲染的落地成本最高。後續還會深刻落地頁內部邏輯展開優化，並建設持續保障性能水平的例行機制。
本期做者 | 袁瑞金，百度商業平臺研發部-資深研發工程師 目前主要負責商業落地頁的性能優化，專一提高端到端的落地頁極速加載。
招聘信息
百度商業平臺研發部主要負責百度商業產品的平臺建設，包括廣告投放、落地頁託管、全域數據洞察等核心業務方向，致力於用平臺化的技術服務讓客戶及生態夥伴持續成長，成爲客戶最爲依賴的商業服務平臺。
不管你是後端，前端，仍是算法，這裏有若干職位在等你，歡迎投遞簡歷，【聯繫方式同名公衆號百度Geek說，輸入內推便可】，百度商業平臺研發部期待你的入！
閱讀原文
推薦閱讀
---------- END ----------
百度Geek說
百度官方技術公衆號上線啦！
技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘信息 · 內推信息 · 技術書籍 · 百度周邊
歡迎各位同窗關注