Recently in Web 分类

关于 Web 页面字体这方面，我是门外汉，弄不出来长篇大论 -- 这样也没必要，从观察统计上简单分析一下看看就够了。

几个页面字体适配度比较好的，HTML body 字体的定义：

• Google: font-family: arial,sans-serif;
• Twitter：font: 13px/1.5 Helvetica Neue,Arial,Helvetica,'Liberation Sans',FreeSans,sans-serif
• 豆瓣：font: 12px/162% Arial,Helvetica,sans-serif;
• 新浪微博：font-family: Arial,Helvetica,sans-serif;
• Apple中国：font: 12px/18px "Lucida Grande","Lucida Sans Unicode",Helvetica,Arial,Verdana,sans-serif;
• 知乎: font: 13px/22px 'Helvetica Neue',Helvetica,Arial,Sans-serif;
• Facebook: font-family: "lucida grande",tahoma,verdana,arial,sans-serif;
• Google+: font: 13px arial,sans-serif;

结论：Arial,Helvetica,San-serif 这个组合适配性是最好的,也是最保险的. 可选:Helvetica Neue . 知乎的定义几乎可以直接照用.

其它：

• 微软中国: font-family: Segoe UI,Tahoma,Arial,Verdana,sans-serif;
• 淘宝：font: 12px/1.5 tahoma,arial,宋体; //看过淘宝同学写过的很棒的字体文章，估计页面不是统一定义的.
• 百度：font: 12px arial;
• QQ: font-family: "宋体","Arial Narrow";
• 新浪：font-family: "SimSun","Arial Narrow";　//最烂

结论：用了宋体的，都比较烂 ... 中文网站要想页面视觉稍微好一点，直接去掉 CSS 中的宋体.

--EOF--

Updated: 对于个人站点，字体可以尽情发挥。

Updated 2: 新浪的同学解释说，之所以用宋体，是因为"宋体的半角字符是等宽字体（1/2个全角），长度的标题不会因出现英文或数字而折行"。估计是历史原因吧，相信这个问题总是有解的，看怎么解决罢了。

在 O'Reilly Velocity China 2010 大会上，业界最有影响里的 Web 性能技术专家 Steve Souders 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲，要知道，Google 已经开网站载入时间纳入到搜索排名因素之中(refer)，或许 Web 性能优化，商业网站要考虑作为一项战略来对待了。

我们看一组数据（信息来源）:

• Amazon: 增加 100ms 延迟将导致收入下降 1%；
• Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%；
• Yahoo!: 400ms 延迟会导致流量下降 5-9%；
• Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问，首页用个那么大的背景图干啥?);
• Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;
• Google Maps 将文件大小减少 30% 后请求增加了 30%；
• Netflix 在服务器端启用 gzip ，页面快了 13-25%，节省了 50% 的网络流量；
• Shopzilla 将页面载入时间从 7秒缩减到 2秒，转化率提升了 7-12%，页面请求增加 25%，只用一半服务器就够了

要注意，这些只是数据，实际上，我们没有办法验证这些数据的真实性。但是可以肯定的是，网站访问速度过慢，一定对用户有负面影响。严重一些的，国外有 Friendster 因为网站访问过慢而导致的用户流失可以作为前车之鉴；网站访问速度快也可以增加竞争优势，比如Tumblr 一骑绝尘而将竞争对手 Posterous 甩在后面。国内这方面的例子比如优酷，斥重金改进用户访问速度，很大程度上保持了竞争优势。

相比投资在硬件上，我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势，我毫不犹豫的说看好百姓网，为何？访问一下同类网站，比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。

当前最需要 WPO （甚至有些落后的) 的可能要数电子商务网站以及那些依托于大型 C2C 站点上的网店了。很多电子商务网站负责人非常重视 SEO，但在 SEO 已经快成为一种伪技术的今天，被忽视许久的 WPO 更应该引起重视。举例来说，可能绝大多数淘宝上的大卖家都不懂 Web 相关技术，当然也就无所谓什么 Web 性能优化了。我曾经见过有的卖家首页上一个页面放置几百个图片，一个页面动辄 7-8 Mb，用户访问速度可想而知，如果用户正常浏览都无法做到的话，要想购买产品恐怕也就无从谈起了。如果能对这一部分用户进行有针对性的处理，投入产出的价值还是显而易见的。说起图片来，可能这是最影响电子商务网站访问速度的一个因素，没有针对 Web 优化的图片、过大的尺寸或是失真的压缩图片比比皆是，无疑会严重影响用户体验与购买欲望(这里推荐做电子商务的朋友不妨关注一下 Yupoo.com 专门针对用户的这个需求而推出的图片管家服务)。

WPO 的好处？增加网站营收，降低运营开销，提升访问量，进而提升竞争力。

WPO 做起来其实并没有那么难，通过一些特定的准则(比如 YSlow 14条, refer)即可取得一些卓有成效的改进。期待 WPO 能早日成为 Web 工程师必备的常识。也建议每一个技术团队的负责人应该将 WPO 作为一项战略来抓，而不是只是一两个技术人员的事情。从现在就开始吧。

--EOF--

补充："快比慢好"，Google 把这句话作为十大价值观之一(refer)。而 Facebook 从创立至今，也一直将提升页面访问速度作为一项重要的策略。

补充一篇必读文章：WPO - Web Performance Optimization

拿到这本 《实战 Nginx》 有几天了，休假期间将感兴趣的几章阅读完毕。作者张宴是国内 Nginx 最早的技术传播者之一，产生的影响也最大，他的一系列 Nginx 实战的文章相信让很多 Nginx 用户受益良多。

尽管之前已经在他的网络文章或者 PPT 里看到过这本书里包含的一些内容，我还是要说一下第六章中的架构图是这本书中非常有参考价值的内容(至少对我如此)，作为网站维护者，即使不用 Nginx，这几张图也非常值得分析一下。对于从 Apache 迁移到 Nginx 的用户，第七章关于 Rewrite 规则的讲解则不可错过。

这本书的最大缺点或者说不够严谨的地方，我觉得主要是体现在某些章节上关于设置项的说明缺少足够的阐释，比如"优化 Linux 内核参数"、"MySQL 5.1 配置优化"等内容如果添加足以让读者查找更多信息的注释就更好了。另外，从章节的安排上，如果多一节专门讲述 Nginx 优化的内容或许也会不错。

对于没有 Nginx 经验或者是想进一步了解 Nginx 的系统工程师，这本书是值得一读的。这本书的定价不过是一张电影票的价钱，如果可以解答你在工作中的几个技术问题，你说是否值得购买呢?

--EOF--

在 Alexa 上观测最近的一些数据的变化，发现了一个奇怪的域名: 1e100.net ，全球排名 45 。乍看上去，这个域名非常山寨，不过查询一下，发现这居然是 Google 的域名。Google 的名字是 Googol 这个单词拼错得来的，而 Googol 就是 10¹⁰⁰ 这个大数。1e100 = 1x10^100 = Googol (refer)。Twitter 上也有网友对此进行了提示。

这么看来，1e100 这样的域名风格倒是很 Google 化。从网上的反馈看，Google 有不少服务都在使用 1e100.net 这个域名，最多的应该是 Google Chrome 浏览器的 Safe Browsing 特性对地址的使用(对 Firefox 也有影响)，而且会启用较多的并发连接，所以会有网站对此带来的压力无法承受而屏蔽 Google 的这个服务(refer)，此外也让我想起以前 Google Chrome 早期的版本解析 DNS 多少有点慢，不知道是否有相关因果关系。Google 的其它产品包括 Google Toolbar、Google Analytics、YouTube 、FeedBurner 等服务也用这个域名。也有人发现 Google IPV6 地址也是通过这域名在进行测试。不过直接访问 1e100.net 是访问不到的，Google 通过子域名的形式进行使用。

按理说，这种不对外提供服务的地址，Alexa 没必要统计流量的，或许是他们的小失误倒是让我们了解到 Google 的一点有趣的信息。

--EOF--

更多参考：

• Why is goog using 1e100.net? 解释了为什么不是 10e100.net 。
• Google 的 Project 10¹⁰⁰ 项目。
• Google doppelgänger casts riddle over interwebs

更新：最新的消息说是 Google 不同数据中心间用来" identify servers, hinting that reverse DNS plays a role" ，关键词"Spanner"。

Google 现在有官方解释了：What is 1e100.net? 用于标记Google网络中的服务。主要有两个目的：1) 保持简单性; 2) 加强安全。

针对小型站点的技术普及信息，中大型网站的牛人不用看，耽误您的时间我负不起这责任。
用 Windows 做网站的也别看了，不适合。

说起单点故障(Single Point of Failure，SPOF)，倒是可以想起电影 《2012》中，一把焊枪把齿轮卡住，从而导致整个舱门无法关闭，进而整个引擎无法发动。这是个有点生动的例子--如此庞大的一个系统，居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability)，这是致命的事情。

大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够 :)

一般来说，只要系统能够比较清楚的分出层次来，要消除单点故障还是有章可循的事情。比如，一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效的消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，而随着架构的变化，定期审查系统潜在单点也是有必要的。

有人或许会问，假设一个起步中的站点，只有一台服务器，什么东西都在一个盒子里，到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些，首先必须考虑硬盘(存储层)的问题，如果机器只有一块硬盘，即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的)，还是建议你起码再弄一块。做镜像，让出错的概率降低，这是划算的投入，当然消除单点，成本几乎不可避免的要增加。如果硬盘多，或者有其他备份机制，可选的方法就更多，别刻舟求剑。

第二个要考虑网卡与网线的单点问题。先说网线，如果要问一个系统里面最容易物理损坏的是哪个组件，答案恐怕非网线莫属，对于网线这样多数时候因为距离需要定制的东西，总是购买成品还是有成本的，从我观察到的情况来看，各个 IDC 的网线使用手工制作的比例不小，这个质量几乎很难控制，一根线，两个水晶头，哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了，网卡绑定 (NIC bonding)一个很简单很通用的办法(refer)，但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡，如果是自己攒服务器，记得网卡多一块成本没多大，但是用处会有很多。如果耐着性子看到这里，先别急着去 Google，还有问题呢，两根网线如何接到上行交换机，什么样的交换机支持绑定，如何确定绑定是真正生效的? 答案是，尝试一下。

然后是什么? 是跑多个数据库，还是跑两个 Web 服务器，一个不行用另一个顶? 对于单台服务器，其它能消除单点的地方恐怕收效也不会特别大，现在少做无用功，或许要重点考虑如何备份，如何优化，以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是，除了 SSH 登录之外，要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿，如果 IDC 距离较远，需要斟酌一下。好吧，网站有了一点发展，用户量也增加了，感觉需要增加服务器了。再增加一台服务器，抗风险能力一下子加强了许多，毕竟一台机器质量再好，也有出错的时候。现在，Web 服务器、DB 服务器可以考虑引入 HA 的方案，如果单台服务能力够，主备模式也不错。随着网站的发展，服务器数量继续增加...

随着服务器数量的增加，到了必须要自己购买网络设备的时候了。同样的设备，一买恐怕就要买双份，原因无它--一台总要出错，哪怕是电源被拔错--而这样的情况实际上并不少见。如果预算不够，那就再等等，但是要记住，定期审查，有可能的话，进行弥补总不会错。

到现在，所有的服务器都还在一个 IDC 呢，IDC 本身也是个单点啊，服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧，"南北互通"怎么样...或许在选择第一个机房的时候已经遇到了类似的问题，或许现在正在受到这个问题的困扰。选好 IDC 之后，首先计划一下数据如何备份过来，然后，网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击，对自己的网站影响能承受么?

更多的服务器，提供更多的应用，更多的用户，更多的收入... 接下来该怎么办呢? 现在，您所面对的已经不是一个小型 Web 站点了，可以不用看这篇文章了。

到现在，我还没说人的问题，如果这些信息只有一个人知道，万一这个人出了点事情怎么办? 作为老板，还要考虑人的单点问题。

--EOF--

Updated: DNS 的健康程度检查重要性应该提升一些。如何检查？有很多在线的工具可供使用，简单直接。

网站优化技术总是在进化。今天重新阅读了一下以前的前端优化笔记，发现对于 YSlow 优化 34 条准则关于减少 DNS 查找 (Reduce DNS Lookups)的部分或许应该修正一下了。

DNS 作为互联网的基础协议，其解析的速度似乎容易被网站优化人员忽视。现在浏览器厂商已经有在针对 DNS 进行优化，典型的一次 DNS 解析耗费 20-120 毫秒，减少 DNS 解析数是个优化的方式，而能够缩减 DNS 解析的时间也是有经济效益的事情。这就是浏览器厂商重视 DNS Prefetching 的主要原因。DNS Prefetching 对于性能的收益可以简单的用"DNS 同步请求到异步"来解释，也就是具有此属性的域名不需要用户点击链接就在后台解析，而域名解析和内容载入是串行的网络操作，所以这个方式能减少用户的等待时间，提升用户体验。

Google Chrome 内置就有 DNS Prefetching 技术(注意之前有几个小版本因为这一特性反而带来了性能问题) ，而 Firefox 3.5 也引入了这一 新特性。至于 IE 8，暂时还看不到有什么举措(或许是我没注意到?)。

对于一个网站来说，如果希望能充分利用用户浏览器端的这个功能，可以在页面添加 link 属性的锚点来做到。类似：

<link rel="dns-prefetch" href="http://www.google-analytics.com/">

另外还有这个 x-dns-prefetch-control 也有必要适当用一下。对于某些站点引用了 Google 的某些服务脚本，可能这尤其有用。

另外一种加速 DNS 的途径是考虑使用 pdnsd 之类的缓存 DNS 代理服务器来加速某些 DNS 请求。

在 Chrome 中，可以通过在地址栏输入 about:histograms/DNS 来观测一些有趣的 DNS 性能数据。

--EOF--

几天前看到的这个关于密码遮盖（Password Masking) 问题的讨论，顺着链接有找到了一些讨论来看，继而发现相关文章已经有人翻译了(refer)，但中文技术社区好像很少见到讨论(也可能是我孤陋寡闻)。

这是个令人印象深刻的话题，因为挑战的是习惯性的设计方式。放眼看去，所有需要输入密码才可登录的网站都是遮盖密码的。密码遮盖带来的坏处是显而易见--用户的输入成了盲区，不知道自己输入的是否对，点击登录变成了变相的试错操作，产生比较多的再次登录操作，对给用户造成非常糟糕的使用感受。然而似乎很少有人如何去考虑改进这个现状。关注别人视而不见的问题才会带来革新与创新，要不怎么说人家 Jakob Nielsen 是用户体验方面的大牛呢，要从别人口中出来这个论断可能会被人笑话，而大牛就敢于挑战常规，弄个问题就给大家带来思考了--扯远了。

似乎多数人赞同添加一个额外的检查框（CheckBox），安全性要求不高的应用，默认不遮挡，用户输入完毕之后，再选择旁边的检查框对密码进行遮挡；对于安全性要求比较高的应用，默认密码遮挡，但可以选择显示一下密码明文一下，方便用户检查是否有拼写错误。

如果你用过苹果的产品，比如 iPhone 新 OS 3.0 的版本，你会发现密码的处理又进了一步，密码输入时是显示明文的，方便用户确认没有输错，在几秒钟后或者输入下一个字符的时候再对这个字符遮盖。(很多移动厂商好像现在都这么设计了)

(截图有点喧宾夺主，对付着看吧)

这个想法真的很让人欣赏，对于手持设备能够比较有效的防止了窥探(peeking over your shoulder)，也减少了用户输入错误的频率。只是不知道是不是已经被手机厂商申请了专利。对于大屏幕显示器来说，窥探的可能性有多大？缺乏数据支持，很难说明。或许，这里的安全专家的分析对质疑者也会有点帮助。

其实我觉得密码遮盖问题在用户初次注册的时候带来的问题尤其严重。在这个环节如果添加一个 CheckBox 要用户知道自己连续两次输入的密码是什么应该是有必要的(有人举手同意麽?) ，否则的话，用户要的密码可能不是自己输入的，短时间内连续两次输入，出现键入错误的几率并非不存在。

好吧，现在开始审视一下自己的网站登录框设计以及注册页面吧...新的问题或许是，你有勇气做点修改麽?

如果觉得上面说的都是废话，那么不妨考虑这两个问题：

• 为什么我们之前就没考虑到这一点?
• 如何才能先于别人一步想到这一点?

--EOF--

延伸阅读：Better Password Inputs, iPhone Style

现在网络上已经可以看到很多公司的团队对外的 BLOG ，关于这个话题，在这里记录一下我的一些个人看法。当然贵团队如果已经开博或者即将开博的话，毋须照搬，这不是什么指导。

明确团队开博目的

首先必须确定要传递哪些信息给读者? 宣传公司团队文化? 技术宣传? 产品宣传? 还是兼而有之? 如果只是为了跟风，那就没必要的。实际上，我相信大部分团队 BLOG 不过是跟风而已，不过跟风跟的好，也能起到不错的作用。如果能认真经营 BLOG ，它就能给你带来价值，超乎你想象的价值。

一般而言，建议对外开博前，可以在内部先试运行一下，给大家熟悉网络环境一个缓冲期。

不与业绩指标挂钩

据说很多团队的 BLOG 居然和 KPI 挂钩的，这是非常不适合的做法。很明显这会导致一个现象：到了接近考核的时候，团队每个成员都流水帐一样连发多篇文章凑数，对读者来说，是一种信息轰炸，起不到什么正面作用，对团队多数成员来说，也觉得这样圆满完成任务也不错嘛，势必影响真正用心写文章的成员。当然我相信很多人看了我这个帖子后会改变 KPI 的设置方式，比如"每月要发布几篇"... 简言之，本末倒置。

控制文章发布频率

团队 BLOG 管理员(没错，应该有个管理员)应该控制文章正式发布的频率。细水长流，尤佳。记住，节奏最有力量。

控制频率的另外一点是要做好长期性准备，不要几天热乎劲儿过去之后就乏于更新。如果潜在读者偶尔访问过来，发现最近一篇更新是一年前，或许就会留下负面印象。

不要强制团队成员

必须要认清的一件事情是，一个团队中，肯定有些人员的确不善于文字表达，如果要他写一篇文章，可能比杀了他还更难受。如果强制性的压着他憋文章，恐怕只能适得其反。好的方式是发起者能够引导团队成员中的那些低调者，使他觉得这事情有意思，可以尝试一下，能够更多锻炼自己。比如针对技术人员来说，写文章过程中如果熟悉一下 HTML 基本语法，在日常工作中也不无裨益。

不要堆砌垃圾文章

这里面的一条铁律是：不要转贴那些网上随处可见的"心得"，"感悟"之类的心灵鸡汤文章，那些文章不能改变外界对你团队的正面看法(当然有可能增加负面看法)。适当的转载关于自己团队或者公司的第三方文章是可以接受的。

记住，垃圾信息和网站质量成反比的。信息不是越多越好。

内容格式非常重要

内容是团队向外展示的载体，固然重要，可如果文章不经过很好的格式化，就好比一块好田地长满了庄稼也同样长满野草一样让人讨厌。这是如此简单的一点，但我们还是能看到有许多团队对此熟视无睹。一篇连段落都不分的技术文章内容再好，也不会有更多技术人喜欢看。

不但 Web 页面要注重格式化，对 RSS 输出也同样也要注意，甚至应该更加以重视。至于输出全文，那是必须的。团队 BLOG 不要在乎什么 PV 之类的事情，那是非常土鳖的做法。内容是否有价值，不在于有多少人看了这篇文章，而是有多少目标读者从中得到收益。

--待续-