先看目錄，大家按需取用，當然更建議全文閱讀（全文7756字，建議閱讀20分鐘）
大部分設計師應該都遇到過這種場景：在做設計前并沒有考慮到加載，但在進行還原度走查或者驗收的時候才發現，由于某些頁面數據請求較慢，導致在頁面中會出現空屏狀態。這時才想起需要在這些頁面添加動畫來承載頁面的過渡。
歸根結底是因為設計師在設計過程中，更多關注頁面本身，而很少去思考頁面在呈現過程中何時會出現白屏狀態，都是后知后覺去補充完善。加載作為必備的一環，卻總是被忽略。目前很多B端產品在這方面都沒有一個系統合理的規劃，導致系統的加載體驗缺失或者不統一。
因此希望這篇文章能夠講清楚中后臺加載出現的場景和規則，對需要深入了解加載以及在制定加載規則的設計師朋友們帶來一些幫助。
加載通俗來講就是用戶從觸發頁面操作，到頁面最終呈現的一個等待過程。這個過程始終存在不可避免，只是時間有快有慢?？斓募虞d只需要幾百毫秒就結束，但慢的加載就可能會達到幾秒甚至十幾秒，讓人產生焦慮。
而為什么會有如此大的差距，這就需要從頁面渲染的整體過程來進行說明。當我們從瀏覽器輸入網址，再到我們看到完整頁面的這個過程，網頁到底經過了哪些步驟呢。經過資料查詢和與前端確認，整體過程可以闡述如下：
從這里我們可以看到頁面的呈現是程序經過了一系列操作才最終呈現到我們面前的。在這里可以將其簡化為四個階段：用戶操作功能→頁面向服務器發送請求→服務器接受并返回數據→頁面呈現。
而決定整個頁面加載快慢的就在于請求與數據這里。一般我們可以將頁面的數據分為2種類型：靜態資源和動態資源。
靜態資源：前端的固定頁面，這里面包含HTML、CSS、JS、圖片等等，不需要查數據庫也不需要程序處理，直接就能夠顯示的頁面。可以簡單理解為你頁面上的固定字段和結構。這種頁面一般加載速度比較快，比如我們看到的展示型官網一般都是前端寫好的靜態資源。
動態資源：而對于頁面上的動態變化的，需要程序處理或者從數據庫中讀數據，能根據不同的條件在頁面顯示不同的數據，比如表格數據、統計數據等稱為動態資源，這種都需要調用后臺接口來進行返回，因此加載速度相比于靜態資源就會更慢。
而它們的區分點用下圖可以表示：
可以看到靜態資源基本是直接返回，而動態資源還需要連接數據庫調取資源，尤其是在遇到數據庫調取較慢時就會花費更多時間。而我們加載緩慢的大多數問題，也基本上更多出現在動態資源的獲取上。
當我們清楚加載形成的原因，接下來要做的就是在需要加載的地方對其進行處理。這也是在設計過程中我們經常遺漏的地方。我們先看一下目前常見的2種處理方式：「默認處理」和「使用進度指示器」
2.1程序默認處理方式：直接顯示
當我們對加載過程不進行任何處理時，程序就會以默認的方式進行-即根據資源獲取速度一步步呈現?？梢钥吹胶俚旰笈_的處理過程就是一種默認處理方式：
但是這種做法就會導致我們在頁面加載過程中會出現空屏狀態，比如上圖切換到概覽時出現了空屏狀態，尤其是當遇到了網絡緩慢的情況，會造成在加載時頁面停留在當前狀態下不動，往往會讓用戶陷入到「系統故障」的錯覺。
2.2通用處理方式：進度指示器
這個名詞說起來可能比較陌生，它指代的就是我們平時經?？吹降募虞d動畫、骨架屏或者進度條等。進度指示器的作用就是告知用戶當前頁面并沒有故障，而是正在讀取數據。
通過添加進度指示器來對空屏狀態進行承載，能夠減輕用戶的焦慮感。目前很多B端產品更通用的形式是添加動畫來過渡。
但是在體驗過程中很容易發現一個問題，就是在產品的整體加載過程中，某些空屏狀態是沒被加載動畫覆蓋到的。當這些沒被覆蓋到的加載過程過長時，很容易出現焦慮感。比如神策數據在左側列表切換時的加載過程就沒被覆蓋：
想要更全面的把加載動畫覆蓋到所有頁面，我們就需要弄清頁面在哪些狀態下會出現空屏狀態，從而制定統一的加載動畫規則。這個問題可以先思考一下，后面解答。
在制定統一加載規則之前，我們需要明確一個概念，就是加載的模態與非模態。
3.1模態加載
模態加載的含義就是當前加載會中斷用戶其余操作，用戶在這個期間只能等待加載而不能進行其他操作（有的模態會提供取消按鈕）。如果你的頁面涉及到以下2種情況，可以考慮使用：
1.用戶當前的操作本身不能與其他操作同時進行。比如系統更新，或者工具類的導入導出相關操作，我們只能等待更新、導出完成才能繼續進行后續的操作。這時候可以使用模態加載來承載，比如protopie的導入操作；
2.當用戶進入到一個全新的頁面時，這個時候頁面什么都沒有，我們只能等待頁面加載完成才能進行后續的操作，因此在這種情況下也可以采用模態加載，比如我們剛進入Asanan產品頁面看到的首屏加載動畫：
除了上述2種情況外，你也可以根據你的業務場景來進行模態加載的選擇，但建議是盡量少用模態加載，其會對用戶的打斷和干擾性比較強。
3.2非模態加載
非模態加載的話，這種加載通常只會出現在需要加載的部分，不會中斷用戶其他操作。對用戶干擾比較小。比如我們常見的功能切換加載、數據篩選加載等都屬于非模態加載。
非模態加載相比于模態加載會更輕量，因為用戶隨時都可以打斷也不會影響到其他操作。因此建議在大部分情況下都可以使用非模態彈窗來進行承載，比如飛書的左側欄切換操作：
接下來我們進入正題，在這里我從加載的角度將網頁整體加載過程分為呈現加載規則和操作加載規則。
我們先談頁面呈現規則。前面已經明確加載產生的原因和類型后，我們就可以開始為我們的產品制定統一的加載規則，以保證后續頁面加載的一致性。
4.1 頁面的加載過程拆解
在拆解頁面的加載過程前，我們進一步闡述之前提到的渲染原則，從前文中提到最后會經過「解碼」和「渲染」2個步驟，這也是決定了我們看到的頁面的最終呈現順序：
1.頁面的渲染順序
我們看到的頁面是由HTML、CSS和JavaScript來進行構成的。HTML可以看作最簡單的框架、CSS則是賦予了框架樣式，JavaScript則是負責頁面中的交互(當然JS也可以控制樣式，這里只描述主要功能)。
頁面在「解碼」階段，拿到的HTML文檔會被解碼為DOM樹，同時將CSS文件解析成CSSOM，這兩者結合后一起渲染頁面，JS一般是在最后渲染。所以邏輯上就是框架和樣式一起渲染，最后渲染交互。視覺的角度來講就是先看到元素樣式，然后才能進行對應操作。
2.頁面呈現的視覺順序
由于瀏覽器渲染順序一般會根據代碼的順序進行渲染，而代碼在頁面中的構建一般也是按照頁面的上下和左右的順序去寫的，因此我們看到的頁面的視覺呈現順序也是遵循從上到下，從左到右。
所以幾乎所有的產品都是先看到頂欄，然后左側邊欄，然后其他內容。因此我們可以通過這個原則來拆解對應的頁面，我們按照頁面常規結構可以將其分為三個加載部分：頂欄、左側導航欄、內容區域。而其加載順序如圖所示：
當知道對應頁面的渲染順序后，我們就能夠清楚在頁面渲染的過程中哪些地方會出現空屏了。因此將頁面加載過程拆解為如下順序：
我們的加載動畫需要承載的就是上述這些白屏的地方，從而將加載細化為三種場景的拆分：全局加載+局部加載+內部加載。如圖所示：
通過這三種加載就可以涵蓋頁面所涉及到的所有部分。接下來詳細闡述一下這三種類型的定義和用法。
4.2 全局加載
如上圖所示，全局加載的目的是為了覆蓋用戶從輸入網址到頁面的資源渲染的這個中間過程的空屏狀態而存在的。而這種狀態會涉及三種場景：
1.通過網址進入到一個新的頁面時；
2.通過鼠標右鍵或網頁刷新按鈕對該頁面刷新時；
3.通過頁面操作需要新開頁面時。
該全局加載的動畫構成為：
1：覆蓋整個頁面的加載，由純白色+加載動畫構成；
2：加載類型為模態加載，因為用戶在這種頁面狀態下并不能進行其它操作。
但在這里我們需要注意全局加載的開始和結束時間：
開始時間：當進入頁面時立即呈現加載動畫；
結束時間：當頁面加載出頂欄的時候，此時停止加載。
為何要這么處理結束時間，原因其實圖中已經給出了。這里再解釋一下原則：只要有頁面資源返回，我們的全局加載動畫就會結束，隨后啟用局部加載來承接后續的狀態，避免用戶在當前狀態長時間等待。而頂欄在一般情況下都是最先加載出來的，所以以頂欄出現作為結束全局加載的標準。當然如果你的結構沒有頂欄，可以以左側欄來作為結束標準。
4.3 局部加載
局部加載是用在頁面整體框架加載的過程中，承接在全局加載后。局部加載的使用場景可以概括如下：
1.頂欄加載結束后，用在剩余框架的加載效果（具體體現為左側邊欄和右側內容區域）；
2.對于涉及到局部頁面的切換操作都會進行局部加載（比如左側邊欄的切換）；
光看文字可能不是特別清晰，在這里可以舉一個動態的例子來幫助理解：
上述展示的是在頁面呈現的時候一個完整的局部加載。在這里需要注意的是我們首次渲染和第二次渲染在加載動畫上是可以有區分的，可以通過程序控制讓這種加載動畫只在初次加載時出現。
第一次加載時出現是因為我們需要有加載動畫來承接框架首次加載的空屏時間：
但第二次的時候由于有緩存（緩存會加載我們的靜態資源，能夠讓我們的頁面框架在第二次時更快顯示），這樣在讀取框架時基本不需要加載，我們就可以通過程序來直接去掉其中的局部加載動畫，直接顯示框架來進行呈現。
目前在飛書和釘釘等B端產品后臺均采用了這種處理方式。可以看到圖中我在第一次切換到角色管理時是有碰撞小球的局部動畫存在的，而第二次再次進入時則直接出現框架。這樣既能夠保證加載動畫能夠覆蓋所有的空屏狀態，又避免了局部加載動畫的頻繁出現。
4.4 內部加載
內部加載是用在頁面內部不同模塊數據間的加載。當框架都已經加載結束，但某些數據由于接口比較慢，此時還沒有返回，這時我們就可以用內部加載來進行承載。這應該是我們更常見的加載情況：
在進行內部加載的時候，需要注意，內部加載的時候一般標題是存在的，因為標題基本都是固定的，所以能夠很快被拉取。比如Zoho的內部加載，加載時標題已經出現了：
通過這三種類型的加載，能夠覆蓋從用戶輸入網址，到頁面渲染完成這個頁面呈現過程中的全部加載場景。
說完頁面的呈現規則，再談頁面操作加載規則。頁面的操作其實對應的是頁面控件的反饋。而我們的常用的控件比如有按鈕、tab切換等。我們不僅需要考慮控件本身的加載狀態，而且需要考慮到控件影響的其他頁面范圍。
5.1需要考慮控件本身加載
控件的加載并不是隨時都需要，我們要根據實際的數據量大小及業務場景來選擇性使用。目前我們需要考慮的控件及其加載狀態主要有如下：
比如圖中的按鈕的加載狀態是必備的，在很多場景下都會用到。但是下拉列表和級聯列表，在一般的場景下都不太需要進行加載，當遇到列表中的數據特別多或者調取特別慢時就可以考慮為其加上加載狀態。
5.2當控件操作會影響到頁面其他元素
這種控件比如日期篩選、表格篩選或者保存等操作，當你切換篩選條件后所有與其相關的頁面元素都會發生變化。在這種情況下我們需要考慮到被影響元素的狀態。目前的設計實現上有兩種做法：
1.被影響元素不可被操作，且該區域有遮罩+加載動畫來覆蓋；
2.被影響元素可進行操作，無任何動畫，但操作并不會影響之前提交的結果；
這兩種方案一種是利用遮罩防止用戶無效操作，另一種則是保持了足夠的操作自由性。個人在這里更傾向于處理方式1，我認為被影響的元素是需要有遮罩+動畫的，來避免用戶在加載期間對其進行無效操作，比如示例中方案2后面修改的名稱是沒有被系統保存的。
需要注意的是如果在產品中使用方案1，我們的遮罩區域只需要覆蓋被影響的元素就可以了（保存這種可以將按鈕一起覆蓋），比如通過篩選導致圖表數據發生變化，這時只需覆蓋圖表區域，而不用覆蓋篩選區域。這樣的好處是當某些篩選數據出現加載過慢問題時，用戶可以通過切換篩選項來打斷當前加載。
上述描述的操作都是針對于當前頁加載。當控件導致頁面刷新或者跳轉時，則整體遵照頁面呈現的規則進行加載。
上面闡述的加載已經完全能夠覆蓋我們頁面整體的加載，但是還是需要提及一下骨架屏和進度條這兩種加載形式。
先說骨架屏。實際上骨架屏的使用效果體驗是優于加載動畫的體驗的（骨架屏的加入使用會讓用戶感覺網頁出現的更快）。那么為什么在大部分的B端業務頁面中沒被用到呢，主要有2點原因：
1.每種骨架屏都需要進行對應的定制開發，需要與加載后的頁面框架保持一致，這會增加了開發成本。
2.中后臺的業務界面對來說固定結構的頁面會較少，這對于骨架屏的使用機會就相對較少。
個人認為在前期可以以統一加載體驗為主，在后期業務相對成熟后，可以針對固定結構，通過骨架屏的使用優化加載體驗。
再說進度條。我理解的進度條的使用條件：對于加載時間較長的規定場景可以考慮用進度條來承載，比如我們常見的游戲加載中進度條就用得比較多，因為游戲一般資源比較大。還比如figma在進入設計文件的過程中也采用了進度條加載也是因為設計文件可能會很大。
進度條在特定場景下能夠緩解用戶焦慮，讓用戶知道進展。但進度條在多數情況下都抓取不到程序的真實進度，這也會導致有時候我們看著加載到99%，那最后的1%遲遲加載不出來的的原因。目前很多中后臺產品對于進度條加載使用相對較少的原因，很大程度是沒有那種加載特別長的場景。
因此這兩種加載場景的使用會更加定制化，如果需要使用請根據具體的業務場景來進行選擇。
如果把加載動畫等比作頁面加載的外在，那么緩存和加載策略則是頁面加載的內核，合理使用緩存和加載策略可以從根本上提升我們頁面的加載速度，讓用戶更快速地看到頁面。
7.1 關于頁面的資源緩存
大家肯定聽過緩存這個概念，前后端都可以使用緩存。緩存就是數據交換的緩沖區（稱作Cache），是存貯數據（使用頻繁的數據）的臨時地方。在這里主要講一下瀏覽器緩存：
從這張圖可以看出，服務器在請求數據時，會進行緩存的判斷，如果有緩存則首先讀取緩存，如果沒有則從服務器中拿取。調取緩存會在很大程度上提升頁面的加載速度，縮短了從服務獲取數據的時間。通常瀏覽器會主動對頁面的靜態資源進行對應的緩存，這也就解釋了我們第二次進入頁面會比初次進入頁面時加載快的原因。
但程序其實也可以對動態資源（也就是需要從數據庫等拿到的資源）進行緩存的，并且可以設置緩存的過期時間（比如設置過期時間為1小時，那么1小時過后就會重新拉取新資源）。對于某些動態資源拉取過慢并且更新頻率不高的我們可以采用動態資源緩存的策略，從而提升整體的頁面加載體驗。
7.2 加載策略的正確使用
現階段我們常用的主要有下列6種加載策略：
加載策略的本質就是通過對應的加載設置來縮短產品與服務器交換數據的時間，接下來我們詳細看一下每種加載策略的具體使用策略：
7.2.1懶加載
懶加載是當內容落入視窗被用戶看到時，才會進行加載。這種比較節省資源和減輕服務器壓力。對于當前頁面內容很多的可以采用這種加載策略。而這種加載策略的設計，能夠讓用戶更快看到當前屏幕內的內容，減少等待時間。
比如蘋果官網的加載策略就采取了這樣的一種方式。我們可以看到右側的資源只有在我們向下滾動出現在屏幕中時才會進行對應的加載，這樣能夠保證用戶在進入網頁第一時間看到首屏內容，并且用戶幾乎感知不到這種加載延遲。
7.2.2預加載
預加載是在頁面空閑的時候就把用戶即將用到的資源加載完存到緩存中，等用戶需要使用時，通過緩存直接調用呈現。比如用戶在看A頁面的時候，就可以通過預加載來準備用戶需要的B頁面資源。當用戶需要B頁面的時候，立刻就可以呈現。
比如某些頁面在實際中加載比較慢，這個時候就可以考慮是否用預加載的策略來提升網頁整體加載速度。比如知乎的視頻和文字在都進行了對應的預加載。即使當你處于斷網狀態（圖中我將頁面網絡切換為斷開狀態），可以看到依舊可以點擊全文進行查看和視頻的部分預覽。
7.2.3分步加載
當頁面中有文字和圖片時，優先加載占用網絡資源小的，比如文字資源，然后再進行占用資源較大的加載，比如圖片資源。通過分步加載也能有效減少頁面等待時間。比如大眾點評等圖片很多的網站往往會采用這種加載策略。
7.2.4分頁加載
分頁加載是我們目前很常見的方式，比如我們常用的百度和谷歌等搜索引擎都是使用的分頁加載，分頁適用于數據量比較大的內容，比如表格數據或者大數據搜索場景可以使用。
分頁加載可以理解為當前獲取到100條數據，但是將100條數據分別拆成5頁每頁20條數據提供給用戶，這樣也可以讓用戶減少等待時間：
在目前還有一種滾動分頁的加載，就是不提供視覺上的分頁，而是當用戶進行滾動時，自動加載一定數量的內容，這樣從用戶的視角看就是一個連續不間斷的數據展示。比如一些資訊類的網站就是采用的這種加載策略，有的也把這種滾動分頁的方式稱為自動加載。
7.2.5延遲加載
這里講的延遲加載更多的是一種防護加載機制，一般延遲設置的時間為300ms。這里的延遲加載有2種使用，第一種多用于搜索，通過延遲加載能夠讓用戶更好進行連續輸入，避免搜索結果被高頻率刷新，同時緩解服務器壓力。如下圖，可以看到我在輸入1后會有個延遲才出現加載列表，并且我在連續輸入12306的過程中是沒有對結果進行更新的，當我輸入完后才更新。
第二種則是通過延遲加載可以更好防止反復操作。當用戶在同一組件上面進行切換時，如果該操作小于300ms,則只記錄最后的點擊操作。這種情況可以用在我們的表格翻頁和開關等狀態上，防止用戶瘋狂點擊導致數據反復請求和屏幕閃爍的情況。我們可以通過下面這個組件演示例子來進行對應的感知：
延遲加載更多用于上述2種場景，對于其他情況的加載，直接加上就可以了，并不需要刻意設置延遲。
7.2.6后臺加載
這里想要表達的含義是當用戶在操作后，客戶端立即反饋操作成功，然后把請求放到后臺與服務器交互，這一過程用戶不需要了解，不需要等待。無論在什么網絡環境下你基本上都能操作成功。比如微信的朋友圈發布就是這樣的操作，即使你在斷網的情況下都能夠立刻發布，但實際上這個時候并沒有發送成功，還需要上傳到服務器后才你的朋友們才能看見。
這樣的好處是用戶使用起來非常流暢，但是壞處就是，當操作不成功時，用戶并不能及時進行感知，仍然以為操作已經成功了。所以這種場景我們也需要根據場景進行對應的判斷和選擇。對于復雜的B端場景個人建議慎用或者不用這種操作，畢竟很多發布的功能會同時影響很多業務線。
這里就拿微信的朋友圈發布來進行舉例，下方手機狀態都為斷網狀態，可以看到微信立即發布，而貼吧在這種狀態下提示網絡錯誤。
通過這些加載策略的選擇性使用，能夠在特定環境下提升我們系統的整體使用體驗。因此我們需要對這些加載策略有一個比較全面的認識，這樣我們不僅知道加載慢的原因，還可以利用加載策略去提升頁面性能。
在整體的加載過程中，別忘了考慮加載異常的情況。在通常情況下我們會我們會遇到網絡速度過慢或者突然斷網這兩種狀況讓頁面一直加載不出來，這時我們需要考慮對長時間的加載過程進行處理。
通常做法是我們要對加載狀態有一個最長時間的限制，一般為加載不超過10s，超過最長時間后就進行異常狀態顯示（提示語+刷新按鈕）。這樣用戶可以選擇重新加載或者離開此頁面，而不是一直等待。
在這里還想到一點，就是對于編輯頁面，我們應當加入網絡連接是否異常的判斷，比如當進入到編輯頁面后，如果遇到網絡斷開，需要在頁面的頂部加上常駐提示條【當前網絡連接斷開】，這樣用戶能夠及時進行察覺并修復。避免在無網環境下繼續輸入。這對于某些需要輸入很多內容且并不提供本地保存的頁面來講是非常有必要的。
加載在設計中是非常容易被忽略的模塊，因為在大部分情況下網絡速度都較快，人們很難深刻地感受到加載過程。但加載卻在產品運行中起著不可或缺的作用。通過這篇文章想要告訴大家的有幾個點：
1.我們需要明白加載為什么會出現，這個過程是怎么樣的；
2.加載的通用處理手段是怎么樣的，非通用處理方式有哪些；
3.通過緩存和對應加載策略能夠讓頁面加載速度有本質上的提升。
這樣當我們在頁面上遇到加載速度慢的問題時，在為其加上動畫承載過渡的同時，還應該思考其加載緩慢背后的原因，是因為數據量太大還是加載策略的相關問題，是否可以將其進行懶加載或者分步加載，這時我應該去找前端或者后端如何溝通。從源頭上解決加載時間長的問題，才是后續產品設計過程中的長久思路。
最后，雖然進行了很多資料查詢和技術溝通，但文章不可避免會出現不當之處，歡迎進行反饋。
