前端开发之如何正确实现加载过程中…

加载过程中根据其所应用场景，其实现并不一样。本文根据服务端渲染与浏览器端渲染以及客户端渲染三种应用场景分别阐述其实现的细节原理与技巧。

首先需要声明的一点是，我们强烈反对同构开发，不是我们做不到同构开发，而是因为这是一种不科学不合理的开发方式，举个例子吧！造飞机✈不难，造一个高性能飞机也不难，造船不难，造潜水艇也不难，但要造一个即能飞天，又能下潜，还能陆地跑，除了玩具外，我不认为它能投入生产。别的就不多说了，如果看完下面的内容，并且知道讲的是什么，就不难理解，为什么没有人造即能飞天又能潜水的怪怪物了。

在云上：天空飞翔之服务端渲染

在陆地：小步快跑之浏览器端渲染

深海潜行：客户端渲染如何设计一个好用的loading

服务端渲染之实现一个绿色的加载进度条

服务端渲染是指在服务器上根据用户的请求，进行数据处理，然后吐出一段html或png或txt或css的任意数据给浏览器或客户端，客户端接受到之后会去解码数据，如果是html的话还会去渲染这段html，如果我们的网页在服务端渲染的内容比较多，不光是数据处理，而是内容比较多，受限于网络传输的不稳定，一个网页的内容可能超过500kb，而此时用户的网络可能并不快，浏览器本身已经考虑到这种情况，会采取逐步渲染的方式呈现网页，当然前提是不能有阻塞内容呈现的js存在。很多时候用户和浏览器并不知道这个网页究竟有多长，response header里面的content length并不是规范里面强制规定的，也就是网页本身就允许不定长度，直到接收到response end才算结束，所以一般浏览器也不看这个长度。

如何改善加载过程呢？

一般的做法是，先在header里面写一个function用于操作进度条显示。如

function updateProcess(rate:number):void

然后在body里面插入一个div，并为其编写好样式。注意必须是插入的静态的div标签，不能是js生成的哦，如果是js生成，注意不能使用onload事件绑定脚本，因为那样会阻塞页面的呈现，浏览器将显示一个空白的页面，或显示上一个页面的残影，而不是逐步加载了。

然后每一个块之间插入一个Script标签，内容是

...网页的一部分内容

updateProcess(20)

...网页的一部分内容

updateProcess(30)

...网页的一部分内容

updateProcess(40)

...网页的一部分内容

updateProcess(50)

...网页的一部分内容

updateProcess(100)

结束

这种方式适合于服务端渲染，除了可以在模版里面这么写外，也可以动态的根据处理的内容，实时flush内容到浏览器，以便提示加载的情况。但一般不这么做，因为每个连接都是有最大时间的，一般的服务器，最大连接时间是30多秒吧。但也有的服务器，因为考虑到性能，担心太多无用的链接占用，而选择超过5秒连接没有断开，将强制断开这些连接，这是有风险的，因为有一些地方网络不太好，比较校园网，可能才50kb的网速，如果一个网页的内容本身内容比较丰富且多，那么超过5秒后内容还没有加载完，却强行断开，会导致网页只显示一半。这时用户必须手动刷新一下页面，如果这个用户网络情况一直不好，则可能会出现一直无法打开，其实不是他没有网络，而是他的网络太慢，可能网速才几kb每秒，对于这些用户我们也不能直接放弃他们呀。改善弱网用户的体验也是程序员们所需要做的，解决办法就是异步加载呀。将数据都在服务端算好之后，通过api返回，然后前端处理后呈现出来。

这样可以加快用户的访问。具体的原理是因为

1、前端渲染更高效，有效的减少了数据的体积

2kb+10条1kb json数据=12kb

相同的内容服务端渲染好的

内容(2kb+1kb)*10遍=30kb

2、服务器渲染受服务器性能状况影响，而浏览器处理的性能几乎可以忽略不计

前端性能优化的几个点，

A、异步化加载，

B、前端各种各样的数据缓存

浏览器端的loading

浏览器端的loading，有很多人的用法是错误的，导致并没有起到loading的作用。正确的用法是

网页内容

先加载必要的meta，如编码，图标等

然后是标题，这样用户将能在最快的情况下看到网页的标题和logo，这是有意义的，用户这样才能知道这个网页是可以打开的，并且浏览器能更及时的给予用户反馈

必要的基础css，这个css不能特别大，也不能加载所有的样式图片，最好只有是loading的样式图片，大小不能超过2kb

loading的html的结构，只能是静态的html标签，不能用js操作

js的那些基础库什么的，比如jquery/react等当前页面的js

必须严格按这个顺序来加载，loading才能真实的反映出效果来。

对于用户来说，用户大部分的时候确实都是浪费在加载数据上面，不论是加载api数据还是加载网页的脚本样式。所有的时间都是浪费在传输上面，而网页本身支持逐步加载，那么先把loading加载出来，然后再加载那些元素，这样才能体现loading的作用啊，但很多网页啊，先把js加载好了，然后再显示个loading出来，然后显示页面，其实在大部分情况下，用户的体验是先是个大白页，然后过个2-3秒后，出来个loading，然后内容才出来。其实没有必要，这种情况下还不如不要loading呢，此时的loading其实只是反映请求api的时间，但是一般前端api都是要求即时响应的，并且数据量不会太大。真正大头上需要放loading的地方却没有放loading这才是问题。

客户端的loading

客户端也有loading，但不建议客户端和浏览器端那样，用整页的loading，因为没有必要啊，客户端的所有代码都是在本地执行的，又不像浏览器的代码需要先下载后执行。客户端代码都已经在本地了，都不需要加载代码，显示整页loading，没什么用，而对于api的加载时间，主流的app都是采用，刷新数据的方式加载。而loading，一般是不用，即使用也是局部的。什么是刷新数据的加载呢，就是app发布的时候，已经把整屏的数据内置到app里面了，所以即使此时用户初次安装，没有授权网络，断网离线，也能看到内容和图片，因为都是内置的数据，当获取到用户的网络权限后，请求api，刷新内置的数据。因为是在原数据位置更新数据，所以不需要loading，而是直接替换内容了。整屏的loading比较影响用户的操作，阻塞了流程，体验不好。。

根据水瓶座强大的预言能力，预测。未来做同构开发的最终将面临两个选择，

选择一，被前端开发给淘汰掉，因为跟不上前端开发的要求

选择二，被迫放弃同构开发。没有第三种可能~~