项目优化与用户体验的思考

这是我参与更文挑战的第3天，活动详情查看： 更文挑战

写作背景

先说结论，这篇文章是我完成几个项目之后的一些思考与总结，并不是性能优化的实践，所以小伙伴们觉得有所启发的话，可以在评论区多多交流。

图片

在我完成工作中的第一个项目之后， 心里有着说不出的恶心与难受。

不是觉得其他的什么恶心，而是为自己的代码感到恶心，写的时候自我感觉良好，但是之后就开始发现，自己的代码也成了自己所讨厌的*山。

难受也是因为自我感觉良好，最后这写出来这样的代码， 当时甚至有点崩溃，差点删库跑路了，别和我说前端不能接触数据库的鬼话，我可以删远程仓库。

所以我看着项目代码， 思考一下可以项目中可以优化的点。

结构

这一点原本是我最不看重的地方，但是也作为思考点的主要原因是，在请求数据的时候，空数据带来的结构塌陷，数据不足也会带来结构塌陷。尽管这个可以通过骨架屏或者loading+遮罩来掩饰，但确实是塌陷了。

首先，希望大家别反驳， 我知道可以遮挡，我知道真实上线后，会有足够的数据来撑起架构，但当时我还是思考了一下，是否有保持结构稳定的必要性。

不过想来或许会有一定的隐患，通过显示的设置宽高来维持的结构稳定，势必也会在开发响应式的过程中带来额外的负担，所以这一点大概只适合我这样独立开发且摸索自己风格的时候去搞，但凡有个协作同事，我估计都要被打死。

总结一下：这不是必须要做的，甚至非必须都算不上，只是在很冷门的某些情况下，才需要考虑。

骨架屏

这一点是有效提高用户体验以及个人愉悦度的方法了，但是并不是任何使用， 通常适用于列表（例如掘金首页），以及APP（其实也是列表）。如果是比较常规的布局网站，展示多个版块的，使用骨架屏就会带来我上面提到的结构问题。

因为骨架屏的结构往往与真是渲染数据之后的结构是不相同的，即便很有心的重写骨架屏结构保持与真实数据结构一致了，多个不同栏目使用不同结构结构的骨架屏也难免会有一些显得乱乱的。

总结一下：所以只适合在较为明显的重复布局（如列表）中使用骨架屏，涉及到非循环的布局，就不使用了。

loading

这个优化方案就是骨架屏的兄弟方案了，并且适用骨架屏的地方一定可以用loading，但是适用loading的地方，不一定使用骨架屏。

试想一下，当你打开腾讯官网，如下布局的时候，这种使用骨架屏吗？

答案是不适用，不过你会发现他用的也不是loading，而是另一种解决方案，下面会提到。

总结一下：骨架屏和loading可以算是互补的两个方案，但是有一个共同的缺点，都会显示加载过程。

首屏加载

这一方案也是我在看了好几篇文章之后，多次看到的一种解决方案。

其实也是一种补足方案，用于弥补骨架屏和loading等方案带来的加载过程这一缺点。

尽管看起来骨架屏和loading已经能满足大部分需求了，但是再想想，如果能直接让用户看到真实数据， 不是体验更好吗？

这就是这里提到的首屏加载方案了，个人认为，这种方案也有它的局限性，首先服务器得相对快一点，其次是更适用于首页非列表布局的场景下。如上面提到的腾讯官网。

可以shift+f5深刷新，实在不行句降网速看看他的加载效果，简而言之，就是先显示一部分，然后再渲染剩下的部分。

在我之前看过的文章中有提到，这种实现方法是优先保持图片结构稳定，其次是优先渲染文字>图片>动图，这个顺序并不是让浏览器去控制，因为浏览器可以同事渲染多个图片，但是也会导致加载时间过程的问题。

实现方式如下，先将获取到的图片地址存在自定义属性data-src中，待文字渲染结束后，通过js将图片url放入到行内样式中设置为背景图（img标签同理）。这一方案可以保证文案优先渲染，并在渲染图片的时候，优先渲染首屏的图片，之后是依次向下渲染，或者监听用户滚动高度实现渐入的效果，就看个人了。

这里推荐下我的看的小册： 前端性能优化原理及实践，众所周知（我自己），我推荐不是因为写作的作者多厉害，那不重要，我只看这份作品值不值得推荐。

<div data-imgurl="https://image.host.com" style="background-image: url('')" ></div>
复制代码

图片的使用

这部分的内容在上面推荐的修言大佬的小册前端性能优化原理及实践有写到，我就不过多阐述了。

主要原因也是，当我们在工作中，我们没办法去决定用户或甲方上传什么图，我们只能做好自己。

那我就总结下修言大佬的内容：对比度低用jpg，透明背景/高对比度图用png，渐进式加载需要用ps在保存图片时勾选连续并保存在jpeg（也是推荐的大图格式，占用内存较小）。

图标可以选择iconfont、使用base64、以及使用css雪碧图。不了解雪碧图看这

防抖与节流

防抖与节流，很早以前就看到过这个概念，以及实现方法， 但是一直不清楚有什么用。

但当我开发第一个项目的时候，我就知道了。

具体的实现我就不在这里写了，本文只提供一些思路。

粗暴的理解下防抖与节流：

防抖：用户完成动作前不执行，完成动作后自动执行

节流：用户动作期间，间隔一段时间执行一次。

最直接的应用场景，就是搜索的关联提示，这一效果可以参考百度搜索，在输入关键词时出现的搜索联想。

在我项目中有一个类似的场景，算是借用了防抖的思想，不过就是个简单的状态管理，即用户在拉起微信支付的时候，暂时禁用支付按钮，避免用户网络卡顿时，多次简单支付带来多个订单请求。

做法也就是加了一个状态，状态为false时，支付函数暂时不执行，等待上一个支付请求响应。