編輯導(dǎo)語(yǔ)：產(chǎn)品設(shè)計(jì)在任何產(chǎn)品中都是非常重要的，用戶在使用產(chǎn)品時(shí)的用戶體驗(yàn)以及一些交互體驗(yàn)，都會(huì)影響到產(chǎn)品的各方面；在產(chǎn)品頁(yè)面中，用戶在等待加載頁(yè)面時(shí)，也需要合適的設(shè)計(jì)進(jìn)行操作；本文作者分享了關(guān)于加載功能的原理和設(shè)計(jì)，我們一起來(lái)了解一下。

作為產(chǎn)品設(shè)計(jì)師，我們?cè)O(shè)計(jì)的功能都會(huì)面臨用戶的使用；在用戶使用的過(guò)程中會(huì)因?yàn)槭褂脮r(shí)長(zhǎng)的延長(zhǎng)和上次文件等情況，從而產(chǎn)生大量的文件數(shù)據(jù)，這些文件數(shù)據(jù)的堆積會(huì)讓整個(gè)數(shù)據(jù)庫(kù)越發(fā)的臃腫，從而造成用戶體驗(yàn)上的不流暢。

一、狹義和廣義上的加載

狹義上的加載是由用戶體驗(yàn)和交互動(dòng)效組成

為什么我會(huì)說(shuō)是狹義上的，因?yàn)閱?wèn)起加載，大家首先想到的是頁(yè)面上的加載，那種思考用戶體驗(yàn)和頁(yè)面動(dòng)態(tài)的加載，并且我們還會(huì)脫口而出：

我們要讓用戶在等待的過(guò)程中也有很好用戶的體驗(yàn)，讓用戶在等待的時(shí)候可以感知到我們正在努力加載的情況，這能減緩用戶的焦慮；同時(shí)，我們還要順便把加載做的更加有趣，吸引用戶注意力，讓用戶沉浸其中，讓用戶享受等待時(shí)刻。

不是說(shuō)這些內(nèi)容說(shuō)的不對(duì)，而是因?yàn)檫@些話從UI、UE、UXD等設(shè)計(jì)師口中說(shuō)出，我覺(jué)得十分正常且合理。因?yàn)樗麄冊(cè)谶M(jìn)行思考，思考如何中感官上提升用戶對(duì)我們產(chǎn)品的正向感官；但如果這話從產(chǎn)品經(jīng)理的口中說(shuō)出來(lái)，那我感覺(jué)會(huì)感到十分驚艷，因?yàn)檫@比較的忘本逐末了。

上面一長(zhǎng)串的回答，是我們大部分人的想法，“狹隘”的從體驗(yàn)上出發(fā)去思考問(wèn)題，想通過(guò)卓越的體驗(yàn)來(lái)緩解用戶焦慮，從而降低跳失率，避免用戶的大量流失。沒(méi)有思考和挖掘周?chē)嗟耐庠谝蛩?，糅合在一起評(píng)估思考，所以我說(shuō)是狹義上的加載。

作為產(chǎn)品設(shè)計(jì)師，以后是產(chǎn)品經(jīng)理我們，我們的核心能力應(yīng)該在于有深度的思考和評(píng)估優(yōu)劣后的決策；我們要從錯(cuò)綜復(fù)雜的問(wèn)題中抽離問(wèn)題，通過(guò)衡量多方面因素進(jìn)行評(píng)估，再?zèng)Q策出適合當(dāng)前環(huán)境的最優(yōu)解方案，哪怕這個(gè)方案看起來(lái)是又瓜又蠢，但這就是我們的核心價(jià)值之一。

而廣義上的加載,是除了用戶體驗(yàn)，交互特效外還有數(shù)據(jù)、系統(tǒng)耗時(shí)組成。

前者我們上面說(shuō)，加載主要形式體現(xiàn)在動(dòng)效上。但這里需要補(bǔ)充的是，后者數(shù)據(jù)上的加載才是真正加載問(wèn)題的核心。要知道系統(tǒng)加載一條數(shù)據(jù)和十條數(shù)據(jù)所花費(fèi)的時(shí)間在我們看來(lái)是相似的，這樣低量的數(shù)據(jù)幾乎可以在0.01秒內(nèi)就能運(yùn)算出來(lái)。

但是要知道系統(tǒng)數(shù)據(jù)一般是上萬(wàn)級(jí)別的，讀寫(xiě)一百萬(wàn)條數(shù)據(jù)的時(shí)候，我們就能明顯感知到花費(fèi)的時(shí)間大大的增加，這個(gè)感知時(shí)間增加也就形成了加載。

在理解加載的時(shí)候，我們還需要了解數(shù)據(jù)上的加載屬于后端加載，頁(yè)面上的顯示內(nèi)容的加載就屬于前端的加載了；因?yàn)槊看巫x寫(xiě)都需要進(jìn)行時(shí)間等到系統(tǒng)反饋，每次頁(yè)面內(nèi)容的顯現(xiàn)，都是內(nèi)容的緩存，點(diǎn)擊的反饋組合一起的結(jié)果，這些都是需要耗時(shí)的。這也是我為什么說(shuō)這是廣義上的加載。

二、常見(jiàn)的加載

因加載刷新實(shí)現(xiàn)原理相同，只是文字描述的定義不同，這里我們暫時(shí)當(dāng)成一體看待，如果要區(qū)分，也可以認(rèn)為第一次裝載內(nèi)容時(shí)叫加載，對(duì)已裝載的內(nèi)容進(jìn)行再次裝載我們叫刷新即可。

1. 全屏

這種加載方式在手機(jī)APP中十分常見(jiàn)，但是在PC網(wǎng)頁(yè)端不常見(jiàn)（甚至是不用做）。

常見(jiàn)平臺(tái)：移動(dòng)端

優(yōu)點(diǎn)：完整性好，在對(duì)完整性有特殊要求的閱讀類(lèi)等應(yīng)用中，使用全屏加載可以很好的保障用戶閱讀內(nèi)容的完整性。

缺點(diǎn)：在弱網(wǎng)（流量信號(hào)弱）、服務(wù)器異常（服務(wù)器響應(yīng)時(shí)間過(guò)長(zhǎng)）等情況下，會(huì)長(zhǎng)時(shí)間處于加載狀態(tài)。如果未做瀏覽緩存功能，會(huì)讓用戶像傻子一樣等著。

2. 拉拽（觸發(fā)式）

移動(dòng)端：

PC端：

優(yōu)點(diǎn)：比較符合用戶的交互習(xí)慣，不管是上拉還是下拉，都屬于用戶正常的操作行為。能夠增加產(chǎn)品的趣味性和“溫度”。

缺點(diǎn)：當(dāng)用戶操作行為幅度不夠大的時(shí)候，不容易觸發(fā)當(dāng)前加載機(jī)制。特別是在部分中老年人使用的時(shí)候，常常無(wú)法正常喚起加載。

當(dāng)然除了滑動(dòng)行為觸發(fā)的加載，還有就是用戶主動(dòng)點(diǎn)擊按鈕加載的方式，我將他們統(tǒng)稱為觸發(fā)式加載。因?yàn)椴还苁腔瑒?dòng)還是點(diǎn)擊都屬于用戶的交互而作出的觸發(fā)，因此將他們歸于一類(lèi)。

3. 骨架

移動(dòng)端：

PC端：

優(yōu)點(diǎn)：銜接用戶感官，和真實(shí)內(nèi)容布局相似提升體驗(yàn)

缺點(diǎn)：研發(fā)調(diào)試成本高，有可能出現(xiàn)做了效果，但是從來(lái)都沒(méi)有觸發(fā)過(guò)。

骨架屏加載常用和自動(dòng)加載、懶加載以及預(yù)加載幾個(gè)配合使用。這也照常其實(shí)很多人很難區(qū)分他們?nèi)齻€(gè)的區(qū)別，所以簡(jiǎn)單的提及一下。

• 骨架加載：正式在加載前，等待后端反饋接口，本地?zé)o最新緩存內(nèi)容后觸發(fā)，配合自動(dòng)加載、懶加載使用。
• 自動(dòng)加載：監(jiān)控用戶操作行為進(jìn)行觸發(fā)。如：滑動(dòng)、點(diǎn)擊等
• 懶加載：通過(guò)接口或代碼延遲加載某些內(nèi)容或符合固定行為進(jìn)行加載。如：對(duì)內(nèi)容接口拆分處理，根據(jù)優(yōu)先反饋數(shù)據(jù)進(jìn)行展示。

4. 自動(dòng)加載

優(yōu)點(diǎn)：在網(wǎng)絡(luò)暢通情況下，讓用戶對(duì)內(nèi)容的加載無(wú)任何感官。抖音、快手的利器之一。

缺點(diǎn)：對(duì)部分低流量用戶不太友好，畢竟后臺(tái)要偷跑流量。?

在設(shè)計(jì)的時(shí)候可以適當(dāng)?shù)拿鞔_自動(dòng)加載邊界，是加載后續(xù)多少內(nèi)容。內(nèi)容是全量標(biāo)題、圖片、視頻一起全部加載完成，還是低量只是加載標(biāo)題和骨屏結(jié)合懶加載進(jìn)行顯示。

5. 懶加載（分步驟、漸進(jìn)加載）

優(yōu)點(diǎn)：在網(wǎng)絡(luò)暢通情況下，讓用戶對(duì)大內(nèi)容都加載有一定的連貫性，適合feel模式（瀑布式）。

缺點(diǎn)：只要技術(shù)不拉垮就沒(méi)問(wèn)題，如果拉垮，內(nèi)容會(huì)顯示不全。

再次申明我理解他們是從技術(shù)角度進(jìn)行名詞區(qū)分的，如有失誤請(qǐng)諒解。

6. 預(yù)加載

這里可能會(huì)讓你感覺(jué)和上面幾個(gè)加載相似沒(méi)有什么區(qū)別，那是因?yàn)樗麄冎饕獏^(qū)別在于技術(shù)實(shí)施上。

這種預(yù)加載可以是在加載外部?jī)?nèi)容列表的時(shí)候就已經(jīng)將所有列表的文字內(nèi)容進(jìn)行緩存了。就是在無(wú)網(wǎng)絡(luò)情況下點(diǎn)擊進(jìn)入文章也能正常閱讀文字，在閱讀文字的時(shí)候進(jìn)行圖片、視頻的加載（自動(dòng)加載和懶加載都說(shuō)的同，只是代碼邏輯不通而已）。

優(yōu)點(diǎn)：對(duì)文字內(nèi)容產(chǎn)品支撐較好，因?yàn)槲淖謱?duì)流量、存儲(chǔ)要求較低，后臺(tái)偷跑流量很少，幾乎可不記。

7. 多態(tài)（異步加載）

這種比較靈活，可以因?yàn)樾枰虞d過(guò)長(zhǎng)，所以強(qiáng)行以為了驗(yàn)證你的賬戶安全進(jìn)行驗(yàn)證，之后在你輸入驗(yàn)證碼的時(shí)間內(nèi)進(jìn)行加載。同理還讓你玩游戲等待等。

上面這些內(nèi)容簡(jiǎn)單的列舉了我們常見(jiàn)的加載樣式，接下來(lái)我們便深入一丟丟講解下技術(shù)上的加載，以便從產(chǎn)品角度解決技術(shù)的上問(wèn)題。

三、后端的加載

我們可以把負(fù)責(zé)業(yè)務(wù)能力開(kāi)發(fā)，并將業(yè)務(wù)數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)的開(kāi)發(fā)人員統(tǒng)稱為后端開(kāi)發(fā)（研發(fā)）。同時(shí)數(shù)據(jù)在展示到頁(yè)面之前，都需要通過(guò)后端技術(shù)手段先從數(shù)據(jù)提取出數(shù)據(jù)再通過(guò)設(shè)計(jì)好的邏輯運(yùn)算得到結(jié)果，最后將結(jié)果反饋給前端用于頁(yè)面呈現(xiàn)，便形成了系統(tǒng)。所以后端是我們認(rèn)知加載的第一步。

后端開(kāi)發(fā)在寫(xiě)代碼的時(shí)候一定會(huì)遵循開(kāi)發(fā)模式進(jìn)行開(kāi)發(fā)，因?yàn)殚_(kāi)發(fā)工作本就是多人配合的工作，只有大家按照約定成俗的設(shè)計(jì)規(guī)范進(jìn)行開(kāi)發(fā)，才能相互維護(hù)和迭代。雖然也有不遵循的開(kāi)發(fā)，但與我們無(wú)關(guān)，我們了解一下即可。

后端的開(kāi)發(fā)模式會(huì)按照各自負(fù)責(zé)的模塊進(jìn)行拆分，分成業(yè)務(wù)、工具、數(shù)據(jù)庫(kù)、對(duì)象和服務(wù)等模塊。代碼們根據(jù)各自職能做到各司其職，好似流水線工人流水作業(yè)。因此，這樣能夠避免出現(xiàn)代碼冗余出現(xiàn)代碼雜亂和耦合，也能有效減少資源浪費(fèi)和維護(hù)困難等問(wèn)題。

想知道加載時(shí)間是多少，只需要計(jì)算數(shù)據(jù)在服務(wù)器中花費(fèi)時(shí)間之和就行，這便是所謂的加載時(shí)間了。同時(shí)，我們還需要分成兩部分來(lái)進(jìn)行認(rèn)知。一個(gè)是系統(tǒng)耗時(shí)，另一個(gè)是數(shù)據(jù)庫(kù)耗時(shí)。

后端系統(tǒng)耗時(shí)主要是由于數(shù)據(jù)要在不同模塊之間扭轉(zhuǎn)所耗費(fèi)的時(shí)間組成，這類(lèi)耗時(shí)可以說(shuō)是十分少，但也會(huì)出現(xiàn)系統(tǒng)耗時(shí)過(guò)長(zhǎng)的時(shí)候，但只要我們確定了問(wèn)題，很快就能對(duì)這部分代碼進(jìn)行優(yōu)化從而恢復(fù)到最佳效果。

但是還有一種無(wú)法優(yōu)化代碼的情況，那就是產(chǎn)品邏輯上的問(wèn)題造成的系統(tǒng)耗時(shí)增加，這種是優(yōu)化代碼都無(wú)法縮短縮短耗時(shí)的，因?yàn)樾薷牧司蜔o(wú)法實(shí)現(xiàn)業(yè)務(wù)邏輯。所以為了避免出現(xiàn)這種情況，我們?cè)谠O(shè)計(jì)產(chǎn)品功能的時(shí)候需要注意幾個(gè)問(wèn)題：

1. 預(yù)讀緩存、異步處理

在不必要環(huán)節(jié)使用異步處理作為主選方式，所謂的實(shí)時(shí)反饋也不一定需要實(shí)時(shí)處理。例如在設(shè)計(jì)含有首頁(yè)信息的產(chǎn)品，我們可以先讓用戶查閱緩存的內(nèi)容，這個(gè)緩存內(nèi)容可以是前端緩存（緩存到用戶客戶端上的內(nèi)容），也可以是后端緩存內(nèi)容（實(shí)現(xiàn)預(yù)緩存好的內(nèi)容）。

因?yàn)槭菫g覽緩存內(nèi)容，所有用戶幾乎是感觸不到加載耗時(shí)，就算是從后端讀取的緩存內(nèi)容，這個(gè)加載時(shí)間也會(huì)很短暫，比直接讀取實(shí)時(shí)數(shù)據(jù)快捷幾倍。

同時(shí)，我們?cè)诋?dāng)用戶瀏覽的時(shí)候，我們這是就可以進(jìn)行前后端的預(yù)加載等待用戶的再次加載行為（等待接口的觸發(fā)的時(shí)候，后端已開(kāi)始進(jìn)行相關(guān)內(nèi)容的預(yù)加載）。

常見(jiàn)加載場(chǎng)景：預(yù)加載、自動(dòng)加載、懶加載

常見(jiàn)應(yīng)用場(chǎng)景：電商產(chǎn)品、內(nèi)容產(chǎn)品

2. 冷熱數(shù)據(jù)切換

冷熱數(shù)據(jù)分別是指冷數(shù)據(jù)和熱數(shù)據(jù)，冷數(shù)據(jù)代指固定數(shù)據(jù)，不會(huì)發(fā)生變化，不會(huì)被其他服務(wù)使用的數(shù)據(jù)。熱數(shù)據(jù)代指短期內(nèi)大量被讀寫(xiě)查詢的數(shù)據(jù)。

在做產(chǎn)品時(shí)會(huì)遇見(jiàn)一些奇怪的需求，比如強(qiáng)制需要查看實(shí)時(shí)數(shù)據(jù)（老板、投資人需求無(wú)法拒絕）。在面對(duì)這種需求的時(shí)候我們會(huì)遇見(jiàn)很多問(wèn)題。

比如，線上數(shù)據(jù)在實(shí)時(shí)讀寫(xiě)，每秒有大量的數(shù)據(jù)在寫(xiě)入，這時(shí)提取數(shù)據(jù)會(huì)增加數(shù)據(jù)庫(kù)負(fù)載，有可能造成數(shù)據(jù)庫(kù)負(fù)載過(guò)高影響用戶使用（直接數(shù)據(jù)庫(kù)“爆炸”）。

所以我們?cè)谠O(shè)計(jì)功能時(shí)，要盡可能對(duì)實(shí)時(shí)數(shù)據(jù)少用，如果無(wú)法避免必須大量使用，那么協(xié)調(diào)研發(fā)復(fù)刻數(shù)據(jù)庫(kù)作熱數(shù)據(jù)向冷數(shù)據(jù)轉(zhuǎn)化使用。設(shè)計(jì)固定周期如30分鐘、1小時(shí)，每到固定時(shí)間同步一次，將線上實(shí)時(shí)數(shù)據(jù)庫(kù)或指定數(shù)據(jù)同步至我們復(fù)刻的冷數(shù)據(jù)庫(kù)中以便正常使用。

這個(gè)問(wèn)題也可以用異步的方式出了，比如要使用的時(shí)候必須先發(fā)起查詢請(qǐng)求，之后等待一定的時(shí)間，在等待時(shí)間結(jié)束后才給結(jié)果。

但這種方式實(shí)效性比較差，遇見(jiàn)強(qiáng)制要求實(shí)時(shí)查詢的需求，那么還是冷熱數(shù)據(jù)切換比較滿足需求（研發(fā)：再急也必須等我把數(shù)據(jù)撈出來(lái)啊，不然你來(lái)），又或者通過(guò)新技術(shù)去獲取。

常見(jiàn)加載場(chǎng)景：拉拽加載（觸發(fā)式加載）

常見(jiàn)應(yīng)用場(chǎng)景：ERP、B端產(chǎn)品

3. 避免動(dòng)態(tài)計(jì)算數(shù)據(jù)

我們要知道后端服務(wù)是給用戶提供基礎(chǔ)服務(wù)能力的，但這種服務(wù)能力只是包含少量的計(jì)算服務(wù)，而非專(zhuān)門(mén)作為計(jì)算而衍生出的計(jì)算服務(wù)。

所以我們要盡可能減少數(shù)據(jù)的計(jì)算，避免所展示的內(nèi)容是需要通過(guò)繁重的計(jì)算而產(chǎn)生。需要注意的是推薦策略或推薦系統(tǒng)其實(shí)也算額外的計(jì)算服務(wù)，使用他們勢(shì)必造成耗時(shí)增加，但這種耗時(shí)增加屬于可控范圍，同時(shí)優(yōu)勢(shì)大于劣勢(shì)，所以不必過(guò)于排斥。

如果結(jié)果卻是需要計(jì)算處理，可以通過(guò)建立產(chǎn)品矩陣，通過(guò)另一條產(chǎn)品線（單獨(dú)部署一套服務(wù)給他用戶）進(jìn)行處理，又或者將未處理數(shù)據(jù)進(jìn)行導(dǎo)出，讓他人工處理。

還有就是通過(guò)熱冷數(shù)據(jù)轉(zhuǎn)化后，定時(shí)在固定周期內(nèi)用閑置時(shí)間內(nèi)的服務(wù)進(jìn)行計(jì)算（比如每天凌晨人少的時(shí)候進(jìn)行異步計(jì)算），計(jì)算后再存儲(chǔ)至冷數(shù)據(jù)庫(kù)中，以便直接使用。

常見(jiàn)加載場(chǎng)景：骨架加載

常見(jiàn)應(yīng)用場(chǎng)景：數(shù)據(jù)可視化、數(shù)據(jù)類(lèi)產(chǎn)品功能

從產(chǎn)品角度來(lái)說(shuō)，能夠從產(chǎn)品角度去優(yōu)化后端加載的暫時(shí)我就了解上面幾種，下面我們接著說(shuō)從產(chǎn)品角度如何去優(yōu)化前端的加載。

四、前端的加載

前端的加載耗時(shí)更多是技術(shù)上的耗時(shí)，以產(chǎn)品角度調(diào)整功能設(shè)計(jì)其實(shí)比較難以進(jìn)行優(yōu)化，，每當(dāng)你看頁(yè)面加載半天不顯示結(jié)果的時(shí)候去問(wèn)前端研發(fā)。前端常說(shuō)：

“你去找后端，這是后端的問(wèn)題。你看我這接口已經(jīng)請(qǐng)求了，是后端數(shù)據(jù)沒(méi)反過(guò)來(lái)，所以一直卡在加載…..“

不要以為這是前端開(kāi)騙你，但確實(shí)是事實(shí)。因?yàn)榇蟛糠智闆r下前端加載時(shí)間過(guò)長(zhǎng)都是因?yàn)楹蠖藛?wèn)題造成。所以和研發(fā)好好溝通定位問(wèn)題即可。雖然問(wèn)題大部分是后端問(wèn)題，但我們簡(jiǎn)單的了解下前端可優(yōu)化加載速度還是有好處的。

前端主要核心在于效果呈現(xiàn)和用戶交互兩個(gè)方面。效果呈現(xiàn)主要是說(shuō)前端要通過(guò)代碼和框架將內(nèi)容將數(shù)據(jù)內(nèi)容可視化成用戶可以理解的畫(huà)面，而用戶交互則是將用戶在可視化頁(yè)面上的接觸行為轉(zhuǎn)化成數(shù)據(jù)交互。

1. 資源整合復(fù)用（雪碧圖）

頁(yè)面上會(huì)有很多icon小圖標(biāo)和圖片組成，其實(shí)單獨(dú)一個(gè)一個(gè)加載這些圖片是十分麻煩的，先不說(shuō)請(qǐng)求多，其次還會(huì)因?yàn)榧虞d順序的問(wèn)題，出現(xiàn)部分icon圖標(biāo)提前顯示，一部分icon圖標(biāo)不顯示。

這時(shí)可以使用資源整合復(fù)用的方式，將很小的icon圖標(biāo)或小圖，合并成一張大圖，再通過(guò)相關(guān)技術(shù)去識(shí)別所需求的小圖能極大的縮減時(shí)間。

常見(jiàn)應(yīng)用場(chǎng)景：移動(dòng)端app、小程序

2. 分頁(yè)預(yù)加載

還有我們場(chǎng)景的預(yù)加載，懶加載和自動(dòng)加載等技術(shù)，這都屬于前端技術(shù)。在數(shù)據(jù)內(nèi)容較多時(shí)采用分頁(yè)、自動(dòng)加載等形式在用戶瀏覽等間隙進(jìn)行加載后續(xù)內(nèi)容，等內(nèi)容加載完成后放置本地緩存，用戶點(diǎn)擊下一頁(yè)或滑動(dòng)時(shí)可立即看到頁(yè)面內(nèi)容。

常見(jiàn)應(yīng)用場(chǎng)景：瀏覽場(chǎng)景下

3. 前后端配合：資源最小化利用

原理很簡(jiǎn)單，協(xié)調(diào)前后端進(jìn)行約束，在需要加載圖片的地方將高質(zhì)量圖片轉(zhuǎn)化成低質(zhì)量圖片進(jìn)行展示（原圖1MB，在展示的時(shí)候展示20KB低質(zhì)量版），在需要展示原圖時(shí)再暫時(shí)原圖。

還有就是約束視頻內(nèi)容的緩存是在加載頁(yè)面的時(shí)候進(jìn)行緩存還是在用戶點(diǎn)擊播放的時(shí)候進(jìn)緩存。這也會(huì)影響頁(yè)面內(nèi)容的加載。

五、總結(jié)

文章就在這里，其實(shí)對(duì)于加載技術(shù)上還有很多可以說(shuō)的東西。比如：耗時(shí)最嚴(yán)重地方其實(shí)是數(shù)據(jù)SQL（數(shù)據(jù)庫(kù)操作語(yǔ)言）查詢方面，要對(duì)SQL、索引、表結(jié)構(gòu)進(jìn)行優(yōu)化才能減少耗時(shí)等。

但我們畢竟不是研發(fā)，而且這文章是從產(chǎn)品角度去思考的，大家簡(jiǎn)單的了解下就行不用去研究那么多。另外，我不想過(guò)多的從技術(shù)角度去講解，畢竟我也不太會(huì)技術(shù)哈哈。

這篇文章的意義在于，我想告訴大家不要一說(shuō)到加載，只能想到什么加載樣式、用戶體驗(yàn)的。我們要知道是什么原因造成了這里會(huì)加載，這個(gè)加載耗時(shí)會(huì)是多久，能不能優(yōu)化，能優(yōu)化該找前端還是后端。

不能優(yōu)化那么該如何協(xié)調(diào)其他人從用戶體驗(yàn)上去改變用戶對(duì)我們產(chǎn)品的感官等。畢竟做產(chǎn)品經(jīng)理容易做產(chǎn)品難，要學(xué)的東西太多了，學(xué)無(wú)止境呀。

作者：wcof，在努力做產(chǎn)品不做產(chǎn)品經(jīng)理的人；微信公眾號(hào)：Wcof（ID：wcofPM）

本文由 @Wcof 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議。