当前位置:千赢国际官网 > 千赢网页手机版登入 > 千赢国际官网拖拽上传前传,前端优化带来的思

千赢国际官网拖拽上传前传,前端优化带来的思

文章作者:千赢网页手机版登入 上传时间:2019-10-05

浏览器缓存机制浅析

2015/08/05 · HTML5 · 1 评论 · 缓存

本文作者: 伯乐在线 - 韩子迟 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

前端优化带来的思考,浅谈前端工程化

2015/10/26 · 前端职场 · 2 评论 · 工程化

原文出处: 叶小钗(@欲苍穹)   

File杂谈——拖拽上传前传

2015/07/24 · HTML5 · 拖拽上传

原文出处: 百码山庄   

在《File杂谈——初识file控件》一文中,我们已经对file控件有了初步的了解,并且对制作一个视觉和体验一致的file控件做了较为详细的说明,今天我们继续了解file控件的更多特性,并延伸出更多。

非HTTP协议定义的缓存机制

浏览器缓存机制,其实主要就是HTTP协议定义的缓存机制(如: Expires; Cache-control等)。但是也有非HTTP协议定义的缓存机制,如使用HTML Meta 标签,Web开发者可以在HTML页面的<head>节点中加入<meta>标签,代码如下:

XHTML

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

1
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

上述代码的作用是告诉浏览器当前页面不被缓存,每次访问都需要去服务器拉取。使用上很简单,但只有部分浏览器可以支持,而且所有缓存代理服务器都不支持,因为代理不解析HTML内容本身。下面主要介绍HTTP协议定义的缓存机制

重复优化的思考

这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚:

传输层面:减少请求数,降低请求量 执行层面:减少重绘&回流

1
2
传输层面:减少请求数,降低请求量
执行层面:减少重绘&回流

传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如:

① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流

② 浏览器在document下载结束会检测静态资源,新开线程下载(有并发上限),在带宽限制的条件下,无序并发会导致主资源速度下降,从而影响首屏渲染

③ 浏览器缓存可用时会使用缓存资源,这个时候可以避免请求体的传输,对性能有极大提高

衡量性能的重要指标为首屏载入速度(指页面可以看见,不一定可交互),影响首屏的最大因素为请求,所以请求是页面真正的杀手,一般来说我们会做这些优化:

新增属性

在HTML5到来之前,绝大多数情况下使用file控件,我们前端工程师需要的有用信息都只能通过value属性获得的文件名字符串来获取(比如:文件类型、文件的直接名称等),这个很不方便,多文件上传的时候就更加麻烦了。另外,我们想不通过其他手段获取上传文件的大小更是一种奢望。

不过,好在这一切并没有那么糟,随着HTML5的到来,file控件上新增了files属性。该属性包括了file控件选择的文件对象集合,每个文件对象包含了当前文件的基本信息(类型、名称、大小)等,这样一来我们再也不用使用正则啊,字符串拆分啊,等等麻烦的方法去获取我们想要的信息了。下面我们在Chrome的控制台看下files属性的结构。我的测试方法是这样的:

首先,使用Chrome浏览器随便打开一个网页,然后F12调出开发工具,接着在Console中输入:

JavaScript

document.body.innerHTML = '<input type="file" id="J_File">'; var f = document.getElementById('J_File'); f.onchange = function() { console.log(this.files); };

1
2
3
4
5
document.body.innerHTML = '<input type="file" id="J_File">';
var f = document.getElementById('J_File');
f.onchange = function() {
    console.log(this.files);
};

这时页面会被替换成一个file控件,点击选择一个或多个(多个需要在input标签上增加multiple属性)本地文件,这时change事件将会被触发,控制台将会输出一下数据:

千赢国际官网 1

显而易见,files属性的值是一个FileList类型的对象,它和数组类似,同样拥有length属性,而且我们也可以直接使用循环去获取每一个文件(File)对象(例:取第一个文件就是files[0])。我们继续看每个文件对象中包含的信息,我们常用的name、size、type等应有尽有了,突然感觉好高大上。

然而,我要告诉大家的是,我们也不能肆无忌惮的使用file控件的files属性,因为它在IE9及以下版本的IE浏览器中是不存在的,我们需要使用其他的手段(flash等)来弥补这个问题,这里就不展开了。

大话浏览器缓存

浏览器缓存一直是一个让人又爱又恨的存在,一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了“错误”的东西,而在开发过程中千方百计地想把缓存禁掉。如果没听说过浏览器缓存或者不知道浏览器缓存的用处,可以先浏览一下这篇文章->Web缓存的作用与类型 。

那么浏览器缓存机制到底是如何工作的呢?核心就是把缓存的内容保存在了本地,而不用每次都向服务端发送相同的请求,设想下每次都打开相同的页面,而在第一次打开的同时,将下载的js、css、图片等“保存”在了本地,而之后的请求每次都在本地读取,效率是不是高了很多?真正的浏览器工作的时候并不是将完整的内容保存在本地,各种浏览器都有不同的方式,譬如firefox是一种类似innodb的方式存储的key value 的模式,在地址栏中输入 about:cache 可以看见缓存的文件,chrome会把缓存的文件保存在一个叫User Data的文件夹下。但是如果每次都读取缓存也会存在一定的问题,如果服务端的文件更新了呢?这时服务端就会和客户端约定一个有效期,譬如说服务端告诉客户端1天内我服务端的文件不会更新,你就放心地读取缓存吧,于是在这一天里每次遇到相同的请求客户端都开心地可以读取缓存里的文件。但是如果一天过去了,客户端又要读取该文件了,发现和服务端约定的有效期过了,于是就会向服务端发送请求,试图下载一个新的文件,但是很有可能服务端的文件其实并没有更新,其实还是可以读取缓存的。这时该怎么判断服务端的文件有没有更新呢?有两种方式,第一种在上一次服务端告诉客户端约定的有效期的同时,告诉客户端该文件最后修改的时间,当再次试图从服务端下载该文件的时候,check下该文件有没有更新(对比最后修改时间),如果没有,则读取缓存;第二种方式是在上一次服务端告诉客户端约定有效期的同时,同时告诉客户端该文件的版本号,当服务端文件更新的时候,改变版本号,再次发送请求的时候check一下版本号是否一致就行了,如一致,则可直接读取缓存。

而事实上真正的浏览器缓存机制大抵也是如此,接下来就可以分别对号入座了。

需要注意的是,浏览器会在第一次请求完服务器后得到响应,我们可以在服务器中设置这些响应,从而达到在以后的请求中尽量减少甚至不从服务器获取资源的目的。浏览器是依靠请求和响应中的的头信息来控制缓存的

减少请求数

① 合并样式、脚本文件

② 合并背景图片

③ CSS3图标、Icon Font

file控件的地位受到威胁

随着files属性的出现,file控件的地位显然得到了很好的提升,但是这并不表示它的地位更加稳固。随着HTML5二来的,并不只有file控件的files属性。我们已经可以在越来越多的网站上可以看到拖拽上传这个一个新颖并且更符合用户行为的交互效果。这里我先不说拖拽上传功能的实现,我们先一起来看看另一种获取FileList对象的方法。

首先,我们需要一个拖拽上传的静态界面,细节不多说,直接上代码:

XHTML

<style> * {margin: 0;padding: 0;} .up-area {margin: 50px auto;border: 1px dashed #ccc;background-color: #eee;width: 600px;height: 400px;line-height: 400px;text-align: center;color: #666;cursor: pointer;} .up-area:hover {background-color: #ddd;} </style> <input type="file" name="" id="J_UploadFile" style="display: none;"> <div class="up-area" id="J_UploadArea"> 点击此处或拖入文件进行上传 </div> <script> (function(){ var area = document.getElementById("J_UploadArea"), file = document.getElementById("J_UploadFile"); function uploadFile(fs) { console.log(fs); } area.onclick = function() { console.log('click'); file.click(); }; file.onchange = function() { uploadFile(this.files); }; area.ondragenter = function(ev) { this.className = 'up-area hover'; ev.preventDefault(); }; area.ondragover = function(ev) { ev.preventDefault(); }; area.ondrop = function(ev) { ev.preventDefault(); console.log('drop'); var dt = ev.dataTransfer; this.className = 'up-area'; uploadFile(dt.files); }; })(); </script>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<style>
    * {margin: 0;padding: 0;}
    .up-area {margin: 50px auto;border: 1px dashed #ccc;background-color: #eee;width: 600px;height: 400px;line-height: 400px;text-align: center;color: #666;cursor: pointer;}
    .up-area:hover {background-color: #ddd;}
</style>
<input type="file" name="" id="J_UploadFile" style="display: none;">
<div class="up-area" id="J_UploadArea">
    点击此处或拖入文件进行上传
</div>
<script>
(function(){
    var area = document.getElementById("J_UploadArea"),
        file = document.getElementById("J_UploadFile");
    function uploadFile(fs) {
        console.log(fs);
    }
    area.onclick = function() {
        console.log('click');
        file.click();
    };
    file.onchange = function() {
        uploadFile(this.files);
    };
    area.ondragenter = function(ev) {
        this.className = 'up-area hover';
        ev.preventDefault();
    };
    area.ondragover = function(ev) {
        ev.preventDefault();
    };
    area.ondrop = function(ev) {
        ev.preventDefault();
        console.log('drop');
        var dt = ev.dataTransfer;
        this.className = 'up-area';
        uploadFile(dt.files);
    };
})();
</script>

在线Demo。将文件拖入灰色区域释放便可以在页面上看到文件信息。

细心的朋友可能已经发现了,其实我们这里又提供了优化file控件的另外一种方式——完全使用另一个标签替代,在该标签的click事件中主动触发file控件的click事件,正如上面代码中的: file.click() 。但是,这不是本文的重点。

我们仔细看上面代码中的最后一段,即ondrop的事件处理函数,我们的files对象并不是来自file控件,而是一个叫dataTransfer的东西。那么我们是不是可以大胆的猜测,拖拽上传功能其实可以完全抛开file控件独立完成?这里先留个悬念,我们以后再讨论。

在上面的案例中我们通过点击来选择文件从而获取FileList对象,和通过将文件拖拽到灰色区域来获取FileList对象,这两种方式虽不同,但我们得到的数据确是一样的,这足以说明file控件不再独裁,它的地位已经渐渐开始受到威胁。

1 赞 1 收藏 评论

千赢国际官网 2

Expires与Cache-Control

Expires和Cache-Control就是服务端用来约定和客户端的有效时间的。

千赢国际官网 3

比如如上一个响应头,Expires规定了缓存失效时间(Date为当前时间),而Cache-Control的max-age规定了缓存有效时间(2552s),理论上这两个值计算出的有效时间应该是相同的(上图好像不一致)。Expires是HTTP1.0的东西,而Cache-Control是HTTP1.1的,规定如果max-age和Expires同时存在,前者优先级高于后者。Cache-Control的参数可以设置很多值,譬如(参考浏览器缓存机制):

千赢国际官网 4

降低请求量

① 开启GZip

② 优化静态资源,jQuery->Zepto、阉割IScroll、去除冗余代码

③ 图片无损压缩

④ 图片延迟加载

⑤ 减少Cookie携带

很多时候,我们也会采用类似“时间换空间、空间换时间”的做法,比如:

① 缓存为王,对更新较缓慢的资源&接口做缓存(浏览器缓存、localsorage、application cache这个坑多)

② 按需加载,先加载主要资源,其余资源延迟加载,对非首屏资源滚动加载

③ fake页技术,将页面最初需要显示Html&Css内联,在页面所需资源加载结束前至少可看,理想情况是index.html下载结束即展示(2G 5S内)

④ CDN

……

从工程的角度来看,上述优化点半数以上是重复的,一般在发布时候就直接使用项目构建工具做掉了,还有一些只是简单的服务器配置,开发时不需要关注。

可以看到,我们所做的优化都是在减少请求数,降低请求量,减小传输时的耗时,或者通过一个策略,优先加载首屏渲染所需资源,而后再加载交互所需资源(比如点击时候再加载UI组件),Hybrid APP这方面应该尽可能多的将公共静态资源放在native中,比如第三方库,框架,UI甚至城市列表这种常用业务数据。

Last-Modified/If-Modified-Since

而Last-Modified/If-Modified-Since就是上面说的当有效期过后,check服务端文件是否更新的第一种方式,要配合Cache-Control使用。比如第一次访问我的主页simplify the life,会请求一个jquery文件,响应头返回如下信息:

千赢国际官网 5

然后我在主页按下ctrl r刷新,因为ctrl r会默认跳过max-age和Expires的检验直接去向服务器发送请求(下文再探讨各种刷新后如何读取缓存),我们看看请求截图:

千赢国际官网 6

请求头中包含了If-Modified-Since项,而它的值和上次请求响应头中的Last-Modified一致,我们发现这个日期是在遥远的2013年,也就是说这个jquery文件自从2013年的那个日期后就没有再被修改过了。将If-Modified-Since的日期和服务端该文件的最后修改日期对比,如果相同,则响应HTTP304,从缓存读数据;如果不相同文件更新了,HTTP200,返回数据,同时通过响应头更新last-Modified的值(以备下次对比)。

拦路虎

有一些网站初期比较快,但是随着量的积累,BUG越来越多,速度也越来越慢,一些前端会使用上述优化手段做优化,但是收效甚微,一个比较典型的例子就是代码冗余:

① 之前的CSS全部放在了一个文件中,新一轮的UI样式优化,新老CSS难以拆分,CSS体量会增加,如果有业务团队使用了公共样式,情况更不容乐观;

② UI组件更新,但是如果有业务团队脱离接口操作了组件DOM,将导致新组件DOM更新受限,最差的情况下,用户会加载两个组件的代码;

③ 胡乱使用第三方库、组件,导致页面加载大量无用代码;

……

以上问题会不同程度的增加资源下载体量,如果听之任之会产生一系列工程问题:

① 页面关系错综复杂,需求迭代容易出BUG;

② 框架每次升级都会导致额外的请求量,常加载一些业务不需要的代码;

③ 第三方库泛滥,且难以维护,有BUG也改不了;

④ 业务代码加载大量异步模块资源,页面请求数增多;

……

为求快速占领市场,业务开发时间往往紧迫,使用框架级的HTML&CSS、绕过CSS Sprite使用背景图片、引入第三方工具库或者UI,会经常发生。当遇到性能瓶颈时,如果不从根源解决问题,用传统的优化手段做页面级别的优化,会出现很快页面又被玩坏的情况,几次优化结束后我也在思考一个问题:

前端每次性能优化的手段皆大同小异;代码的可维护性也基本是在细分职责; 既然每次优化的目的是相同的,每次实现的过程是相似的,而每次重新开发项目又基本是要重蹈覆辙的,那么工程化、自动化可能是这一切问题的最终答案

1
2
前端每次性能优化的手段皆大同小异;代码的可维护性也基本是在细分职责;
既然每次优化的目的是相同的,每次实现的过程是相似的,而每次重新开发项目又基本是要重蹈覆辙的,那么工程化、自动化可能是这一切问题的最终答案

工程问题在项目积累到一定量后可能会发生,一般来说会有几个现象预示着工程问题出现了:

① 代码编写&调试困难

② 业务代码不好维护

③ 网站性能普遍不好

④ 性能问题重复出现,并且有不可修复之势

像上面所描述情况,就是一个典型的工程问题;定位问题、发现问题、解决问题是我们处理问题的手段;而如何防止同一类型的问题重复发生,便是工程化需要做的事情,简单说来,优化是解决问题,工程化是避免问题,今天我们就站在工程化的角度来解决一些前端优化问题,防止其死灰复燃。

文中是我个人的一些开发经验,希望对各位有用,也希望各位多多支持讨论,指出文中不足以及提出您的一些建议

ETag/If-None-Match

而ETag/If-None-Match则是上文大话中说的第二种check服务端文件是否更新的方式,也要配合Cache-Control使用。实际上ETag并不是文件的版本号,而是一串可以代表该文件唯一的字符串(Apache中,ETag的值,默认是对文件的索引节(INode),大小(Size)和最后修改时间(MTime)进行Hash后得到的。),当客户端发现和服务器约定的直接读取缓存的时间过了,就在请求中发送If-None-Match选项,值即为上次请求后响应头的ETag值,该值在服务端和服务端代表该文件唯一的字符串对比(如果服务端该文件改变了,该值就会变),如果相同,则相应HTTP304,客户端直接读取缓存,如果不相同,HTTP200,下载正确的数据,更新ETag值。

千赢国际官网 7

看如上截图,与服务器约定的直接读取本地缓存的时间过了,就会向服务器发送新的请求,请求头中带If-None-Match项,该字符串值会在服务端进行匹配,很显然,并没有什么变化(看响应头的ETag值),于是响应HTTP304,直接读取缓存。或许你会发送该请求也有If-Modified-Since项,如果两者同时存在,If-None-Match优先,忽略If-Modified-Since。或许你会问为什么它优先?两者功能相似甚至相同,为什么要同时存在?HTTP1.1中ETag的出现主要是为了解决几个Last-Modified比较难解决的问题:

  1.  Last-Modified标注的最后修改只能精确到秒级,如果某些文件在1秒钟以内,被修改多次的话,它将不能准确标注文件的修改时间
  2. 如果某些文件会被定期生成,但有时内容并没有任何变化(仅仅改变了时间),但Last-Modified却改变了,导致文件没法使用缓存
  3. 有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致等情形

消灭冗余

我们这里做的第一个事情便是消除优化路上第一个拦路虎:代码冗余(做代码精简),单从一个页面的加载来说,他需要以下资源:

① 框架MVC骨架模块&框架级别CSS

② UI组件(header组件、日历、弹出层、消息框……)

③ 业务HTML骨架

④ 业务CSS

⑤ 业务Javascript代码

⑥ 服务接口服务

因为产品&视觉会经常折腾全站样式加之UI的灵活性,UI最容易产生冗余的模块。

不能缓存的请求

当然并不是所有请求都能被缓存。

无法被浏览器缓存的请求:

  1. HTTP信息头中包含Cache-Control:no-cache,pragma:no-cache(HTTP1.0),或Cache-Control:max-age=0等告诉浏览器不用缓存的请求
  2. 需要根据Cookie,认证信息等决定输入内容的动态请求是不能被缓存的
  3. 经过HTTPS安全加密的请求(有人也经过测试发现,ie其实在头部加入Cache-Control:max-age信息,firefox在头部加入Cache-Control:Public之后,能够对HTTPS的资源进行缓存,参考《HTTPS的七个误解》)
  4. POST请求无法被缓存
  5. HTTP响应头中不包含Last-Modified/Etag,也不包含Cache-Control/Expires的请求无法被缓存

UI组件

UI组件本身包括完整的HTML&CSS&Javascript,一个复杂的组件下载量可以达到10K以上,就UI部分来说容易导致两个工程化问题:

① 升级产生代码冗余

② 对外接口变化导致业务升级需要额外开发

用户行为与缓存

浏览器缓存过程还和用户行为有关,譬如上面提到的,打开我的主页simplify the life,有个jquery的请求,如果直接在地址栏按回车,响应HTTP200(from cache),因为有效期还没过直接读取的缓存;如果ctrl r进行刷新,则会相应HTTP304(Not Modified),虽然还是读取的本地缓存,但是多了一次服务端的请求;而如果是ctrl shift r强刷,则会直接从服务器下载新的文件,响应HTTP200。

千赢国际官网 8

通过上表我们可以看到,当用户在按F5进行刷新的时候,会忽略Expires/Cache-Control的设置,会再次发送请求去服务器请求,而Last-Modified/Etag还是有效的,服务器会根据情况判断返回304还是200;而当用户使用Ctrl F5进行强制刷新的时候,只是所有的缓存机制都将失效,重新从服务器拉去资源。

更多可以参考浏览器缓存机制

UI升级

最理想的升级是保持对外的接口不变甚至保持DOM结构不变,但多数情况的UI升级其实是UI重做,最坏的情况是不做老接口兼容,这个时候业务同事便需要修改代码。为了防止业务抱怨,UI制作者往往会保留两个组件(UI UI1),如果原来那个UI是核心依赖组件(比如是UIHeader组件),便会直接打包至核心框架包中,这时便出现了新老组件共存的局面,这种情况是必须避免的,UI升级需要遵守两个原则:

① 核心依赖组件必须保持单一,相同功能的核心组件只能有一个

② 组件升级必须做接口兼容,新的特性可以做加法,绝不允许对接口做减法

总结

盗图浏览器缓存机制,两张图很清晰

千赢国际官网 9

 

 

千赢国际官网 10

UI组成

项目之初,分层较好的团队会有一个公共的CSS文件(main.css),一个业务CSS文件,main.css包含公共的CSS,并且会包含所有的UI的样式:

千赢国际官网 11

半年后业务频道增,UI组件需求一多便容易膨胀,弊端马上便暴露出来了,最初main.css可能只有10K,但是不出半年就会膨胀至100K,而每个业务频道一开始便需要加载这100K的样式文件页面,但是其中多数的UI样式是首屏加载用不到的。

所以比较好的做法是,main.css只包含最核心的样式,理想情况是什么业务样式功能皆不要提供,各个UI组件的样式打包至UI中按需加载:

千赢国际官网 12

如此UI拆分后,main.css总是处于最基础的样式部分,而UI使用时按需加载,就算出现两个相同组件也不会导致多下载资源。

本文由千赢国际官网发布于千赢网页手机版登入,转载请注明出处:千赢国际官网拖拽上传前传,前端优化带来的思

关键词: 千赢国际官网