本文主要通过以下几方面来说明懒加载技术的原理，个人前端小菜，有错误请多多指出 一、什么是图片滚动加载？ 通俗的讲就是：当访问一个页面的时候，先把img元素或是其他元素的背景图片路径替换成一张大小为1*1px图片的路径（这样就只需请求一次），只有当图片出现在浏览器的可视区域内时，才设置图片正真的路径，让图片显示出来。这就是图片懒加载。 二、为什要使用这个技术？ 比如一个页面中有很多图片，如淘宝、京东首页等等，如果一上来就发送这么多请求，页面加载就会很漫长，如果js文件都放在了文档的底部，恰巧页面的头部又依赖这个js文件，那就不好办了。更为要命的是：一上来就发送百八十个请求，服务器可能就吃不消了（又不是只有一两个人在访问这个页面）。 因此优点就很明显了：不仅可以减轻服务器的压力，而且可以让加载好的页面更快地呈现在用户面前（用户体验好）。 三、怎么实现？ 关键点如下： 1、页面中的img元素，如果没有src属性，浏览器就不会发出请求去下载图片（也就没有请求咯，也就提高性能咯），一旦通过javascript设置了图片路径，浏览器才会送请求。有点按需分配的意思，你不想看，就不给你看，你想看了就给你看~ 2、如何获取正真的路径，这个简单，现在正真的路径存在元素的“data-url”（这个名字起个自己认识好记的就行）属性里，要用的时候就取出来，再设置； 3、开始比较之前，先了解一些基本的知识，比如说如何获取某个元素的尺寸大小、滚动条滚动距离及偏移位置距离； 1）屏幕可视窗口大小：对应于图中1、2位置处 原生方法：window.innerHeight 标准浏览器及IE9+ || document.documentElement.clientHeight 标准浏览器及低版本IE标准模式 || document.body.clientHeight 低版本混杂模式 jQuery方法： $(window).height() 2）浏览器窗口顶部与文档顶部之间的距离，也就是滚动条滚动的距离：也就是图中3、4处对应的位置； 原生方法：window.pagYoffset——IE9+及标准浏览器 || document.documentElement.scrollTop 兼容ie低版本的标准模式 || document.body.scrollTop 兼容混杂模式； jQuery方法：$(document).scrollTop(); 3）获取元素的尺寸：对应于图中5、6位置处；左边jquery方法，右边原生方法 $(o).width() = o.style.width; $(o).innerWidth() = o.style.width+o.style.padding; $(o).outerWidth() = o.offsetWidth = o.style.width+o.style.padding+o.style.border; $(o).outerWidth(true) = o.style.width+o.style.padding+o.style.border+o.style.margin; 注意：要使用原生的style.xxx方法获取属性，这个元素必须已经有内嵌的样式，如<div style="…."></div>； 如果原先是通过外部或内部样式表定义css样式，必须使用o.currentStyle[xxx] || document.defaultView.getComputedStyle(0)[xxx]来获取样式值 4）获取元素的位置信息：对应与图中7、8位置处 1）返回元素相对于文档document顶部、左边的距离； jQuery：$(o).offset().top元素距离文档顶的距离，$(o).offset().left元素距离文档左边缘的距离 原生：getoffsetTop()，高程上有具体说明，这边就忽略了； 顺便提一下返回元素相对于第一个以定位的父元素的偏移距离，注意与上面偏移距的区别； jQuery：position()返回一个对象，$(o).position().left = style.left，$(o).position().top = style.top； 4、知道如何获取元素尺寸、偏移距离后，接下来一个问题就是：如何判断某个元素进入或者即将进入可视窗口区域？下面也通过一张图来说明问题。 1）外面最大的框为实际页面的大小，中间浅蓝色的框代表父元素的大小，对象1~8代表元素位于页面上的实际位置；以水平方向来做如下说明！ 2）对象8左边界相对于页面左边界的偏移距离（offsetLeft）大于父元素右边界相对于页面左边界的距离，此时可判读元素位于父元素之外； 3）对象7左边界跨过了父元素右边界，此时：对象7左边界相对于页面左边界的偏移距离（offsetLeft）小于 父元素右边界相对于 页面左边界的距离，因此对象7就进入了父元素可视区； 4）在对象6的位置处，对象5的右边界与页面左边界的距离 大于 父元素左边界与页面左边界的距离； 5）在对象5位置处时，对象5的右边界与页面左边界的距离 小于 父元素左边界与页面左边界的距离；此时，可判断元素处于父元素可视区外； 6）因此水平方向必须买足两个条件，才能说明元素位于父元素的可视区内；同理垂直方向也必须满足两个条件；具体见下文的源码； 四、扩展为jquery插件 使用方法：$("selector").scrollLoad({ 参数在代码中有说明 })
|
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 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 |
(function($) { $.fn.scrollLoading = function(options) { var defaults = { // 在html标签中存放的属性名称； attr: "data-url", // 父元素默认为window container: window, callback: $.noop }; // 不管有没有传入参数，先合并再说； var params = $.extend({}, defaults, options || {}); // 把父元素转为jquery对象； var container = $(params.container); // 新建一个数组，然后调用each方法，用于存储每个dom对象相关的数据； params.cache = []; $(this).each(function() { // 取出jquery对象中每个dom对象的节点类型，取出每个dom对象上设置的图片路径 var node = this.nodeName.toLowerCase(), url = $(this).attr(params["attr"]); //重组，把每个dom对象上的属性存为一个对象； var data = { obj: $(this), tag: node, url: url }; // 把这个对象加到一个数组中； params.cache.push(data); }); var callback = function(call) { if ($.isFunction(params.callback)) { params.callback.call(call); } }; //每次触发滚动事件时，对每个dom元素与container元素进行位置判断，如果满足条件，就把路径赋予这个dom元素！ var loading = function() { // 获取父元素的高度 var contHeight = container.outerHeight(); var contWidth = container.outerWidth(); // 获取父元素相对于文档页顶部的距离，这边要注意了，分为以下两种情况； if (container.get(0) === window) { // 第一种情况父元素为window，获取浏览器滚动条已滚动的距离；$(window)没有offset()方法； var contop = $(window).scrollTop(); var conleft = $(window).scrollLeft(); } else { // 第二种情况父元素为非window元素，获取它的滚动条滚动的距离； var contop = container.offset().top; var conleft = container.offset().left; } $.each(params.cache, function(i, data) { var o = data.obj, tag = data.tag, url = data.url, post, posb, posl, posr; if (o) { //对象顶部与文档顶部之间的距离，如果它小于父元素底部与文档顶部的距离，则说明垂直方向上已经进入可视区域了； post = o.offset().top - (contop + contHeight); //对象底部与文档顶部之间的距离，如果它大于父元素顶部与文档顶部的距离，则说明垂直方向上已经进入可视区域了； posb = o.offset().top + o.height() - contop; // 水平方向上同理； posl = o.offset().left - (conleft + contWidth); posr = o.offset().left + o.width() - conleft; // 只有当这个对象是可视的，并且这四个条件都满足时，才能给这个对象赋予图片路径； if ( o.is(':visible') && (post < 0 && posb > 0) && (posl < 0 && posr > 0) ) { if (url) { //在浏览器窗口内 if (tag === "img") { //设置图片src callback(o.attr("src", url)); } else { // 设置除img之外元素的背景url callback(o.css("background-image", "url("+ url +")")); } } else { // 无地址，直接触发回调 callback(o); } // 给对象设置完图片路径之后，把params.cache中的对象给清除掉；对象再进入可视区，就不再进行重复设置了； data.obj = null; } } }); }; //加载完毕即执行 loading(); //滚动执行 container.bind("scroll", loading); }; })(jQuery); |
五、参考： 1、jQuery.lazyload详解 2、张大大：http://www.zhangxinxu.com/wordpress/?p=1259 3、Jquery图片延迟加载插件jquery.lazyload. http://www.daxueit.com/article/3944.html 4、jQuery.lazyload实现延时加载详解步骤 http://www.daxueit.com/article/21.html 5、jquery lazyload延迟加载技术的实现原理分析 http://www.daxueit.com/article/3777.html 6、Lazyload 延迟加载效果 7、图片延迟加载（lazyload）的实现原理
View Details两端对齐，从概念上来说，其实不难理解。如果不明白什么叫两端对齐，可以玩玩word等办公软件。 下面谈谈如何实现文本的两端对齐。我所知道的大概有以下几种方法 text-align w3school指出，text-align用于设置块级元素内文本的水平对齐方式。如果想使inline元素或inline-block元素居中对齐，可以使用text-align: center方法，对于block元素无法使用text-align实现居中对齐。如果想让block元素居中对齐，可以使用margin: auto方法。 text-align属性下有一个justify值可以设置元素的两端对齐。但是text-align: justify属性有一些不足之处： 在单行文本下，无法实现两端对齐效果。 在多行文本下，无法实现最后一行文本的两端对齐效果。 单行文本
|
1 2 3 4 5 |
<div <span class="hljs-class"><span class="hljs-keyword">class</span></span>=<span class="hljs-string">"keith"</span>>unclekeith wanna be a geek!<span class="xml"><span class="hljs-tag"></<span class="hljs-name">div</span>></span></span> .keith { background-color: lightblue; text-align: justify; } |
对于多行文本而言，如下图，按照我们的理解应该如右图显示，可是在设置text-align: justify之后，会按照左图显示。无法是西安最后一行文本的两端对齐效果。 解决方法 如果要真正的实现两端对齐效果，可以用以下方法解决。
|
1 2 3 4 5 6 7 8 9 |
解决方法的思路：由于在单行文本下和多行文本下最后一样无法实现两端对齐效果，因此给元素新增一行，即可实现<span class="hljs-selector-tag">justify</span>的两个不足之处。 <span class="hljs-selector-class">.keith</span> { <span class="hljs-attribute">text-align</span>: justify; } <span class="hljs-selector-class">.keith</span><span class="hljs-selector-pseudo">:after</span> { <span class="hljs-attribute">display</span>: inline-block; <span class="hljs-attribute">width</span>: <span class="hljs-number">100%</span>; <span class="hljs-attribute">content</span>: <span class="hljs-string">''</span>; } |
如果感觉最后多了空行，可以为元素设置一个高度，并且设置overflow: hidden隐藏掉即可。 justify-content CSS3新增的flex布局下，有一个justify-content属性，此属性可以控制伸缩项目的水平对齐方式。其中有两个值，可以实现两端对齐。但是justify-content存在兼容性问题，IE10以上，FF，Chrome都支持。而所有浏览器都支持text-align属性
|
1 2 |
<span class="hljs-attribute">justify-content</span>: space-around。 伸缩项目会平均地分布在伸缩容器内，两端保留一半的空间。 <span class="hljs-attribute">justify-content</span>: space-between。伸缩项目会平均地分布在伸缩容器内，第一个伸缩项目在伸缩容器的左边缘，最后一个伸缩项目在伸缩容器的右边缘。 |
justify-content: space-around; justify-content: space-between text-justify 还有一个text-justify属性，这个属性估计很少人会使用到，因为只有IE浏览器和FF55以上的浏览器才支持。因为兼容性实在不好，就不说了.. from:https://www.cnblogs.com/unclekeith/p/7073536.html
View Details本文分为三个部分 JS 数字精度丢失的一些典型问题 JS 数字精度丢失的原因 解决方案（一个对象+一个函数） 一、JS数字精度丢失的一些典型问题 1. 两个简单的浮点数相加 1 0.1 + 0.2 != 0.3 // true Firebug 这真不是 Firebug 的问题，可以用alert试试 （哈哈开玩笑）。 看看Java的运算结果 再看看Python 2. 大整数运算 1 9999999999999999 == 10000000000000001 // ？ Firebug 16位和17位数竟然相等，没天理啊。 又如 1 2 var x = 9007199254740992 x + 1 == x // ？ 看结果 三观又被颠覆了。 3. toFixed 不会四舍五入（Chrome） 1 1.335.toFixed(2) // 1.33 Firebug 线上曾经发生过 Chrome 中价格和其它浏览器不一致，正是因为 toFixed 兼容性问题导致 二、JS 数字丢失精度的原因 计算机的二进制实现和位数限制有些数无法有限表示。就像一些无理数不能有限表示，如 圆周率 3.1415926…，1.3333… 等。JS 遵循 IEEE 754 规范，采用双精度存储（double precision），占用 64 bit。如图 意义 1位用来表示符号位 11位用来表示指数 52位表示尾数 浮点数，比如 1 2 0.1 […]
View Details背景： 这个问题不是一天两天了，有时候是网速不行，有时候是被墙了，有时候是github把node-sass的包转移目录导致下载失败。 Cannot download "https://github.com/sass/node-sass/releases/download/xxx/binding.node的问题 另附node-sass的binding.node各个版本的安装包，哪里少，就单独下载哪个，下载完了之后，跟着我，一起把文件放在指定位置即可解决这个问题 https://github.com/sass/node-sass/releases/tag/v4.7.2 1.本机位置 C:\Users\Administrator\AppData\Roaming\npm-cache\node-sass\ 这个里面是各种版本，报错提示你哪个版本下载失败，你就塞到哪个版本的文件夹里，如图所示 2.删除项目的node_moduls目录 3.重新npm install 4.另附全局安装命令
|
1 2 3 |
npm i sass-loader node-sass webpack <span class="hljs-comment">--g</span> npm i style-loader css-loader <span class="hljs-comment">--g</span> |
qq 43163707 落雨 本文地址:http://www.cnblogs.com/ae6623/p/8711853.html
View Details|
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 |
var gulp = require('gulp'); var connect = require('gulp-connect'); var replace = require('gulp-replace'); function defaultTask(cb) { // place code for your default task here cb(); replaceTask(); connect.server({ root: "build", port:8888 }); connect.serverClose(); } function replaceTask(){ /*index*/ gulp.src(['./index.html']) .pipe(replace("@@{user_domain_url}", "http://user.domain.com")) .pipe(replace('@@{nickname}', 'gz')) .pipe(gulp.dest('build/')); /*js*/ gulp.src(['js/*.js']) .pipe(replace("@@{user_domain_url}", "http://user.domain.com")) .pipe(replace('@@{nickname}', 'gz')) .pipe(gulp.dest('build/js')); } exports.default = defaultTask; |
View Details
流程 1. 输入命令(可以使用git bash或者命令控制台cmd) npm install -g gulp 安装全局gulp命令 2. 创建一个项目文件夹, 当前项目文件夹下输入命令npm init 配置package.json文件, 这一部分看情况自己决定是否填, 不想填也可以, 直接按回车 当前项目文件夹下输入命令npm install gulp --save-dev 全局安装gulp后，还需要在每个要使用gulp的项目中都单独安装一次 开始使用gulp 其实, gulp的使用比webpack要简单很多. 配置gulpflie.js文件 在当前项目文件下创建文件名为gulpfile.js文件, 作为该项目配置文件.
|
1 2 3 4 5 6 |
//gulpfile.js var gulp = require('gulp'); gulp.task('default',function(){ console.log('hello world'); }); |
其实在项目文件夹下输入命令gulp时, 就是触发这个default任务, 因此, 我们定义多个自定义事件, 这样在输入gulp时, 就可以直接将我们写的命令也一起触发. gulp API gulp.src(globs[, options]) globs参数是文件匹配模式(类似正则表达式)，用来匹配文件路径(包括文件名)，当然这里也可以直接指定某个具体的文件路径。当有多个匹配模式时，该参数可以为一个数组。 options为可选参数。通常情况下我们不需要用到。 下面我们重点说说Gulp用到的glob的匹配规则以及一些文件匹配技巧。 名称 说明 * 匹配文件路径中的0个或多个字符，但不会匹配路径分隔符，除非路径分隔符出现在末尾 ** 匹配路径中的0个或多个目录及其子目录,需要单独出现，即它左右不能有其他东西了。如果出现在末尾，也能匹配文件。 ? 匹配文件路径中的一个字符(不会匹配路径分隔符) […] 匹配方括号中出现的字符中的任意一个，当方括号中第一个字符为^或!时，则表示不匹配方括号中出现的其他字符中的任意一个，类似js正则表达式中的用法 !(pattern|pattern|pattern) 匹配任何与括号中给定的任一模式都不匹配的 ?(pattern|pattern|pattern) 匹配括号中给定的任一模式0次或1次，类似于js正则中的(pattern|pattern|pattern)? +(pattern|pattern|pattern) 匹配括号中给定的任一模式至少1次，类似于js正则中的(pattern|pattern|pattern)+ *(pattern|pattern|pattern) 匹配括号中给定的任一模式0次或多次，类似于js正则中的(pattern|pattern|pattern)* @(pattern|pattern|pattern) 匹配括号中给定的任一模式1次，类似于js正则中的(pattern|pattern|pattern) 例子:
|
1 2 3 4 5 6 7 8 |
//转换html文件 gulp.task('html', function(){ gulp.src('./src/index.html') .pipe(connect.reload()) .pipe(gulp.dest('./dist'));//写入命令 }); 当有多种匹配模式时可以使用数组 |
|
1 2 3 4 |
//使用数组的方式来匹配多种文件 gulp.src(['js/*.js','css/*.css','*.html']) 使用数组的方式还有一个好处就是可以很方便的使用排除模式，在数组中的单个匹配模式前加上!即是排除模式，它会在匹配的结果中排除这个匹配，要注意一点的是不能在数组中的第一个元素中使用排除模式 |
|
1 2 |
gulp.src([*.js,'!b*.js']) //匹配所有js文件，但排除掉以b开头的js文件 gulp.src(['!b*.js',*.js]) //不会排除任何文件，因为排除模式不能出现在 |
数组的第一个元素中 此外，还可以使用展开模式。展开模式以花括号作为定界符，根据它里面的内容，会展开为多个模式，最后匹配的结果为所有展开的模式相加起来得到的结果。展开的例子如下： a{b,c}d 会展开为 abd,acd a{b,}c 会展开为 abc,ac a{0..3}d 会展开为 a0d,a1d,a2d,a3d a{b,c{d,e}f}g 会展开为 abg,acdfg,acefg a{b,c}d{e,f}g 会展开为 abdeg,acdeg,abdeg,abdfg gulp.dest(path[,options]) gulp.dest()方法是用来写文件的 path为写入文件的路径 options为一个可选的参数对象，通常我们不需要用到 要想使用好gulp.dest()这个方法，就要理解给它传入的路径参数与最终生成的文件的关系。 gulp的使用流程一般是这样子的：首先通过gulp.src()方法获取到我们想要处理的文件流，然后把文件流通过pipe方法导入到gulp的插件中，最后把经过插件处理后的流再通过pipe方法导入到gulp.dest()中，gulp.dest()方法则把流中的内容写入到文件中，这里首先需要弄清楚的一点是，我们给gulp.dest()传入的路径参数，只能用来指定要生成的文件的目录，而不能指定生成文件的文件名，它生成文件的文件名使用的是导入到它的文件流自身的文件名，所以生成的文件名是由导入到它的文件流决定的，即使我们给它传入一个带有文件名的路径参数，然后它也会把这个文件名当做是目录名，例如：
|
1 2 3 4 5 6 7 8 |
var gulp = require('gulp'); gulp.src('script/jquery.js') .pipe(gulp.dest('dist/foo.js')); //最终生成的文件路径为 dist/foo.js/jquery.js,而不是dist/foo.js 要想改变文件名，可以使用插件gulp-rename 下面说说生成的文件路径与我们给gulp.dest()方法传入的路径参数之间的关系。 gulp.dest(path)生成的文件路径是我们传入的path参数后面再加上gulp.src()中有通配符开始出现的那部分路径。例如： |
|
1 2 3 4 5 6 7 |
var gulp = reruire('gulp'); //有通配符开始出现的那部分路径为 **/*.js gulp.src('script/**/*.js') .pipe(gulp.dest('dist')); //最后生成的文件路径为 dist/**/*.js //如果 **/*.js 匹配到的文件为 jquery/jquery.js ,则生成的文件路径为 dist/jquery/jquery.js 再举更多一点的例子 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
gulp.src('script/avalon/avalon.js') //没有通配符出现的情况 .pipe(gulp.dest('dist')); //最后生成的文件路径为 dist/avalon.js //有通配符开始出现的那部分路径为 **/underscore.js gulp.src('script/**/underscore.js') //假设匹配到的文件为script/util/underscore.js .pipe(gulp.dest('dist')); //则最后生成的文件路径为 dist/util/underscore.js gulp.src('script/*') //有通配符出现的那部分路径为 * //假设匹配到的文件为script/zepto.js .pipe(gulp.dest('dist')); //则最后生成的文件路径为 dist/zepto.js 通过指定gulp.src()方法配置参数中的base属性，我们可以更灵活的来改变gulp.dest()生成的文件路径。 当我们没有在gulp.src()方法中配置base属性时，base的默认值为通配符开始出现之前那部分路径，例如： |
[…]
View Details为了防止客户端的静态资源缓存，我们需要每次更新css或js的时候，通过md5或时间戳等方式重新命名静态资源； 然后涉及到的html模板里的src也要做相应的修改，静态资源需要优化(压缩合并) 文件目录结构 html模板文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <html> <head> <!-- build:css styles/main.min.css --> <link rel="stylesheet" href="../styles/one.css"> <link rel="stylesheet" href="../styles/two.css"> <!-- endbuild --> </head> <body> <!-- build:js scripts/main.min.js --> <script type="text/javascript" src="../scripts/one.js"></script> <script type="text/javascript" src="../scripts/two.js"></script> <!-- endbuild --> </body> </html> gulp配置文件:gulpfile.js 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 […]
View DetailsStateOfJS 刚刚发布了 2018年的 JavaScript 现状调查报告，今年他们调查了超过 20000 名 JavaScript 开发者，以确定他们正在使用什么，他们对什么感到满意以及他们想要学习什么。 1、JavaScript 现状 —— “方言” 随着 JavaScript 的成熟，开发者基于 JavaScript 创建了许多其他语言，或者叫“方言”，如 ES6、TypeScript、Flow、Reason、Elm、ClojureScript 、CoffeeScript 等等。曾几何时，CoffeeScript 是该方向的唯一支持者，但如今它已被 ES6 、TypeScript、Flow 等取代。 StateOfJS 表示有充分的理由认为这是整个 JavaScript 的未来。因为随着像 Web Assembly 这样的项目的出现，直接使用 JavaScript 编写代码可能很快就会变得古怪。 2018年的两位大赢家是 ES6 和 TypeScript 。另外 Reason 也值得关注，它背后有 Facebook 的支持，并且拥有非常高的满意度和兴趣值。 2、JavaScript 现状 —— 前端框架 结果基本上和其他榜单类似，React 和 Vue 唱主角，Angular 有垮台的趋势。 StateOfJS 表示，两年前有 27％ 的受访者表示从未听说过 Vue ，但如今这一比例已降至 1.3％ ！虽然 React 仍然拥有更大的市场份额，但 Vue 的迅速崛起也没有停止的迹象。 Angular 本身拥有庞大的用户群，但也很难看到它重新登上前端框架的冠亚宝座。 3、JavaScript 现状 —— 数据层 毫无疑问，Redux 是使用最广泛的工具，82％ 的满意率也证明了它的成熟程度。不过 GraphQL 也并非没有冲击的可能，其用户在两年内从 5％ 上升到了 20％ 。 4、JavaScript 现状 —— 后端框架（服务端） JavaScript 在后端（服务端）领域近年来似乎没有取得任何重大突破，虽然每年都有无数的框架出现，但很少有能够获得很大的成功并挑战 Express 的地位的。 即便是拥有 Express 继任者称号的 Koa ，其满意度也相对较低，使用量也有大幅下滑。 该领域有一个有趣的参与者 —— Next.js，最近引起了很多人的兴趣。虽然它与功能齐全的 Node 后端不太可比，但它专注于解决 React 应用的服务器端渲染问题，使其成为一个非常实用的工具。 5、JavaScript 现状 —— 测试 […]
View Details这是一个非常有趣的 非主流前端领域，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题，入行到现在一直在学习和实践中。 在我的印象中，facebook是这个领域的鼻祖，有兴趣、有梯子的同学可以去看看facebook的页面源代码，体会一下什么叫工程化。 接下来，我想从原理展开讲述，多图，较长，希望能有耐心看完。 让我们返璞归真，从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css，用文本编辑器写代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。前端就是这么简单，好好玩啊，门槛好低啊，分分钟学会有木有！ 然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太™完美了！那么，研发完成。。。。了么？ 等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。 看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样： 利用304，让浏览器使用本地缓存。但，这样也就够了吗？不成！304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样： 强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？ 很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。好像这样： 下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！当然没有！大公司的变态又来了，思考这种情况： 页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！ 重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。 什么东西与文件内容相关呢？我们会很自然的联想到利用 数据摘要要算法 对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的： 这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！ 唉~~~~，让我喘口气 现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径： 好了，当我要更新静态资源的时候，同时也会更新html中的引用吧，就好像这样： 这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？ 1.先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。 2.先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。 好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。 但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！ 这个奇葩问题，起源于资源的覆盖式发布，用 待发布资源覆盖 已发布资源，就有这种问题。解决它也好办，就是实现非覆盖式发布。 看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。 所以，大公司的静态资源优化方案，基本上要实现这么几个东西： 1.配置超长时间的本地缓存 —— 节省带宽，提高性能 2.采用内容摘要作为缓存更新依据 —— 精确的缓存控制 3.静态资源CDN部署 —— 优化网络请求 4.更资源发布路径实现非覆盖式发布 —— 平滑升级 全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在 前端所有静态资源加载的位置都要做这样的处理 。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概示意图就是： 好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！ 要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。 总之，前端性能优化绝逼是一个工程问题！ 以上不是我YY的，可以观察 百度 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。 建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？ 另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！ 妈妈，我再也不玩前端了。。。。5555 业界实践 Assets Pipeline Rails中的Assets Pipeline完成了以上所说的优化细节，对整个静态资源的管理上的设计思考也是如此，了解rails的人也可以把此答案当做是对rails中assets pipeline设计原理的分析。 rails通过把静态资源变成erb模板文件，然后加入<%= asset_path 'image.png' %>，上线前预编译完成处理，fis的实现思路跟这个几乎完全一样，但我们当初确实不知道有rails的这套方案存在。 相关资料： 英文版：http://guides.rubyonrails.org/asset_pipeline.html 中文版：http://guides.ruby-china.org/asset_pipeline.html FIS的解决方案 用 F.I.S 包装了一个小工具，完整实现整个回答所说的最佳部署方案，并提供了源码对照，可以感受一下项目源码和部署代码的对照。 源码项目：https://github.com/fouber/static-resource-digest-project 部署项目：https://github.com/fouber/static-resource-digest-project-release 部署项目可以理解为线上发布后的结果，可以在部署项目里查看所有资源引用的md5化处理。 这个示例也可以用于和assets pipeline做比较。fis没有assets的目录规范约束，而且可以以独立工具的方式组合各种前端开发语言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），并与其他后端开发语言结合。 assets pipeline的设计思想值得独立成工具用于前端工程，fis就当做这样的一个选择吧。 from:https://www.cnblogs.com/minigrasshopper/p/7694053.html
View Details每个参与过开发企业级web应用的前端工程师或许都曾思考过前端性能优化方面的问题。我们有雅虎14条性能优化原则，还有两本很经典的性能优化指导书：《高性能网站建设指南》、《高性能网站建设进阶指南》。经验丰富的工程师对于前端性能优化方法耳濡目染，基本都能一一列举出来。这些性能优化原则大概是在7年前提出的，对于web性能优化至今都有非常重要的指导意义。 然而，对于构建大型web应用的团队来说，要坚持贯彻这些优化原则并不是一件十分容易的事。因为优化原则中很多要求是与工程管理相违背的，比如“把css放在头部”和“把js放在尾部”这两条原则，我们不能让团队的工程师在写样式和脚本引用的时候都去修改一个相同的页面文件。这样做会严重影响团队成员间并行开发的效率，尤其是在团队有版本管理的情况下，每天要花大量的时间进行代码修改合并，这项成本是难以接受的。因此在前端工程界，总会看到周期性的性能优化工作，辛勤的前端工程师们每到月圆之夜就会倾巢出动根据优化原则做一次性能优化。 本文从一个全新的视角来思考web性能优化与前端工程之间的关系，通过解读百度前端集成解决方案小组（F.I.S）在打造高性能前端架构并统一百度40多条前端产品线的过程中所经历的技术尝试，揭示前端性能优化在前端架构及开发工具设计层面的实现思路。 性能优化原则及分类 笔者先假设本文的读者是有前端开发经验的工程师，并对企业级web应用开发及性能优化有一定的思考，因此我不会重复介绍雅虎14条性能优化原则。如果您没有这些前续知识，请移步这里来学习。 首先，我们把雅虎14条优化原则，《高性能网站建设指南》以及《高性能网站建设进阶指南》中提到的优化点做一次梳理，按照优化方向分类，可以得到这样一张表格： 优化方向 优化手段 请求数量 合并脚本和样式表，CSS Sprites，拆分初始化负载，划分主域 请求带宽 开启GZip，精简JavaScript，移除重复脚本，图像优化 缓存利用 使用CDN，使用外部JavaScript和CSS，添加Expires头，减少DNS查找，配置ETag，使AjaX可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 代码校验 避免CSS表达式，避免重定向 表格1 性能优化原则分类 目前大多数前端团队可以利用yui compressor或者google closure compiler等压缩工具很容易做到“精简Javascript”这条原则；同样的，也可以使用图片压缩工具对图像进行压缩，实现“图像优化”原则。这两条原则是对单个资源的处理，因此不会引起任何工程方面的问题。很多团队也通过引入代码校验流程来确保实现“避免css表达式”和“避免重定向”原则。目前绝大多数互联网公司也已经开启了服务端的Gzip压缩，并使用CDN实现静态资源的缓存和快速访问；一些技术实力雄厚的前端团队甚至研发出了自动CSS Sprites工具，解决了CSS Sprites在工程维护方面的难题。使用“查找-替换”思路，我们似乎也可以很好的实现“划分主域”原则。 我们把以上这些已经成熟应用到实际生产中的优化手段去除掉，留下那些还没有很好实现的优化原则。再来回顾一下之前的性能优化分类： 优化方向 优化手段 请求数量 合并脚本和样式表，拆分初始化负载 请求带宽 移除重复脚本 缓存利用 添加Expires头，配置ETag，使Ajax可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 表格2 较难实现的优化原则 现在有很多顶尖的前端团队可以将上述还剩下的优化原则也都一一解决，但业界大多数团队都还没能很好的解决这些问题。因此，本文将就这些原则的解决方案做进一步的分析与讲解，从而为那些还没有进入前端工业化开发的团队提供一些基础技术建设意见，也借此机会与业界顶尖的前端团队在工业化工程化方向上交流一下彼此的心得。 静态资源版本更新与缓存 如表格2所示，“缓存利用”分类中保留了“添加Expires头”和“配置ETag”两项。或许有些人会质疑，明明这两项只要配置了服务器的相关选项就可以实现，为什么说它们难以解决呢？确实，开启这两项很容易，但开启了缓存后，我们的项目就开始面临另一个挑战：如何更新这些缓存。 相信大多数团队也找到了类似的答案，它和《高性能网站建设指南》关于“添加Expires头”所说的原则一样——修订文件名。即： 最有效的解决方案是修改其所有链接，这样，全新的请求将从原始服务器下载最新的内容。 思路没错，但要怎么改变链接呢？变成什么样的链接才能有效更新缓存，又能最大限度避免那些没有修改过的文件缓存不失效呢？ 先来看看现在一般前端团队的做法： 或者 大家会采用添加query的形式修改链接。这样做是比较直观的解决方案，但在访问量较大的网站，这么做可能将面临一些新的问题。 通常一个大型的web应用几乎每天都会有迭代和更新，发布新版本也就是发布新的静态资源和页面的过程。以上述代码为例，假设现在线上运行着index.html文件，并且使用了线上的a.js资源。index.html的内容为： 这次我们更新了页面中的一些内容，得到一个index.html文件，并开发了新的与之匹配的a.js资源来完成页面交互，新的index.html文件的内容因此而变成了： 好了，现在要开始将两份新的文件发布到线上去。可以看到，index.html和a.js的资源实际上是要覆盖线上的同名文件的。不管怎样，在发布的过程中，index.html和a.js总有一个先后的顺序，从而中间出现一段或大或小的时间间隔。对于一个大型互联网应用来说即使在一个很小的时间间隔内，都有可能出现新用户访问。在这个时间间隔中，访问了网站的用户会发生什么情况呢？ 如果先覆盖index.html，后覆盖a.js，用户在这个时间间隙访问，会得到新的index.html配合旧的a.js的情况，从而出现错误的页面。 如果先覆盖a.js，后覆盖index.html，用户在这个间隙访问，会得到旧的index.html配合新的a.js的情况，从而也出现了错误的页面。 这就是为什么大型web应用在版本上线的过程中经常会较集中的出现前端报错日志的原因，也是一些互联网公司选择加班到半夜等待访问低峰期再上线的原因之一。此外，由于静态资源文件版本更新是“覆盖式”的，而页面需要通过修改query来更新，对于使用CDN缓存的web产品来说，还可能面临CDN缓存攻击的问题。我们再来观察一下前面说的版本更新手段： 我们不难预测，a.js的下一个版本是“1.0.1”，那么就可以刻意构造一串这样的请求“a.js?v=1.0.1”、“a.js?v=1.0.2”、……让CDN将当前的资源缓存为“未来的版本”。这样当这个页面所用的资源有更新时，即使更改了链接地址，也会因为CDN的原因返回给用户旧版本的静态资源，从而造成页面错误。即便不是刻意制造的攻击，在上线间隙出现访问也可能导致区域性的CDN缓存错误。 此外，当版本有更新时，修改所有引用链接也是一件与工程管理相悖的事，至少我们需要一个可以“查找-替换”的工具来自动化的解决版本号修改的问题。 对付这个问题，目前来说最优方案就是基于文件内容的hash版本冗余机制了。也就是说，我们希望工程师源码是这么写的： 但是线上代码是这样的： 其中”_82244e91”这串字符是根据a.js的文件内容进行hash运算得到的，只有文件内容发生变化了才会有更改。由于版本序列是与文件名写在一起的，而不是同名文件覆盖，因此不会出现上述说的那些问题。同时，这么做还有其他的好处： 线上的a.js不是同名文件覆盖，而是文件名+hash的冗余，所以可以先上线静态资源，再上线html页面，不存在间隙问题； 遇到问题回滚版本的时候，无需回滚a.js，只须回滚页面即可； 由于静态资源版本号是文件内容的hash，因此所有静态资源可以开启永久强缓存，只有更新了内容的文件才会缓存失效，缓存利用率大增； 修改静态资源后会在线上产生新的文件，一个文件对应一个版本，因此不会受到构造CDN缓存形式的攻击 虽然这种方案是相比之下最完美的解决方案，但它无法通过手工的形式来维护，因为要依靠手工的形式来计算和替换hash值，并生成相应的文件。这将是一项非常繁琐且容易出错的工作，因此我们需要借助工具。我们下面来了解一下fis是如何完成这项工作的。 首先，之所以有这种工具需求，完全是由web应用运行的根本机制决定的：web应用所需的资源是以字面的形式通知浏览器下载而聚合在一起运行的。这种资源加载策略使得web应用从本质上区别于传统桌面应用的版本更新方式。为了实现资源定位的字面量替换操作，前端构建工具理论上需要识别所有资源定位的标记，其中包括： css中的@import url(path)、background:url(path)、backgournd-image:url(path)、filter中的src js中的自定义资源定位函数，在fis中我们将其规定为__uri(path)。 html中的<script src=”path”>、<link href=”path”>、<imgsrc=”path”>、已经embed、audio、video、object等具有资源加载功能的标签。 为了工程上的维护方便，我们希望工程师在源码中写的是相对路径，而工具可以将其替换为线上的绝对路径，从而避免相对路径定位错误的问题（比如js中需要定位图片路径时不能使用相对路径的情况）。 fis的资源定位设计思想 fis有一个非常棒的资源定位系统，它是根据用户自己的配置来指定资源发布后的地址，然后由fis的资源定位系统识别文件中的定位标记，计算内容hash，并根据配置替换为上线后的绝对url路径。 要想实现具备hash版本生成功能的构建工具不是“查找-替换”这么简单的。我们考虑这样一种情况： 资源引用关系 由于我们的资源版本号是通过对文件内容进行hash运算得到，如上图所示，index.html中引用的a.css文件的内容其实也包含了a.png的hash运算结果，因此我们在修改index.html中a.css的引用时，不能直接计算a.css的内容hash，而是要先计算出a.png的内容hash，替换a.css中的引用，得到了a.css的最终内容，再做hash运算，最后替换index.html中的引用。 这意味着构建工具需要具备“递归编译”的能力，这也是为什么fis团队不得不放弃gruntjs等task-based系统的根本原因。针对前端项目的构建工具必须是具备递归处理能力的。此外，由于文件之间的交叉引用等原因，fis构建工具还实现了构建缓存等机制，以提升构建速度。 在解决了基于内容hash的版本更新问题之后，我们可以将所有前端静态资源开启永久强缓存，每次版本发布都可以首先让静态资源全量上线，再进一步上线模板或者页面文件，再也不用担心各种缓存和时间间隙的问题了！ 在本系列的下一部分，我们将介绍静态资源管理与模板框架的思路和用法。 作者简介：张云龙，百度公司Web前端研发部前端集成解决方案小组技术负责人，目前负责F.I.S项目，读者可以关注他的微博：http://weibo.com/fouber/。 from:http://www.infoq.com/cn/articles/front-end-engineering-and-performance-optimization-part1
View Details