CSS的API并不多，掌握到会用的程度并不难，但如果要用得好，我们需要在前者的基础上更进一步，研究如何组织CSS。
 
      应用CSS的能力应该分为两部分：一部分是CSS的API，重点是如何用CSS控制页面内元素的样式；另一部分是CSS框架，重点是如何对CSS进行组织。前者属于基础部分，这部分的能力是用“对”和“错”来评判的，比如说，要把文字设置为红色，只能用color:red；这样的写法是对的，其他任何写法都是错的，不存在“好”和“坏”的区别。只有“对”和“错”。CSS的API并不多，掌握到会用的程度并不难，但如果要用得好，我们需要在前者的基础上更进一步，研究如何组织CSS。如何组织CSS是一个见仁见智的问题，不是用“对”和“错”来评判的，我们更可能会用好、比较好、很烂、非常棒、这样的字眼来评判。

随着Ajax的兴起，网站性能不再局限于只是让网站快速呈现。越来越多的网站在加载完成后，借助JavaScript来实现页面内容的动态更新。这类网站的程序原理和传统的桌面客户端程序类似，同时对这些程序进行性能优化需要一套有别于传统网站的技术。

      从更高的层面上来说，基于用户界面内容的需求，Web应用和传统桌面应用有一个共同的目标：尽可能快地响应用户的输入。当浏览器响应用户发起的加载网站的请求时，它需要处理大量与响应相关的工作：与用户请求的站点建立网络连接，解析HTML，请求相关资源等。详细地分析这个过程，我们可以找到方法优化页面，最大程度地提高渲染速度，但浏览器最终掌控着页面的加载和呈现。

现在你已经知道足够快的门槛了，下一步是研究如何才能测量JavaScript的执行速度，以确定它是否超出前面提到的范围。

           现在你已经知道足够快的门槛了，下一步是研究如何才能测量JavaScript的执行速度，以确定它是否超出前面提到的范围。

      通过人的观察来测量延迟时间虽不精确，却是最简单最直接的方法：只要在目标平台上运行一下应用程序，然后确定性能是否足够快。因为确保用户界面性能足够好的目的就是让使用者感到愉悦，所以这样做测试其实是否足够快。因为确保用户界面性能足够好的目的就是让几秒来量化延迟，所以可以使用粗略的分类。

内存管理不善会导致UI的性能问题。因为缺乏优秀的排除内存问题的工具，开发者通常要观察浏览器的内存使用，然后逐步减少引起问题的应用的内存占用。有个好消息是内存故障排查工具正在开发中。
 
      内存分页是与内存相关的另一种风险。操作系统为应用提供两种可用的内存：物理的和虚拟的。物理内存映射在基础计算机中极快的RAM芯片上；虚拟内存映射到非常慢的海量存贮设备上，它用更大的可用存储空间弥补了内存的相对狭小。

      如果网页的内存需要增长到足够大，可能会迫使操作系统开始内存分页，一个极慢的进程凭借迫使其他进程放弃其真正的内存来给浏览器不断增长的需求腾出空间。之所以使用术语——分页，是因为多有的现代操作系统把内存组织到独立的页面上，这个术语描述了映射到物理或虚拟内存上的最小内存单元。当分页发生时，系统把内存页从物理内存转移到虚拟内存上，反之依然。

提早实现自动化部署，一种可重复和可靠的方式，在目标机器上部署你的应用。
 
      系统能在你的机器上运行，或者能在开发者和测试人员的机器上运行，当然很好。但是，它同时也需要能够部署在用户的机器上。如果系统能运行在开发服务器上，很好，但是它同时也要运行在生产环境中。

      这就意味着，你要能用一种可重复和可靠的方式，在目标机器上部署你的应用。不幸的是，大部分开发者只会在项目的尾期才开始考虑部署问题。结果经常出现部署失败，要么是少了依赖的组件，要么是少了一些图片，要么就是目录结构有误。

选择最佳脚本加载技术的决策树，不同域、无序，不同域、保持顺序。
 
      不同域、无序

           XHR Eval、XHR注入和Script in Iframe技术在这些情况下无法使用，因为主页面的域与脚本的域不同。我们不应该使用Script Defer技术，因其迫使脚本按顺序加载，相反，如果脚本能一到达就执行的话会让页面加载更快一些。对于这种情况，Script DOM Element技术是最佳方案，但它会导致在Firefox中加载时保持顺序，虽然我们并不希望这样。注意这两种技术都触发忙指示器，但我们没有办法避免这个问题。包含JavaScript广告和控制的网页是符合这种情况的实例。广告和控件的脚本所在的域往往和主页面不同，但是它们之间没有任何依赖关系，所以加载顺序无关紧要。

不同格式图像的特点，这些特点决定了如何在Web上使用这些图像，同时也是选择图像格式的因素之一。
 
   图形VS照片
不管你使用哪种图像格式，优化方法取决于图像的具体类型；

   图形

   网站的Logo、草图、图表、大部分动画和图标都属于图形。这些图像通常由连续的线条或其他尖锐的颜色过渡组成，颜色数量相对较少。

   照片

照片通常有百万数量级的颜色，并且包含平滑的颜色过渡和渐变，想象一下用相机拍摄的日落时的照片。绘画作品的图像更接近于照片，而不是图形。

客户端Comet的性能优化目的是：减少数据传输的延迟、HTTP连接的保存和管理、远程消息和处理跨域问题。服务器端的性能优化目的是：保存和共享HTTP的连接数、并尽量较少每个连接所消耗的内存、CPU、I/O和宽带。

       连接管理

    即便是很少的数据，服务器也会永久地为每一个用户打开一个HTTP连接，这导致打开很多连接。连接有两个限制：内存和CPU。但无论如何，每个连接都会因操作系统或开发语言而产生内存占用。如果每个连接使用一个线程就会导致一个完整执行堆栈的内存占用，即使它能被降到几乎合理的程度，通常大小也为2MB。另外，如果线程数的增加超过进程数，那么我们将会以超负荷而告终，因为操作系统在线程与进程之间切换的开销比我们实际执行代码的开销还要多。正是这个原因，我们需要选择一个异步网路架构。

Comet利用HTTP规范中不常用的特殊性来工作。通过更智能的长连接管理和减少每个连接占用的服务端资源，Comet比传统Web服务更易于提供更多的同步连接，客户端与服务端之间的数据传输更快。
大规模的应用必须使用异步连接处理，因为传统的服务架构中每个连接都需要使用一个线程。对于高并发的应用，Comet服务器通常会根据操作系统来改进事件库，操作系统处理异步I/O的方式多种多样，传统的方式是选择（select）或轮询（poll）。应用程序可以通过这些结构来询问操作系统哪些套接字（Socket）已经可以写入和读取从而避免发生阻塞。

虽然iframe不会直接阻塞主页面中的资源下载，但是有几种方式会导致主页面阻塞iframe的下载。除了预期的脚本行为之外，在Internet Explorer 和Firefox中，主页面的样式表会阻塞iframe的下载。
即使是空iframe，其开销也是很高的，他们的开销比其他的DOM元素高出1~2个数量级。
当我们在典型方式下使用iframe时（），它会阻塞onload事件。这会延长浏览器的忙指示，导致用户感觉页面加载很慢。动态地设置iframe的SRC属性能在Safari和Chrome中避免这个问题。对于其他浏览器而言，可以在onload事件后设置SRC属性来避免。