面向體驗的重構優化
38 人贊了文章
前端重構程序員是一個關注代碼同時還要留意體驗的異類。代碼的優化雖然難，但是有比較多的性能測試工具去證明優化的成果。然而體驗這種東西，我們又要如何去證明它的好與壞呢？
一、視覺體驗優化
- 頁面載入
- 數據請求
- 圖片渲染
二、數據證明體驗效果
今天我著重會基於「webnovel」PC站點從以上兩點給大家介紹，如何從體驗的角度去做重構的優化，並如何用數據去證明你的優化是有效果的。
一、視覺體驗優化
我們要做體驗的優化，首先要我們要知道什麼才是好的體驗。
不知道哪裡聽過這麼一句話，「 好的體驗，就是感覺不到在體驗 」。這句話聽起來很矛盾，但是卻和業界公認的體驗小紅書「 Don』t make me think 」的理念一樣。你想用戶來「 webnovel 」是來看小說的，不是來稱讚我們網頁體驗做得多麼優秀的。當用戶開始關注到我們網站體驗的時候，那正是說明我們的體驗不好的時候。
那用戶在什麼地方容易感受到我們網站的體驗呢？
頁面載入
第一個地方就是頁面載入的時候。這裡我們明顯可以看到「 webnovel 」的 Logo 和三個小圖標在頁面刷新的時候，會有一瞬間從無到有的過程。
我們「 webnovel 」站點是面向全球海外用戶的，跳出了國內兼容 IE 瀏覽器的怪圈，於是在小圖標這塊我們選擇了瀏覽器兼容性要求高，但是呈現效果卻更好的SVG圖標「 SVG 屬於矢量圖標，在能保證體積更小的情況下，還能在放大縮小的時候不失真 」。我們將 Iconfont 「來自阿里的在線圖標管理工具 」自動幫我們生成的 JS 代碼引用到頁面中，結果就出現了上面的呈現效果。
這個原理其實很簡單，我們 SVG 圖標的 DOM 結構是在 JS 執行之後動態添加到我們的標籤內部的。所以就會出現先呈現頁面，再呈現圖標的效果。於是我們很自然的想到，直接將 JS 生成的 DOM 結構放到我們的內部，來解決這個問題。
但是很傻很天真，在拷貝 DOM 結構的時候我們發現，這個 SVG 代碼量也太多了，直接放到頁面內部會大大增加我們 HTML 的代碼量，影響整個頁面呈現的速度，這個感覺是撿了芝麻丟西瓜。
最後我們採用的解決方案是，把 SVG 圖標做了拆分，首屏的顯示的圖標我們採用直接添加 DOM 的方式，其它剩餘的圖標還是選擇 JS 動態載入老方法。這樣首屏之外的圖標即使有閃動用戶也很難看到。於是我們解決了首屏圖標閃動的問題，也避免了 SVG 圖標代碼量的問題。用戶感知不到圖標的閃動，也就不會花時間去思考我們頁面載入是快是慢的體驗問題了。
提前載入首屏數據，能一定程度上增強我們用戶刷新和跳轉頁面時候的體驗。
數據請求
第二個地方的就是我們數據請求的時候。當我們切換TAB的時候，能明顯看到一個 Loading 的效果。用戶的動作觸發數據請求，在等待的過程我們用 Loading 來告知用戶這一狀態，以減弱用戶等待的焦慮。這其實是一個對於數據載入，增強體驗常規的做法。
可是不管我們的數據請求多麼的快，用戶都還是能明顯能看到這個 Loading 的效果。這並不是我們想要的。
我們這邊處理的辦法是，在用戶滑鼠放到這個按鈕的時候，我們認為用戶是有了點擊的意願，於是我們就提前發起了數據請求的操作。當用戶按下這個按鈕的時候，我們的數據請求的整個過程可能已經結束，而這也就意味著我們的 Loading 狀態已經消失。此時用戶就能直接看到我們載入好的數據了。也就是說很有可能，在整個過程中用戶是看到不到我們的 Loading 狀態的。這不就是我們想要的體驗上的優化嗎？
利用用戶操作的空閑時間，提前做一些預處理，不失為一個增強數據請求體驗的好辦法。
圖片渲染
我們都知道，圖片和圖標都是屬於展示性的元素，特別是像我們 「 webnovel 」網站設計師很用心製作的書封，我們自然會願意選擇體積更大但是質量更高的高清圖。為了避免影響正文的展示，我們又不得不選擇了類似圖片 Lazyload 的機制，讓這個圖片延遲載入。
但是可以明顯看到這和之前的數據載入的 Loading 邏輯一樣，需要一個表示 Loading 態的占點陣圖。等圖片載入完成，占點陣圖會一瞬間被我們的高清書封替換，於是此時就出現了我們不期望的閃動。
當用戶一看到閃動，他們就會去思考你這個載入是快還是慢。但是我們要的是 「Don』t make me think 」。我們不希望讓用戶去思考除開我們產品之外的東西。所以我們得想個辦法弱化甚至去除這種閃動。
講到這裡呢就不得不科普以下我們瀏覽器本身就有的圖片緩存機制了。在一定時間段內你瀏覽器訪問過的圖片，會被瀏覽器緩存。當你再一次看到這個圖片的時候，這個圖片就直接讀取瀏覽器緩存的內容一瞬就打開，不會有閃動問題。
於是我們就想是不是可以利用這個機制，解決之前閃動的問題。但是現在難點是，我們詳情頁的書封是比首頁的書封大的。因為尺寸不一樣所以是不同的圖片，於是就沒有緩存這個概念。
如果我們讓詳情頁也用首頁的書封，詳情頁小圖被拉伸就會看起來很模糊。如果首頁用詳情頁的大書封，首頁的圖片數據載入開銷又太大。
我們這邊採用的解決方案是，三層疊加法。我們把占點陣圖，小書封，大書封，按照上圖的層級完美的疊在了同一個位置。當用戶從首頁進入到我們詳情頁的時候，我們占點陣圖和小書封都是直接使用瀏覽器緩存瞬間呈現的，因為小書封是疊在占點陣圖之上的，所以用戶是看不到占點陣圖的。而此時大書封正在載入，當大書封載入好了之後，就會蓋在小書封之上。等用戶仔細看這個書封的時候，這個大書封其實很有可能已經載入完成。
從上圖的GIF可以看出，整個過程就從之前的占點陣圖到大書封的閃現，變成了現在的小書封到大書封的漸變。其實這是很難被用戶發現的。
看到這裡可能有同學會問說，既然這裡都看不到占點陣圖，為什麼還需要載入這個圖呢？其實原因很簡單，因為不是每個人都是從首頁進入到詳情頁的。有可能用戶是直接打開的這個鏈接。那麼此時占點陣圖就回到了最初的邏輯。先看到占點陣圖然後再看到書封。當然我也得承認對於這樣的用戶，我們其實是多載入了一個小書封的資源的。但是對於體驗上的優化來說，這一點資源的消耗我個人認為還是可以接受的。
還有一個好玩兒的點是，在這個地方因為同時載入了，占點陣圖，小書封，大書封，它們作為圖片也都會被瀏覽器緩存，當用戶跳轉到其它頁面的時候，如果有相同的圖片，那又是瞬開的。這樣我們就充分的利用了瀏覽器緩存，讓用戶在我們網站上的體驗得到了進一步的提升。
圖片緩存，讓網站體驗比好更好。
二、數據證明體驗效果
視覺層的體驗優化是所見即所得的，你可以很快的看到優化的成果。但是有很多因為瀏覽器差異，或者用戶差異引起的體驗問題，我們沒法直觀和快速的去證明體驗優化的效果。我們就得靠數據去證明了。
要用數據說話，首先我們得有數據，而這個數據的收集工具我們海外 PC 站用的則交給了來自 Google 的 Analytics。這邊給大家講關於這個的一個有趣故事。
有一天我在用 webpagetest 「 一個全球知名的測試網站載入速度的工具 」測試我們 「 webnovel 」頁面的時候我看到了這樣一個結果。
大家注意看那個最長的綠色，看到了吧，一個 DNS 載入怎麼比後面的 SSL + CSS 載入 + CSS渲染還要長？CSS 可是強制阻塞我們頁面渲染的重要元素，它要是慢了，你網站做再多優化都沒有用。這個你讓人怎麼忍？
怎麼辦呢？我們選擇了一個暴力但是有效的辦法，直接把 CSS 合併到我們的 HTML 文件中 「 CSS 內聯到 HTML 內部 」。CSS 文件都沒有了，看你還怎麼 DNS、SSL … 哇！好棒，我拿著這個去找老大邀功。老大啪啪給我提了兩個點就把我打懵了。
第一， 你這個明顯是首次載入頁面時候的效果，對於大多數這個 CSS 文件已經有緩存的用戶，你如何證明，這個優化對他們是又用的？
第二，「 webnovel 」是面向全球的網站，你又如何證明，這個優化對所有地區的用戶的優化力度 ？
是啊我要怎麼證明？「 webnovel 」全球這麼多的用戶，我就用一份 「 webpagetest 」 的測試報告去涵蓋所有的終端和用戶群體，顯示是不具有公信力的。並且我又要如何證明這個優化的力度是多少？
此時中國好同事出現了，我的前端邏輯小夥伴幫我在框架機內部做了一個隨機預處理的AB樣本輸出。道理很簡單，就是讓 50% 的用戶是用原始的方式載入我們的 CSS ，另外 50% 的用戶使用我們 CSS 內聯到 HTML 內部的方式。這樣我只需要加個標識符區別一下這兩個樣本，上報到 GA 「 Google Analytics 」 ，然後 GA 會自動幫我們統計和處理這些樣本，最後我只需要將這兩個樣本的平均值做一個 10 以內的減法，就知道了我們的優化力度具體是多少了。
然而另一個問題出現了，我們應該把什麼作為數據上報給 GA 呢？顯然用整個網頁的載入時間去證明 CSS 的載入是不對的。那我用 CSS 載入完成之後的那個時間去證明？可是我又怎麼能證明 CSS 載入完成之後頁面就已經渲染好了呢？我們不是在做體驗的優化嗎？又怎麼能僅憑藉 CSS 文件的載入來證明用戶體驗變好了呢？
此時我是凌亂的。不行，整個場面我要HOLD住，不能慌。
體驗，體驗，CSS都沒有載入，用戶連頁面都沒有看到又怎麼能叫體驗？於是用戶剛看到頁面的時間，被我認定是一定程度上可以證明體驗優劣的。
怎麼去獲取這個時間呢？其實利用 performance API，就可以獲取到上圖所示的瀏覽器各個階段的時間。
Chrome瀏覽器 可以用 window.chrome.loadTimes().firstPaintTime； IE8+ 瀏覽器可以用 window.performance.timing.msFirstPaint；
來獲取頁面開始渲染的時間。最後大家一致的意見是，將這個 「 firstPaintTime - navigationStart 」的時間近似理解為用戶從訪問頁面到看到頁面的時間。
於是，我很開心的把這個這個時間上報到 GA，然後版本上線，等待數據收集。最後得出如下的統計結果：
看到以上的數據結果，這個優化的時間和總時間比起來比預想的差太多了。感覺不應該啊？
當我們仔細分析這個數據，發現在這整個的時間段內，服務端的時間佔了 1.1s 。我在這拚命的優化體驗，可是最後發現體驗的瓶頸並不在我們前端這邊。這充分的說明，有的東西還是得靠數據說話，而不是你以為你以為的就是你以為的。當然除開這個瓶頸時間我們可以得出如下的結論。
至此我們有理有據的證明了優化體驗的成果，雖然結果出乎了我們的預料，但是卻證明，數據上報是能夠證明我們體驗成果的一個有理證據。
當然我們也把這個瓶頸問題，反饋給力服務端的同學。然後得到的答覆是，「 webnovel 」還屬於我們海外站的新項目，很多海外伺服器有待跟進。相信在後續設備之後，會解決這個痛點。
數據上報，讓你的體驗優化有理有據。
總結
篇幅有限，這邊我只是零散的列舉了，我個人認為可以從用戶體驗角度去做的幾點重構優化，以及如何利用數據去證明你優化的力度。希望對於大家有一定的啟發和幫助，有什麼問題，也請給我留言，我們可以深入的交流。
本文作者：ziven 鄭成忠
原創聲明：本文為閱文前端團隊 YFE 成員出品，請尊重原創，轉載請聯繫公眾號 ( id: yuewen_YFE ) 獲取授權，並註明作者、出處和鏈接。
推薦閱讀：