- 让功能、页面尽可能早的可用、可交互 + 让界面任何时候都能迅速响应。
- 使用setInterval作为重复定时器的缺点：1、某些间隔会被跳过；2、多个定时器的代码执行之间的间隔可能会比预期的少。为此，可以使用setTimeout并在内部迭代setTimeout来避免这两个问题。
- 设计良好的代码，可以做到应用程序某一部分发生错误不会影响另一个实际上毫不相干的部分。
-
使用innerHTML、innerText、outerHTML、outerText替换子节点可能会导致浏览器的内存问题，尤其实在IE中。如果被删除的子树中的元素设置了事件处理程序或者具有值为JavaScript对象的属性，就会出现这个问题。
假如某个元素有一个事件处理程序（或者一个作为属性的JavaScript对象），当使用上述某个属性将该元素从文档树中移除后，元素与事件处理程序之间的绑定依旧存在内存中。如果这种情况频繁出现，页面占用的内存数量就会显著增加。因此，在使用这4个属性时，对于即将移除的元素，最好先于手工移除它的所有事件处理程序和JavaScript对象属性。 - 无论什么时候，只要创建了一个新函数，就会根据一组特定的规则为该函数创建一个prototype属性，在默认的情况下，所有prototype属性都会自动获得一个constructor（构造函数）属性，这个属性包含一个指向prototype属性所在函数的指针。
创建了自定义的构造函数之后，其原型属性默认只会得到constructor属性，至于其他方法，则都是从Object继承而来的。当调用构造函数创建一个新实例后，该实例的内部将包含一个指针（内部属性），指向构造函数的原型属性。在很多实现中，这个内部属性的名字是__proto__，而且通过脚本可以访问到（在FF，Safari，Chrome和Flash的ActionScript中，都可以通过脚本访问）；而在其他实现中，这个属性对脚本是完全不可见的。不过，要明确的真正重要的一点，就是这个连接于实例与构造函数的原型属性之间，而不是存在于实例于构造函数之间。 - 当为对象实例添加一个属性时，这个属性就会屏蔽原型对象中保存的同名属性；换句话说，添加这个属性只会阻止我们访问原型中的那个属性，但不会修改那个属性。即使将换个属性设置为null，也只会在实例中设置这个属性，而不会恢复其指向原型的连接。不过，使用delete操作符则可以完全删除实例属性，从而让我们能够重新访问原型中的属性。
- in操作符只要通过对象能够访问到属性就返回true，hasOwnProperty只在属性存在于实例中时才返回true，因此只要in操作符返回true而hasOwnProperty返回false，就可以确定属性是存在于原型中的了。
- 无论你想了解任何一个库，首先把它的核心逻辑或者说核心方法给理顺了，接下来的代码读起来就很Hi了
- 在有dom引用的作用域下，不要出现跟这个引用同级的scope
- A single 50k file may take less overhead than two 25k files, but it will also tend to load in approximately twice as much time, because the browser can’t take advantage of parallel downloading. You shouldn’t load fifty 1k files either – that’d be crazy! But maybe 2 or 3 files in parallel might be quicker than one big file. Just try it and see.
-
Transfer-encoding:chunked对HTML内容加载来说，非常有用，它使得HTML内容可以边加载边解析。但是如果将它作用于js、CSS文件，会造成资源无法加载，切记。
同时，Transfer-encoding:chunked可能被一些代理给删掉，所以应该考虑到这种情况的存在。
-
终端用户响应时间 = 页面下载时间+ 服务器响应时间 + 浏览器处理及渲染时间
页面下载时间 = 在带宽上消耗的时间 + 在网络延迟上消耗的时间 = 页面尺寸 / 网络带宽 + （网络延迟 × HTTP 请求数）/ 并发度
因此：
终端用户响应时间 = 页面下载时间 + 服务器响应时间 + 浏览器处理及渲染时间 = 页面尺寸 / 网络带宽 + （网络延迟 × HTTP 请求数）/ 并发度 + 服务器响应时间 + 浏览器处理及渲染时间
在这个简化模型中，有些因子没有被考虑 :
- DNS 查询时间；
- HTTP 请求建立时间；
- HTTP 连接的连接保持状态；
- 浏览器，服务器在处理传输时消耗的时间，等等；
- 带宽对并发度的影响。
如何降低页面下载时间
-
减少 HTTP 请求数来降低在网络延迟上的消耗。方法有：
- 尽可能的缓存 HTTP 请求。这样至少可以降低后续的访问的页面下载时间。
- 将多个文件捆绑整合。如 Dojo Shrinksafe 可将多个 Javascript 文件整合成一个。CSS Sprite 可将多个图片整合成一个。
- 当然通过设计 / 代码重整的方法来减少互联网应用的 HTTP 请求数总是有效的。
-
减少页面尺寸来降低在网络带宽上的消耗。方法有：
- 尽可能的缓存 HTTP 请求。这样至少可以降低后续的访问的页面下载时间。
- 启动 HTTP 压缩。主流浏览器都支持 gzip enconding。通过在服务器端启动 HTTP 压缩，大致可以减少 60% 以上的文本尺寸。
- 当然通过设计 / 代码重整的方法来减少互联网应用的页面尺寸也总是有效的。
-
提高并发率。方法有 :
- 预读。如 a.js 将引用 b.js，b.js 将引用 c.js。在正常情况下，这是个串行的过程。但如果在引用 a.js 时就引用 b.js 和 c.js 就可以很好的提高并发度。并降低在网络延迟上的消耗。
-
在脚本语言中，主要的性能剖析方法有时间片剖析和调用流程剖析：
- 时间片剖析：时间片剖析能记录与统计一段时间内各个方法被调用的次数以及占用的时间片长度。它的结果通常能帮我们回答这些问题：“时间都花在哪些方法里了？” “谁用了最多的时间？” “每个方法被调用了多少次？”。
- 调用流程剖析：调用流程剖析记录一段时间内每个方法的调用、退出以及它调用的子方法，同时记录该方法消耗的时间。它的结果能显示每个方法的调用流程与方法在这个堆栈所消耗的时间。它通常能帮我们回答这些问题：“是谁调用了这个方法？”，”这个方法都调用了哪些其他方法？”
- 避免给setTimeout/setInterval传递一个字符串做第一个参数，更好的方式是使用一个匿名函数代替，这样就可以避免setTimeout/setInterval内部转换字符串的过程消耗。
- 要明白inline脚本对页面加载和渲染是完全阻塞的，特别是样式表后面直接跟着inline脚本，会阻塞后续资源的加载。有三种方式来解决：把inline脚本放到最末尾；使用setTimeout；使用defer属性。
- 在页面加载的过程中，对于表单的submit和超链接等等之类的，应该在页面加载的过程中就可以使用，而不能阻碍用户的正常交互，这主要是为了防止页面加载过慢，用户点击搜索form而无法提交的交互，造成用户体验的问题。原则：越少的依赖js，就可以使得跟用户的交互更流畅。
- 在head和body标签之间加flush()函数，让css文件快速的加载下来并解析，但是这样就使得页面还是一篇空白，因为HTML还没有加载下来。解决办法：在主要内容加载后开始flush()；