這！就是1688 PC首頁

轉載至微信公衆號：方凳雅集

在2019.09.06，20財年版的1688 PC 首頁終於全量發佈了！

新版1688 PC首頁傳送門 >> www.1688.com

除了UI上透傳的1688品牌心智的變化，在數據對比上，新版首頁的業務指標的轉化率（UV點擊率、L-D、L-O、引導搜索效率等等），總體有了較大的提高。（因爲數據敏感，這裏就不po具體的數據對比了）

此次改版，技術給1688PC首頁帶來了什麼？更智能 + 更快 = 效能更高。

下文主要分兩塊給你們介紹新版的1688 pc首頁（簡稱「新版首頁」）。

第一部分，新版首頁在產品和視覺設計、數據投放與分流策略上發生了什麼改變，是怎麼變得更智能的。

第二部分，站在體驗技術的角度，在新版首頁的前端技術實現上，咱們作了什麼小創新，讓新版首頁的技術更現代、性能更好、質量更有保障。

1、新版首頁的變化

來，先感覺一下新舊版首頁的UI對比。

1. 提高業務效能，打造源頭廠貨通天下和品牌心智

先給你們講講背景，新版首頁有着非凡的使命。

• 今年1688的核心戰略是無限接近源頭廠貨，源頭廠貨通天下，打造用戶的心智，更豐富的品類市場及1688超級產地日活動的透出；
• 打造品牌心智，咱們不只作工廠白牌，還有愈來愈多的品牌商入駐；
• 強化搜索與場景中控，對於老版首頁須要大量的人肉配置（更新頻率極低），新版首頁大部分模塊利用算法推出更接近用戶需求的場景和商品，低運營成本的同時，帶來更好的轉化效率；
• 首頁不只僅是個流量分發渠道，也是將來營收增加可能性的佈局。

2. 更高效更精準的投放與分流

首頁不只是網站的門面，也是一個大型用戶流量分流器，首頁的轉化效率起到很是關鍵的做用。新舊版首頁很明顯的一個改進點在於頁面的數據投放與分流策略上。

在舊版首頁中，如首屏的營銷活動（小焦）和佔據234屏的橫向區域，因爲是大量的人肉配置，會形成配置頻率很低，且出的商品或場景，是人肉挑選，不會根據用戶偏好展現，這會讓轉化效率大打折扣，首頁的用戶流量過來了，可是接不住，不能實現進一步的轉化。

I. 大富翁：統一活動資源管理

大富翁，是CBU全站活動資源投放管理平臺。支持的模塊包括首焦（首屏輪播）的營銷活動資源投放、小焦（非消和消費品的營銷活動）的營銷場景投放、KA品牌牆、底部資源位、大促氛圍（頂通、首屏背景、N連珠）等。

大富翁平臺的優點有如下幾點：

1. 首頁的活動資源統一在大富翁配置和投放，運營同窗來投活動不再是不知道找誰了，統一管理投放，同一個時間段同一個坑位只有一個活動，定時切換；
2. 首頁研發只須要對接大富翁平臺的數據源，不用對接千千萬萬個不一樣行業、橫向的運營小二，也避免人肉切配置數據和多個活動在同一個坑位衝突的問題；
3. 大富翁的封神榜，統一收集資源相關的數據統計，讓投放的資源數據可跟蹤。

II. 智能臉譜：智能分流策略，場景中控的千人千面

智能臉譜，着力於解決CBU各資源位的流量運營問題，旨在提高運營的流量運營能力以及cbu總體流量更精準更高效的分發。支持8個橫向業務的模塊分流，第一行是廠貨通、淘貨源、跨境、微供、第二行是工業品、消費品、進口、企業匯採。

智能臉譜的優點有如下幾點：

1. 運營產出一個業務的業務池，每一個業務展現3個場景，其中每一個場景的offer圖是個性化產出的；
2. 目前業務池中，只有以上8個橫向模塊，因此業務的坑位暫時是肯定的，在將來這個區域的業務更豐富，可經過智譜，根據用戶的偏好（核身身份、主營類目或採購等）展現不一樣的業務模塊中的不一樣場景，但願更高效更精準地作流量分發。

III. 猜你喜歡

猜你喜歡模塊是基於算法根據用戶偏好向用戶推送最匹配需求的高效分發場景，從數據能夠看到，猜你模塊是除了首屏外，點擊率最高的模塊，本次改版中該模塊從本來的「5*4行」20個坑位到如今的「5*40行」200個坑位，猜你模塊的UV點擊率比翻倍還要多一點。

除了區域的擴展之外，信息架構上，在原來一些核心信息（標題、圖片、已售、價格）的基礎上，添加了「鎮店之寶」「實力商家」等展現商品實力的標，以及「包郵」、「滿減」等利益點的透傳，讓買家對供應商更有信心以及對營銷的利益點更清晰，在原有個性化推品的基礎上，以上的信息透傳也是增長了L-D的轉化的因素之一。

在將來，首頁在猜你模塊也會進行迭代，添加卡片的混排，進一步在商品中推場景，提高轉化效率。

2、前端技術的小創新

首頁的改版，在業務上，透傳出更多今天1688的核心戰略源頭廠貨通天下的心智，同時把大量之前須要人肉配置但更新得很低頻的模塊，升級爲由數據驅動、千人千面的智能模塊，每一個模塊的轉化效能更高、維護成本更低。下面我畫了一個結構圖，你們能夠更清晰地瞭解新版首頁的總體內容框架、前端作了什麼改造以及依賴哪些CBU基礎服務和平臺。

I. 首頁的前端技術方案的小變化

a. 搭建模式新嘗試，assets+源碼模板+純數據組件

PC首頁轉型成智能化的流量分發渠道，整張頁面須要人肉配置的地方已經不多（導航、公告等），而首頁用到的組件通常是定製的，在其餘導購頁面的複用率也低。出於大促氛圍須要全局配置的考慮，若是繼續使用原有多個組件的搭建方式，大促氛圍實現和維護成本會較高。

首頁在性能和質量保障上，須要定製化的處理。常規的搭建頁面，組件獨立開發和配置，性能優化的手段是由搭建平臺統一提供的，較難針對某一場景，對整個頁面作定製化的性能優化動做。

前端的小私心，想要在前臺導購場景中落地React 16.x。因爲歷史問題，已有的頁面很難往React16和Fusion Next 1.x作升級，須要兼容頁面中其餘的組件的技術體系，首頁做爲PC端流量大頭，若是在首頁試點成功，其餘導購場景也能夠hold得住，首頁前端項目組決定往前走一步，整個頁面用React 16.x & Fusion Next 1.x開發。

所以，首頁的構成，從多個基於jQuery組件的組件式搭建，到1個基於React 16.x的assets應用+純數據配置的源碼頁面式搭建。

b. 當奇美拉趕上puppeteer，SSR get √

一開始首頁就像普通的assets頁面同樣，一個 <div id="app"></div> 加上靜態資源，整個模板就結束了。但後來發現，首頁的首屏性能仍是很關鍵的，畢竟是出來賣的嘛（捂臉），咱們得在性能上下點功夫。

如上圖，打通了奇美拉的發佈系統，作了一個assets頁面靜態化的puppeteer服務，在頁面發佈時，先經過headless chrome渲染一次頁面，再把渲染後的模板content注入到同一個pageid的內容中，因此新版首頁實際上是服務端渲染的，加載後根據請求的最新數據內容，作最小顆粒度的dom diff和更新。

用puppeteer作了什麼？一圖勝千言。

c. 性能對比

新舊版首頁在一樣網絡環境下的性能錄製對比，左邊是新版首頁，右邊是舊版首頁。 first paint 到 onload event ，從本來的3295ms到如今的1217ms，而可交互時間（TTI，DCL&&加載85%內容）預估大概是從原來的1900s到如今的1000ms。看習慣舊版首頁的同窗在我邊上，第一次看到新版首頁，說是肉眼可見的快了，首屏快了，對業務的價值是首屏搜索、活動或廣告的點擊率的潛在上漲。

首頁性能談不上快吧，因爲業務節奏的問題抓緊先上了一版，在Main裏能夠看到不少小紅旗提示有可能的性能瓶頸，預加載、pwa、code splitting等等，還有不少的優化空間，性能優化之路仍需持續進行。

II. 首頁的大促氛圍

通常來講，PC首頁的大促氛圍會包括如下部分：

• 頂通，alibar下面的頂部通欄
• logo位置，大促倒計時 或 動態gif
• 首屏的氛圍大背景
• 首屏五連珠
• 第二屏的會場智能分流器
• 全頁的大促氛圍主題色以及各個平常區塊在大促下的配色調整等

a. 首頁大促氛圍 之 研發的痛

在老版首頁中，之前走的是搭建體系，首頁的每一個模塊是一個獨立的組件，配置都是單獨配置的。大促氛圍讓前端同窗至關頭疼，大促是一個總體的氛圍配置，但老版首頁每一個模塊都是獨立配置的，想要把幾個模塊共用一張氛圍背景，變得至關困難，搭建平臺自己不開放這樣的反作用設置，前端同窗可能須要經過比較hack的方式來完成，甚至準備2份組件（如帶logo和searchbox的頭部組件），一份是平常版，一份是大促版，這會形成配置的混亂以及較大的維護成本。

另外，以前的大促氛圍配置，是靜態的、人肉的，PC首頁的氛圍發佈，須要人肉蹲點完成。運營或者前端同窗先收集好大促氛圍的資源，在氛圍切換前把組件配置保存好，切換的00:00，人肉點一下發布。因爲PC首頁還有出於性能考慮的源站緩存機制（24小時），每次頁面發佈後，須要人工刷新下CDN緩存，讓用戶訪問的頁面從新回源到最新的頁面版本。

b. 首頁大促氛圍 之 痛定思痛

都9102年了，咱們認爲，這樣的人肉蹲點切氛圍的方式，該退出歷史的舞臺了，在新版首頁的大促氛圍須要上點現代武器~

武器1：添加氛圍全局控制，支持自動切換

關鍵字：大促氛圍實現再也不難難難，平常/大促氛圍再也不須要前端同窗蹲點人肉切換

上文也提到，基於之前的模塊式搭建方式，首頁配氛圍時特別痛苦，尤爲是一行N列布局，須要通用一張背景圖時，須要前端把1張圖切割成N份，分別配置到不一樣的組件中，僞裝是一張通圖。又或者某些複雜的模塊，須要維護平常和大促兩份組件。

考慮到PC首頁轉型成智能化的流量分發渠道，整個頁面須要人肉配置的地方已經不多（導航、公告等），而首頁用到的組件通常是定製的，在其餘導購頁面的複用率也低。

新版首頁的搭建方式是源碼模板+少許數據配置，算是一個「大組件」，針對像大促氛圍這樣全局的控制，實現效率更高，維護成本更低。

同時支持大促氛圍，再也不須要前端同窗在準點發佈頁面後，再人肉蹲點清理用戶訪問資源的緩存。

• on（手動開）
• off（手動關）
• auto（自動，識別大促數據源中的開關字段判斷開關）

武器2：氛圍數據的統一管理，排期定時投放

關鍵字：定時定資源自動投放，資源再也不衝突，資源配置再也不須要運營同窗蹲點人肉更新

氛圍資源配置再也不寫死在每一個組件的靜態配置中，由大富翁統一管理，以下圖，頂通banner、動態logo、五連珠素材，針對不一樣的階段氛圍場景（平常、預熱、爆發、返場等等），同一個時間段投放對應的資源，定時自動切換數據。這解決了蹲點更新數據的問題。

III. 首頁的灰度方案

a. www.1688.com 的灰度方案

在作每次頁面級別的大改版時，咱們須要預先考慮好灰度的方案，包括分桶邏輯和灰度期間的數據對比，每每落地比想象中稍微複雜一些，下面給你們分享一下 www.1688.com 的灰度方案。

新舊版首頁的灰度時間其實很是短，由於要趕在9月份大促以前發佈，在新版首頁直接上大促的氛圍。

• 08.26-08.29，灰度10%；
• 08.30-09.05，灰度50%；
• 09.06，全量發佈。

可能你會好奇爲何是10到50再直接開100，是否是跨度稍微大了一些。Um，也是有緣由的，由於當時跟CDN同窗寫上，提供的CDN側的分桶方案，只有pt5（10%）、pt20（40%）、null（其餘）三個桶，因此咱們切流的時候，第一次是 pt5 命中新版，第二次是 pt5 || pt20 命中新版，第三次是全量鋪開新版。

要素1：流量分桶

1688PC首頁的源站因爲歷史緣由是一個Java應用(cbu-static)，須要作灰度的頻率比較低。採用的作法是，建立兩個頁面，這兩個頁面都在cbu_static上承載，CDN節點依然部署了上述的分桶邏輯，當回源到cbu_static時，在tengine層面能夠根據請求頭中的x-air-pt來proxy_pass到不一樣的路徑上，以實現灰度的效果。

結合CDN+源站的灰度多版本緩存機制，www.1688.com的灰度流程以下：

1. 用戶流量進來，訪問CDN上的靜態資源
2. CDN根據用戶的cna或utdid（用戶身份惟一標識），進行灰度分桶計算，判斷用戶進入了哪一個分桶
3. 在 www.1688.com 的訪問header中，打入 x-air-pt 的頭
4. 源站根據 x-air-pt 的值，返回灰度版本對應的首頁版本（新首頁 或 舊首頁）。用戶訪問的 www.1688.com 頁面資源到源站回源，利用 header 中 vary 參數的值 x-air-pt 回源到多個副本
5. 用戶最終看到命中的首頁版本

要素2：查看灰度數據

分桶成功以後，同是經過 www.1688.com 進來的流量，咱們須要區分進入哪一個版本的流量以及各個區塊的曝光、點擊等業務指標，方便作AB版本的數據的對比和產品方案上的調優。最終，咱們是經過 A+的AB Test 服務進行新舊版本首頁數據的對比。

一開始，因爲新舊版首頁的源頁面原本就不是一張頁面，咱們是打算直接使用兩個不一樣的spmB來作數據觀察的，PD同窗只需在A+中輸入不一樣的spmA.spmB就能夠。可是首頁做爲PC的流量大頭，廣告、搜索等核心業務的數據依賴舊版首頁的spm（ a260k.dacugeneral ），對新首頁灰度的數據側需求是spm的B位須要跟舊版的保持一致，目的是在灰度期間首頁的業務數據不會出現斷層。

因此，在首頁的灰度方案中，新老頁面的spm是一致的，在此基礎上加上spm b位的版本號，其中新版本的是 a260k.dacugeneral/new ，舊版本的是 a260k.dacugeneral/default 。灰度的數據統計使用的是 A+ 的AB Test，支持離線和實時的數據統計。除了頁面概況，也能夠經過搜索spm c位，查詢某個頁面版本的某個區塊的數據狀況。

IV. 首頁的質量保障

新首頁的質量保障目前主要作了什麼？

• Plan A ：首屏的前端靜態數據兜底，保證在極端狀況下，譬如服務接口全掛了，1688首頁首屏仍能正常展現，下面的模塊按需隱藏或兜底；
• Plan B ：React 16的錯誤邊界，解除一個組件搞掛整個頁面的風險；
• Plan C ：Retcode埋點上報（常規埋點和主動上報），經過頁面數據監控和優化；
• Plan D ：在發佈時接入自動化測試，作頁面模塊接口的有效性校驗，甚至頁面的UI差別比對。待自動化測試同窗介入。[ to do]

I. 容錯 —— error boundaries

新版首頁是個「大組件」，一個 index.jsx 中引入子目錄下的各類 components ，初期開發階段，整個應用處於「裸奔」的狀態，一個組件拋錯誤，整個頁面都會掛掉。平常拋JS error的狀況包括但不限於代碼邏輯沒注意寫錯了、數據接口掛了或者返回結構不如預期、多層數據獲取的容錯等。首頁有19個組件和一些公用的函數，若是其中一處報錯，會把整個頁面搞掛，風險太大。

據瞭解，常規的搭建頁面中，每一個組件在渲染前會逐個加入try-catch的容錯判斷。

此處掌聲給React 16的Error Boundaries。

部分 UI 的 JavaScript 錯誤不該該致使整個應用崩潰，爲了解決這個問題，React 16 引入了一個新的概念 —— 錯誤邊界。

錯誤邊界是一種 React 組件，這種組件能夠捕獲並打印發生在其子組件樹任何位置的 JavaScript 錯誤，而且，它會渲染出備用 UI，而不是渲染那些崩潰了的子組件樹。錯誤邊界在渲染期間、生命週期方法和整個組件樹的構造函數中捕獲錯誤。

作了一個ErrorHandle的HOC，隔離每一個component，並根據模塊特性，決定拋錯時整塊隱藏或展現什麼佔位。

1. 經過 getDerivedStateFromError 捕獲報錯；
2. 利用聲明週期中的 componentDidCatch 作拋出錯誤後的處理，如Retcode錯誤上報；
3. 當有錯誤拋出時，能夠經過state控制該渲染什麼。

II. Retcode 監控與上報

新版首頁接入了Retcode，監控頁面平常的js報錯（error boundary也會對拋錯的錯誤信息進行主動上報），針對有服務端接口的模塊，作主動上報，類型包括服務系統錯誤、沒有數據、數據不符合預期等。

把首頁retcode監控與GOC監控打通，儘早發現和解決線上問題，避免線上質量問題響應速度慢，持續擴散問題的影響面。

寫在最後

首頁改版的第一階段算是結束了，但發佈並不等於結束了，持續優化迭代的路仍然很長。後續1688 PC首頁還會做爲咱們團隊同窗目前在研究的SSR、搭建的灰度能力、B類特點數據編排、場景的A/B實驗與效能分析等等技術解決方案的落地場景，還會給你們帶來B系前端技術的更多技術深度好文，敬請期待喲~

這！就是CBU體驗技術團隊。