低信噪比的HTML5优化

　　百度搜索引擎建议是我们的HTML文件最好不要超过128KB，其实现在对于那些大文件搜索引擎也是很容易就抓取到的，只不过我们是尽量在可能的情况下把我们的网页代码越精简越好，我们要知道搜索引擎抓取网页的时候可能不去索引整个的文件，索引的仅是前面一部分的信息，如果网页代码冗余过大，那么就容易把我们网页文章部分推后了，对于搜索引擎抓取网页是不利的，因此我们要对网页代码精简化。

1.如何加快HTML页面加载速度？

• 页面精简：去掉html页面不必要的空格、注释，尽量将script和css写在外部文件中。
• 可以借用第三方工具对页面进行加速。
• 减少文件数量减少页面上引用的文件数量可以减少HTTP连接数(src="")
• 许多JavaScript、CSS文件可以合并最好合并了
• 减少外部域名文件的引用
• 优化页面元素加载顺序.例如：首先加载页面最初显示的内容和与之相关的JavaScript和CSS，不需要的图片文件放到后面加载，或者引用延迟加载的js
• 减少页面中inline(嵌套)和JavaScript的数量
• 不要在table标签中嵌套table标签，不过现在基本上都用div+css了，HTML5也出来了
• 检查页面是否有js错误，或者空引用（检查页面有没有502错误），有没有js文件的重复加载

2.为何要保持标签整洁?

　　客户端的优化近来倍受关注，可是有些较基本的方面却被忽视。如果你仔细观察某些页面（即便是那些本来应该深度优化的页面），很容易就能在他们的标签中找到一大堆冗余的、不高效的结构。所有这些累赘给本来应该尽可能保持轻量级的页面增加了不必要的负担。来看看有哪些最容易犯的错误:在script标签内放html注释。

3.JS滑动事件实现

　　在PC的页面上很好实现，绑定click和mouseover等事件来完成。但是在移动设备上，要实现这种轮播的效果，就需要用到核心的touch事件。处理touch事件能跟踪到屏幕滑动的每根手指。

定义touchstart的事件处理函数，并绑定事件：

if (!!self.touch) self.slider.addEventListener('touchstart',self.events,false); 

//定义touchstart的事件处理函数
start: function(event) {
    event.preventDefault();  // 阻止触摸事件的默认动作,即阻止滚屏
    var touch = event.touches[];  // touches数组对象获得屏幕上所有的touch，取第一个touch
    // 取第一个touch的坐标值
    startPos = {
        x: touch.pageX,
        y: touch.pageY,
        time: +new Date
    };
    // 绑定事件
    this.slider.addEventListener('touchmove',this,false);
    this.slider.addEventListener('touchend',this,false);
},
触发touchstart事件后，会产生一个event对象；
event对象里包括触摸列表；
获得屏幕上的第一个touch，并记下其pageX和pageY的坐标；
此时绑定touchmove和touchend事件；

4.javascript中for...in语句来遍历对象中的属性

　　for...in 语句用于遍历对象的属性（对对象的属性进行循环操作）。

JavaScript for...in 语句
for...in 语句用于对数组或者对象的属性进行循环操作。
for ... in 循环中的代码每执行一次，就会对数组的元素或者对象的属性进行一次操作。
语法：
for (变量 in 对象)
{
    在此执行代码
}
“变量”用来指定变量，指定的变量可以是数组元素，也可以是对象的属性。

5.了解javascript解析引擎在执行代码前后是怎么工作的 http://www.nowamagic.net/librarys/veda

　　简单地说，JavaScript解析引擎就是能够“读懂”JavaScript代码，并准确地给出代码运行结果的一段程序。比方说，当你写了 var a = 1 + 1; 这样一段代码，JavaScript引擎做的事情就是看懂（解析）你这段代码，并且将a的值变为2。学过编译原理的人都知道，对于静态语言来说（如Java、C++、C），处理上述这些事情的叫编译器（Compiler），相应地对于JavaScript这样的动态语言则叫解释器（Interpreter）。这两者的区别用一句话来概括就是：编译器是将源代码编译为另外一种代码（比如机器码，或者字节码），而解释器是直接解析并将代码运行结果输出。 比方说，firebug的console就是一个JavaScript的解释器。但是，现在很难去界定说，JavaScript引擎它到底算是个解释器还是个编译器，因为，比如像Chrome的JS引擎，它其实为了提高JS的运行性能，在运行之前会先将JS编译为本地的机器码（native machine code），然后再去执行机器码（这样速度就快很多），相信大家对JIT（Just In Time Compilation）一定不陌生吧。我个人认为，不需要过分去强调JavaScript解析引擎到底是什么，了解它究竟做了什么事情我个人认为就可以了。

　　JavaScript引擎是一段程序，我们写的JavaScript代码也是程序，如何让程序去读懂程序呢？这就需要定义规则。比如，之前提到的var a = 1 + 1;，它表示：左边var代表了这是申明（declaration），它申明了a这个变量。右边的+表示要将1和1做加法。中间的等号表示了这是个赋值语句。最后的分号表示这句语句结束了。上述这些就是规则，有了它就等于有了衡量的标准，JavaScript引擎就可以根据这个标准去解析JavaScript代码了。那么这里的ECMAScript就是定义了这些规则。其中ECMAScript 262这份文档，就是对JavaScript这门语言定义了一整套完整的标准。其中包括：怎么样算是数字、怎么样算是字符串等等。标准的JavaScript引擎就会根据这套文档去实现，注意这里强调了标准，因为也有不按照标准来实现的，比如IE的JS引擎。这也是为什么JavaScript会有兼容性的问题。至于为什么IE的JS引擎不按照标准来实现，就要说到浏览器大战了。简单的说，ECMAScript定义了语言的标准，JavaScript引擎根据它来实现，这就是两者的关系。那么，JavaScript解析引擎与浏览器又是什么关系？简单地说，JavaScript引擎是浏览器的组成部分之一。因为浏览器还要做很多别的事情，比如解析页面、渲染页面、Cookie管理、历史记录等等。那么，既然是组成部分，因此一般情况下JavaScript引擎都是浏览器开发商自行开发的。比如：IE9的Chakra、Firefox的TraceMonkey、Chrome的V8等等。从而也看出，不同浏览器都采用了不同的JavaScript引擎。因此，我们只能说要深入了解哪个JavaScript引擎。

6.高性能的HTML

　　避免使用Iframe,在测试中所有的DOM元素都是空的，如加载大的脚本或样式块可能比加载某些iframe元素耗时更长，但从基准测试结果来看，即使是空的iframe，其开销也是非常昂贵的，鉴于iframe的高开销，我们应尽量避免使用。尤其是对于移动设备，对于目前大部分还是只有有限的CPU与内存的情况下，更应避免使用iframe。

　　避免空链接属性：空的链接属性是指img、link、script、ifrrame元素的src或href属性被设置了，但是属性却为空。如<img src=””>，我们创建了一个图片，并且暂时设置图片的地址为空，希望在未来动态的去修改它。但是即使图片的地址为空，浏览器依旧会以默认的规则去请求空地址。

　　避免节点深层次嵌套：深层级嵌套的节点在初始化构建时往往需要更多的内存占用，并且在遍历节点时也会更慢些，这与浏览器构建DOM文档的机制有关。通过浏览器HTML解析器的解析，浏览器会把整个HTML文档的结构存储为DOM树结构。当文档节点的嵌套层次越深，构建的DOM树层次也会越深。

　　缩减HTML文档，提高下载速度最显而易见的方式就是减少文件的大小，特别是压缩内嵌在HTML文档中的JavaScript和CSS代码，这能使得页面体积大幅精简。除此之外减少HTML文档大小还可以采取下面几种方法：删掉HTM文档对执行结果无影响的空格空行和注释；避免Table布局；使用HTML5。

　　避免脚本阻塞加载：当浏览器在解析常规的script标签时，它需要等待script下载完毕，再解析执行，而后续的HTML代码只能等待。为了避免阻塞加载，应把脚步放到文档的末尾，如把script标签插入在body结束标签之前：

<script src="example.js" ></script>
 </body>

　　显式设置图片的宽高，当浏览器加载页面的HTML代码时，有时候需要在图片下载完成前就对页面布局进行定位。如果HTML里的图片没有指定尺寸（宽和高），或者代码描述的尺寸与实际图片的尺寸不符时，浏览器则要在图片下载完成后再“回溯”该图片并重新显示，这会消耗额外时间。所以，最好为页面里的每一张图片都指定尺寸，不管是在页面HTML里的<img>标签，还是在CSS里。

<img src="hello.png" width="" height="">

7. 安全登录怎么生成Token？

　　在做客户端和服务端的交互，如果客户端每次请求都要带用户名和密码很不现实，所以应该存在一种机制，服务端生成token，返回给客户端，客户端凭借这个token请求相应的接口。 知道有个Oauth授权框架，但是我只涉及到自己的客户端和服务端，并没有第三方，不知道token怎么取得。先访问验证接口。接口输出一个根据用户信息生成的token（内容格式随意）和uid。然后后边的每次提交提交token和uid，服务端验证即可。token生成可以根据useragent等客户端信息来生成。

8. 一个好的用户登录功能：关系到用户安全

　　如何管理自己的口令让你知道怎么管理自己的口令，破解你的口令让你知道在现代这样速度的计算速度下，用穷举法破解你的口令可能会是一件很轻松的事。在这里我想告诉从开发者的角度上来做设计这个用户名和口令的事。下面一几件规则：限制用户输入一些非常容易被破解的口令。如什么qwert，123456, password之类，就像twitter限制用户的口令一样做一个口令的黑名单。另外，你可以限制用户口令的长度，是否有大小写，是否有数字，你可以用你的程序做一下校验。当然，这可能会让用户感到很不爽，所以，现在很多网站都提供了UX让用户知道他的口令强度是什么样的（比如这个有趣的UX），这样可以让用户有一个选择，目的就是告诉用户：要想安全，先把口令设得好一点。

　　千万不要明文保存用户的口令。正如如何管理自己的口令所说的一样，很多时候，用户都会用相同的ID相同的口令来登录很多网站。所以，如果你的网站明文保存的话，那么，如果你的数据被你的不良员工流传出去那对用户是灾难性的。所以，用户的口令一定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之类的有hash算法的不可逆的加密算法。CSDN曾明文保存过用户的口令。（另，对于国内公司的品行以及有关部门的管理方式，我不敢保证国内网站以加密的方式保存你的口令。我觉得，做为一个有良知的人，我们应该加密保存用户的口令）。

　　是否让浏览器保存口令。我们有N多的方法可以不让浏览器保存用户名和口令。但是这可能对用户来说很不爽。因为在真实世界里谁也记得不住那么多的口令。很多用户可能会使用一些密码管理工具来保存密码，浏览器只是其中一种。是否让浏览器保存这个需要你做决定，重点是看一下你的系统的安全级别是否要求比较高，如果是的话，则不要让浏览器保存密码，并在网站明显的位置告诉用户：保存口令最安全的地方只有你的大脑。

　　口令在网上的传输。因为HTTP是明文协议，所以，用户名和口令在网上也是明文发送的，这个很不安全。你可以看看这篇文章你就明白了。要做到加密传输就必需使用HTTPS协议。但是，在中国还是有很多网站的Web登录方式还在使用ActiveX控件，这可能成为IE6还大量存在的原因。我通常理解为这些ActiveX控件是为了反键盘记录程序的。 不过，我依然觉ActiveX控件不应该存在，因为在国外的众多安全很重要的站点上都看不到ActiveX的控件的身影。

　　首先，我想告诉大家的是，因为HTTP是无状态的协议，也就是说，这个协议是无法记录用户访问状态的，其每次请求都是独立的无关联的，一笔是一笔。而我们的网站都是设计成多个页面的，所在页面跳转过程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数据。所以，我们每个页面都需要对用户的身份进行认证。当然，我们不可能让用户在每个页面上输入用户名和口令，这会让用户觉得我们的网站相当的SB。为了实现这一功能，用得最多的技术就是浏览器的cookie，我们会把用户登录的信息存放在客户端的cookie里，这样，我们每个页面都从这个cookie里获得用户是否登录的信息，从而达到记录状态，验证用户的目的。但是，你真的会用cookie吗？下面是使用cookie的一些原则。千万不要在cookie中存放用户的密码。加密的密码都不行。因为这个密码可以被人获取并尝试离线穷举。所以，你一定不能把用户的密码保存在cookie中。我看到太多的站点这么干了。正确设计“记住密码”。这个功能简直就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。一般的设计是：一时用户勾选了这个功能，系统会生成一个cookie，cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，你就可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。这个并不是很安全。下面是一些更为安全的方法供你参考：在cookie中，保存三个东西——用户名，登录序列，登录token。上述三个东西会存

用户名：明文存放。
登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。
登录token：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。(每次的一个session会话，维持一个token)

在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。这样的设计会有什么样的效果，会有下面的效果：登录token是单实例登录。意思就是一个用户只能有一个登录实例；登录序列是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token”，而真正的用户回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录token”不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列和登录token，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录。一个设备会让另一个设备的登录token和登录序列失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑： IP 地址，如果以口令方式登录，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为口令只有真正的用户知道。如果 IP相同 ，那么，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为是同一用户有同一IP（当然，同一个局域网里也有同一IP，但我们认为这个局域网是用户可以控制的。网吧内并不推荐使用这一功能）。如果 （IP不同 && 没有用口令登录），那么，“登录token” 就会在多个IP间发生变化（登录token在两个或多个ip间被来来回回的变换），当在一定时间内达到一定次数后，系统才会真正觉得被盗用的可能性很高，此时系统在后台清除“登录序列”和“登录token“，让Cookie失效，强制用户输入口令（或是要求用户更改口令），以保证多台设备上的cookie一致。

　　不要让cookie有权限访问所有的操作。否则就是XSS攻击，这个功能请参看新浪微博的XSS攻击。下面的这些功能一定要用户输入口令：修改口令。修改电子邮件。（电子邮件通常用来找回用户密码，最好通发邮件或是发手机短信的方式修改，或者干脆就不让改：用电子邮件做帐号名）。用户的隐私信息。用户消费功能。权衡Cookie的过期时间。如果是永不过期，会有很不错的用户体验，但是这也会让用户很快就忘了登录密码。如果设置上过期期限，比如2周，一个月，那么可能会好一点，但是2周和一个月后，用户依然会忘了密码。尤其是用户在一些公共电脑上，如果保存了永久cookie的话，等于泄露了帐号。所以，对于cookie的过期时间我们还需要权衡。

　　　详情参考：http://coolshell.cn/articles/5353.html