在Firefox上安装了支持微格式(Microformats)的扩展(Operator, Tail Export等)的，也许会注意到年会注册程序的页面上已经提供了hCalendar的支持。以下是在这些页面上使用几个扩展的截图。
下面是Tail Export在边栏里列出的年会议程页面页面上所有hCalender微格式，用户可以点击export图标把感兴趣的活动/议题加入到本地的程序比如Outlook, Mozilla Calendar项目的软件比如Thunderbird Lightning等。
导入到Outlook里后：
我个人更喜欢Operator这个扩展，因为它还能把微格式导入到在线的日历服务比如Google Calendar和Yahoo! Calendar，而且似乎对unicode支持比较好。以下是截图：
导入到GCal里：
链接：更多关于微格式的截图。
从这些页面和本地程序的数据交互，以及网页和网页之间的程序调用和数据交互，展示了语义网(Semantic Web)，最基础的技术支持(HTML, MIME, HTTP)就能提供很好的在线和本地（尤其是移动终端, iphone, mobile firefox? mobile xulrunner?）集成以及更好的用户体验。
另：年会注册程序里除了hCalendar，年会页面当然也能提供hCard（个人信息）的微格式，但是在没有更好的隐私保护措施和共识之前，对hCard的支持目前还是没有开放出来。其它的格式比如FOAF，hReview，rel-tag, rel-license等的支持，会在将来陆续提供。
P.S. 有点遗憾，因为临时有事，没能来得及在年会开始之前做这个介绍。
减少DNS查找能够缩短页面反应时间，但是所有网站资源都只用一个域名，从而把DNS查找减少到一个，也不是最好的办法。不仅仅因为减少的平行下载的可能，更因为Web Cache对带与不带cookie的请求和返回的处理不同。
我的网站域名是www.yining.org，有个页面（比如就这篇blog entry）带有一张图片，其src为：/img/camel.gif，那么它的URL就是:”http://www.yining.org/img/camel.gif”。如果这个页面设置了cookie（比如为了记录留言者的ID和网站地址等），cookie的作用域名自动为www.yining.org，那么每次访问该页的时候，因为URL的域名部是www.yining.org，那么浏览器都会带着cookie对该图片发起请求，即使一路上的web cache有www.yining.org/img/camel.gif的记录，也依然要到我的服务器(the origin server)，而不是从中间的web cache返回 - 因为带cookie的请求都可能根据不同cookie的值而返回不同的response。
但是这对许多静态资源（图片, css, 和javascript）来说不是最理想的，因为不论cookie是什么，它们的response里都是同样的内容，对它们的请求没有必要每次都回到origin server。其次，因为不同web cache对带cookie的请求支持不同，即使有的cache能够缓存带cookie的response，但是1）不是大多数的cache都能做到这点，2）大多数的cache都缺省缓存不带cookie的response。因此最好的办法就是使用不同的域名把静态资源隔离开。虽然cookie的path属性也能做到这点，但是毕竟限制太多，不如使用专门的域名灵活。
所以应该尽量把所有静态的对象和动态页面的域名分开，更严谨地说，是把不需要读写客户端cookie的服务器资源与需要读写cookie的程序分开到不同的域名。比如我可以设置另一个域名static.yining.org，在引用该图片的<img>里的src属性改为”http://static.yining.org/img/camel.gif”，那么当访问首页的时候，浏览器就不会带着cookie（因为作用的域名现在不一样了），这样就能更好地利用web cache缓存和服务器的性能。我请教过一位曾经在NetAppliance（最大的web cache厂商）工作的同学，据他说根据经验，带和不带cookie之间的差别有可能是20%甚至更大。
雅虎的YSlow插件的规则之一：Rule 9 – Reduce DNS Lookups提到：
Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.
说说自己的理解：
首先，一个页面所需要访问的域名数量为n，那么就需要n次DNS查找，而DNS查找通常是blocking call，就是说在得到结果之后才能继续，所以越多的DNS查找，反应速度就越慢；
其次，并行下载(parallel downloading)由两个因素决定：到服务器的连接数量，以及每个连接内部的流水线请求数量。
一个页面里到服务器的连接数量由两个因素决定：
- 页面所需访问的域名数量，和
- 浏览器所允许的最多连接数
后者在Mozilla/Firefox中还由浏览器所允许最多连接数(network.http.max-connections，缺省为24)，和每个服务器所允许的最大连接数(network.http.max-connections-per-server，缺省为8)决定。如果max-connection-per-server是m，那么一个需要访问n个不同域名的主机的页面，最多可以有n*m个连接 － 前提是n*m小于max-connections的值；
每个连接内部的流水线请求(pipelined requests)的数量也是浏览器的参数(Firefox上由network.http.pipelining来设置，缺省为4)，前提是服务器支持persistent connection（比如在Apache设置KeepAlive为On）。之前的例子就不需要那么多的连接了（对服务器和浏览器来说，一个连接里多个流水线请求能够比多个并行连接更好些），假设pipelining的值为p，那么就可以只使用n*m/p个连接了。(BTW，对Firefox做优化的一些插件其实就是对上面的几个设置做调整）
所以减少页面内不同hostname的数量不一定会减少并行下载的数量，也要看所需要的请求(css, javascript, 图片等)的数量，因此YSlow的解释说是potentially。
雅虎今天推出了YSlow插件（这名字不错：Why Slow? ），需要先装Firebug，YSlow其实是它的“插件”。YSlow从Firebug收集当前网页和该网页的访问信息后进行分析，如有必要则给出如何提高页面加载速度的建议，比如减少DNS查询，使用外部并压缩Javascript等。这些建议是根据13个提高网页速度的指导原则，其内容已经在Yahoo Developer Blog上系列连载了一段时间，最近更新速度快了很多几乎每天一篇（是为了配合YSlow的推出？）。除此外还有专门一本书：《High Performance Web Sites》，内容就是这个系列（多了一个关于Ajax的专题），应该有更深入的分析和解释（这本书是Rough Cut，所以有O’Reilly Safari帐号的可以先睹为快了）。
这个High Performance系列说明网站开发者（包括我自己）非常需要深入了解HTTP和HTML。对Java尤其尤其是J2EE程序员来说，不要只是build around the web, 而是build for the web。很多程序员（尤其是刚毕业的大学生）不在意HTTP的细节，从所谓的“企业级开发”的角度把HTTP请求仅仅当作作一种函数调用，导致能提高性能的所有HTTP的特性都被“抽象”掉了，也就不了解或者利用这些属性。比如，我常在面试的时候问：HTTP GET和POST的区别在哪里？大部分的回答只有参数大小和位置的不同。
YSlow上的指导原则里的内容还有些可以补充的（很多东西应该都放到那本书里去了吧），比如在High Performance Web Sites: Rule 13 – Configure ETags里，作者建议在Apache上把ETag关掉，实际上只需要告诉Apache不要用Inode信息生成ETag就可以。还有其他一些，回头写上来。这里，这里，和这里也有很多非常好的建议。
另外要注意的是，网页速度跟网站性能是不同的概念，网页在浏览器上加载得快，并不能保证网站的性能就好，虽然二者之间有密切的关联。
P.S. 关于网站的延展性(scalability)和速度(performance)，O’Reilly已经出了两本，另一本是《Building Scalable Web Sites》，都是雅虎员工写的，在这要赞一下雅虎对Web开发社区的贡献。
为了更方便阅读网页(”Improves readability”)，有人专门针对Lifehacker.com（我每天必看的网站）页面写了个Greasemonkey用户脚本，把多余的页面元素删除掉(”Removes various elements from the Lifehacker site”)。
猜猜看Lifehacker的反应是什么?
It removes too many elements of the site’s design, but this custom Lifehacker user style is still a compliment. You like us enough to mod us!
稍微有点不满意(删除掉太多页面设计元素了)，但这对Lifehacker.com还是一个认可，因为用户喜欢Lifehacker到了改装页面（mod的感觉没翻译出来）的地步。
所以：
- 如果有用户用user script改装你的页面，那这是一件好事情（你提供了他们不愿意放弃的内容），同时也是一件需要考虑的事情（页面设计也许太花哨或者色彩搭配不够好）；
- 页面的mark up不能太复杂，否则user script不好写 ;)
- 页面的mark up不能经常变动，否则user script会失效；
这就让我想起几天前看到的一句话：
Your Markup is an API. With all the hype about APIs and mash-ups, it’s easy to forget that your HTML is also an API, and your users are experimenting with it right now.
— Matthew Magain
但页面设计和编写的重要性绝对不仅仅在为了考虑用户使用Greasemonkey user script（毕竟这样用户比例特别小），在结构化的数据的发布和读取上，尤其是microformats的推广更是证明了“页面是API”。下一个版本的Firefox，Firefox3.0，已经在考虑集成对microformats的支持，这里有一些Firefox3在支持microformats的用户界面设计模拟图，已经包括hCard, hCalendar等格式。
话说回来，无聊一下，如果写Greasemonkey user script来改装网页，你会改装国内的哪个网站？怎么改？
我一直认为网页标准的普及和支持是Web2.0发展中的非常重要的推动力量之一，一是CSS让网页设计和维护更容易，二是Javascript让用户互动更友好，这使得更简洁更友好的web 2.0界面更流行更受欢迎。
同时，越来越多的控制转移到了用户手中，比如Firefox的NoScript扩展让用户可以关闭或者开启所有或者某些网页上的Javascript。这就使得一些网站的页面在Javascript被关闭的时候，不能或者部分不能使用。例子：在豆瓣上对东西评价打分的界面在关闭Javascript后就失效了，似乎也没有其它手段可以做评价和打分。
这是不是有点吹毛求疵呢？那再看看Amazon上类似页面的处理，用户可以对一件商品做评价，和标记自己是否拥有，界面如下所示：
也是使用了Ajax，不需要重新载入页面；把Javascript关掉，刷新页面，由于Javascript被关闭，页面此处则显示一个“Rate this item”的链接，链接到的页面出现以下这个界面，一个简单的“web 1.0”的表单：
这就是“可降解的”(Degradable)Javascript的应用的例子，在浏览器不支持或者不完全支持Javascript的时候，仍然能够正常展现和提供页面所有功能。虽然用户体验不如Javascript开启的时候好，但用户仍然能够完成他想要做的事情。
需要关闭Javascript么？有些情况下，是的，比如出于速度和安全的考虑，比如使用不支持或者完全支持Javascript的浏览器（不，不只是Lynx，还有移动终端上）。更重要的是，不能因为用户选择关闭Javascript，就不让他们使用到某些功能。尊重用户的选择，这应该更是web2.0的精神和力量的所在吧。
那么，既要支持javascript被关闭的情况，又要有Ajax，会不会增加开发的难度呢？Jeremy Keith, DOM Scripting的作者，不这么认为，在他的书里也提到Progressive enhancement（渐进增强）的开发过程和Hijax的手段，简单地说，就是
- 首先以传统的或者说web1.0的方式设计和实现网页；
- 在1的基础上，添加Javascript实现Ajax，优化用户互动；
因为即使使用Ajax，所有处理还是在服务器端完成的。更多关于progressive enhancement和Degradable Javascript可参考：