之前只是听人说过React，最近下定决心仔细学习一下react，发现这个东西真的很牛逼，很好学，也很好用，先给出几个学习链接
amaze还可以，不过我觉得react-bootstrap应该更好
最近学习了一个通讯录的小demo，总结了一些东西
折腾了一下午，完成服务器翻墙设置
据说最好选择旧金山节点
我自己试的是纽约的速度好
$ apt-get update
$ apt-get install python-pip
$ pip install shadowsocks
my_server_ip和password填写自己的
{
"server":"my_server_ip",
"server_port":8388,
"local_address": "127.0.0.1",
"local_port":1080,
"password":"mypassword",
"timeout":300,
"method":"rc4-md5",
"fast_open": false
}
ssserver -c /etc/shadowsocks.json -d start
$ dpkg-reconfigure tzdata
并且可以查看记录
$ cat /var/log/shadowsocks.log
需要注意的就是，记得从GFWList更新PAC
真是奇葩，一直更新PAC不成功，害我用其他方法，今天试了一下，再添加同样的一个服务器就能够更新成功了
详细内容可查看
http://www.w3cplus.com/css/A-pixel-is-not-a-pixel-is-not-a-pixel.html
在retina屏幕 1px(逻辑像素) = 4dx(物理像素)
最佳viewport
<meta name="viewport" content="width=device-width, initial-scale=1,user-scalable=no">
学习ing
居中
div.center1{
position: absolute;
top:50%;
left: 50%;
transform: translate(-50%,-50%);
-webkit-transform:translate(-50%,-50%);
}
div.center2{
display: flex;
display: -webkit-flex;
justify-content: center;
align-items: center;
}
请移步 http://www.w3cplus.com/node/45
写的很好
由于做微信公众平台的时候需要根据经纬度获取地址，所以才有这个，本来没什么好写的，可是由于没做过php解析json对象，所以还是吃了点小亏，写下来记录一下
直接给出链接 http://developer.baidu.com/map/index.php?title=webapi/guide/webservice-geocoding
在该例子中需要通过经纬度获取地址
api链接 http://api.map.baidu.com/geocoder/v2/?ak=百度应用&location=经度,纬度&output=json&pois=0;
不需要回调函数
通过该地址返回的json数据如下
{
status: 0,
result: {
location: {
lng: 112.99999999488,
lat: 35.999999889577
},
formatted_address: “山西省长治市长治县东师线”,
business: “”,
addressComponent: {
city: “长治市”,
country: “中国”,
direction: “”,
distance: “”,
district: “长治县”,
province: “山西省”,
street: “东师线”,
street_number: “”,
country_code: 0
},
poiRegions: [ ],
sematic_description: “”,
cityCode: 356
}
}
我看了阮一峰的一篇文章 http://www.ruanyifeng.com/blog/2011/01/json_in_php.html
由于返回的是json文本，所以首先要将json文本转换为php数据结构,利用json_decode($json),
$json = '{"a":1,"b":2,"c":3,"d":4,"e":5}';
var_dump(json_decode($json));
经过上述转换，即可得到如下php对象
object(stdClass)#1 (5) {
["a"] => int(1)
["b"] => int(2)
["c"] => int(3)
["d"] => int(4)
["e"] => int(5)
}
所以获取其中对象的时候，可利用如下方式
$json->{'a'}
function getKm($lat1, $lng1, $lat2, $lng2)
{
if($lat1 == 0 && $lng1 == 0){
if($lat2 == 0 && $lng2 == 0){
return "0";
}else {
$url = "http://api.map.baidu.com/geocoder/v2/?ak=gGboNqlNjflXCNq0A6ewpSLB&location=" . $lat2 . "," . $lng2 . "&output=json&pois=0";
$json = file_get_contents($url);
$json = json_decode($json);
return $json->{'result'}->{'addressComponent'}->{'city'};
}
}else {
$dis = getKmnum($lat1,$lng1,$lat2,$lng2);
return $dis.'km';
}
}
function getKmnum($lat1, $lng1, $lat2, $lng2)
{
$earthRadius = 6367000; //approximate radius of earth in meters
$lat1 = ($lat1 * pi()) / 180;
$lng1 = ($lng1 * pi()) / 180;
$lat2 = ($lat2 * pi()) / 180;
$lng2 = ($lng2 * pi()) / 180;
$calcLongitude = $lng2 - $lng1;
$calcLatitude = $lat2 - $lat1;
$stepOne = pow(sin($calcLatitude / 2), 2) + cos($lat1) * cos($lat2) * pow(sin($calcLongitude / 2), 2);
$stepTwo = 2 * asin(min(1, sqrt($stepOne)));
$calculatedDistance = $earthRadius * $stepTwo;
$dis = ceil(round($calculatedDistance) / 1000);
return $dis;
}
在讨论浏览器优化之前，首先我们先分析下从客户端发起一个HTTP请求到用户接收到响应之间，都发生了什么？知己知彼，才能百战不殆。这也是作为一个WEB开发者，为什么一定要深入学习TCP/IP等网络知识。
当用户发起一个HTTP请求时，首先客户端将与服务端之间建立TCP连接，成功建立连接后，服务端将对请求进行处理，并对客户端做出响应，响应内容一般包括响应主体。
我的上一篇文章中对这个有详细的介绍
为了进行可靠的数据传输，TCP在进行发送数据之前，会进行TCP三次握手，以此确定接收方能够成功收取传输的数据，而建立连接的过程，必然是要耗费系统资源，以及时间资源的。
当服务端接收到客户端发送来的请求之后，如果请求内容是静态资源，服务端会从硬盘中取出静态资源，然后将静态资源放在响应主体中，发送给客户端。如果是动态资源，服务端首先取出资源，并通过业务逻辑操作，动态生成最终的响应主体，然后发送给客户端。
客户端接受到服务端传输过来的网络资源，然后进行渲染，绘制等，最终展示给用户。
通过简单的了解，我们了解到TCP建立连接是有资源消耗，时间消耗的，那么如果我们无需每次简历TCP连接，那是否可以提高网站的性能呢？答案是肯定的。
优化点1：减少TCP连接
我们知道，在获取资源的时候，以获取速度从慢到快是：网络资源->本地硬盘资源->本地内存资源。而网络资源也分硬盘资源以及内存资源。并且网络资源的传输，也是有相当大的时延的。
优化点2：对数据进行缓存
本篇文章主要说的优化点是与HTTP首部有关的优化，或者说是与浏览器端有关的优化，其它优化这里暂不赘述。
HTTP连接设计之初是请求-响应-关闭，也就是每建立一次HTTP连接，只能进行一次资源请求，当需要在同一目标服务器上获取多个资源的时候，就需要多次建立HTTP连接，而这个多次建立连接的过程，便降低了网站的性能。
于是，出现了Connection:Keep-Alive，人称持久连接。Keep-Alive避免了建立或者说重新建立连接的过程，减少了HTTP连接。
而与此配套的有Keep-Alive:timeout=120,max=5
其中,timeout=120 是指这个TCP通道保持120S，max=5 指这个TCP通道最多接收5个HTTP请求，之后便自动关闭该连接。
Last-Modified首部是服务端对客户端的HTTP响应所加的一个与缓存有关的HTTP首部，该首部标记了所请求资源在服务端的最后修改时间。类似：
Last-Modified : Fri , 12 May 2015 13:10:33 GMT
当客户端发现HTTP响应头中有Last-Modified，会对资源进行缓存，在下次请求资源时，在HTTP请求头中添加If-Modified-Since首部，首部中将会添加上次成功请求资源时响应头部的Last-Modified属性值，即：
If-Modified-Since : Fri , 12 May 2015 13:10:33 GMT
当服务端接收到的HTTP请求中，发现有If-Modified-Since头部时，会将该属性值与请求资源的最后修改时间进行比对，如果最后修改时间与该属性值一致时，服务端会返回一个304 Not Modified响应，该响应中不包括响应实体。浏览器收到304的响应后，会进行重定向，获取本地缓存资源。如果最后修改时间与该属性值不一致，则会从服务端重新获取资源，做出200响应。
ETag其实与Last-Modified是差不多的方式，但是ETag并没有选择以时间作为标记，而是对所请求文件进行某些算法来生成一串唯一的字符串，作为对某一文件的标记。当收到客户端对某一资源的请求时，服务端在响应时，添加ETag首部,如下：
ETag:W/"a627ff1c9e65d2dede2efe0dd25efb8c"
当客户端发现ETag头部时，同样会对资源进行缓存，并在下次请求时，在请求头部添加If-None-Match，如：
If-None-Match:W/"a627ff1c9e65d2dede2efe0dd25efb8c"
当服务端收到请求中含有该头部时，会使用同样的ETag生成算法对文件ETag进行计算，并与If-None-Match属性值进行比对，如果一致，则返回一个304 Not Modified响应，基本与上一种方式是一致的。
上述两种方式中，每次请求资源时，虽然在有缓存的情况下，选择缓存进行渲染绘制，但是在这之前还是发起了一次HTTP请求，虽然并没有真实的响应实体，但是依然会造成一些资源消耗。而Expires与上述两种方式使用了不同的思路。
当服务端希望客户端浏览器对某一资源进行缓存时，为了免去客户端每次都要询问自己：我上次的缓存现在还能用吗？所以，服务端选择了放权。只去告诉浏览器，我这次给你的资源你可以用多长时间，在这个时间段内，你可以一直使用它，无需每次咨询我。而服务端就是通过Expires属性来告诉客户端浏览器可以多长时间内不需要询问服务端。如下：
Expires:Thu, 19 Nov 2015 15:00:00 GMT
当客户端在响应首部中发现该属性值时，便会将该资源缓存起来，而缓存的过期时间即是Expires中的时间。在这个时间段内，浏览器完全自主。
但是，Expires有一个不足的地方是，如果服务端时间与客户端本地时间不统一时，可能服务端让客户端可以对该资源缓存一个小时，而客户端本地时间比服务端时间快了两个小时，那就意味着，所有缓存都将不会生效。
于是有了弥补该不足的一个属性，即：Cache-Control。如果服务端在响应首部添加该属性时，客户端将直接使用该属性值来生成本地时间的缓存过期时间，这样便解决了这个问题，如下：
Cache-Control:max-age=3600
如果客户端在2015年10月01日13时00分00秒收到该响应时，便会加上3600秒也就是2015年10月01日14时00分00秒作为缓存过期时间。如果响应头部既有Expires和Cache-Control，浏览器会首选Cache-Control。
这里，基本上说的都是与HTTP首部有关的网站性能优化。本文主要是在对《构建高性能WEB站点. 郭欣著》中第六章浏览器缓存的学习总结笔记。这本书对于WEB站点的优化，从各个层面都做了很详尽的讲解，确实是一本很棒的书，也在这里感谢HQBOSS的推荐。
原文作者：我才是二亮
原文链接：http://www.2liang.me/archives/264
转载必须在正文中标注并保留原文链接、作者等信息。
这个主题用的太好了，包括第三方插件安装也很方便，最近我把这个全部弄好了
安装依照 http://theme-next.iissnan.com/ 这个的教程
在查找URL加载过程时候，无意在segmentfault看到一个关于淘宝的加载过程，觉得挺好的，又觉得内容比较多，就单开一篇文章，直接转载那个答案
你发现快要过年了，于是想给你的女朋友买一件毛衣，你打开了www.taobao.com。这时你的浏览器首先查询DNS服务器，将www.taobao.com转换成ip地址。不过首先你会发现，你在不同的地区或者不同的网络（电信、联通、移动）的情况下，转换后的ip地址很可能是不一样的，这首先涉及到负载均衡的第一步，通过DNS解析域名时将你的访问分配到不同的入口，同时尽可能保证你所访问的入口是所有入口中可能较快的一个(这和后文的CDN不一样)。
你通过这个入口成功的访问了www.taobao.com的实际的入口ip地址。这时你产生了一个PV，即Page View，页面访问。每日每个网站的总PV量是形容一个网站规模的重要指标。淘宝网全网在平日(非促销期间)的PV大概是16-25亿之间。同时作为一个独立的用户，你这次访问淘宝网的所有页面，均算作一个UV（Unique Visitor用户访问）。最近臭名昭著的12306.cn的日PV量最高峰在10亿左右，而UV量却远小于淘宝网十余倍，这其中的原因我相信大家都会知道。
因为同一时刻访问www.taobao.com的人数过于巨大，所以即便是生成淘宝首页页面的服务器，也不可能仅有一台。仅用于生成www.taobao.com首页的服务器就可能有成百上千台，那么你的一次访问时生成页面给你看的任务便会被分配给其中一台服务器完成。这个过程要保证公正、公平、平均(暨这成百上千台服务器每台负担的用户数要差不多)，这一很复杂的过程是由几个系统配合完成，其中最关键的便是LVS，Linux Virtual Server，世界上最流行的负载均衡系统之一，正是由目前在淘宝网供职的章文嵩博士开发的。
经过一系列复杂的逻辑运算和数据处理，用于这次给你看的淘宝网首页的HTML内容便生成成功了。对web前端稍微有点常识的童鞋都应该知道，下一步浏览器会去加载页面中用到的css、js、图片等样式、脚本和资源文件。但是可能相对较少的同学才会知道，你的浏览器在同一个域名下并发加载的资源数量是有限制的，例如ie6-7是两个，ie8是6个，chrome各版本不大一样，一般是4-6个。我刚刚看了一下，我访问淘宝网首页需要加载126个资源，那么如此小的并发连接数自然会加载很久。所以前端开发人员往往会将上述这些资源文件分布在好多个域名下，变相的绕过浏览器的这个限制，同时也为下文的CDN工作做准备。
据不可靠消息，在双十一当天高峰，淘宝的访问流量最巅峰达到871GB/S。这个数字意味着需要178万个4mb带宽的家庭宽带才能负担的起，也完全有能力拖垮一个中小城市的全部互联网带宽。那么显然，这些访问流量不可能集中在一起。并且大家都知道，不同地区不同网络(电信、联通等)之间互访会非常缓慢，但是你却发现很少发现淘宝网访问缓慢。这便是CDN，Content Delivery Network，即内容分发网络的作用。淘宝在全国各地建立了数十上百个CDN节点，利用一些手段保证你访问的(这里主要指js、css、图片等)地方是离你最近的CDN节点，这样便保证了大流量分散已经在各地访问的加速。
这便出现了一个问题，那就是假若一个卖家发布了一个新的宝贝，上传了几张新的宝贝图片，那么淘宝网如何保证全国各地的CDN节点中都会同步的存在这几张图片供用户使用呢？这里边就涉及到了大量的内容分发与同步的相关技术。淘宝开发了分布式文件系统TFS(taobao file system)来处理这类问题。
好了，这时你终于加载完了淘宝首页，那么你习惯性的在首页搜索框中输入了’毛衣’二字并敲回车，这时你又产生了一个PV，然后，淘宝网的主搜索系统便开始为你服务了。它首先对你输入的内容基于一个分词库进行的分词操作。众所周知，英文是以词为单位的，词和词之间是靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思。例如，英文句子I am a student，用中文则为：“我是一个学生”。计算机可以很简单通过空格知道student是一个单词，但是不能很容易明白“学”、“生”两个字合起来才表示一个词。把中文的汉字序列切分成有意义的词，就是中文分词，有些人也称为切词。我是一个学生，分词的结果是：我 是 一个 学生。
进行分词之后，还需要根据你输入的搜索词进行你的购物意图分析。用户进行搜索时常常有如下几类意图：
(4)确定型：已经做了基本决定，重点考察某个对象。Query例如：”诺基亚N97″，”IBM T60″。通过对你的购物意图的分析，主搜索会呈现出完全不同的结果来。
之后的数个步骤后，主搜索系统便根据上述以及更多复杂的条件列出了搜索结果，这一切是由一千多台搜索服务器完成。然后你开始逐一点击浏览搜索出的宝贝。你开始查看宝贝详情页面。经常网购的亲们会发现，当你买过了一个宝贝之后，即便是商家多次修改了宝贝详情页，你仍然能够通过‘已买到的宝贝’查看当时的快照。这是为了防止商家对在商品详情中承诺过的东西赖账不认。那么显然，对于每年数十上百亿比交易的商品详情快照进行保存和快速调用不是一个简单的事情。这其中又涉及到数套系统的共同协作，其中较为重要的是Tair，淘宝自行研发的分布式KV存储方案。
然后无论你是否真正进行了交易，你的这些访问行为便忠实的被系统记录下来，用于后续的业务逻辑和数据分析。这些记录中访问日志记录便是最重要的记录之一，但是前边我们得知，这些访问是分布在各个地区很多不同的服务器上的，并且由于用户众多，这些日志记录都非常庞大，达到TB级别非常正常。那么为了快速及时传输同步这些日志数据，淘宝研发了TimeTunnel，用于进行实时的数据传输，交给后端系统进行计算报表等操作。
你的浏览数据、交易数据以及其它很多很多的数据记录均会被保留下来。使得淘宝存储的历史数据轻而易举的便达到了十数甚至更多个PB(1PB=1024TB=1048576GB)。如此巨大的数据量经过淘宝系统1:120的极限压缩存储在淘宝的数据仓库中。并且通过一个叫做云梯的，由2000多台服务器组成的超大规模数据系统不断的进行分析和挖掘。
从这些数据中淘宝能够知道小到你是谁，你喜欢什么，你的孩子几岁了，你是否在谈恋爱，喜欢玩魔兽世界的人喜欢什么样的饮料等，大到各行各业的零售情况、各类商品的兴衰消亡等等海量的信息。
说了这么多，其实也只是叙述了淘宝上正在运行的成千上万个系统中的寥寥几个。即便是你仅仅访问一次淘宝的首页，所涉及到的技术和系统规模都是你完全无法想象的，是淘宝2000多名顶级的工程师们的心血结晶，其中甚至包括长江学者、国家科学技术最高奖得主等众多大牛。同样，百度、腾讯等的业务系统也绝不比淘宝简单。你需要知道的是，你每天使用的互联网产品，看似简单易用，背后却凝聚着难以想象的智慧与劳动。
在segmentfault上面找到了我想要的答案
参考《What really happens when you navigate to a URL》中写到的
详细介绍如下，转载自 http://blog.163.com/mapingtao@126/blog/static/82837017201031422424678/
导航的第一步是通过访问的域名找出其IP地址。DNS查找过程如下：
DNS有一点令人担忧，这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：
因为像Facebook主页这样的动态页面，打开后在浏览器缓存中很快甚至马上就会过期，毫无疑问他们不能从中读取。
所以，浏览器将把一下请求发送到Facebook所在的服务器：
GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 这个请求定义了要读取的URL： “http://facebook.com/”。 浏览器自身定义 (User-Agent 头)， 和它希望接受什么类型的相应 (Accept and Accept-Encoding 头). Connection头要求服务器为了后边的请求不要关闭TCP连接。
请求中也包含浏览器存储的该域名的cookies。可能你已经知道，在不同页面请求当中，cookies是与跟踪一个网站状态相匹配的键值。这样cookies会存储登录用户名，服务器分配的密码和一些用户设置等。Cookies会以文本文档形式存储在客户机里，每次请求时发送给服务器。
用来看原始HTTP请求及其相应的工具很多。作者比较喜欢使用fiddler，当然也有像FireBug这样其他的工具。这些软件在网站优化时会帮上很大忙。
除了获取请求，还有一种是发送请求，它常在提交表单用到。发送请求通过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=85)。发送请求在请求正文头之后发送其参数。
像“ http://facebook.com/ ”中的斜杠是至关重要的。这种情况下，浏览器能安全的添加斜杠。而像“http://example.com/folderOrFile ”这样的地址，因为浏览器不清楚folderOrFile到底是文件夹还是文件，所以不能自动添加斜杠。这时，浏览器就不加斜杠直接访问地址，服务器会响应一个重定向，结果造成一次不必要的握手。
图中所示为Facebook服务器发回给浏览器的响应：
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
服务器给浏览器响应一个301永久重定向响应，这样浏览器就会访问“http://www.facebook.com/” 而非“http://facebook.com/”。
为什么服务器一定要重定向而不是直接发会用户想看的网页内容呢？这个问题有好多有意思的答案。
其中一个原因跟搜索引擎排名有关。你看，如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是两个网站，结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下。
还有一个是用不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。
现在，浏览器知道了“ http://www.facebook.com/ ”才是要访问的正确地址，所以它会发送另一个获取请求：
GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com
头信息以之前请求中的意义相同。
服务器接收到获取请求，然后处理并返回一个响应。
这表面上看起来是一个顺向的任务，但其实这中间发生了很多有意思的东西- 就像作者博客这样简单的网站，何况像facebook那样访问量大的网站呢！
Web 服务器软件
web服务器软件（像IIS和阿帕奇）接收到HTTP请求，然后确定执行什么请求处理来处理它。请求处理就是一个能够读懂请求并且能生成HTML来进行响应的程序（像ASP.NET,PHP,RUBY…）。
举个最简单的例子，需求处理可以以映射网站地址结构的文件层次存储。像http://example.com/folder1/page1.aspx这个地址会映射/httpdocs/folder1/page1.aspx这个文件。web服务器软件可以设置成为地址人工的对应请求处理，这样page1.aspx的发布地址就可以是http://example.com/folder1/page1。
请求处理
请求处理阅读请求及它的参数和cookies。它会读取也可能更新一些数据，并讲数据存储在服务器上。然后，需求处理会生成一个HTML响应。
所有动态网站都面临一个有意思的难点 -如何存储数据。小网站一半都会有一个SQL数据库来存储数据，存储大量数据和/或访问量大的网站不得不找一些办法把数据库分配到多台机器上。解决方案有：sharding （基于主键值讲数据表分散到多个数据库中），复制，利用弱语义一致性的简化数据库。
委托工作给批处理是一个廉价保持数据更新的技术。举例来讲，Fackbook得及时更新新闻feed，但数据支持下的“你可能认识的人”功能只需要每晚更新（作者猜测是这样的，改功能如何完善不得而知）。批处理作业更新会导致一些不太重要的数据陈旧，但能使数据更新耕作更快更简洁。
图中为服务器生成并返回的响应：
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
2b3Tn@[...]
整个响应大小为35kB，其中大部分在整理后以blob类型传输。
内容编码头告诉浏览器整个响应体用gzip算法进行压缩。
关于压缩，头信息说明了是否缓存这个页面，如果缓存的话如何去做，有什么cookies要去设置（前面这个响应里没有这点）和隐私信息等等。
请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现，而不是以文件形式下载它。浏览器会根据报头信息决定如何解释该响应，不过同时也会考虑像URL扩展内容等其他因素。
在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了：
开始根据资源的类型，将资源组织成屏幕上显示的图像，这个过程叫渲染，网页渲染是浏览器最复杂、最核心的功能。
在浏览器显示HTML时，它会注意到需要获取其他地址内容的标签。这时，浏览器会发送一个获取请求来重新获得这些文件。
下面是几个我们访问facebook.com时需要重获取的几个URL：
图片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式样表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名，发送请求，重定向等等…
但不像动态页面那样，静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯，而从缓存中直接读取。服务器的响应中包含了静态文件保存的期限信息，所以浏览器知道要把它们缓存多长时间。还有，每个响应都可能包含像版本号一样工作的ETag头（被请求变量的实体值），如果浏览器观察到文件的版本ETag信息已经存在，就马上停止这个文件的传输。
试着猜猜看“fbcdn.net”在地址中代表什么？聪明的答案是”Facebook内容分发网络”。Facebook利用内容分发网络（CDN）分发像图片，CSS表和JavaScript文件这些静态文件。所以，这些文件会在全球很多CDN的数据中心中留下备份。
静态内容往往代表站点的带宽大小，也能通过CDN轻松的复制。通常网站会使用第三方的CDN。例如，Facebook的静态文件由最大的CDN提供商Akamai来托管。
举例来讲，当你试着ping static.ak.fbcdn.net的时候，可能会从某个akamai.net服务器上获得响应。有意思的是，当你同样再ping一次的时候，响应的服务器可能就不一样，这说明幕后的负载平衡开始起作用了。
在Web 2.0伟大精神的指引下，页面显示完成后客户端仍与服务器端保持着联系。
以Facebook聊天功能为例，它会持续与服务器保持联系来及时更新你那些亮亮灰灰的好友状态。为了更新这些头像亮着的好友状态，在浏览器中执行的JavaScript代码会给服务器发送异步请求。这个异步请求发送给特定的地址，它是一个按照程式构造的获取或发送请求。还是在Facebook这个例子中，客户端发送给http://www.facebook.com/ajax/chat/buddy_list.php一个发布请求来获取你好友里哪个在线的状态信息。
提起这个模式，就必须要讲讲”AJAX”– “异步JavaScript 和 XML”，虽然服务器为什么用XML格式来进行响应也没有个一清二白的原因。再举个例子吧，对于异步请求，Facebook会返回一些JavaScript的代码片段。
除了其他，fiddler这个工具能够让你看到浏览器发送的异步请求。事实上，你不仅可以被动的做为这些请求的看客，还能主动出击修改和重新发送它们。AJAX请求这么容易被蒙，可着实让那些计分的在线游戏开发者们郁闷的了。（当然，可别那样骗人家~）
Facebook聊天功能提供了关于AJAX一个有意思的问题案例：把数据从服务器端推送到客户端。因为HTTP是一个请求-响应协议，所以聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。
这些情况发生时长轮询是个减轻服务器负载挺有趣的技术。如果当被轮询时服务器没有新消息，它就不理这个客户端。而当尚未超时的情况下收到了该客户的新消息，服务器就会找到未完成的请求，把新消息做为响应返回给客户端。
转载 http://www.w3cfuns.com/article-1283-1.html
《高性能网站建设指南》，对作者提出的前端性能优化的14个规则获益匪浅，为了让自己印象更深刻点，决定作此文，当做学习笔记也好，知识总结也罢，总归看过的东西要让自己很好地掌握很好地运用起来才是王道。在解读这些规则的同时，我会用我一年半多的移动网站开发经历提出一些针对移动网站的优化建议。
前端优化的黄金准则指导着前端页面的优化策略：只有10%-20%的最终用户响应时间花在接受请求的HTML文档上，剩下的80%-90%时间花在为HTML文档所引用的所有组件（图片、脚本、样式表等）进行的HTTP请求上。因此，改善响应时间的最简单途径就是减少组件的数量，并由此减少HTTP请求的数量。当然很多人就会说，既然这样，那我们就减少页面组件的数量不就OK了吗？那你试试，你会掀起一场性能优化和产品设计之间的大PK。
<a href=”用户跳转页面URL”>
<div class=”定义用户icon显示的样式表”></div>
</a>
<a href=”购物车跳转页面URL”>
<div class=” 定义用户icon显示的样式表”></div>
</a>
这种方式无可厚非的，但是两张图片就有两个HTTP请求，这明显是增加了页面中的HTTP请求。那么我们可以把这两个HTTP请求变成一个吗？
答案当然是可以的，这就是图片地图：允许在一张图片上关联多个URL，而目标URL的选择取决于用户单击了图片上的哪个位置。
这样上面京东两个图标合并成一张图片，这样图片的HTTP请求就减少了一个。
示例代码如下：
<img src=合并后的图片>
<map name=”map1”>
<areashape=”rect” coords=”0,0,40,40” href=”用户跳转页面URL”>
<areashape=”rect” coords=”50,0,90,40” href=”购物车跳转页面URL”>
</map>
不过图片地图只支持矩形形状，其他形状不支持。
CSS Sprites一句话：将多个图片合并到一张单独的图片，这样就大大减少了页面中图片的HTTP请求。
直接将图片包含在Web页面中而无需进行HTTP请求。但是此种方法存在明显缺陷：
但是样式表、脚本也不是分割越细越好，因为没多引用一个样式表就增加一次HTPP请求，能合并的样式表尽量合并。一个网站有一个公用样式表定义，每个页面只要有一个样式表就OK啦。
通过以上四个努力之后，你会发现你的网页响应时间最多能减少一半，这不是作者说大话，也不是我狂吹，我亲手用我的移动网站首页做了一个尝试，本地测试之后响应时间能减少40%左右。所以减少页面HTTP请求数量，是一个很重要的原则。遵循此原则可以同时改善首次访问和后续访问的响应时间，而每一个网站的首次响应时间会决定用户之后还来不来的重要原因。
什么叫内容发布网络（CDN）？它是一组分布在多个不同地理位置的Web服务器，用于更加有效地向用户发布内容。主要用于发布页面静态资源：图片、css文件、js文件等。如此，能轻易地提高响应速度。关于CDN的具体详细原理以及优缺点，各位可以自行询问度娘或者google。
下面这个比较全
http://www.bootcdn.cn/
浏览器使用缓存来减少HTTP请求的数据，并减小HTTP响应的大小，使页面加载更快。Web服务器使用Expires头来告诉浏览器它可以使用一个组件的当前副本，直到指定的deadline为止。HTTP规范中称此头为：在这一时间之后响应被认为失效。个人对这块表示不想使用，其实就是一句话，把一些css、js、图片在首次访问的时候全部缓存到浏览器本地，从我做移动网站的过程中发现，其实没有这么复杂，完全可以使用HTML5提供的本地缓存机制就OK了。关于HTML5本地缓存机制，各位可以查阅相关资料。后续我也会对HTML5的缓存机制进行介绍的。
书中关于压缩从gzip压缩方式到如何压缩讲了很多，我想直接跳过，对于做PC网站或者移动网站来说，急需要压缩的是css文件和js文件，至于如何压缩，网上有很多在线工具，去挑选一个自己用的顺手看的顺眼的就好，当然也有人选择对HTML进行压缩，这样也可以。但是实际工作中我没有这么做。之所谓没有这么做，是因为我觉得很麻烦。不要鄙视我，毕竟我不是一个真正意义上的前端工程师，哈哈！
如果将css样式定义放在页面中或者页面底部，会出现短暂白屏或者某一区域短暂白板的情况，这和浏览器的运营机制有关的，不管页面如何加载，页面都是逐步呈现的。所以在每做一个页面的时候，用Link标签把每一个样式表定义放在head中。
浏览器在加载css文件时，页面逐步呈现会被阻止，直到所有css文件加载完毕，所以要把css文件的引用放到head中去，这样在加载css文件时不会组织页面的呈现。但是对于js文件，在使用的时候，它下面所有也页面内容的呈现都会被阻塞，将脚本放在页面越靠下的地方，就意味着越多的内容能够逐步呈现。
CSS表达式是动态玩CSS的一种很强大的方式，但是强大的同时也存在很高的危险性。因为css表达式的频繁求值会导致css表达式性能低下。如果真想玩css表达式，可以选用只求值一次的表达式或者使用事件处理来改变css的值。
内联js和css其实比外部文件有更快的响应速度，那为什么还要用外部呢？因为使用外部的js和css可以让浏览器缓存他们，这样不仅HTML文档大小减少，而且不会增加HTTP请求数量。另外，使用外部js和css可以提高组件的可复用性。
DNS查询有时间开销，通常一个浏览器查找一个给定主机名的IP地址需要20-120ms。缓存DNS：缓存DNS查询可以很好地提高网页性能，一旦缓存了DNS查询，之后对于相同主机名的请求就无需进行再次的DNS查找，至少短时间内不需要。所以在使用页面中URL、图片、js文件、css文件等时，不要使用过多不同的主机名。
如何精简？
其实W3Cfuns已经给大家准备好精简JS所需的所有工具“前端神器”，这点W3Cfuns为大家做的很不错，在这个规则里我们就用到“JS压缩/混淆/美化工具”
最初始的精简方式：就是移除不必要的字符减小js文件大小，改善加载时间。包括所有的注释、不必要的空白字符。
高级一点的精简方式就是：混淆。
它不但会移除不必要的字符，还会改写代码，比如函数和变量的名字会被改成很短的字符串，这样使js代码更简练更难阅读。
但是我一般很少使用混淆，一个现在互联网时代，代码没有必要整的那么神秘，大可以大家一起share，天下代码一起抄，只要抄出自己的特色就ok了。
而且一旦使用混淆，对于js代码的维护和调试都很复杂，因为有时候混淆之后的js代码完全看不懂。其实实际开发过程中，从文件大小和代码可复用性来说，不仅仅是js代码需要精简，css代码一样也很需要精简。
重定向的英文是Redirect，用于将用户从一个URL重新跳转到另一个URL。
最常见的Redirect就是301和302两种。
关于重定向的性能影响这里就不说了，自行查阅相关资料吧。
在我们实际开发中避免重定向最简单也最容易被忽视的一个问题就是，设置URL的时候，最后的“/”，有些人有时候会忽略，其实你少了“/”，这时候的URL就被重定向了，所以在给页面链接加URL的时候切记最后的“/”不可丢。
重复的js代码除了有不必要的HTTP请求之外，还会浪费执行js的时间。
将你使用的js代码模块化，可以很好地避免这个问题，至于js模块化如何实现，现在有很多可以使用的开源框架，我用的比较多的是我们公司玉伯的Sea.js。
Etag（Entity Tag），实体标签，是Web服务器和浏览器用户确认缓存组件的有效性的一种机制。写的很复杂，对我这种非专业的前端开发人员来说，有点过了，关于这个原则有兴趣的自己看吧。
针对页面中主动的Ajax请求返回的数据要缓存到本地，当然这个是针对短期内不会变化的数据。如果不确定数据变化周期的话，可以增加一个修改标识的判断，我正常处理过程中会给一些Ajax请求返回的数据增加一个MD5值的判断，每次请求会判断当前MD5是否变化，如果变化了取最新的数据，如果不变化，则不变。
噼里啪啦说了一堆，14个规则啊，那我们开发过程中要针对这每一个规则对自己的前端代码做check吗？我反正不这么干，做前端页面，尤其是移动网站的页面，我所记住的准则就是：尽量减少页面大小，尽量降低页面响应时间。在页面性能和交互设计之中找平衡点。
参考 http://www.w3cfuns.com/article-5598566-1-1.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
<style>
.cell{ margin:10px;background-color: #ccc; width:200px; height:200px; color:#457344; }
.center1{text-align: center; line-height: 200px;}
.center1 span{vertical-align: middle;}
</style>
</head>
<body>
<div class="cell center1">
<img src="4.jpg"/>
</div>
<div class="cell center1">
<span>ssssssssss</span>
</div>
</body>
</html>
这种方法使用text-align和vertical-align，line-height来实现居中，不过只适用于行内元素且不兼容IE6，第二种居中将解决IE6兼容问题。
position前面的’‘是用来兼容IE6
.center2{ text-align: center; _position: relative;
line-height: 200px;}
.center2 span{ _position: absolute; top:50%; left:50%;}
.center2 img{_position: relative; top:-50%;left:-50%;
vertical-align: middle; }
因为IE6，7不支持table-cell，所以IE6，7中显示不正常.设置元素的display:inline-block而具有行内元素的特性，因此可用text-align:center使其水平居中。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
<style>
.center4{
display: table-cell; //作为一个表格单元格显示
vertical-align: middle; //垂直方向居中
text-align: center //水平方向居中
}
.center4 div{
width:100px;
padding:10px;
background:#333;
display: inline-block; //兼容IE6，使具有块级元素的特征，能使用text-align使其居中
}
</style>
</head>
<body>
<div class="cell center4">
<div>
居中
</div>
</div>
</body>
</html>
既然IE6，7不支持table-cell,于是干脆使用表格嵌套使其居中，因为td已经默认设置了vertical-align:middle。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Document</title>
<style>
.center5 { text-align: center}
.center5 div{
display: inline-block;
width:100px;
padding: 10px;
background-color: #333;
}
</style>
</head>
<body>
<table >
<tr>
<td class="center5">
<div>
居中
</div>
</td>
<td class="center5">
<div>
居中2
</div>
</td>
</tr>
</table>
</body>
</html>
使用
padding:0;
margin:auto;
转载自DDD的bokehttp://liuxiaofan.com
##问题
一个网站会涉及到很多表单的制作，特别是复选框(checkbox)和单选框(radio)。但是在前端开发过程中，单(复)选框和它们后面的提示文字在不进行任何设置的 情况下，是无法对齐的，而且在Firefox和IE中相差甚大。即使设置了vertical-align:middle，也依然不能完美对齐。
解决办法：
然后去除表单元素的边距。
<input class="inputcheckbox" name="test" value="1" type="checkbox">
<label>测试文字x</label>
将张鑫旭精简了一下 http://www.zhangxinxu.com/wordpress/2010/10/%E9%A1%B5%E9%9D%A2%E9%87%8D%E6%9E%84%E2%80%9C%E9%91%AB%E4%B8%89%E6%97%A0%E5%87%86%E5%88%99%E2%80%9D-%E4%B9%8B%E2%80%9C%E6%97%A0%E5%AE%BD%E5%BA%A6%E2%80%9D%E5%87%86%E5%88%99/
无宽度指的是宽度分离，并不是指没有宽度
使用宽度计算+横向拼接的做法不仅浪费精力、开发成本，最终实现的页面其实也是比较脆弱的。举个实际点的例子，比如新浪微博内容列表布局，用firebug看了下其布局的方式，结果就是定宽的浮动布局。左边头像左浮动，宽度56像素；右侧内容484像素，右浮动。如下图所示：
这是个比较简单的两栏布局，这里宽度限定，左右浮动，这也是目前主流布局方式。但是主流的方法并不一定是最好的方法，就此例子而言，没有左右padding/margin/border等属性，所以右侧栏的宽度(484px)确定貌似还是比较简单的（事实上还是要去量一下，这是可避免的劳力成本）；但是，其扩展性和重用性则完全不及格了，首先，这里的列表不可能放在500像素宽的div中（没有了重用性），日后要是网站改版，总体宽度增加，那么显然，这里的宽度又要重新计算，这就缺少了扩展性；同时，这种浮动布局会带来一些副作用，首先是浮动本身的代码成本，其次是清除浮动所需要的成本。(如下图)
“无宽度”具体指的是没有固定的宽度值（尤其是以px为单位的宽度值，em需看具体情况，%百分值不在其中）
这是比较简单的也是比较基本的两栏布局，一般这种layout我们需要借助一些平时会给我们带来麻烦的，本身带刺的一些CSS属性，那就是float以及position:absolute属性，我在“absolute绝对定位的非绝对定位用法”一文中就多次提到我的这个观点：未设定left/top值的absolute元素和float元素就是两个混蛋近亲，同样的都是“包裹与破坏”，但是，虽然很多时候，这种破坏会给我们带来些麻烦（例如清除浮动造成的高度塌陷的问题），但是，万物皆有两面性，我们有时候可以利用这种破坏的特性来帮助我们进行更加有韧性的布局。
如下图是重构之后的代码
相比原来的代码，只是把头像的56像素宽度左浮动和484像素内容宽度右浮动改成position:absolute和padding-left:76px，然后，实现的效果就是一模一样了，不仅代码量少了，布局也更有扩展性。同时，也不需要什么清除浮动之类的代码了：
整个布局的CSS代码就非常之清爽，没有浮动，没有计算，也没有清除浮动，而且扩展性强。
.abs{position:absolute;}
.pl76{padding-left:76px;}
facebook在个人主页动态列表使用的定位方法：
但是，facebook这里的absolute定位属于标签内定位，外套relative属性限制，好处在于可以直接忽略我上面提到的不少需要注意的细节，且易于理解掌握，但是不足在于CSS代码量，开销，开发成本都比较大。所以，个人权衡来讲，还是直接的外标签裸absolute属性方法更好些。
还有，今天我去看facebook首页好友动态列表的代码，发现了一个很牛逼的方法，float外加table-cell方法（table-cell的宽度上千上万却依然布局良好，很神奇），我琢磨着，可能是因为国外基本上不鸟IE6浏览器的缘故，所以会果敢的使用display:table-cell属性，此方法要想在国内盛行，还需有段时日。
position与float在例子中的表现有所不同，当页面宽度小，右列内容比较多时，两者没有区别。
当页面宽度很大，右列内容所显示的高度比左列小时，就会发现父元素的表格不一致了。使用position时，父元素框架不会被撑开。而使用float时，父元素框架会同样被撑开，显示起来较为美观。
结论：使用float进行宽度自适应会比较好。
之前一直也没怎么区分过作用域链与原型链，本文试图梳理一下参考 http://www.cnblogs.com/lhb25/archive/2011/09/06/javascript-scope-chain.html
在JavaScript中，变量的作用域有全局作用域和局部作用域两种（这个不多解释）
JavaScript里一切都是对象。函数对象和其它对象一样，拥有可以通过代码访问的属性和一系列仅供JavaScript引擎访问的内部属性。其中一个内部属性是[[Scope]]，该内部属性包含了函数被创建的作用域中对象的集合，这个集合被称为函数的作用域链，它决定了哪些数据能被函数访问。
当一个函数创建后，它的作用域链会被创建此函数的作用域中可访问的数据对象填充。例如定义下面这样一个函数：
function add(num1,num2) {
var sum = num1 + num2;
return sum;
}
作用域链图如下
函数add的作用域将会在执行时用到。例如执行如下代码：
var total = add(5,10);
执行此函数时会创建一个称为“运行期上下文(execution context)”的内部对象，运行期上下文定义了函数执行时的环境。每个运行期上下文都有自己的作用域链，用于标识符解析，当运行期上下文被创建时，而它的作用域链初始化为当前运行函数的[[Scope]]所包含的对象。
这些值按照它们出现在函数中的顺序被复制到运行期上下文的作用域链中。它们共同组成了一个新的对象，叫“活动对象(activation object)”，该对象包含了函数的所有局部变量、命名参数、参数集合以及this，然后此对象会被推入作用域链的前端，当运行期上下文被销毁，活动对象也随之销毁。新的作用域链如下图所示：
从作用域链的结构可以看出，在运行期上下文的作用域链中，标识符所在的位置越深，读写速度就会越慢。如上图所示，因为全局变量总是存在于运行期上下文作用域链的最末端，因此在标识符解析的时候，查找全局变量是最慢的。所以，在编写代码的时候应尽量少使用全局变量，尽可能使用局部变量。一个好的经验法则是：如果一个跨作用域的对象被引用了一次以上，则先把它存储到局部变量里再使用。例如下面的代码：
function changeColor(){
document.getElementById("btnChange").onclick=function(){
document.getElementById("targetCanvas").style.backgroundColor="red";
};
}
这个函数引用了两次全局变量document，查找该变量必须遍历整个作用域链，直到最后在全局对象中才能找到。这段代码可以重写如下：
function changeColor(){
var doc=document;
doc.getElementById("btnChange").onclick=function(){
doc.getElementById("targetCanvas").style.backgroundColor="red";
};
}
这段代码比较简单，重写后不会显示出巨大的性能提升，但是如果程序中有大量的全局变量被从反复访问，那么重写后的代码性能会有显著改善。
函数每次执行时对应的运行期上下文都是独一无二的，所以多次调用同一个函数就会导致创建多个运行期上下文，当函数执行完毕，执行上下文会被销毁。每一个运行期上下文都和一个作用域链关联。一般情况下，在运行期上下文运行的过程中，其作用域链只会被 with 语句和 catch 语句影响。
with语句是对象的快捷应用方式，用来避免书写重复代码。例如：
function initUI(){
with(document){
var bd=body,
links=getElementsByTagName("a"),
i=0,
len=links.length;
while(i < len){
update(links[i++]);
}
getElementById("btnInit").onclick=function(){
doSomething();
};
}
}
这里使用width语句来避免多次书写document，看上去更高效，实际上产生了性能问题。
当代码运行到with语句时，运行期上下文的作用域链临时被改变了。一个新的可变对象被创建，它包含了参数指定的对象的所有属性。这个对象将被推入作用域链的头部，这意味着函数的所有局部变量现在处于第二个作用域链对象中，因此访问代价更高了。如下图所示：
因此在程序中应避免使用with语句，在这个例子中，只要简单的把document存储在一个局部变量中就可以提升性能。
另外一个会改变作用域链的是try-catch语句中的catch语句。当try代码块中发生错误时，执行过程会跳转到catch语句，然后把异常对象推入一个可变对象并置于作用域的头部。在catch代码块内部，函数的所有局部变量将会被放在第二个作用域链对象中。示例代码：
另外一个会改变作用域链的是try-catch语句中的catch语句。当try代码块中发生错误时，执行过程会跳转到catch语句，然后把异常对象推入一个可变对象并置于作用域的头部。在catch代码块内部，函数的所有局部变量将会被放在第二个作用域链对象中。示例代码：
try{
doSomething();
}catch(ex){
alert(ex.message); //作用域链在此处改变
}
请注意，一旦catch语句执行完毕，作用域链机会返回到之前的状态。try-catch语句在代码调试和异常处理中非常有用，因此不建议完全避免。你可以通过优化代码来减少catch语句对性能的影响。一个很好的模式是将错误委托给一个函数处理，例如：
try{
doSomething();
}catch(ex){
handleError(ex); //委托给处理器方法
}
优化后的代码，handleError方法是catch子句中唯一执行的代码。该函数接收异常对象作为参数，这样你可以更加灵活和统一的处理错误。由于只执行一条语句，且没有局部变量的访问，作用域链的临时改变就不会影响代码性能了。
一般是定义构造函数时用到，可以认为是针对构造函数的或者说针对构造函数对应的类的
原型链的头部就是Object类/构造函数，如果有构造函数1.prototype = 构造函数2；那么也就有这么一个原型链； Object ==> 构造函数1 ==> 构造函数2
这样的好处是构造函数2对应的类，可以拥有构造函数1 和Object中的属性，js没有对应继承的关键字，所以用原型链来模拟继承的效果
Tip:原型链东西太多了，之后再单开一篇