回憶曾跨過的坎:開局就被要求給頁面做性能優化

語言: CN / TW / HK

引言

我在剛入行那年,第一次參加內部團建的時候,我對着領導大放厥詞:“老大,你有沒有感覺咱app上那些h5頁面都好卡啊!隨便點個入口進去明顯感覺要等好久……”

當時一個大組裏有幾個小組,總共37號人。我就藉着酒勁當着所有人的面“胡亂詆譭”他人。其實是我年輕氣盛不懂事,現在想想簡直是社死現場。

第二天到公司,老闆叫我進了小黑屋。故事也就從此拉開了前端這條路的第一次序幕……

原來能被接手的都是爛攤子

從小黑屋裏出來,我腳底都是漂浮的。沒辦法,自己吹的牛跪着也要崩住了。

關於性能瓶頸的普遍問題

小黑屋裏也不是什麼都沒收穫,領導很認真的給我説了一下目前公司遇見的一些疑難雜症。有以下幾條。

  • 頁面打開慢,例如點擊商品標籤跳轉到詳情頁的時候,白屏的時間有點長(能清晰的被用户感知到慢)
  • 喚端失敗率很高,以至於目前都放棄了從外鏈喚起app到達目標頁面的功能。
  • 老闆不知道咱做的功能好還是壞,全靠實際的下單量、客單價、毛利來做評判(總之就是賺錢多少)
  • 活動頁更新迭代很慢,一到大促就需要技術瘋狂加班……

你看,做老闆的都是直切要害,告訴你現在遇到的瓶頸。 但是,沒有人教我怎麼做。你沒辦法很順利的直接將老闆的話變成技術瓶頸。 這都需要你去分析去看。

作為一枚初入行的菜鳥,即羞澀又恐慌,導致即不敢問,也不敢説自己不懂(死要面子)。遇事不決先觀察,我曾經是美術生,寫生的時候第一件要認真做的事情就是觀察花草樹木人的每個細節,然後才能決定如何下筆。

我大概花了1個星期多一點時間,去勾搭各個部門的人,一副我對誰都有興趣的樣子(後續渣男的綽號也由此而來)。

  1. 我從數據團隊那邊要了份簡易的用户行為數據,大概瞭解到高流量被分佈在哪些時間段,對哪些業務比較敏感。
  2. 從客户端那瞭解瞭如何與h5頁面打交道的
  3. 從基礎服務、部署平台那邊瞭解了前端h5項目的整個編譯打包部署流程

得出初步結論:

1. 流量大的頁面,例如大促活動頁內容太豐富了,沒有主次之分。

2. 打包後的bundle.js 體積太大,不利於頁面加載資源。

2. 異常率較高,頁面報錯、接口異常、白屏次數多。

嘗試有效解決方法

腦瓜子疼。知道得越多,腦瓜子越疼。 這才2016年(當時是2016年),為什麼我這個菜鳥要承受生命不該承受之痛苦。

我勾搭了一個客户端的小姐姐(我發誓,純技術交流),也是最耐心最好溝通的一個。當時她提醒過我一句:“你為什麼不做緩存呢?我們 webview 都是活着的。”

我讓小姐姐給我打了個測試包,給我提供了一個方法能直接去更改緩存的方法。我只剩那麼一試,我僅僅只是將一個不復雜頁面的HTML 和 css 單獨抽出來,直接寫死到緩存裏。然後那個頁面 "chua~" 一下就出來了,雖然只是個靜態頁面,但這説明我的路子可能是對的。這樣,我就開始想着有哪些東西是可以放到緩存或者交給客户端幫忙解決的。

很快,小姐姐又給我來了個透心涼:不要想着啥都放緩存,緩存有限制的,而且活動頁辣麼多……

我忽然間意識到,也只有商城首頁才最有資格去使用緩存。比較首頁的資源才是最多的,其中最重的就是圖片了。那時候有去扒拉某淘的頁面是怎麼處理資源的。 驚奇發現打開某淘的活動頁,內容已經都看到了,但有些請求缺還在發。最關鍵的是一些圖片資源url 是.webp

所以初步總結下

1. 圖片是大頭,首頁的圖片可以放緩存。儘量都處理成webp格式

2. 瀏覽器緩存配好

3. 非首頁儘量做到少加載資源,或者不重要的資源延遲加載

4. 接口也是個大頭,關鍵接口也可以做個預請求

分析一下不同點的解決方案實現難度

圖片問題好説,沒啥大的技術含量,轉下格式,做好圖片緩存。 首頁靜態資源也好説,畢竟是首頁,有充足的理由去和客户端那邊進行溝通。

問題是非首頁的問題咋搞。即使做了延遲請求、延遲加載,依舊還是差了些意思。這時候,我心裏已經有些底了。我去找我的領導説: “我們能不能搞一個node服務,搞SSR。”

現實狠狠打了我的臉。

1. 你知道申請一台機器要花多少成本嗎?

2. 你能保證這個服務穩定嗎?

3. 你一個人搞不定吧? 現在資源有些緊張……

其實有預料到這樣的結果,別説老闆了,全公司估計也沒誰會輕易的相信一個剛入行的菜鳥萌新,況且也暫時拿不出能讓領導們認可的技術方案和可預測的結果。

關於SSR 的替代方案,倒是想了個竅門,就是讓客户端打開webview 的時候也做一個延遲。 簡單來説就是 webview已經打開了,但是延遲一點時間跳轉到h5頁面。

以現在的眼光看待曾經的問題

很明顯,現在已經老掉牙的h5性能優化的幾個點: 懶加載、緩存、離線包、並行化 ……

現在的知識點已經很多很豐富,現在網上資料一大堆。 以現在的角度來講,手段並不難,難的是如何根據實際業務場景去作出合適的選擇。 公司必然會考慮 成本、投入產出問題。

這時候你可能需要清晰的瞭解到,哪些頁面是需要做到秒開的,或者秒開率要達多少。那從賺錢的角度來講,千萬級流量的頁面強網秒開要達80%,弱環境達50%。 百萬級流量……

那話又説回來,當你把頁面秒開做的足夠好了,你又該怎麼證明呢? 或者説 你該拿什麼來像老闆證明你達到了要求呢? 老闆需要你用準確的數據、可視化的圖表來清晰直觀的表達結果是怎樣的。

老闆的要求其實劃分一下就兩點:

1. 快、流暢

2. 穩定

至於老闆能賺多少錢,剩下的問題就是業務和產品的問題了。

關於下篇文要講的穩定性平台

可能會有人問: 穩定性平台幹嘛的?

給個準確定位的話,大概有幾點: 用户畫像(用户行為)異常概況告警容災

根據字面意思其實就能很清晰的瞭解。 你要知道用户幹了什麼, 如有異常(js異常、服務異常、白屏、卡頓等)要及時告知相關責任人,並進行告警。容災,如果線上萬一哪個環節出了問題(尤其是大促場景流量很高的時候)能及時回覆至上一個正常狀態。

下面先放在簡陋的圖:

一個項目通常都會經歷 需求 -> 開發 -> 測試 -> 預發/發佈 -> 線上運行 幾個階段。 不同公司之間的區別也就是在不同階段中規範標準的不同。但毫無疑問的是,必須要先保證線上運行階段是正常的,然後才有必要去談其它階段。 其實圖中要仔細畫的還有很多, 下篇文重點講一下穩定性相關內容。

( 我正在參與掘金技術社區創作者簽約計劃招募活動,點擊鏈接報名投稿。 )