前奏
一個前端,成家之時,需要一份婚禮邀請函。用網上哪些網站(婚禮紀、易企秀)生成出來的,樣式、動畫效果感覺很贊,但公司logo、廣告彈窗、載入速度、自定義版圖都讓我這個職(qiang)業(po)前(zheng)端(huanzhe)感覺,這需求肯定過不了產品驗收。
除了這是一份簡單的婚禮邀請函架構之外,這更多是一個前端入門H5效能優化的開胃菜。
檢視效果,手機瀏覽器開啟,可點選: 演示demo
倉庫地址:Invitation-Demo
圖片均來源於網路,如有侵權,請聯絡刪除;
架構設計
框架選型
市面上哪些低程式碼輸出的邀請函,基本都是基於juery的;對於我這種沒有經歷過juery,IE摧殘的年輕前端,什麼jquery的架構設計,基本不會;原生JS,那也是不可能的;React一把梭,才是我的最優解,寫起來順手,自己的積累也最多;
基本就純react,沒有依賴什麼其他第三方庫,就外加了個React-Router 和 動畫庫;
<AnimatedRouter>
<Route path="/home" exact component={Home} />
<Route path="/guide" exact component={Guide} />
<Route path="/location" exact component={Location} />
<Route path="/bridge" exact component={Bridge} />
<Route path="/bridgeRoom" exact component={BridgeRoom} />
<Redirect to="/" component={Home} />
</AnimatedRouter>
架構設計
傳統設計,如婚禮紀、易企秀這些,大多采用基於錨點的單頁設計,和SPA有所區別, 是以前那種很純正的單頁, 可以理解為SPA的前身,就是所有的頁面內容都同時存在於一個html中,通過可見性或滾動來展示某個或多個頁面, 來個程式碼直觀點。
<body>
<header>
<a href="#first">1</a>
<a href="#sec">2</a>
<a href="#thi">3</a>
</header>
<content>
<div id="first">這是第一頁</div>
<div id="sec">這是第2頁</div>
<div id="thi">這是第3頁</div>
<div id="for">這是第4頁</div>
</content>
</body>
當我點選2時,會跳到第2頁,點選3時,跳到3頁,id在這裡作為一種描點標記。
SPA也是hash,但把錨點換了一種玩法,他是每一次切換hash時,動態在一個節點上解除安裝和重新掛載內容,不存在內容同時存在的情形。和上面的單頁相比:
缺點:頁面與頁面之間切換沒有那麼順滑,如果不做特殊處理,切換就會顯得很生硬;
優點:更符合現代前端的開發習慣
互動差別:錨點頁面切換,更多是上下滑動;而spa的切換,可上下,也可左右,這取決於開發者的處理方式;
所以在框架選型一節可以看到,我總共有5個頁面,為了頁面切換順滑,我使用了react-transition-group
元件來處理我的頁面過渡。
另外,為了把邀請函做的更像邀請函,我採用了幻燈片式的自動播放,播放完後支援手動滑動的方式。
autoPlay = async () => {
// 開始自動播放;
await wait(() => { this.props.history.push('/bridge'); }, WAIT_TIME);
await wait(() => { this.props.history.push('/bridgeRoom'); }, WAIT_TIME);
await wait(() => { this.props.history.push('/guide'); }, WAIT_TIME);
await wait(() => { this.props.history.push('/next'); }, WAIT_TIME);
await wait(() => { this.props.history.push('/location'); }, WAIT_TIME);
// 加滑動操作指示箭頭
touchArrow.create({ startHash: ['/', '/home' ], endHash: '/location' });
// 開啟滑動
touchManage(this.props.history);
}
所以在這些基礎上,我寫邀請函,就可以像寫一個普通前端應用那樣自如。
其他
因為要做成邀請函,又是自動播放,那肯定就少不了音樂,不然邀請函的代入感就大打折扣。
播放音樂其實是個很簡單的操作,在這個版權為王的時代,下首自己中意的歌才是最難的。
另外,為了更少的引入三方庫,減少包體積,所以在滑動手勢操作檢測和loading動畫上,我都採用了純手寫js和css的方式來實現。
樣式優化
作為一個婚禮邀請函,除了婚禮新人圖片一定要選漂亮的之外,網頁本身的樣式也需要過硬的設計。
基本的樣式排版,構圖,可以參考婚禮紀、圖怪獸上面的一些現成作品, 畢竟別人是靠這個吃飯的,設計上我不得不低頭。
翻頁動畫
在架構設計設計一節已討論過,spa 的頁面切換,如果不做特殊處理,切換時就會顯得很生硬,所以我引入了react-transition-group
元件,元件設計很面面俱到,你可以根據自己的需求,自定義過渡動畫;
元件使用很簡單,自定義一下css動畫就好。
圖片進場動畫
由於圖片,我做了壓縮處理和在頁面載入時做了prelaod,所以基本不用考慮圖片load的問題,只需考慮進場問題,做過ppt的就知道,進場動畫可以提升你簡報的水平,邀請函也一樣。
字型樣式
一般來說,我們用個預設字型,作為一個邀請函,整個頁面效果會顯得比較生硬,所以,最好的做法,是去網上選一個讓自己滿意的字型,然後css裡設定一下;
@font-face {
font-family: special;
src: url('./font.ttf');
}
body {
font-family: special;
}
載入優化
網路
如果你打包的靜態資源都放github pages裡,這肯定會很慢的。所以,有錢就買個好點的靜態資源服務,或者oss,這裡我強烈推薦阿里雲的,再有勝者,可以直接搞個cdn加速。
我個人都是部署一體化,靜態資源都部署在阿里雲伺服器上,圖片等媒體資源都放oss上,加上我域名開啟了http2,這樣的配置,基本能保證到首屏秒開。
預載入
因為我所有的資源都放在了oss上,整體架構是採用翻頁設計,所以採用了preload提前載入。
<link rel="preload" href="https://doddle.oss-accelerate.aliyuncs.com/strong/font.ttf" as="font" />
<link rel="preload" href="https://doddle.oss-accelerate.aliyuncs.com/strong/top.jpeg" as="image" />
<link rel="preload" href="https://doddle.oss-accelerate.aliyuncs.com/strong/btm.jpeg" as="image" />
這種方式,基本能保證下一頁,圖片不會loading,都是秒開。
圖片處理
一般一張婚紗照,圖片大小在8M以上,如果你直接拿這個去載入,你的邀請函別人開啟指定都是混亂不堪的, 所以圖片大小壓縮很重要,這裡我推薦一個網站,前端必收藏:squoosh, 基本上圖片大小能減少80% 以上。
加上前面的preload, 基本能保證圖片秒開;
字型處理
因為字型原始檔5M,載入肯定會很慢,所以採用了 font-spider 來做壓縮處理,處理完之後,一般檔案大小在100kb左右;
操作步驟:
- 全域性安裝font-spider 外掛
npm i font-spider -g
font-spider的字元壓縮,其實是基於html頁面的字元和字型樣式進行壓縮的,所以當下的開發方式(html內容寫在js中),字元壓縮基本幹不了什麼;所以只有先提取js中的內容放到一個空html中,然後再做壓縮;為了讓這一工程簡化,我寫了一段命令,你只需執行一個指令,即可完成壓縮:
- 執行指令
npm run font
自動化的字元提取思路,可以檢視我倉庫中的程式碼。
其他
這裡做最重要的一個提醒,因為我們的邀請函多是走微信發出給親朋好友,那騰訊安全的那倒砍你必須先淌過,我記憶中需要做兩件事:1、域名最好是https,並且是國內的;2、域名根路徑含有騰訊頒發的序列化檔案。我邀請函剛發出時,就發現沒法訪問,就識別為詐騙,後面和對方郵件溝通,才解封:
至此,終於把5個月前打算寫的東西寫完了,做這個分享,願能對你有一點小幫助。自己寫一個邀請函,雖然折騰,但自己做的,能充分表達自己,媳婦滿意,感覺就很值得了。