昆明网站建设信得过品牌，西南首家三维全景技术提供商，为您提供营销型网站建设服务。

周鸿祎（yī ），湖北黄冈人。毕业于西安交大管理学院系统工程系，获硕士学位。曾就职方正集团，先后担任事业部总经理、研发中心常务副主任等职。现360安全中心董事长 。曾获得了”2004中国十大管理英才”、”中国管理百人”、”《财经时报》2004中国十大财经人物”、”2004中国IT风云人物”、”2004年五大得意人物”等奖项。现360安全中心董事长。

在互联网领域创业的人越来越多，但究竟怎样才能打造出成功的互联网产品，一直存在着理解的误区，也困扰着很多创业者。

从我个人多年的实践中，我认为互联网产品有几个容易被忽视的特点：第一，互联网产品要有一个灵魂，要符合相关领域的游戏规则，能打动用户的心。如果这一点没做好，产品设计外观做得再华丽，后台再强大，也很难成功。打动用户的心，这好像是废话，但也最质朴，很多产品其实不是在真正满足用户需求，而是在发明或幻想用户需求，甚至逆着用户需求在做。像国内很多SNS网站都模仿Facebook，尽管很像，但都不太成功，而开心网摸对了用户的脉，中国互联网用户上SNS实际是以开心、娱乐为主，简单、容易上手、好玩的小游戏就打动了用户。

第二，互联网产品需要不断运营、持续打磨，好产品是运营出来的，不是开发出来的。而传统的软硬件产品都有个物化的载体，不可能经常改，比较稳定。互联网产品的本质是服务，就是通过某种形式的桥梁和窗口把服务传递给用户，由于用户的需求不断在变，产品就要随时调整。早些年微软的Windows XP比较成功，因为在传统软件时代，用户需求不多，厂商很容易能了解到；到了互联网时代，闭门造车出来的Vista就不可避免的失败，用户需求变化太快了，厂商对此没有把握。

产品一定是让人去用的，不断根据用户反馈去修正。现在很多人都在讲“以用户和市场为中心”，但实际上还是“以公司为中心”。我曾经看过一家大公司的内部报告，说要做一个IM产品打败腾讯，说可以为自身带来什么价值，可以整合内部产品等，但从头到尾没有涉及能为用户创造何种价值。这种出发点必然决定失败的结局。

我认为自己做客户端的资历比马化腾要深，但如果真的做一个IM产品，在产品细节和技术上可能比他做得好，但很难比他成功。我们俩的背景不一样，我做传统软件出身，而腾讯的创业团队是从做传呼的润迅出来的，之前就在做服务，这一点给了马化腾很大的帮助。这是一个分水岭，马化腾很早就掌握了互联网产品的规律，把它当成服务来做，持续改进。

无论你的想法高明与否，我认为都不如用户的选择高明。有了任何想法，不要奢望做到完美再推向市场，不如先简单地做出一点点，就拿到市场上做实验，一旦对了就迅速跟进，一旦不对调整的成本也很低。把用户作为试金石，集小胜为大胜。

从前面两点可以推出第三个特点，大家都说产品要做到专注和极致，对于互联网产品我感觉是“伤其十指，不如断其一指”。在产品方向上，一定要先学会做减法，而不是做加法。要先找对一个点做到极致，否则你什么功能都做，最后都不突出，没有鲜明的卖点。

如果你掌握了互联网产品的规律，可能你不用太多的人力，只要瞄准用户的需求点，同时在网站技术开发方面，采用“小步快跑，循序渐进，不断试错”的思路，我觉得就有可能会超过大公司。

前端优化，这几字对于做网站的人来说应该相当熟悉了。
近年来，前端的用户体验现在显得越来越重要，从后台开发，到前台技术很多工作都围绕如何提高前端用户体验而展开。我们也许能从这篇文章里获取一些有用的信息，用到自己的实际项目工作中。这篇文章的作者来自yahoo的异常表现小组。他们是一个很小的队伍，专门针对雅虎的产品进行质量检测和改进，该作者作为 一个后端工程师，现在却开始捣鼓前端代码优化方面的工程，他认为这是一个极好的进步的机会。他的目标是改进用户端体验，他度量了在各个带宽下浏览器的响应 时间，得出如下的一个图表，它展示了来自http://yahoo.com的http的流量。现在我们来好好学习一下：

以上图标的第一个标签就是html，是一个html文档最开始加载的东东，在这个例子中，读取html代码只占了整个响应时间中的5%，这个结果适 用于绝大多数网站，在采样美国的前十位网站中，只有一家超过5%但少于20%，其余80%的时间是用来读取网页其他内容的，也就是说，前端（原文是 front-end，意思就是不包括html代码的其余内容，可以是图片，脚本，flash，视频，各种东西）。这就是为什么我们要把目光集中在这些东西 来提高显示速度的关键原因。

为什么要从前端开始着手有三个主要原因：

这里有提升和改进的潜力。如果能减少一半的体积，就能减少40%的响应时间。

改进前端比改进后端需要的时间和资源更少。（改进后端要重新设计应用程序规划，代码，寻找优化代码的方法，添加或改变硬件配置，分布式数据库，等等）

前端的改进在我们的工作中已经被证实，我们在yahoo有五十个小组，在我们的最佳表现规则下，提高了他们的用户端响应时间达到25%或更高。

我们的黄金规则是：首先优化前端表现，这些东西耗费了用户端响应时间中的80%。

1.减少http请求数

图片，css，script，flash，等等这些都会增加http请求数，减少这些元素的数量能减少响应时间。

CSS Sprites技术能减少图片的请求数，把零散的小图片放到一起，运用background-position来改变背景图片的位置，前提是html元素事先定义好宽高，其实就像一个遮罩，移动背景就会看到不同的景象。

内嵌图像 用data:URL scheme的方式把图片内容代码直接嵌入html代码中，这样会增大html代码的体积，改进的方式是把内嵌图片嵌入到css中（css被缓存），这样就会更好的减少http请求数而且不增大html的体积。

很多用户都是在空缓存的情况下进入你的网站的，这样第一次的速度就会显得很重要。

第一条规则是最重要的一条规则。

2.运用cdn技术

具体方式，可以Google一下。

3.加一个长时间过期的头部

Expires: Thu, 15 Apr 2010 20:00:00 GMT
浏览器会用缓存来减少http请求数来加快页面加载的时间，如果页面头部加一个很长的过期时间，浏览器就会一直缓存页面里的元素。
不过这样会带来一个问题，就是如果页面里的东西变动的话就要改名字了，否则用户端不会主动刷新，在yahoo工作组用的是版本号，例如yahoo_2.0.6.js

4.Gzip压缩

Gzip是现在最流行和最有效的压缩方式，她是GNU开发的，RFC1952标准化。
（Gzip是在服务器端压缩图片，css，脚本等，传送到用户端的浏览器再解压，这样可以提高传输速度，不过对服务器的压力会增大，一般选择部分元素压缩比较合适。）

5.把样式表放到顶部

我们发现把css放到文档头部会让网页加载得更快。因为这样可以让页面逐渐加载。
把样式表放到接近底部的问题是它阻止了页面元素的逐渐显示。这样还会导致“flash of unstyled content” 即在样式表加载之前页面内容是以没有样式的形式显示出来的，待加载完样式后，页面重绘，内容一闪即改变了样式表现。

6.把脚本放到底部

把脚本放到尽可能底部的地方，一个原因是让页面逐渐渲染，另一个是实现更好的并行下载。

对于脚本，脚本以下的内容被阻止逐渐加载了，因为只有当下载完脚本以后才会下载下面的内容，第二个脚本引起的问题是阻止平行下载。 “http/1.1 specification”建议浏览器对一个域名， 同一时间下载数不超过2个（按：实际监测发现一般有超过2个），我曾经让ie并行下载100个图片。 当脚本正在下载的时候，浏览器不会开始下载任何东西。

7.避免css expressions

css expressions 是一个有力（和危险）的方式动态的改变css的属性。他们自ie5就开始被支持，举个例子，用css expression可以让背景色每个小时轮换一次。但是被非ie浏览器忽略的。

background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00″ );

expressions的问题就在与它的计算频率绝对超出我们的想象，甚至当我们移动鼠标，都会引起页面的重绘！

下面是举例页面

减少css expressions计算次数的一个方法就是使用一次性的expressions。 当第一次expression计算出一个明确的值，就让样式等于这个值，不再变动。如果样式的属性一定要动态的改变，就用时间句柄吧！

8.让脚本和样式外延

Javascript和CSS应该是外部调用还是内嵌呢？
用外部调用文件的方式更快，因为他们是可以被缓存的，如果是内嵌在页面中他们就无法被缓存了！想想如果用户要在你的网站看很多很多的页面，如果都是使用同一个外部脚本和样式，那么他们一旦被缓存，就再也不需要下载了，这样会给你带来很大的潜在好处。

9.减少DNS查询

10.减小脚本体积

有两个比较流行的工具是用来减小脚本的体积的–JSMin和YUI Compressor。（按：这个压缩和Gzip压缩是不一样的，Gzip是传输压缩，这个是代码压缩）

11.避免重定向

重定向会减慢用户体验，它会延迟所有的东西直至到达新页面。一个最浪费的重定向经常会发生而我们的开发者又会经常忽略的就是比如 http://astrology.yahoo.com/astrology的结果是重定向到http://astrology.yahoo.com /astrology/ 在Apache里用Alias 或者mod_rewrite或者DirectorySlash解决。
从一个旧网站跳转到新网站也是经常要用到重定向，还有就是连接一个网站中的不同部分和在某些情况下（比如不同浏览器，不同的用户帐号类型，等等）的用户导 向。用重定向很简单，而且只需要一点额外的代码，虽然在这些情况下用重定向减少了开发者的复杂度，但它降低了用户的体验，变通的做法是用Alias和 mod_rewrite如果两个部分是在同一主机上的话，如果是由域名变更引起的重定向，变通的做法是通过Alias或mod_rewrite创建一个 CNAME（一个DNS记录，创建一个别名，从一个域名指向另一个域名）

12.去掉重复的脚本

（按：简单的说，同一个脚本如果被调用多次，浏览器并不会忽略后续的脚本，而总是覆盖加载，覆盖运行，这样会增加开销）

13.配置ETags

ETags（Entity tags）是服务器和浏览器的一个功能，它用来判断浏览器缓存里的元素是否和原来服务器上的一致。ETags比last-modified date更具有弹性，它用一个独一无二的字符串来标识一个元素的版本。
源服务器用响应头里的ETag来特定一个元素的ETag：
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: “10c24bc-4ab-457e1c1f”
Content-Length: 12195
之后，如果浏览器要验证这个元素，它就会用If-None-Match头来回传ETag到源服务器。如果符合的话，一个304状态的代码就会从源服务器返回到浏览器，这样源服务器就节省了传输具体数据的开销。
GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: “10c24bc-4ab-457e1c1f”
HTTP/1.1 304 Not Modified

用Etags的问题就在于它会标识那个特定的服务器，如果换了服务器，Etags也就失去了原有的功能，但是这种现在在网络上太常见了，因为我们经常用服务器集群。默认情况下，Apache和IIS会在Etag中内嵌数据，这样会动态减少验证成功的机会。

Apache1.3和2.x的ETag格式是inode-size-timestamp。虽然一个文件可能在不同服务器的同一个目录，同样的大小，安全级，时间戳等等，它的inode会随着服务器的不同而不同。

IIS5.0和6.0有同样类似Etags的东西，叫时间戳：ChangeNumber（更改号），更改号是一个用来追踪IIS配置变化的计数器，ChangeNumber在不同IIS服务器之间是不一样的。

它最终的问题就是，IIS和Apache产生的Etags会在不同服务器之间无法匹配，这样我们的浏览器就无法得到我们期待的304响应，而给我们 的是一个普通的200响应，和正常的数据流。如果你的网站只有一个服务器还无所谓，如果是集群，而你用的是默认的ETag配置，你的用户就会获得更慢的页 面，你的服务器也会有更高的负载，消耗更大的带宽资源，代理也无法高效缓存你的内容，甚至即使你有一个长时间过期的头部（按：见第三条规则），也不会阻止 它重新载入内容。

如果你不想发挥Etags提供的这个弹性验证模型的优势，你最好关掉它。Apache中关掉它的方法是在Apache的配置文件中写这么一句：
FileETag none

14.让Ajax缓存

人们会问这些规则同样适用于web2.0吗？当然！这个规则是我在雅虎工作做web2.0后得出的第一条规则。

Ajax的一个好处是它会给你实时的回馈，因为它和后台的服务器是异步传输的，然而，用Ajax并不能保证你的用户不用无聊的拨弄手指头来等待这个 回馈，在很多应用中，用户是否需要等待取决于Ajax是怎么用的，举例说，在一个基于网页的邮件客户端，用户会持续等待Ajax的回馈来搜索符合他的标准 的邮件信息。记住“异步”并不意味着“实时”。让它缓存的方式同样是加一个过期头部。