整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
讀一開始我們的H5頁面秒開率只有30%左右，現在我們的H5頁面秒開率達到了 75%。這中間巨大的差異究竟有哪些黑科技在里面？我們為什么要做H5頁面的秒開優化？我們的秒開指標是如何統計的？客戶端和H5是怎么配合做到 1+1>2的？監控是如何發現H5頁面可優化項的？我們又通過監控發現了哪些可優化的問題呢？
H5秒開優化是一個老生常談的問題，本文將逐步介紹如何通過客戶端 + H5 的優化手段（1+1>2）把秒開從 30% 提升到 75% ？后續接口預請求、客戶端預渲染以及預加載2.0上線后還會再次助力指標提升。
為什么要做優化？
Global Web Performance Matters for ecommerce 的報告中指出：
整體系統架構圖：
首先講一下得物用來衡量秒開的指標 FMP，那為什么不選擇 FCP 或者 LCP 呢？FCP 只有要渲染就會觸發，LCP 兼容性不佳，得物希望站在用戶的角度來衡量秒開這件事情，用戶從點擊打開一個WebView到首屏內容完整的呈現出來的時間點就是得物定義的FMP觸發時機。
指標清楚了之后，再來看一下完整的 FMP 包含哪些耗時。
接下來將分為兩大部分進行介紹，客戶端優化部分和H5 優化部分。
通過 HTML 預加載、HTML 預請求、離線包、接口預請求、鏈接保活、預渲染等手段提升頁面首屏打開速度，其中預加載、預請求、離線包分別可提升10%左右的秒開。
通過配置由客戶端提前下載好HTML主文檔，當用戶訪問時直接使用已經下載好的HTML文檔，以此減少HTML網絡請求時間，從而提升網頁打開速度。
前人栽樹后人乘涼，得物App有很多的資源位，banner、金剛位、中通位等，這些位置顯示什么內容，早就已經是智能推薦算法產出的了，那么就可以直接指定這些資源位進行預加載。
頁面被預加載之后，總不能一直不更新吧？那么什么時候更新頁面的緩存呢？
被現實打臉：
但是在后面的灰度過程中被現實狠狠的教育了一頓，發現有些SSR的頁面會涉及到狀態的變更，比如說：領劵場景。這些狀態都是經過SSR服務渲染好的，用戶在進入頁面時還沒有領劵，這個時候去更新HTML文檔，實屬更新了個寂寞，在用戶領劵之后關閉頁面再次進入，發現頁面中的狀態仍是讓用戶領劵，點擊領劵又告訴人家你已經領過了。
改進措施
至此問題也解決了，工程師的任務結束了嗎？如果你認為功能做上去就算結束，那么此時此刻請你一定要轉變思維，想一想我們的目標是什么？我們的目標是「提升秒開」，預加載只是一種提升秒開的手段，但是在功能做上去之后并不知道這個功能帶來了多少秒開的收益，因此在把功能開發完成上線之后，就要開始關注上線之后的結果，來看看預加載的性能表現如何。從下圖可以看到，預加載開啟狀態下可提升10%以上的秒開率。
（1）SSR服務擴容
要解決服務器壓力問題，很自然就會想到增加機器，于是我們對SSR機器數量做了一次擴容，將機器數量提升了一倍，這個時候繼續嘗試擴大預加載的用戶數量，但是仍然無法抗住這么大的QPS，而且此時還引發了第二個問題，算法部門的服務器發出了告警，于是放量計劃又一次遇到了阻礙。
（2）破局者 CDN
利用CDN 服務器的緩存能力既可以減輕 SSR 服務器的壓力又可以減少后端服務鏈路的壓力，這么好的東西為什么不用呢？這里留個懸念，后面將H5優化部分會詳細介紹。
（3）客戶端配合改造
支持針對CDN域名進行全部開放預加載能力，針對非CDN域名保持原有放量比例。
在這個過程中還分析了頁面的流量占比，發現開屏廣告來源的頁面流量占比也很高，那么是不是可以把開屏廣告的HTML文檔內容也給預加載下來呢？
開屏頁面預加載策略
既然可以提前下載好HTML，那是不是可以更進一步，提前把頁面內的資源加載好，這樣在打開一個頁面的時候可以減少大部分的網絡請求從而更快速的把內容呈現給用戶。這里還需要考慮如何跟下面講到的離線包進行協作。
在WebView初始化同時，去請求HTML主文檔，等待HTML文檔下載完成 且 WebView初始成功后渲染，減少用戶等待時間，客戶端請求成功后，WebView加載本地 HTML，并保存以供下次使用。預請求HTML開啟狀態下可提升8%左右的秒開。
預請求 VS 預加載
本質上HTML預加載和HTML預請求的區別就是下載HTML文檔的時機不同， 預加載是在App啟動后用戶無任何操作的情況下就會去下載，但是預請求只會在用戶單擊打開H5頁面的時候才會去下載。如果用戶是第二次打開某個H5頁面，此時發現本地有已經下載好的HTML且尚未過期就會直接使用，這個時候的行為表現就跟預加載的功能是一致的了。
上線之后發現預請求只提升了2%左右的秒開，經過分析發現問題：
在本地用低端機對整個秒開耗時鏈路進行了分析，為什么要用低端機分析呢？低端機有個好處，天然的加上了慢放功能，可以最大程度發現問題。
從圖中可以看出h5 頁面加載之前 耗時 分布在 activityStart() 函數，該函數 包含了 onCreateView ，其中耗時最長是 布局填充 inflate()，因為 WebView 對象是提前創建好的，直接從對象池中取出的，所以耗時主要在 初始化過程，WebView 自身的初始化 WebViewChromiumFactoryProvider. startYourEngines （耗時 87 us，不到 1 ms），耗時還有 WebView 的一些其他初始化，jockey 的初始化 等等。
而秒開的計算是包含了 View 初始化到 WebVIew url 加載 的耗時，從而發現了優化點，可以將Webview loadUrl 前置，h5 頁面加載 與 原生布局填充并行執行。在 onCreateView 時，創建 FrameLayout 進行返回，執行 WebView loadUrl 之后，主線程開始 對布局進行 inflate，布局加載成功后，將其 addView 到 FrameLayout 中，減少了 loadUrl 的阻塞時長。中高端機型有 15ms 左右優化，低端機型有 30 ~ 50 ms 優化 效果。
預請求HTML時機是在進入到 native 頁面中，這個時間點距離用戶單擊事件已經過去100ms，那么是否可以將下載HTML的時機提前呢？經過一番探索，最終選擇在路由階段進行攔截，既可以統一收口而且距離用戶點擊的時間間隔可以忽略不計。通過這種方式將下載HTML時機提前了平均80ms+。
此時的流程變成了下面這樣。
可能有的同學會問了，為什么不在用戶點擊的時候去下載呢？從用戶點擊到路由肯定還是有耗時的。
在上述問題解決后，將緩存時間修改為1天，發現預請求HTML開啟狀態下可提升8%左右的秒開，已經和預加載的效果相差不大了。
通過提前將H5頁面內所需的css、js等資源聚合在一個壓縮包內，由客戶端在App啟動后進行下載解壓縮，在后續訪問H5頁面時，匹配是否有本地離線資源，從而加速頁面訪問速度。
資源攔截這塊安卓這邊實現比較簡單，WebView支持 shouldInterceptRequest, 可以在該方法內檢測是否需要進行資源攔截，需要的話返回 WebResourceResponse 對象，不需要直接返回 null。
但是在iOS 這邊遇到了一些困難，調研了以下方案：
NSURLProtocol 攔截方式，使用WKBrowsingContextController和registerSchemeForCustomProtocol。通過反射的方式拿到了私有的 class/selector。通過把注冊把 http 和 https 請求交給 NSURLProtocol 處理。通過這種方式確實可以攔截請求，但是發現post請求的body會出現丟失的問題。而且NSURLProtocol一經注冊就是全局開啟。我們希望他只會攔截接入了離線包的頁面，但是沒有辦法控制他，他會攔截所有頁面的請求，包括第三方合作頁面，顯然這是無法接受的。
在iOS 11及以上系統中, 擁有了加載自定義資源的API：WKURLSchemeHandler。
可以修改當前頁面url為自定義 scheme 協議，比如：https://fast.dewu.com 修改為 duapp://fast.dewu.com 然后在客戶端內注冊該 scheme，前端配合修改頁面內所有的資源請求未自適應協議，如：src="//fast.dewu.com/xxx" 就可以實現攔截。但是在測試過程中發現，接口為了安全起見只允許白名單內的域名發起跨域請求，且無法配置多個域名，導致該方案無法繼續進行。
仍然是使用 WKURLSchemeHandler 然后通過 hook WKWebview 的 handlesURLScheme 方法來支持 http 和 https 請求的代理。通過這種方式雖然可以攔截請求了，但是遇到了以下問題：
（1）body丟失問題
不過在 iOS 11.3 之后對這種情況做了修復處理，只有 blob 類型的數據會丟失。需要由JS來代理 fetch 和 XMLHttpRequest 的行為，在請求發起時將 body 內容通過 JSBridge 告知 native，并將請求交給客戶端進行發起，客戶端在請求完成后 callback js 方法。
（2）Cookie 丟失、無法使用問題
通過代理 document.cookie 賦值和取值動作，交由客戶端來進行管理，但是這里需要額外注意一點，需要做好跨域校驗，防止惡意頁面對cookie進行修改。
至此功能開發完成上線，先來一組線上收益數據，安卓開啟離線情況有有10%左右的收益，但是iOS開啟離線的反而秒開率更低。經過修復處理后iOS也可提升10%以上的秒開。
安卓和iOS實現差異
經過分析對比發現，安卓的攔截動作比較輕，可以判斷是否需要攔截，不需要攔截可以交給WebView自己去請求。
但是iOS這邊一旦頁面開啟攔截后，頁面中所有的http和https請求都會被攔截掉，由客戶端發起請求進行響應，無法將請求交還給WebView自己去發起。
iOS 緩存問題修復
頁面中的資源經過客戶端請求代理后原本第二次打開WebView本身會使用緩存的內存，現在緩存也失效了，于是只能在客戶端內實現了一套緩存機制。
從下圖可以看到離線包的下載錯誤率在 6% 左右浮動，這么高的下載錯誤率肯定是無法接受的， 經過一系列優化手段，把離線包下載錯誤率從6%左右浮動下降至 0.3%左右浮動。
先來看下優化前的流程圖和問題點。
通過埋點發現大量 unknown host 、網絡請求失敗、網絡連接斷開的情況。分析代碼發現下載未做隊列控制，會同時并發下載多個離線包，從而導致多個下載任務爭搶資源的情況。針對發現的問題點做出了以下優化：
下面是優化之后的流程圖：
針對離線資源是直接存儲在磁盤上的，每次訪問都會有磁盤IO耗時，經過在低端機器上做測試發現這個耗時會在 0 - 10ms 之間進行波動，后面會把內存合理的利用起來，通過設置內存上限，文件數量上限，甚至是文件類型，并通過 LRU 策略進行內存文件的淘汰更新。
通過客戶端發起H5頁面首屏接口請求，遠比等待客戶端頁面初始化、下載HTML、JS下載執行的時機更提前，從而節省用戶的首屏等待時間。在本地測試過程中發現接口預請求可提前100+ms，用戶也就可以更快的看到內容。
客戶端會在App啟動后獲取配置，保存支持預請求的頁面地址及對應的接口信息，在用戶打開WebView時，會并行發起對應預請求的接口，并保存結果。當JS執行開始獲取首屏數據時，會先詢問客戶端是否已經存有對應的響應數據，如果此時已經拿到數據則無需發起請求，否則 js 也會發起接口請求并開啟競速模式。以下是整體流程圖：
那么客戶端怎么知道這個頁面需要請求什么接口呢？以及接口的參數是什么呢？那自然少不了配置平臺，它支持以下功能：
首先即使是在 SSR 的情況下，首屏內容中仍然可能有部分組件是骨架直出的，需要等待頁面渲染執行時才會去請求數據，另外還有一部分頁面是SPA的。針對這兩種情況都能做到很好的補充。
開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。
通過上圖可以看到一個網絡請求在經過DNS解析耗時、TCP建連耗時、SSL建連耗時階段之后才能把請求發出去，那么是否可以節省這段時間的耗時呢？
客戶端常用的網絡請求框架如OkHttp等，都能完整支持http1.1與HTTP2的功能，也就支持連接復用。了解了這個連接復用機制優勢，那就可以利用起來，比如在APP開屏等待的時候，就預先建立關鍵域名的連接，這樣進入相應頁面后可以更快的獲取到網絡請求結果，給予用戶更好體驗。在網絡環境偏差的情況下，這種預連接理論上會有更好的效果。
可以通過對域名鏈接提前發起一個HEAD請求從而建立鏈接，網絡框架會自動將連接放入連接池。并在默認無操作5分鐘后進行釋放，在五分鐘內重復執行上述動作即可一直保持鏈接。
另外這里需要注意下連接池的數量問題，如果連接池的數據太小，但是域名比較多的話，通過預建連保持的鏈接很容易就會被釋放掉，這就需要通過域名收斂或者調大連接池的數量來進行優化。
那預建連會不會增加服務器的壓力呢？這個肯定是會的，首先會針對預建連功能本身就行灰度策略，在HTML頁面通過CDN托管后，直接針對 cdn 域名進行全量開啟，從而不用擔心 cdn 域名扛不住壓力。
來看一下線上效果，通過下圖可以看到在開啟后DNS 90分位耗時從80ms降至0ms，TCP建連90分位耗時從65ms分位耗時降為0，DNS平均耗時從55ms降為4.3ms，TCP建連平均耗時從30ms降為2.5ms。
客戶端提前通過WebView將頁面渲染好，等待用戶訪問時，可直接展示。從而達到瞬開效果。但是這種功能肯定不能對所有的頁面進行開放，而且存在一定的弊端。
下圖【開學季】是業務上已經進行預渲染的H5頁面，可以看到在打開【開學季】頁面時，頁面已經渲染完畢，絲毫沒有等待過程。
后面計劃把這種能力放大到通用的webview上，針對大促以及PV量高的頁面進行開放。
SSR服務端渲染（英語：server side render）一般情況下，一個H5頁面的數據渲染完全由客戶端來完成，先通過AJAX請求到頁面數據并把相應的數據填充到模板，形成完整的頁面來呈現給用戶。而服務端渲染把數據的請求和模板的填充放在了服務端，并把渲染的完整的頁面返回給客戶端。
SSR對于秒開有平均15%的提升，既然是服務端渲染，就會對服務器造成壓力，尤其是在預加載HTML功能開啟后，那得物是如何解決的呢？
通過這么多優化手段仍然無法滿足預加載的需求，并且通過分析發現網絡階段耗時較長，最終還是搬出了CDN這個大殺器，一直沒上CDN的原因有很多，主要有以下幾方面：
（1）得物的頁面是千人千面的每個人看到的內容都不同
通過上述優化4即可解決，將原本SSR渲染的內容修改CSR，由于已經上了CDN了，后續計劃將這部分內容再次修改回SSR，這樣用戶可以更快的看到商品而不是骨架，然后通過 CSR 的方式來更新內容。
（2）頁面狀態變更，無法及時更新緩存
這個問題在上述客戶端預加載優化部分已經有解決方案了，可以通過在頁面打開后針對有需要的組件再次請求接口刷新數據以確保數據的準確性，但是這部分工作量也是比較大的，梳理出來的需要刷新狀態的組件就有30+，而且之后開發的組件都需要考慮狀態更新的事情。
（3）HTML模板內容變更無法及時更新
引起模板內容變更的地方有兩處，第一個場景就是在搭建器場景下，運營可以動態修改模板內容導致頁面結構變更（低頻次），第二個場景是項目發版后模板內容需要更新（高頻）。
這個問題可以通過在感知到內容變更時自動調用CDN服務商的刷新緩存接口來更新CDN緩存內容。
通過puppeteer將SPA頁面渲染出來并將HTML文檔進行保存，配合上述頁面刷新策略，并將HTML通過CDN進行托管，讓你的 SPA 頁面 像 SSR 一樣絲滑。
主要實現方案是通過基于webpack的插件prerender-spa-plugin，并配置需要預渲染的路由，這樣經過打包之后就會產出對應路由的頁面。方案本身是通用的，但是每接入一個頁面都需要人工check。
眾所周知 css 加載會阻塞HTML渲染，最終將首屏公共css從118kb縮減至38kb，下圖通過 chrome 模擬弱網環境下的SSR頁面加載時序圖。從圖中可以看出 styles.fb201fce.chunk.css 下載耗時 18s，阻塞了頁面的渲染，HTML 主文檔耗時 2.38s 就已經下載完成了，但是實際渲染時間卻是在 20s 之后。
優化思路也比較單間，將首屏所需要的css 文件通過內聯方式內嵌到HTML中，由SSR服務一并返回，并對css文件進行拆分，按需加載。
思路有了，接下來就看怎么去實現了，最初嘗試了MiniCssExtractPlugin 插件他可以把css分成單獨的文件，并且每一個js會對應生成一個css文件，但是他需要建立在webpack5之上，然而項目中使用的next版本是9.5，于是就想著升級到最新版next12，升級后發現，在構建中其他包各種報錯，發現有些包并不支持最新的next12，在嘗試一天的修復之后，仍未解決，且升級到最新版不確定是否會引發其他穩定性問題，暫且擱置尋找其他方法。
經過不懈的努力，通過閱讀 next 源碼發現了端倪，發現在打包時將所有的公共css通過 splitChunks 進行分組，由于項目中組件都是動態引入的，這里直接在 next.config.js 中修改webpack打包參數，將 splitChunks.cacheGroups.styles 配置刪除，使用默認的 chunks: async 配置，即可實現按需引入。
（1）避免圖片src為空
雖然src屬性為空字符串，但瀏覽器仍然會向服務器發起一個HTTP請求，尤其是在SSR服務器壓力扛不住的情況下，因此這里需要特別注意一下。
（2）圖片壓縮以及格式選擇
WebP 的優勢體現在它具有更優的圖像數據壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識別無差異的圖像質量；同時具備了無損和有損的壓縮模式、Alpha 透明以及動畫的特性，在 JPEG 和 PNG 上的轉化效果都相當優秀、穩定和統一。
通過向圖片服務器傳遞參數選擇合適的分辨率。
（1）打包優化
（2）非關鍵js、css延遲加載
（3）媒體資源加載優化
（4）其他資源優化
（5）頁面渲染優化
（6）代碼層面優化
為了幫助開發者更好地衡量和改進前端頁面性能，W3C性能小組引入了 Performance API ，其中Navigation Timing API 實現了自動、精準的頁面性能打點。得物前端性能監控指標也都是從 Performance API 中獲取數據進行上報統計分析的。
SDK 數據采集完畢后，會上報到 阿里云 sls 日志平臺，隨后通過 flink 實時消費清洗數據后落庫至 clickhouse 中，平臺后端通過讀取 clickhouse 數據并做各種聚合處理后使用。
做優化之前首先要建立監控指標，互聯網稱之為抓手，沒有監控指標的情況下，任你怎么優化，都不知道優化的效果怎么樣，更不知道下一步該做什么？以及還有哪些問題沒解決。因此優化之前指標先行，當然一定要指標的準確性。
指標大盤主要包含以下功能：
在正常情況下，完成上述的優化措施后用戶基本是可以秒開 H5 頁面的了。但異常情況總是會有的，用戶的網絡環境和系統環境千差萬別，甚至 WebView 也可能發生內部崩潰。當發生問題時，用戶看到的可能就直接只是一個白屏頁面了，所以進一步的優化手段就是需要去檢測是否發生白屏以及相應的應對措施。
檢測白屏最直觀的方案就是對 WebView 進行截圖，遍歷截圖的像素點的顏色值，如果非純色的顏色點超過一定的閾值，就可以認為不是白屏。首先獲取包含 WebView 視圖的 Bitmap 對象，然后把截圖縮小到指定的分辨率大小如:100*auto，遍歷檢測圖片的像素點，當非純色的像素點大于 5% 的時候就可以認為是非白屏的情況，但是還有很多列外的情況，我們通過圖片識別技術對截圖進行分析，可以很好的感知當前是否白屏、是不是在loading、是不是特殊頁面等。
白屏是一個重要的指標，我們針對整體白屏率快速拉升、新增白屏頁面發出告警通知，便于開發人員及時介入開始排查問題。
主要通過 CDN 未覆蓋監控、http請求監控、網絡監控（加載失敗、耗時異常、傳輸大小異常）、圖片監控（未壓縮、分辨率異常）等監控手段發現頁面中的潛在問題，同時還提供了問題分析能力，在問題分析頁面輸入頁面url地址即可幫助您發現問題并給出修改建議。
CDN的重要性不言而喻，它可以加速資源訪問速度，從而提升用戶體驗，我們通過對線上埋點數據分析，找出CDN未覆蓋的資源列表，從而推動各業務同學優化。
為什么要監控HTTP請求呢？我們先來看一下HTTPS相對于HTTP新增的特點：
那么HTTP就容易被中間人查看到內容，甚至被篡改，既然如此為了我們服務的安全性就需要對現有的http協議統一進行升級改造，那就需要監控去發現。
某些頁面秒開率低，那就要分析一下原因，是不是這個頁面的接口響應比較慢呢，還是說頁面本身有請求比較大的資源？如果發生網絡請求失敗的情況也要第一時間感知，不能被動等待用戶反饋。
包含圖片未壓縮、圖片分辨率異常、圖片傳輸大小大于 300kb 異常、動圖資源傳輸大小大于 1M 異常功能。
上面列出來一堆功能，對于業務的同學可能比較煩惱，我一個頁面具體有哪些問題呢？你不能讓我去上面的功能里面一個個看，哪個異常是我負責的頁面的吧？這個功能本身就行將現有的功能利用起來，通過一個頁面path進行聚合分析。
H5異常一直是使用 sentry 進行監控的，但是sentry系統因缺乏同PV、DAU數據的關聯性，因此無法衡量產品異常發生后所帶來的嚴重程度。在業務域關聯上的缺失導致異常問題無法根據業務域進行劃分。用戶行為日志也尚未與Native 端側打通，在問題分析時容易遇到上下文不全的瓶頸。還有一個問題是sentry會有限流措施，當qps較高時會丟棄一部分異常數據。
由于sentry已經可以幫助我們進行一定的問題排查分析能力，我們不打算做sentry同樣的功能，而是做sentry不支持的部分，針對上述問題我們設計了以下功能：
雖然目前秒開率已經做到了75%以上，但是同時我們還有一個重要的指標，90分位耗時，致力于提升末尾用戶H5頁面使用體驗，在90分位優化完成后，可能會考慮繼續深入優化95分位耗時。
至此我們系統的講解了背景以及從指標建立到秒開優化上線的全過程，全文分成了三個部分，客戶端、H5、以及監控。如果閱讀本文對您有所收獲，麻煩您動一動發財的小手點個贊吧！如果閱讀完還意猶未盡或者有什么問題和想法歡迎留言區評論交流。
最后奉上整體優化腦圖：
*文/徐銘
歡迎關注「得物技術」微信公眾號，每周一三五晚18:30更新技術干貨
要是覺得文章對你有幫助的話，歡迎評論轉發點贊～
于OZON的產品詳情頁來說，有兩種形式來表達，分別是：純文本和富文本形式。這兩種形式可以共存，關于富文本Json的內容可以查看歷史文章：https://kuajing365.cn/document/4516.html
那么這篇文章主要給大家介紹一下純文本部分的內容應該寫哪些？
如下圖所示：純文本填寫的內容在特征頁面填寫。
審批通過的產品的詳情頁的描述會出現在產品頁面如下圖所示位置：
那么關于產品詳情頁這里，我們主要應該放哪些信息呢：
1、產品的核心關鍵詞：這里也要出現產品的關鍵詞，要將產品詞以及核心修飾詞、屬性詞放進去。通常會以句子的形式完成，比如說：這是一雙非常輕便的女士跑步鞋。
2、產品的優點或者特點：在這里要將產品的優勢羅列出來，起到打動買家的作用。
3、產品的尺寸、顏色、容量等特征：一般來說，在描述的下方會有特征模塊。不過在這里可以適當將產品的重要屬性列出來。
4、品牌故事或者產品故事：如果你的產品是有品牌的，那么完全可以在這里講一個故事，或者圍繞產品設計一段話。如上圖所示的例子，就是專門針對這個拖鞋設計了一段文案，這個文案可以成為通用文案！那么對于俄羅斯用戶來說，這種方式會起到情感共鳴的作用，有效提升轉化率！
當然，描述信息這里與標題一樣，同樣有一些注意事項：不能描述臟話，不能包含以下非必要的推廣營銷信息，比如：“促銷”、“銷售”、“新奇”、“折扣”、“僅限今天”等詞；產品價格；短語“最佳產品”、“獨特產品”、“驚人產品”等；配送信息；不需要堆砌關鍵詞！
綜上所述，差不多從這四個方面來寫描述即可，也不用寫的太多，無論是哪個國家用戶，對于大段文字其實都是缺乏耐心的！所有更多還是需要配合jason富內容來優化詳情頁，提升整體支付轉化率！
文介紹了制定產品設計規范標準的重要性，也包括行業對于高級產品經理的要求，并以幾點詳細介紹，包括了制定標準的共同目標、基礎要素、設計原則、規范制定的流程以及如何推動規范的執行等。適合產品崗位的你閱讀。
每一款產品，都會有它的產品設計規范。例如支付寶小程序，微信小程序，有它的設計風格和交互的審核要求。
而適用于移動應用以及Web設計，可以參考Material Design（Google），強調直觀性、一致性和有意義的動效設計。
如果你是ios產品，那首先就得去了解Human Interface Guidelines（Apple），再基于這個設計規范制定符合平臺的標準，最通用，最基礎的，就當屬Microsoft Design Guidelines，適用于Windows平臺的設計規范，強調平面化、簡潔和直觀的設計風格。
為什么要制定產品的規范標準？
制定產品的規范標準可以提高產品的一致性、可用性和用戶體驗，幫助建立品牌形象、提升用戶滿意度，并為團隊提供明確的指導，提高工作效率和協作效果。
行業對于高級產品經理的要求:
在講這篇內容之前，先容許我把之前的幾篇文章給大家同步一下，感興趣的小伙伴或者遇到瓶頸的小伙伴一定要看，我相信會對你們的提升帶來很大的幫助，內容很長，建議先收藏。
我們先來簡單的對規范標準有個概念，有很多小伙伴都總是會在這兩個詞進行拉扯，但其實這兩個詞加起來就代表了準則。而規范則是基于標準之下，如支付寶小程序，它的設計規范，對于我們來講，就是平臺的設計標準，我們基于這個標準下再去制定屬于自己產品的設計規范。
那我們現在來看看，標準和規范在文學上的區別為：意思不同、出處不同。
① 意思不同
② 出處不同
規范要求和標準的區別：
③ 成因不同
接下來，我們開始今天的主要內容。小編會通過三個篇章，七個章節，給大家提供落地的方法。
倘若你目前剛好處在對于制定產品的規范標準無從下手的階段，以下內容絕對能夠讓你按部就班的完成；假如你已經為多個平臺制定過標準，也可以參考本篇內容，思考下有沒有進步的空間；假如你從來沒接觸也沒有機會制定，那么，這篇文章就是你的敲門磚。
小編總結了十點，先給大家介紹一下，我們為什么要去做這個事情，這個事情給我們帶來什么價值。
作為產品，我們必須要清楚一個原則在于：我們做的任何事情，都得有它的價值，要清楚它的目的再去做，拒絕為了做而做的行為，切勿讓自己變成了傳聲筒。
綜上所述，制定產品的設計規范標準可以帶來許多益處，包括提升用戶體驗、降低開發成本、增強品牌形象和改善團隊協作。
規范的制定和執行有助于打造出一致、優質的產品，提高用戶滿意度和市場競爭力。
產品設計的常識（Common Sense），很多時候都會被忽略，特別一些小型項目。研發人員會在初期嫌麻煩不對一些常識的問題進行處理，最終導致的影響，往往是影響到產品的本身。
產品一定要把控好這個關卡，誰都可以不懂，產品一定要最清楚最基本的就是系統異常處理設計規范能夠有效解決且避免以下七點：
產品設計是否保持一致很容易反映出一個產品經理做事情的嚴謹性。有不少產品經理設計產品很隨意，抱著“能用就行”的態度做設計，結果就會出現整個產品的一致性非常差。
比如，列表的添加按鈕一會在頁面的右上角，一會在頁面的左上角，搞得用戶使用不同的頁面像是在玩“躲貓貓”游戲一般，學習成本非常高。
再比如移動端，有些頁面使用長按刪除，有的使用向左滑動刪除，還有的需要點擊“…”在彈層中點擊刪除……同一個產品，多種交互形式也會讓用戶困惑。
至此，產品的規范標準入門篇已經跟大家介紹完了。大家在做任何一個項目的時候，都應該注意入門篇的兩個章節，究竟有沒有做到位，有沒有制定規范標準同步到設計，研發。
入門篇基本滿足大部門從0-1的項目，或者是初中級的產品經理所需要掌握的技能，建議大家收藏起來。如果遇到這類任務的時候，就可以以這篇文章，作為你們的任務List，一項一項對應的去檢查是否有做到位。那么我相信你們吹來的作品，一定是具備一定的專業度，一致性以及可延展性的。
在入門篇開始之前，先給大家交個底。我們在制定產品入門篇的規范標準時，有一個部門必須拉他們參與進來，那就UI部。UI部門在入門篇的環節，起到了決定性的作用，由他們為主導，我們為輔助的方式，達成一致性的決定。
這一個環節，最重要的目的是讓產品與UI保持同頻，大家都在統一規范標準下進行設計，為產品添磚加瓦。而且通常我們都會把這個環節以一個功能模塊級別的需求去做，也有這個需求的版本，持續優化迭代。
當然，需要優化迭代的時候，那就應該是由產品為主導，在原有的標準下，再去優化規范，最終形成新一版的規范標準。
這個環節也是能夠讓產品在與UI溝通上的成本減少，在同頻基礎下工作也有利于減少兩個部門之間的摩擦。
相信大家應該也聽說過交互設計師這個崗位，大多數在中小型企業很難有資源去匹配這個崗位，一般都是在成熟的互聯網公司會有這個崗位的需求。
通過這么個規律我們也可以發現：需要注重交互設計，往往到了產品已經扎根土地，茁壯成長的階段。
相對比較穩定的時候就會開始考慮這個問題，但并不代表說，交互設計不重要。交互設計對于產品來言，在做需求時，靠的是經驗，靠的是競品分析，靠的是借鑒。
看到這里的小伙伴們，自動自覺對號入座，往往一味的靠經驗，靠競品，靠借鑒，只會讓產品的交互五花八門，沒有一個體系。單個功能抽出來可能是合理的，方便的；但全部湊在一起的時候，倘若需要用戶去適應，那么就適得其反。
因此，我們產品就需要UI同學幫忙一起制定出產品交互設計規范，而產品本身，也應該有一套自己的標準，把控好產品的交互，這樣才有利于產品的發展。
接下來，我會通過收集一些常見的交互問題，給大家用實例去介紹產品交互設計規范如何制定。
1）做一個頁面交互設計的時候要注意什么？
2）如何理解模態框？
何時應該使用模態框？模態框和阻斷框有什么區別？
模態對話框(Modal DialogueBox) ，阻斷(Blocking），可以用兩個比喻給大家解釋：
3）在具體設計一個產品的過程中，把握住哪些關鍵點才能讓整個產品有著一致的交互體驗，或者交互模式？比如iOS端和android端，比如web端和移動端？
一致性，在交互設計中非常重要！保持交互一致性，有兩個武器：原則和規范。
規范又有兩個層面：指南Guidelines和規格
原則
一些指導性的東西，在設計當中要遵從。在整個產品（無論多少端，多少子產品）都要遵守的。
舉例：一個界面完成一個任務；表單超過10項必須分步驟；用戶必須隨時能回到主界面……這些原則可以由不同的形式來實現，但必須遵從這些原則。
規范
文章開頭也有提及到，忘記了請翻上去復習一下。
指南：圈定具體的交互模式、色彩搭配和設計禁忌。
在這個層面，一個[構]可以有多個[形]，但某個形只能有一個[構]，達到相同位置、相同外觀、相同操作。通過指南能夠讓各個端（IOS和安卓）看起來似曾相識，便于用戶學習和養成習慣。
舉例：在沒有左側導航的詳情界面，必須包含面包屑；面包屑只能出現在PC瀏覽器端，不允許出現在響應式web界面中。
IOS和安卓的官方Guidelines就是這樣的東西，但也可視情況制定私有的指南，也就是各個公司自己的設計指南。
規格：規格非常具體的描述了每一個模式的每一個形態的具體尺寸、色彩、響應，精確到數值。
舉例：一級標題，字號為宋體 18pt；行高30pt；行上下外距為5pt；色值為#CC9300。
3）表單布局有什么規范要注意的？
這個問題是初級產品經理最容易犯的問題，設計太隨意，看到別人的就想復制粘貼過來。這個問題正是可以解決很多初級產品常見錯誤的問題，以及給大家提供一個思路。
這里分享四個常見的表達布局對齊：
首先，我們要清楚，人的視覺是上下，左右的。所以我們會把要填寫的標題，放在左邊，輸入的內容放在右邊。這個原因也在于大部分都是右撇子，所以放在右面方便輸入，而在左邊提到的四點，各有千秋。
關鍵在于考慮的出發點是用戶的視覺，還是表單的體驗，抑或者是信息是否足夠直觀。再者就是是否夠簡潔，都是可供選擇，關鍵在于選定一個就保持一致。
綜上所述我們可以知道，交互設計可以通過交互的顯性和交互的隱性去考慮。
交互顯性
交互顯性指的是用戶在頁面所有的點擊，滑動，跳轉的操作，比如刷新方式有下拉、上滑、按壓點擊等方式。
這就是所謂的交互顯性的操作。要保持產品顯性操作的統一性，同類別的交互不可有不同的操作感受。同時交互顯性要符合大眾的認知習慣，可創新但不可違背潛意識，比如說PC端的交互顯性是以點擊事件作為核心操作的，移動端的交互顯性是以滑動作為核心操作的。
交互隱性
交互隱性指的是用戶信息發生改變時的顯示。比如說訂單狀態的顯示，確認收貨后，綠色的標簽顯示訂單已完成，申請售后則有售后的標簽，一些平臺還會以訂單的顏色區分去給用戶隱喻。
再舉個例子，消息有個小紅點，用戶就會知道去點，上文也有提到隱喻，很多時候，我們就是通過交互隱性的方式，來引導用戶，提示用戶，這樣的方式有利于讓用戶自發性去體驗，感受平臺的功能，帶來舒適感。
歸根結底，產品的交互離不開創新，一致，符合規范。
本章節我們以Web端為例，我們在設計過程中，需要考慮我們基于什么樣的尺寸進行基礎設計。劃分哪些區域需要固定尺寸、哪些需要做適配等。
據統計，使用中系統的用戶的主流分辨率主要為 1920、1440 和 1366。
設計思考，有如下幾點：
web頁面是按照Html的設計規范標準進行布局設計的，由以下三部分構成:
1）Margin（邊距）
為避免頁面元素緊貼邊沿的情況發生，WEB 頁面和其中的表格，應設定邊距，最小邊距值為 “3px”。
一般粗細直角以1px，圓角為2px。
2）Button（按鈕）
按鈕一般有三種樣式：小、中、大。
按鈕是交互設計中必備的元素，它在用戶和系統的交互中承擔著非常重要的作用。
后臺中常見的按鈕類型分為線性按鈕、文字按鈕、圖標按鈕等。
按鈕并列間距為：小間距8px，中間距16px，大間距24px
其中小中大的寬度分別為：58px，74px，96px
3）Table（表單）
常見表單是由多個列表項構成的。而每一個列表項都是由最基本的標簽和輸入框組成，常規的表單包括單選、多選、下拉選、輸入框、時間選擇、開關選擇等控件。
頂部標簽是標簽在控件的上方，標簽可以和控件左對齊，對于橫向空間不足的情況是一種很好的方案。
豎列標簽的使用場景思考：
表格的設計思考：
表格的設計規范的設計思考點如下：
表頭的文案，可遵循信息降噪的原則思考：
4）Progress bar（進度條）
進度條的設計思考：
加載中進度條，存在加載中、成功、失敗三種狀態通過顏色去區分，進度條長度支持自定義。
5）Dialog（彈窗）
彈框主要分為兩個大類模態彈框和非模態彈框，他們最大的區別就是是否強制用戶交互。
常規狀態通常出現在頁面的上方，有普通信息、成功信息、失敗信息、警示信息四種icon。
6）Default（缺省狀態）：
缺省頁面是當頁面沒有數據、用戶沒有建立資料或網絡連接不通暢的情況下所展現的頁面。
為了緩解用戶面對這類情況產生焦慮情緒，設計師可以用一些插畫和文字的結合來引導用戶進行下一步的操作。
產品風格設計的形成一般通過以下幾點：顏色，字體，圖標，尺寸決定的。
1）Color（顏色）
色彩內容主要包含基礎色（如品牌色、黑色、白色）和功能色（如鏈接色、提醒色等），圖表配色為單獨的配色體系。
在前期制定顏色規范的時候，精益求精的設定顏色，切忌顏色過多。
顏色的狀態色盡量用原色進行轉換，設置一個合理的變色公式，讓所有顏色的狀態色都根據這個公式進行轉換。
例：
在設計規范中，盡量把顏色的色值和 rgba 值都寫出來（這里是強迫癥患者要標的，因為有時候色值完全一樣，但 rgba 數值略有不同，雖然效果一樣，但是對于強迫癥的你來說，舒服嗎？）。
狀態色有 4 狀態色：Normal、Hover、Click、Disable。
在設定圖表顏色的時候，要考慮不同的使用樣式（柱狀圖、環形圖、餅圖等…），同時也要考慮他的延展性。比如你設定 12 個 chart 色值，在使用的時候按著順序來使用，當超過 12 個后可以為同一個顏色。
2）Font（文字）
設定統一的字體規范，使用非襯線字體在各個操作系統下都有最佳展示效果。
首先，要設置一個字體家族，保證產品界面的最優展示。
例如（僅作為展示，不是建議）：font-family: “Chinese Quote”, -apple-system, BlinkMacSystemFont, “Segoe UI”, “PingFang SC”, “Hiragino Sans GB”, “Microsoft YaHei”, “Helvetica Neue”, Helvetica, Arial, sans-serif, “Apple Color Emoji”, “Segoe UI Emoji”, “Segoe UI Symbol”;
字號
現在主流的產品中，主體字為 12px / 14px的居多，可根據自身的產品定位以及用戶的習慣進行設定。
字號不要出現奇數，否則在一些顯示器上會有對不齊像素的狀況發生。
字體顏色
字體顏色數量建議在 3~4 個，不宜過多，但是每個層級之間區分要大一些。
文本應該保持至少 4.5:1 （基于亮度值計算）的對比度以保持文本清晰；最佳對比度為 7:1。
測試對比度的網站：https://contrast-ratio.com
WCAG 2.0 中將顏色對比等級分為 3 種，A級，AA級，AAA級，等級越高意味著顏色的對比度越高，呈現出來的視覺壓力越大。
3）icon（圖標）
設定統一的圖標使用規范，讓視覺效果更和諧。
icon大小
icon 的常用尺寸有很多，需要注意的是 icon 的大小中，相鄰的兩個尺寸至少相差 4px，否則你會在后期用的時候會有選擇困難癥。同時功能 icon 盡量貼邊或盡量貼邊繪制，保證展現的視覺統一性（操作 icon 除外）。
單獨 icon 使用的時候，盡量不要太小，最小值建議為 12px。
icon 熱區
icon 的熱區經常被設計師和開發所忽略，本身 icon 的尺寸一般就很小，再加上如果沒有設置熱區的話，操作體驗極差。
所以一定一定要設置 icon 的熱區，設置的值我建議為 icon 大小的 2倍。例：icon 大小為 14 * 14px，則熱區大小為 28 * 28px。
4）size（尺寸）
頁面內布局間、模塊間、模塊內的各部件距離。
尺寸大部分規范中都用的是 8 的倍數，不用糾結，直接用就行。我這里有個公式：Sn=8px * n，n為正整數。特殊：最小支持4px。
進入進階篇階段，我們不只是按照行業標準制定規范，也不是按照一些平臺標準以及常識問題，去為自己的產品制定規范標準。而是需要投入更多的精力，站在更高的角度去思考要為產品帶來什么價值。而價值的體現就在于轉化，管理，引導，復用，創新，切忌盲目動手。
在進階篇沒有唯一的標準，都需要各位結合自身產品的業務，產品定位，用戶畫像去制定。
接下來的內容，也只是小編分享一下比較通用的方法，希望能夠幫助有緣人在迷茫的時候有個新思路。
在開始之前，再給大家補充三點，作為進階篇學習之前，所需要結合著來學習的3個方面：
引導分為 5 種：Newbie guide（新手引導）、Steps guide（步驟引導）、Help / Operation guide（幫助/操作引導）、New function guide（新功能引導）、Blank guide（空白頁引導）。
1）Newbie guide（新手引導）
新手引導是針對新用戶的，首次進入產品的時候，我們要著重的把自己產品的亮點以及操作快速的介紹給新用戶，讓他用最短的時間上手我們的產品。
新手引導要言簡意賅，并且如果非必要的話，盡量給用戶一個可以直接關閉的按鈕，讓用戶有選擇權。我就非常討厭有一些產品的新手引導，必須走完全部流程后才能關閉，惡心的不行。
2）Steps guide（步驟引導）
步驟引導一般用在有固定操作步驟的場景下，指引用戶一步一步的完成想要的結果。常規的步驟引導建議在 3~5 步之間為合理。
3）Help/Operation guide（幫助/操作引導）
幫助/操作引導的展現方式是比較豐富多彩的，可以是提示語、輔助性文本、tooltips 等等，他的作用就是輔助用戶去了解并且知道如何操作這個功能。
這個也是在產品中使用頻率最高的，運用好他，可以讓你的產品事半功倍。
4）New function guide（新功能引導）
他就是常用在新功能上線后，用戶第一次登陸相關頁面后做的一些引導，目的是為了告訴用戶我們做了新東西，你快來試試吧。
5）Blank guide（空白頁引導）
空白頁引導一般用在在缺省頁，對用戶進行一些操作指引，讓無信息的頁面變得更有價值。比如百度在一些缺省頁上就放了一些關于失蹤兒童的信息，就因為做了這個引導，幫助了千萬個家庭找到了失散的孩子。
這一章節在很多平臺里面，都會給忽略掉它的一個重要性，一個產品的延展性，通用性，易用性和親密性都離不開一個好的角色設計規范，角色設計的底層邏輯就是產品權限的制定。
目前的主流產品對于權限的制定都有一套規范標準，小編負責的產品也是通過借鑒主流產品權限的制定方式來設計，本章節主要是給大家分享下小編的方法。
我在做權限制定的對象是角色，而不是用戶，所以也點一下題，我們在做的是對產品角色設計的規范，并不是對用戶權限去做控制，接下來我們先來梳理下在做權限制定的時候常見的問題。
1）權限制定的過程中常遇到的問題有。
我們可管理的權限（系統資源）分為功能權限、數據權限：
這些問題主要都是基于用戶作為權限主體的時候會出現的問題。傳統的方式就是A -> B -> C 這類型的用戶權限去對用戶進行管理，對于業務的調整以及對功能模塊的拓展是不友好的。
因此，我對于權限管理的理解為權限是主體對客體遵循特定機制做出的行為，而本章節主要是給各位分享RBAC模型。
2）對RBAC模型中的關系描述 – 基于角色的訪問控制
RBAC（Role-Based Access Control）是一種訪問控制模型，用于管理系統中的用戶訪問權限。RBAC模型基于角色來定義和分配權限，通過將權限與角色關聯，然后將角色分配給用戶，實現對系統資源的訪問控制。
1. 角色與權限之間的關系：
2. 角色與用戶之間的關系：
這些關系形成了RBAC模型的基本結構，通過這些關系的建立和管理，可以實現對用戶訪問權限的控制和管理。
3）對RBAC模型的分析
RBAC模型的優點包括：
然而，RBAC模型也存在一些挑戰，如角色爆炸問題（角色數量過多）、權限維護復雜、權限繼承問題等。在實施RBAC模型時，需要仔細設計角色和權限的結構，平衡權限的粒度和靈活性，以及確保合理的權限繼承和分配策略。
4）分享一個使用RBAC模型的實例
假設有一個在線學習平臺，涉及學生、教師和管理員三個角色，以及對應的權限：
1. 角色與權限之間的關系：
2. 角色與用戶之間的關系：
3. 在該實例中，RBAC模型的使用如下：
通過RBAC模型，該在線學習平臺實現了對不同角色的權限控制，確保每個用戶只能執行其角色所允許的操作，從而提供了安全和可控的訪問控制機制。
5）最后，對本章節進行一個總結
在權限模型里面有兩個核心概念，第一個是靜態指責分離，第二個是動態指責分離
靜態職責分離
互斥角色限制：有些特殊的崗位，同一個用戶在兩個互斥的角色中只能選擇一個。
比如財務和審計，不能既是運動員又做裁判。
基數限制：考慮容量、并發等的問題，一個用戶擁有的角色是有限的，一個角色擁有的權限也是有限的，一個角色下的用戶也是有限的。
比如微信公眾平臺做的限制：一個微信號可綁定并管理5個公眾號。
先決條件限制：用戶想要獲得高級別的角色，必須先獲得低級別的角色。
比如一個PMer需要先從專員做起，再升為產品經理，再到產品總監。
這種條件限制在人員規模比較大的團隊就很常見了，人越多越需要嚴格且清晰的制度，避免個別的take a shortcut影響大局的穩定。
動態職責分離
動態的限制用戶及其擁有的角色。
一個用戶可以擁有多個角色，但是運行時只能激活一個角色。
常見就像招聘網站這種，用戶既可以招人也可以找工作，角色不同看到的信息完全不一樣，所以就只能激活其中一個角色。
最后給大家總結一下今天分享出來的內容，產品設計的規范標準，具體的規范還會根據產品的特點、行業要求和用戶需求而有所不同。
在制定產品設計規范時，需要綜合考慮用戶體驗、技術可行性、業務目標和品牌形象等因素，以確保產品能夠提供優質的用戶體驗并達到預期的目標。
歸納為以下8點：
本文由@樂少有話說 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
