charset的作用：告诉浏览器，对于服务器端返回来的HTML文件流用何种编码进行解码，从而进行HTML的解析操作。 有三个地方可以设置charset，而且它们的优先级是有顺序的：1、response header；2、HTML文档中的meta；3、浏览器默认的charset声明。那么它们的优先级是如何的呢？ 首先要了解浏览器处理charset的策略：浏览器首先会在服务器返回的response header头中检查是否有charset声明，如果没有，就接着检查HTML head部分的meta标签，是否有声明charset，如果还没有，那么就使用浏览器默认的charset方式进行解码文档流。 在response header头中声明好了charset，那么浏览器在第一时间接收到HTML数据包的时候，就会以这个charset编码进行解码HTML文件流，这种情况下是最快的方式；如果response header头中没找到，那么浏览器会delay解析HTML文档，检查1KB以内的HTML内容是否会包含有charset声明的meta标签。如果还找不到，那么就使用浏览器默认的charset声明进行解码HTML页面，但是这时，已经delay了一些时间了。 如果处理的适当，那么这个delay时间是完全可以避免的，使得HTML页面可以尽可能快的让浏览器使用显示声明的编码进行解码文件流。那就是：在服务端设置好请求内容的charset编码；始终在页面中meta标签内声明charset，当然了，content-type也是十分有必要的。
《重构–改善既有代码的设计》这本书是去年买的了，利用晚上空闲时间看了大部分的内容，包括一些重构的技巧、良好代码的特点、代码可读性和提高语义化等。这本书改变了很多我之前所持有的观念，包括代码性能、模块化设计、结构样式逻辑分离等的思维。下面粗略的罗列几点目前自己从这本书中所理解到的其中一些知识： 重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。 第一次做某件事情时只管去做；第二次做类似的事情会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。 ——“事不过三，三则重构。”
对于压缩HTML的好与坏、利与弊，网上也已经谈论的很多，自己也搜集了一下，毕竟自己最近也在做这样的一个工具来压缩HTML代码，提出一下自己的见解以及一些设想。 支持不压缩HTML的原因有这样的一些考虑：去掉换行、多个空白之后可能会对样式有影响；pre标签形式压缩之后会失去原有的意义；IE条件注释不能够删除；只是压缩空白和注释收益不大，特别是在gzip压缩之后；压缩了代码，看源码不方便；性价比低，付出的技术成本跟收到的效果不成正比…。原因很多哎，所以造成了大部分的站点对于HTML都是未压缩的状态发布了。为什么不压缩 HTML 这几天思前想后，HTML压缩的意义在哪里？
网上看到的一篇文章，说的是js脚本优化的十条细则，看了下文章，优化的知识都很普通，搞前端的人都知道，罗列一下，增强记忆吧： 定义局部变量。对于当前函数作用域内，如果需要使用这个作用域外部的一些变量，那么就尽量使用局部变量储存外部的变量吧，特别是对于嵌套多级的作用域查询，这个耗时也是比较严重的。还有就是获取DOM节点、NodeList、HTMLCollection等等，可以将NodeList、HTMLCollection转化为数组的形式进行操作，减少DOM即时更新所造成的性能消耗。 不要使用with语句。with语句会在当前作用域下面增加作用域链，造成当前作用域下面变量的遍历性能消耗更大。 对于闭包的使用，节省点，不要太过多了。闭包就是提供一个所谓的“封闭式”的作用域，只允许向包含它向别人访问，而不允许别人访问它。但是声明一个闭包的代价比声明普通的函数的代价是要更高的，况且还有IE下内存泄漏的危险。 获取字面量对象的属性和数组的项比获取变量更慢。如果你要获取一些数据的时候，使用变量比用数组、字面量对象的索引来访问来的更快。在循环中经常会需要访问数据，使用变量存储一下，来的更快。 在数组中不要嵌套的过深。js中没有二维数组的概念，但是可以自己编写一个二维数组，并且可以无限的嵌套下去，json很经常就是这么干的。但是嵌套的越深，访问数组中的项就更难了，级数和性能消耗成正比的。 少用for-in循环。众所周知，for-in用于遍历对象的属性和方法，它所要消耗比for、while、do-while更多的性能。在for-in循环中，对于每一个循环，javasript需要创建一个函数来处理每一个循环，这就带来这么两个性能问题：函数创建、销毁的过程；这个函数在创建之后，又会储存它直接上级的作用域的活动对象。 对于循环，合并控制循环的语句，以及控制变量变化方式。在一个控制循环的语句中，比如循环结束条件、索引的递增等等，如果可以优化这些操作，那么对于整个循环的性能是有帮助的。比如对于结束循环条件：for(var i =0;i
今天下午终于有点空闲的时间了，以前基本都是时间安排都是单线程的，这些天突然进入了多线程的时代，很紧张的说。这些天进行了一个项目的改版，修改了整个页面的代码，包括HTML、CSS、Javascript。那么来说一点Javascript代码重构的一点点体会。 我非常喜欢在编写完初步的代码之后，就开始对代码进行重构，这虽然说不是专业的代码重构的工作或者提倡的行为，纯属个人爱好，趁热打铁，为的就是在code review的时候不被批的很惨。 代码重构，很大的程度上是从代码的可读性、可维护性、可扩展性、精简代码结构、提高性能、去除重复性代码、提高代码的复用度等方面入手，把糟糕的代码整理的顺顺当当的，一目了然。就像是一团打卷的面粉，用热水泡过之后，用手撂一撂，顺当的富有弹性，有些人看到会流口水的说。 首先，有一点得说明，代码重构不是为了解决项目难题而开展的工作，它的主要目的是为了代码的可读性和后期的可维护性、可扩展性等这些方面的考虑，而对当前的代码进行小范围的修改，而且是不影响目前界面UI的显示以及交互逻辑功能。说来简单，不影响界面UI以及交互逻辑功能，仅通过这些就开展重构工作，肉眼有时候很难发现代码层面的修改对界面和逻辑造成的整体的影响，所以一个可视化的测试系统，就显得重要了。这个是题外话，还在探究中……
javascript的加载方式，总得来说是在页面上使用script来声明，以及动态的加载这些方式，而动态的加载，在很多js库中都能够很好的去处理，从而不至于阻塞其他资源的加载，并与其并行加载下来。这样的动态异步的加载方式罗列起来有：Ajax的方式、DOM Element Insert、Iframe、document.write、defer等等。这些都能够很好的处理js在加载的时候不会阻塞资源加载的问题，但是，js的执行仍然会阻塞浏览器的渲染。或许这是不得不需要付出的代价，有没有一些方式去缓解js在执行的时候对浏览器的渲染所造成的延迟的影响呢？ 首先，让我们从UI Thread、UI Queue、UI Upate的角度去分析整个页面和javascript的行为。浏览器在加载HTML到最后呈现出来的这段过程，整个就是一个UI Thread进程，这个UI Thread里是一个浏览器的响应队列，而UI Queue则是浏览器的行为队列，包括UI Update，javascript的执行行为。那么在页面加载的过程中，UI Queue里面就储存了UI Update、js加载、js解析、js执行等。不管是UI Thread，还是UI Queue，都是按照顺序来的。页面在刚开始未遇到js的加载和执行的时候，是UI Update的一个过程，一旦遇到js，就会等待js的加载、解析、执行完毕之后，接着又开始UI Update，如此这样的一个相应顺序。