共计 3637 个字符，预计需要花费 10 分钟才能阅读完成。
前奏
一个前端，成家之时，须要一份婚礼邀请函。用网上哪些网站（婚礼纪、易企秀）生成进去的，款式、动画成果感觉很赞，但公司 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 -gfont-spider 的字符压缩，其实是基于 html 页面的字符和字体款式进行压缩的，所以当下的开发方式(html 内容写在 js 中)，字符压缩根本干不了什么；所以只有先提取 js 中的内容放到一个空 html 中，而后再做压缩；为了让这一工程简化，我写了一段命令，你只需运行一个指令，即可实现压缩：
- 运行指令
npm run font自动化的字符提取思路，能够查看我仓库中的代码。
其余
这里做最重要的一个揭示，因为咱们的邀请函多是走微信收回给亲朋好友，那腾讯平安的那倒砍你必须先淌过，我记忆中须要做两件事：1、域名最好是 https，并且是国内的；2、域名根门路含有腾讯颁发的序列化文件。我邀请函刚收回时，就发现没法拜访，就辨认为欺骗，前面和对方邮件沟通，才解封：
至此，终于把 5 个月前打算写的货色写完了，做这个分享，愿能对你有一点小帮忙。本人写一个邀请函，尽管折腾，但本人做的，能充沛表白本人，媳妇称心，感觉就很值得了。
