業内已經有豐富的資料證明快速的網頁浏覽及操作體驗對轉化率等業務名額有明顯的促進作用：
A. Google found out that slowing search results by just 4/10ths of a second would
reduce the number of searches by 8,000,000 per day.
B. You have 5 seconds to engage a customer before they leave your web site.
C. For every 1 second speed improvement to the Amazon website conversions increased +2%
....
AE有面向全世界的使用者，這些使用者處在參差不齊的網絡環境中，且由于跨洲際通路機房的天然的實體距離也會使得AE的使用者性能體驗無法與淘寶這樣内貿網站相提并論。在這種情況下，一方面由于AE性能優化空間更大，對轉化率提升的空間也更大；另一這方面由于使用者環境的千差萬别，以及天然距離，使得AE性能優化的投入成本也會非常距大，比如AE可能需要建立區域機房就近服務于使用者才能解決性能問題。
如何精确量化性能回報（即量化性能優化帶來的轉化率提升最終帶來GMV的提升），進而精确計算投入産出比，是AE性能優化工作的前提。業内雖然有較多資料證明性能與轉化的關系，但在精确衡量投入産出時，每個網站都是不同的無可比性，且很多資料結果由于資料不足夠充分也隻能定性不能定量。
基于阿裡巴巴ODPS的大資料處理能力的優勢，AE性能優化小組@桑植、@跑者、@阿四、@子偉、@馮嘉、@濤明、@震羽、@驗鈔提出并實作了大資料時代的度量方法，通過采集真實使用者通路AE網站的性能Latency資料，以及真實的轉化率資料，實作最精确的性能轉化度量。
目前這一度量還在内部測試調優過程，且已經在内部性能優化中使用，待穩定成熟後，希望能夠貢獻出來，讓集團内部的使用者使用起來。
1）通過大資料的采集、計算、分析，驗證性能與轉化率等業務名額的關系
2）通過大資料的方法，量化性能對轉化率的影響
3）做出通用可複制、業務無關的方案，提供給更多有此類需求的同學使用
1）浏覽器異步執行JS，JS調用Navigation timing API擷取目前頁面各階段Latency，并将Latency資料及目前頁面唯一辨別ID、目前使用者Cookie_id異步發送打點伺服器
2）打點伺服器通過TT将資料導入ODPS
3）ODPS中按Latency分組，将各請求樣本分到其Latency所對應的組中
3）将PV資料按上下遊連結關系關聯起來，進而計算轉化率
4）分别計算各組中樣本轉化率
5）最終得出曲線，是在頁面功能及業務狀态基礎上，各Latency範轉内的轉化率趨勢
A. 浏覽器Navigation-timing和Resource-timing API是方案得以實施的關鍵技術基礎，API由W3C在2012年底提出，它可以讓我們擷取到頁面各個重要的Latency資料
B. ODPS及相關大資料附屬技術産品的的開放性、易用性、處理能力使得方案得以順利實施
1）已經計算出性能區間内的轉化率
2）統計所有樣本在各性能區間内的分布，得出各性能區間的樣本占比
3）将優化後的樣本在性能區間内的占比乘以所在性能區間的轉化率，得出A
4）将優化前的樣本在性能區間内的占比乘以所在性能區間的轉化率，得出B
5）B-A即得出性能優化所帶來的轉化率提升
通過一段時間的觀察，在大的樣本集下，性能與轉化率曲線保持穩定。
圖中為真實的AE某一分站的搜尋資料，柱狀圖為各性能區間的樣本占比，黑色線為各性能區域的轉化率，綠色線為各性能區間的跳出率
Q1:如何排除性能外的業務因素對轉化的影響？
A1:此方案單純的是按性能進行分組統計，在大的樣本下，我們可以假定各性能區間内的業務條件是等同的，是以可以不考慮業務因素的影響。當然，還需要更多的時間去證明
Q2:當業務因素變化時，會使得各性能區間内的轉化資料發生變化，一般會提升，那如何随時時間去衡量性能帶來的轉化提升？
A2:每次度量時，以時間最接近的曲線為主，按3.4的方法進行計算。後續會按需看是否采用線性回歸，按自然時間上的表現拟合出一條曲線，這樣可以去除掉某一天的波動