前奏
一个前端,成家之时,须要一份婚礼邀请函。用网上哪些网站(婚礼纪、易企秀)生成进去的,款式、动画成果感觉很赞,但公司 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 个月前打算写的货色写完了,做这个分享,愿能对你有一点小帮忙。本人写一个邀请函,尽管折腾,但本人做的,能充沛表白本人,媳妇称心,感觉就很值得了。