中后臺(tái)加載-被忽略的體驗(yàn)細(xì)節(jié)

2022-9-23    純純

undefined

大部分設(shè)計(jì)師應(yīng)該都遇到過(guò)這種場(chǎng)景:在做設(shè)計(jì)前并沒(méi)有考慮到加載,但在進(jìn)行還原度走查或者驗(yàn)收的時(shí)候才發(fā)現(xiàn),由于某些頁(yè)面數(shù)據(jù)請(qǐng)求較慢,導(dǎo)致在頁(yè)面中會(huì)出現(xiàn)空屏狀態(tài)。這時(shí)才想起需要在這些頁(yè)面添加動(dòng)畫來(lái)承載頁(yè)面的過(guò)渡。

歸根結(jié)底是因?yàn)樵O(shè)計(jì)師在設(shè)計(jì)過(guò)程中,更多關(guān)注頁(yè)面本身,而很少去思考頁(yè)面在呈現(xiàn)過(guò)程中何時(shí)會(huì)出現(xiàn)白屏狀態(tài),都是后知后覺(jué)去補(bǔ)充完善。加載作為必備的一環(huán),卻總是被忽略。目前很多B端產(chǎn)品在這方面都沒(méi)有一個(gè)系統(tǒng)合理的規(guī)劃,導(dǎo)致系統(tǒng)的加載體驗(yàn)缺失或者不統(tǒng)一。

因此希望這篇文章能夠講清楚中后臺(tái)加載出現(xiàn)的場(chǎng)景和規(guī)則,對(duì)需要深入了解加載以及在制定加載規(guī)則的設(shè)計(jì)師朋友們帶來(lái)一些幫助。


undefined

加載通俗來(lái)講就是用戶從觸發(fā)頁(yè)面操作,到頁(yè)面最終呈現(xiàn)的一個(gè)等待過(guò)程。這個(gè)過(guò)程始終存在不可避免,只是時(shí)間有快有慢??斓募虞d只需要幾百毫秒就結(jié)束,但慢的加載就可能會(huì)達(dá)到幾秒甚至十幾秒,讓人產(chǎn)生焦慮。

而為什么會(huì)有如此大的差距,這就需要從頁(yè)面渲染的整體過(guò)程來(lái)進(jìn)行說(shuō)明。當(dāng)我們從瀏覽器輸入網(wǎng)址,再到我們看到完整頁(yè)面的這個(gè)過(guò)程,網(wǎng)頁(yè)到底經(jīng)過(guò)了哪些步驟呢。經(jīng)過(guò)資料查詢和與前端確認(rèn),整體過(guò)程可以闡述如下:

從這里我們可以看到頁(yè)面的呈現(xiàn)是程序經(jīng)過(guò)了一系列操作才最終呈現(xiàn)到我們面前的。在這里可以將其簡(jiǎn)化為四個(gè)階段:用戶操作功能→頁(yè)面向服務(wù)器發(fā)送請(qǐng)求→服務(wù)器接受并返回?cái)?shù)據(jù)→頁(yè)面呈現(xiàn)。

而決定整個(gè)頁(yè)面加載快慢的就在于請(qǐng)求與數(shù)據(jù)這里。一般我們可以將頁(yè)面的數(shù)據(jù)分為2種類型:靜態(tài)資源和動(dòng)態(tài)資源。


靜態(tài)資源:前端的固定頁(yè)面,這里面包含HTML、CSS、JS、圖片等等,不需要查數(shù)據(jù)庫(kù)也不需要程序處理,直接就能夠顯示的頁(yè)面??梢院?jiǎn)單理解為你頁(yè)面上的固定字段和結(jié)構(gòu)。這種頁(yè)面一般加載速度比較快,比如我們看到的展示型官網(wǎng)一般都是前端寫好的靜態(tài)資源。


動(dòng)態(tài)資源:而對(duì)于頁(yè)面上的動(dòng)態(tài)變化的,需要程序處理或者從數(shù)據(jù)庫(kù)中讀數(shù)據(jù),能根據(jù)不同的條件在頁(yè)面顯示不同的數(shù)據(jù),比如表格數(shù)據(jù)、統(tǒng)計(jì)數(shù)據(jù)等稱為動(dòng)態(tài)資源,這種都需要調(diào)用后臺(tái)接口來(lái)進(jìn)行返回,因此加載速度相比于靜態(tài)資源就會(huì)更慢。

而它們的區(qū)分點(diǎn)用下圖可以表示:

可以看到靜態(tài)資源基本是直接返回,而動(dòng)態(tài)資源還需要連接數(shù)據(jù)庫(kù)調(diào)取資源,尤其是在遇到數(shù)據(jù)庫(kù)調(diào)取較慢時(shí)就會(huì)花費(fèi)更多時(shí)間。而我們加載緩慢的大多數(shù)問(wèn)題,也基本上更多出現(xiàn)在動(dòng)態(tài)資源的獲取上。


undefined

當(dāng)我們清楚加載形成的原因,接下來(lái)要做的就是在需要加載的地方對(duì)其進(jìn)行處理。這也是在設(shè)計(jì)過(guò)程中我們經(jīng)常遺漏的地方。我們先看一下目前常見的2種處理方式:「默認(rèn)處理」和「使用進(jìn)度指示器」


2.1程序默認(rèn)處理方式:直接顯示

當(dāng)我們對(duì)加載過(guò)程不進(jìn)行任何處理時(shí),程序就會(huì)以默認(rèn)的方式進(jìn)行-即根據(jù)資源獲取速度一步步呈現(xiàn)??梢钥吹胶俚旰笈_(tái)的處理過(guò)程就是一種默認(rèn)處理方式:

但是這種做法就會(huì)導(dǎo)致我們?cè)陧?yè)面加載過(guò)程中會(huì)出現(xiàn)空屏狀態(tài),比如上圖切換到概覽時(shí)出現(xiàn)了空屏狀態(tài),尤其是當(dāng)遇到了網(wǎng)絡(luò)緩慢的情況,會(huì)造成在加載時(shí)頁(yè)面停留在當(dāng)前狀態(tài)下不動(dòng),往往會(huì)讓用戶陷入到「系統(tǒng)故障」的錯(cuò)覺(jué)。


2.2通用處理方式:進(jìn)度指示器

這個(gè)名詞說(shuō)起來(lái)可能比較陌生,它指代的就是我們平時(shí)經(jīng)常看到的加載動(dòng)畫、骨架屏或者進(jìn)度條等。進(jìn)度指示器的作用就是告知用戶當(dāng)前頁(yè)面并沒(méi)有故障,而是正在讀取數(shù)據(jù)。

通過(guò)添加進(jìn)度指示器來(lái)對(duì)空屏狀態(tài)進(jìn)行承載,能夠減輕用戶的焦慮感。目前很多B端產(chǎn)品更通用的形式是添加動(dòng)畫來(lái)過(guò)渡。

但是在體驗(yàn)過(guò)程中很容易發(fā)現(xiàn)一個(gè)問(wèn)題,就是在產(chǎn)品的整體加載過(guò)程中,某些空屏狀態(tài)是沒(méi)被加載動(dòng)畫覆蓋到的。當(dāng)這些沒(méi)被覆蓋到的加載過(guò)程過(guò)長(zhǎng)時(shí),很容易出現(xiàn)焦慮感。比如神策數(shù)據(jù)在左側(cè)列表切換時(shí)的加載過(guò)程就沒(méi)被覆蓋:

想要更全面的把加載動(dòng)畫覆蓋到所有頁(yè)面,我們就需要弄清頁(yè)面在哪些狀態(tài)下會(huì)出現(xiàn)空屏狀態(tài),從而制定統(tǒng)一的加載動(dòng)畫規(guī)則。這個(gè)問(wèn)題可以先思考一下,后面解答。


undefined

在制定統(tǒng)一加載規(guī)則之前,我們需要明確一個(gè)概念,就是加載的模態(tài)與非模態(tài)。


3.1模態(tài)加載

模態(tài)加載的含義就是當(dāng)前加載會(huì)中斷用戶其余操作,用戶在這個(gè)期間只能等待加載而不能進(jìn)行其他操作(有的模態(tài)會(huì)提供取消按鈕)。如果你的頁(yè)面涉及到以下2種情況,可以考慮使用:

1.用戶當(dāng)前的操作本身不能與其他操作同時(shí)進(jìn)行。比如系統(tǒng)更新,或者工具類的導(dǎo)入導(dǎo)出相關(guān)操作,我們只能等待更新、導(dǎo)出完成才能繼續(xù)進(jìn)行后續(xù)的操作。這時(shí)候可以使用模態(tài)加載來(lái)承載,比如protopie的導(dǎo)入操作;

2.當(dāng)用戶進(jìn)入到一個(gè)全新的頁(yè)面時(shí),這個(gè)時(shí)候頁(yè)面什么都沒(méi)有,我們只能等待頁(yè)面加載完成才能進(jìn)行后續(xù)的操作,因此在這種情況下也可以采用模態(tài)加載,比如我們剛進(jìn)入Asanan產(chǎn)品頁(yè)面看到的首屏加載動(dòng)畫:

除了上述2種情況外,你也可以根據(jù)你的業(yè)務(wù)場(chǎng)景來(lái)進(jìn)行模態(tài)加載的選擇,但建議是盡量少用模態(tài)加載,其會(huì)對(duì)用戶的打斷和干擾性比較強(qiáng)。


3.2非模態(tài)加載

非模態(tài)加載的話,這種加載通常只會(huì)出現(xiàn)在需要加載的部分,不會(huì)中斷用戶其他操作。對(duì)用戶干擾比較小。比如我們常見的功能切換加載、數(shù)據(jù)篩選加載等都屬于非模態(tài)加載。

非模態(tài)加載相比于模態(tài)加載會(huì)更輕量,因?yàn)橛脩綦S時(shí)都可以打斷也不會(huì)影響到其他操作。因此建議在大部分情況下都可以使用非模態(tài)彈窗來(lái)進(jìn)行承載,比如飛書的左側(cè)欄切換操作:


undefined

接下來(lái)我們進(jìn)入正題,在這里我從加載的角度將網(wǎng)頁(yè)整體加載過(guò)程分為呈現(xiàn)加載規(guī)則操作加載規(guī)則。

我們先談頁(yè)面呈現(xiàn)規(guī)則。前面已經(jīng)明確加載產(chǎn)生的原因和類型后,我們就可以開始為我們的產(chǎn)品制定統(tǒng)一的加載規(guī)則,以保證后續(xù)頁(yè)面加載的一致性。


4.1 頁(yè)面的加載過(guò)程拆解

在拆解頁(yè)面的加載過(guò)程前,我們進(jìn)一步闡述之前提到的渲染原則,從前文中提到最后會(huì)經(jīng)過(guò)「解碼」和「渲染」2個(gè)步驟,這也是決定了我們看到的頁(yè)面的最終呈現(xiàn)順序:


1.頁(yè)面渲染順序

我們看到的頁(yè)面是由HTML、CSS和JavaScript來(lái)進(jìn)行構(gòu)成的。HTML可以看作最簡(jiǎn)單的框架、CSS則是賦予了框架樣式,JavaScript則是負(fù)責(zé)頁(yè)面中的交互(當(dāng)然JS也可以控制樣式,這里只描述主要功能)。

頁(yè)面在「解碼」階段,拿到的HTML文檔會(huì)被解碼為DOM樹,同時(shí)將CSS文件解析成CSSOM,這兩者結(jié)合后一起渲染頁(yè)面,JS一般是在最后渲染。所以邏輯上就是框架和樣式一起渲染,最后渲染交互。視覺(jué)的角度來(lái)講就是先看到元素樣式,然后才能進(jìn)行對(duì)應(yīng)操作。


2.頁(yè)面呈現(xiàn)的視覺(jué)順序

由于瀏覽器渲染順序一般會(huì)根據(jù)代碼的順序進(jìn)行渲染,而代碼在頁(yè)面中的構(gòu)建一般也是按照頁(yè)面的上下和左右的順序去寫的,因此我們看到的頁(yè)面的視覺(jué)呈現(xiàn)順序也是遵循從上到下,從左到右。

所以幾乎所有的產(chǎn)品都是先看到頂欄,然后左側(cè)邊欄,然后其他內(nèi)容。因此我們可以通過(guò)這個(gè)原則來(lái)拆解對(duì)應(yīng)的頁(yè)面,我們按照頁(yè)面常規(guī)結(jié)構(gòu)可以將其分為三個(gè)加載部分:頂欄、左側(cè)導(dǎo)航欄、內(nèi)容區(qū)域。而其加載順序如圖所示:

當(dāng)知道對(duì)應(yīng)頁(yè)面的渲染順序后,我們就能夠清楚在頁(yè)面渲染的過(guò)程中哪些地方會(huì)出現(xiàn)空屏了。因此將頁(yè)面加載過(guò)程拆解為如下順序:

undefined

我們的加載動(dòng)畫需要承載的就是上述這些白屏的地方,從而將加載細(xì)化為三種場(chǎng)景的拆分:全局加載+局部加載+內(nèi)部加載。如圖所示:

undefined

通過(guò)這三種加載就可以涵蓋頁(yè)面所涉及到的所有部分。接下來(lái)詳細(xì)闡述一下這三種類型的定義和用法。


4.2 全局加載

如上圖所示,全局加載的目的是為了覆蓋用戶從輸入網(wǎng)址到頁(yè)面的資源渲染的這個(gè)中間過(guò)程的空屏狀態(tài)而存在的。而這種狀態(tài)會(huì)涉及三種場(chǎng)景:

1.通過(guò)網(wǎng)址進(jìn)入到一個(gè)新的頁(yè)面時(shí);

2.通過(guò)鼠標(biāo)右鍵或網(wǎng)頁(yè)刷新按鈕對(duì)該頁(yè)面刷新時(shí);

3.通過(guò)頁(yè)面操作需要新開頁(yè)面時(shí)。

該全局加載的動(dòng)畫構(gòu)成為:

1:覆蓋整個(gè)頁(yè)面的加載,由純白色+加載動(dòng)畫構(gòu)成;

2:加載類型為模態(tài)加載,因?yàn)橛脩粼谶@種頁(yè)面狀態(tài)下并不能進(jìn)行其它操作。

undefined

但在這里我們需要注意全局加載的開始和結(jié)束時(shí)間:

開始時(shí)間:當(dāng)進(jìn)入頁(yè)面時(shí)立即呈現(xiàn)加載動(dòng)畫;

結(jié)束時(shí)間:當(dāng)頁(yè)面加載出頂欄的時(shí)候,此時(shí)停止加載。


為何要這么處理結(jié)束時(shí)間,原因其實(shí)圖中已經(jīng)給出了。這里再解釋一下原則:只要有頁(yè)面資源返回,我們的全局加載動(dòng)畫就會(huì)結(jié)束,隨后啟用局部加載來(lái)承接后續(xù)的狀態(tài),避免用戶在當(dāng)前狀態(tài)長(zhǎng)時(shí)間等待。而頂欄在一般情況下都是最先加載出來(lái)的,所以以頂欄出現(xiàn)作為結(jié)束全局加載的標(biāo)準(zhǔn)。當(dāng)然如果你的結(jié)構(gòu)沒(méi)有頂欄,可以以左側(cè)欄來(lái)作為結(jié)束標(biāo)準(zhǔn)。


4.3 局部加載

局部加載是用在頁(yè)面整體框架加載的過(guò)程中,承接在全局加載后。局部加載的使用場(chǎng)景可以概括如下:

1.頂欄加載結(jié)束后,用在剩余框架的加載效果(具體體現(xiàn)為左側(cè)邊欄和右側(cè)內(nèi)容區(qū)域);

2.對(duì)于涉及到局部頁(yè)面的切換操作都會(huì)進(jìn)行局部加載(比如左側(cè)邊欄的切換);

光看文字可能不是特別清晰,在這里可以舉一個(gè)動(dòng)態(tài)的例子來(lái)幫助理解:


上述展示的是在頁(yè)面呈現(xiàn)的時(shí)候一個(gè)完整的局部加載。在這里需要注意的是我們首次渲染和第二次渲染在加載動(dòng)畫上是可以有區(qū)分的,可以通過(guò)程序控制讓這種加載動(dòng)畫只在初次加載時(shí)出現(xiàn)。


第一次加載時(shí)出現(xiàn)是因?yàn)槲覀冃枰屑虞d動(dòng)畫來(lái)承接框架首次加載的空屏?xí)r間:

但第二次的時(shí)候由于有緩存(緩存會(huì)加載我們的靜態(tài)資源,能夠讓我們的頁(yè)面框架在第二次時(shí)更快顯示),這樣在讀取框架時(shí)基本不需要加載,我們就可以通過(guò)程序來(lái)直接去掉其中的局部加載動(dòng)畫,直接顯示框架來(lái)進(jìn)行呈現(xiàn)。

undefined

目前在飛書和釘釘?shù)菳端產(chǎn)品后臺(tái)均采用了這種處理方式??梢钥吹綀D中我在第一次切換到角色管理時(shí)是有碰撞小球的局部動(dòng)畫存在的,而第二次再次進(jìn)入時(shí)則直接出現(xiàn)框架。這樣既能夠保證加載動(dòng)畫能夠覆蓋所有的空屏狀態(tài),又避免了局部加載動(dòng)畫的頻繁出現(xiàn)。


4.4 內(nèi)部加載

內(nèi)部加載是用在頁(yè)面內(nèi)部不同模塊數(shù)據(jù)間的加載。當(dāng)框架都已經(jīng)加載結(jié)束,但某些數(shù)據(jù)由于接口比較慢,此時(shí)還沒(méi)有返回,這時(shí)我們就可以用內(nèi)部加載來(lái)進(jìn)行承載。這應(yīng)該是我們更常見的加載情況:

在進(jìn)行內(nèi)部加載的時(shí)候,需要注意,內(nèi)部加載的時(shí)候一般標(biāo)題是存在的,因?yàn)闃?biāo)題基本都是固定的,所以能夠很快被拉取。比如Zoho的內(nèi)部加載,加載時(shí)標(biāo)題已經(jīng)出現(xiàn)了:

通過(guò)這三種類型的加載,能夠覆蓋從用戶輸入網(wǎng)址,到頁(yè)面渲染完成這個(gè)頁(yè)面呈現(xiàn)過(guò)程中的全部加載場(chǎng)景。


undefined

說(shuō)完頁(yè)面的呈現(xiàn)規(guī)則,再談頁(yè)面操作加載規(guī)則。頁(yè)面的操作其實(shí)對(duì)應(yīng)的是頁(yè)面控件的反饋。而我們的常用的控件比如有按鈕、tab切換等。我們不僅需要考慮控件本身的加載狀態(tài),而且需要考慮到控件影響的其他頁(yè)面范圍。


5.1需要考慮控件本身加載

控件的加載并不是隨時(shí)都需要,我們要根據(jù)實(shí)際的數(shù)據(jù)量大小及業(yè)務(wù)場(chǎng)景來(lái)選擇性使用。目前我們需要考慮的控件及其加載狀態(tài)主要有如下:

undefined

比如圖中的按鈕的加載狀態(tài)是必備的,在很多場(chǎng)景下都會(huì)用到。但是下拉列表和級(jí)聯(lián)列表,在一般的場(chǎng)景下都不太需要進(jìn)行加載,當(dāng)遇到列表中的數(shù)據(jù)特別多或者調(diào)取特別慢時(shí)就可以考慮為其加上加載狀態(tài)。


5.2當(dāng)控件操作會(huì)影響到頁(yè)面其他元素

這種控件比如日期篩選、表格篩選或者保存等操作,當(dāng)你切換篩選條件后所有與其相關(guān)的頁(yè)面元素都會(huì)發(fā)生變化。在這種情況下我們需要考慮到被影響元素的狀態(tài)。目前的設(shè)計(jì)實(shí)現(xiàn)上有兩種做法:

1.被影響元素不可被操作,且該區(qū)域有遮罩+加載動(dòng)畫來(lái)覆蓋;

2.被影響元素可進(jìn)行操作,無(wú)任何動(dòng)畫,但操作并不會(huì)影響之前提交的結(jié)果;


這兩種方案一種是利用遮罩防止用戶無(wú)效操作,另一種則是保持了足夠的操作自由性。個(gè)人在這里更傾向于處理方式1,我認(rèn)為被影響的元素是需要有遮罩+動(dòng)畫的,來(lái)避免用戶在加載期間對(duì)其進(jìn)行無(wú)效操作,比如示例中方案2后面修改的名稱是沒(méi)有被系統(tǒng)保存的。

需要注意的是如果在產(chǎn)品中使用方案1,我們的遮罩區(qū)域只需要覆蓋被影響的元素就可以了(保存這種可以將按鈕一起覆蓋),比如通過(guò)篩選導(dǎo)致圖表數(shù)據(jù)發(fā)生變化,這時(shí)只需覆蓋圖表區(qū)域,而不用覆蓋篩選區(qū)域。這樣的好處是當(dāng)某些篩選數(shù)據(jù)出現(xiàn)加載過(guò)慢問(wèn)題時(shí),用戶可以通過(guò)切換篩選項(xiàng)來(lái)打斷當(dāng)前加載。

上述描述的操作都是針對(duì)于當(dāng)前頁(yè)加載。當(dāng)控件導(dǎo)致頁(yè)面刷新或者跳轉(zhuǎn)時(shí),則整體遵照頁(yè)面呈現(xiàn)的規(guī)則進(jìn)行加載。


undefined

上面闡述的加載已經(jīng)完全能夠覆蓋我們頁(yè)面整體的加載,但是還是需要提及一下骨架屏和進(jìn)度條這兩種加載形式。

undefined

先說(shuō)骨架屏。實(shí)際上骨架屏的使用效果體驗(yàn)是優(yōu)于加載動(dòng)畫的體驗(yàn)的(骨架屏的加入使用會(huì)讓用戶感覺(jué)網(wǎng)頁(yè)出現(xiàn)的更快)。那么為什么在大部分的B端業(yè)務(wù)頁(yè)面中沒(méi)被用到呢,主要有2點(diǎn)原因:

1.每種骨架屏都需要進(jìn)行對(duì)應(yīng)的定制開發(fā),需要與加載后的頁(yè)面框架保持一致,這會(huì)增加了開發(fā)成本。

2.中后臺(tái)的業(yè)務(wù)界面對(duì)來(lái)說(shuō)固定結(jié)構(gòu)的頁(yè)面會(huì)較少,這對(duì)于骨架屏的使用機(jī)會(huì)就相對(duì)較少。

個(gè)人認(rèn)為在前期可以以統(tǒng)一加載體驗(yàn)為主,在后期業(yè)務(wù)相對(duì)成熟后,可以針對(duì)固定結(jié)構(gòu),通過(guò)骨架屏的使用優(yōu)化加載體驗(yàn)。


再說(shuō)進(jìn)度條。我理解的進(jìn)度條的使用條件:對(duì)于加載時(shí)間較長(zhǎng)的規(guī)定場(chǎng)景可以考慮用進(jìn)度條來(lái)承載,比如我們常見的游戲加載中進(jìn)度條就用得比較多,因?yàn)橛螒蛞话阗Y源比較大。還比如figma在進(jìn)入設(shè)計(jì)文件的過(guò)程中也采用了進(jìn)度條加載也是因?yàn)樵O(shè)計(jì)文件可能會(huì)很大。

進(jìn)度條在特定場(chǎng)景下能夠緩解用戶焦慮,讓用戶知道進(jìn)展。但進(jìn)度條在多數(shù)情況下都抓取不到程序的真實(shí)進(jìn)度,這也會(huì)導(dǎo)致有時(shí)候我們看著加載到99%,那最后的1%遲遲加載不出來(lái)的的原因。目前很多中后臺(tái)產(chǎn)品對(duì)于進(jìn)度條加載使用相對(duì)較少的原因,很大程度是沒(méi)有那種加載特別長(zhǎng)的場(chǎng)景。


因此這兩種加載場(chǎng)景的使用會(huì)更加定制化,如果需要使用請(qǐng)根據(jù)具體的業(yè)務(wù)場(chǎng)景來(lái)進(jìn)行選擇。


如果把加載動(dòng)畫等比作頁(yè)面加載的外在,那么緩存和加載策略則是頁(yè)面加載的內(nèi)核,合理使用緩存和加載策略可以從根本上提升我們頁(yè)面的加載速度,讓用戶更快速地看到頁(yè)面。


7.1 關(guān)于頁(yè)面的資源緩存

大家肯定聽過(guò)緩存這個(gè)概念,前后端都可以使用緩存。緩存就是數(shù)據(jù)交換的緩沖區(qū)(稱作Cache),是存貯數(shù)據(jù)(使用頻繁的數(shù)據(jù))的臨時(shí)地方。在這里主要講一下瀏覽器緩存:

undefined

從這張圖可以看出,服務(wù)器在請(qǐng)求數(shù)據(jù)時(shí),會(huì)進(jìn)行緩存的判斷,如果有緩存則首先讀取緩存,如果沒(méi)有則從服務(wù)器中拿取。調(diào)取緩存會(huì)在很大程度上提升頁(yè)面的加載速度,縮短了從服務(wù)獲取數(shù)據(jù)的時(shí)間。通常瀏覽器會(huì)主動(dòng)對(duì)頁(yè)面的靜態(tài)資源進(jìn)行對(duì)應(yīng)的緩存,這也就解釋了我們第二次進(jìn)入頁(yè)面會(huì)比初次進(jìn)入頁(yè)面時(shí)加載快的原因。


但程序其實(shí)也可以對(duì)動(dòng)態(tài)資源(也就是需要從數(shù)據(jù)庫(kù)等拿到的資源)進(jìn)行緩存的,并且可以設(shè)置緩存的過(guò)期時(shí)間(比如設(shè)置過(guò)期時(shí)間為1小時(shí),那么1小時(shí)過(guò)后就會(huì)重新拉取新資源)。對(duì)于某些動(dòng)態(tài)資源拉取過(guò)慢并且更新頻率不高的我們可以采用動(dòng)態(tài)資源緩存的策略,從而提升整體的頁(yè)面加載體驗(yàn)。


7.2 加載策略的正確使用

現(xiàn)階段我們常用的主要有下列6種加載策略:

加載策略的本質(zhì)就是通過(guò)對(duì)應(yīng)的加載設(shè)置來(lái)縮短產(chǎn)品與服務(wù)器交換數(shù)據(jù)的時(shí)間,接下來(lái)我們?cè)敿?xì)看一下每種加載策略的具體使用策略:


7.2.1懶加載

懶加載是當(dāng)內(nèi)容落入視窗被用戶看到時(shí),才會(huì)進(jìn)行加載。這種比較節(jié)省資源和減輕服務(wù)器壓力。對(duì)于當(dāng)前頁(yè)面內(nèi)容很多的可以采用這種加載策略。而這種加載策略的設(shè)計(jì),能夠讓用戶更快看到當(dāng)前屏幕內(nèi)的內(nèi)容,減少等待時(shí)間。

比如蘋果官網(wǎng)的加載策略就采取了這樣的一種方式。我們可以看到右側(cè)的資源只有在我們向下滾動(dòng)出現(xiàn)在屏幕中時(shí)才會(huì)進(jìn)行對(duì)應(yīng)的加載,這樣能夠保證用戶在進(jìn)入網(wǎng)頁(yè)第一時(shí)間看到首屏內(nèi)容,并且用戶幾乎感知不到這種加載延遲。


7.2.2預(yù)加載

預(yù)加載是在頁(yè)面空閑的時(shí)候就把用戶即將用到的資源加載完存到緩存中,等用戶需要使用時(shí),通過(guò)緩存直接調(diào)用呈現(xiàn)。比如用戶在看A頁(yè)面的時(shí)候,就可以通過(guò)預(yù)加載來(lái)準(zhǔn)備用戶需要的B頁(yè)面資源。當(dāng)用戶需要B頁(yè)面的時(shí)候,立刻就可以呈現(xiàn)。

比如某些頁(yè)面在實(shí)際中加載比較慢,這個(gè)時(shí)候就可以考慮是否用預(yù)加載的策略來(lái)提升網(wǎng)頁(yè)整體加載速度。比如知乎的視頻和文字在都進(jìn)行了對(duì)應(yīng)的預(yù)加載。即使當(dāng)你處于斷網(wǎng)狀態(tài)(圖中我將頁(yè)面網(wǎng)絡(luò)切換為斷開狀態(tài)),可以看到依舊可以點(diǎn)擊全文進(jìn)行查看和視頻的部分預(yù)覽。


7.2.3分步加載

當(dāng)頁(yè)面中有文字和圖片時(shí),優(yōu)先加載占用網(wǎng)絡(luò)資源小的,比如文字資源,然后再進(jìn)行占用資源較大的加載,比如圖片資源。通過(guò)分步加載也能有效減少頁(yè)面等待時(shí)間。比如大眾點(diǎn)評(píng)等圖片很多的網(wǎng)站往往會(huì)采用這種加載策略。


7.2.4分頁(yè)加載

分頁(yè)加載是我們目前很常見的方式,比如我們常用的百度和谷歌等搜索引擎都是使用的分頁(yè)加載,分頁(yè)適用于數(shù)據(jù)量比較大的內(nèi)容,比如表格數(shù)據(jù)或者大數(shù)據(jù)搜索場(chǎng)景可以使用。

分頁(yè)加載可以理解為當(dāng)前獲取到100條數(shù)據(jù),但是將100條數(shù)據(jù)分別拆成5頁(yè)每頁(yè)20條數(shù)據(jù)提供給用戶,這樣也可以讓用戶減少等待時(shí)間:

在目前還有一種滾動(dòng)分頁(yè)的加載,就是不提供視覺(jué)上的分頁(yè),而是當(dāng)用戶進(jìn)行滾動(dòng)時(shí),自動(dòng)加載一定數(shù)量的內(nèi)容,這樣從用戶的視角看就是一個(gè)連續(xù)不間斷的數(shù)據(jù)展示。比如一些資訊類的網(wǎng)站就是采用的這種加載策略,有的也把這種滾動(dòng)分頁(yè)的方式稱為自動(dòng)加載。


7.2.5延遲加載

這里講的延遲加載更多的是一種防護(hù)加載機(jī)制,一般延遲設(shè)置的時(shí)間為300ms。這里的延遲加載有2種使用,第一種多用于搜索,通過(guò)延遲加載能夠讓用戶更好進(jìn)行連續(xù)輸入,避免搜索結(jié)果被高頻率刷新,同時(shí)緩解服務(wù)器壓力。如下圖,可以看到我在輸入1后會(huì)有個(gè)延遲才出現(xiàn)加載列表,并且我在連續(xù)輸入12306的過(guò)程中是沒(méi)有對(duì)結(jié)果進(jìn)行更新的,當(dāng)我輸入完后才更新。

第二種則是通過(guò)延遲加載可以更好防止反復(fù)操作。當(dāng)用戶在同一組件上面進(jìn)行切換時(shí),如果該操作小于300ms,則只記錄最后的點(diǎn)擊操作。這種情況可以用在我們的表格翻頁(yè)和開關(guān)等狀態(tài)上,防止用戶瘋狂點(diǎn)擊導(dǎo)致數(shù)據(jù)反復(fù)請(qǐng)求和屏幕閃爍的情況。我們可以通過(guò)下面這個(gè)組件演示例子來(lái)進(jìn)行對(duì)應(yīng)的感知:

延遲加載更多用于上述2種場(chǎng)景,對(duì)于其他情況的加載,直接加上就可以了,并不需要刻意設(shè)置延遲。


7.2.6后臺(tái)加載

這里想要表達(dá)的含義是當(dāng)用戶在操作后,客戶端立即反饋操作成功,然后把請(qǐng)求放到后臺(tái)與服務(wù)器交互,這一過(guò)程用戶不需要了解,不需要等待。無(wú)論在什么網(wǎng)絡(luò)環(huán)境下你基本上都能操作成功。比如微信的朋友圈發(fā)布就是這樣的操作,即使你在斷網(wǎng)的情況下都能夠立刻發(fā)布,但實(shí)際上這個(gè)時(shí)候并沒(méi)有發(fā)送成功,還需要上傳到服務(wù)器后才你的朋友們才能看見。


這樣的好處是用戶使用起來(lái)非常流暢,但是壞處就是,當(dāng)操作不成功時(shí),用戶并不能及時(shí)進(jìn)行感知,仍然以為操作已經(jīng)成功了。所以這種場(chǎng)景我們也需要根據(jù)場(chǎng)景進(jìn)行對(duì)應(yīng)的判斷和選擇。對(duì)于復(fù)雜的B端場(chǎng)景個(gè)人建議慎用或者不用這種操作,畢竟很多發(fā)布的功能會(huì)同時(shí)影響很多業(yè)務(wù)線。


這里就拿微信的朋友圈發(fā)布來(lái)進(jìn)行舉例,下方手機(jī)狀態(tài)都為斷網(wǎng)狀態(tài),可以看到微信立即發(fā)布,而貼吧在這種狀態(tài)下提示網(wǎng)絡(luò)錯(cuò)誤。

通過(guò)這些加載策略的選擇性使用,能夠在特定環(huán)境下提升我們系統(tǒng)的整體使用體驗(yàn)。因此我們需要對(duì)這些加載策略有一個(gè)比較全面的認(rèn)識(shí),這樣我們不僅知道加載慢的原因,還可以利用加載策略去提升頁(yè)面性能。



在整體的加載過(guò)程中,別忘了考慮加載異常的情況。在通常情況下我們會(huì)我們會(huì)遇到網(wǎng)絡(luò)速度過(guò)慢或者突然斷網(wǎng)這兩種狀況讓頁(yè)面一直加載不出來(lái),這時(shí)我們需要考慮對(duì)長(zhǎng)時(shí)間的加載過(guò)程進(jìn)行處理。

通常做法是我們要對(duì)加載狀態(tài)有一個(gè)最長(zhǎng)時(shí)間的限制,一般為加載不超過(guò)10s,超過(guò)最長(zhǎng)時(shí)間后就進(jìn)行異常狀態(tài)顯示(提示語(yǔ)+刷新按鈕)。這樣用戶可以選擇重新加載或者離開此頁(yè)面,而不是一直等待。

在這里還想到一點(diǎn),就是對(duì)于編輯頁(yè)面,我們應(yīng)當(dāng)加入網(wǎng)絡(luò)連接是否異常的判斷,比如當(dāng)進(jìn)入到編輯頁(yè)面后,如果遇到網(wǎng)絡(luò)斷開,需要在頁(yè)面的頂部加上常駐提示條【當(dāng)前網(wǎng)絡(luò)連接斷開】,這樣用戶能夠及時(shí)進(jìn)行察覺(jué)并修復(fù)。避免在無(wú)網(wǎng)環(huán)境下繼續(xù)輸入。這對(duì)于某些需要輸入很多內(nèi)容且并不提供本地保存的頁(yè)面來(lái)講是非常有必要的。


加載在設(shè)計(jì)中是非常容易被忽略的模塊,因?yàn)樵诖蟛糠智闆r下網(wǎng)絡(luò)速度都較快,人們很難深刻地感受到加載過(guò)程。但加載卻在產(chǎn)品運(yùn)行中起著不可或缺的作用。通過(guò)這篇文章想要告訴大家的有幾個(gè)點(diǎn):

1.我們需要明白加載為什么會(huì)出現(xiàn),這個(gè)過(guò)程是怎么樣的;

2.加載的通用處理手段是怎么樣的,非通用處理方式有哪些;

3.通過(guò)緩存和對(duì)應(yīng)加載策略能夠讓頁(yè)面加載速度有本質(zhì)上的提升。


這樣當(dāng)我們?cè)陧?yè)面上遇到加載速度慢的問(wèn)題時(shí),在為其加上動(dòng)畫承載過(guò)渡的同時(shí),還應(yīng)該思考其加載緩慢背后的原因,是因?yàn)閿?shù)據(jù)量太大還是加載策略的相關(guān)問(wèn)題,是否可以將其進(jìn)行懶加載或者分步加載,這時(shí)我應(yīng)該去找前端或者后端如何溝通。從源頭上解決加載時(shí)間長(zhǎng)的問(wèn)題,才是后續(xù)產(chǎn)品設(shè)計(jì)過(guò)程中的長(zhǎng)久思路。


作者:蒙東東    來(lái)源:站酷

藍(lán)藍(lán)設(shè)計(jì)建立了UI設(shè)計(jì)分享群,每天會(huì)分享國(guó)內(nèi)外的一些優(yōu)秀設(shè)計(jì),如果有興趣的話,可以進(jìn)入一起成長(zhǎng)學(xué)習(xí),請(qǐng)加藍(lán)小助,微信號(hào):ben_lanlan,報(bào)下信息,藍(lán)小助會(huì)請(qǐng)您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請(qǐng)與我們聯(lián)系01063334945。

分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責(zé)聲明:藍(lán)藍(lán)設(shè)計(jì)尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問(wèn)題,請(qǐng)及時(shí)與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

藍(lán)藍(lán)設(shè)計(jì)www.bouu.cn )是一家專注而深入的界面設(shè)計(jì)公司,為期望卓越的國(guó)內(nèi)外企業(yè)提供卓越的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)、UI設(shè)計(jì)公司、界面設(shè)計(jì)公司、UI設(shè)計(jì)服務(wù)公司、數(shù)據(jù)可視化設(shè)計(jì)公司、UI交互設(shè)計(jì)公司、高端網(wǎng)站設(shè)計(jì)公司、UI咨詢、用戶體驗(yàn)公司、軟件界面設(shè)計(jì)公司



分享本文至:

日歷

鏈接

個(gè)人資料

存檔