网站分析

1、www.qq.com

　　在pc端和移动端是分为两套代码来写的。

pc端：

　　布局：整体的布局是从上往下的布局方式，没有特定的两栏、三栏布局，而是从上到下交错式排列。整体的思想是width固定为1000px（无响应式），两边的margin是auto，这样，可以在浏览器大小发生变化时，实现一部分margin的响应式，但是内容没有实现响应式。整体看上去还是比较朴素。

　　用户体验：

搜索。在进入首页，就可以在最上面发现搜狗搜索，这个搜索虽然看上去不错，但是和我的预期是不一样的，点击搜索之后，是随即跳转到了搜索的网站，而不是在站内搜索有用的信息，意义何在？
提供的服务不错。在下拉网页时，可以在右下角发现回到顶部、用户反馈、下载客户端常用功能，避免用户浪费时间寻找。
为什么腾讯首页上的标签页的图片一直在旋转呢？还是有很多问题的。
每一个模块之间对于设计方面亲密性原则把控的不是很好。所以整体看起来会比较混乱，另外，虽然模块比较多，但是每一个模块下展示的数目并不多，如果希望再看多一点内容，唯一办法就是进入相应的栏目，而网易在这一部分就做的很好，提供了‘换一换’的功能。

　　性能：整体加载网页的速度较快，但是也是存在一个问题。首页的加载，发送了各种请求287个。并且去查看图片的请求可以发现多达134个，所以这个请求量还是非常巨大的，因为其中只有部分经常不变的图片使用了雪碧图的方式，还有很多没有使用雪碧图的方式，导致请求量较大。并且雪碧图的合并也是有问题的，占用了较多的空间。

　　js使用：通过查看network，可以发现js的数量为40个左右，还是比较多的，比较好的是大部分js都是经过压缩的，只有一些没有压缩。可以看到www.qq.com首页使用的主要是jquery以及sea.js，前者使用的时1.11左右的版本，可以看出qq首页已经至少3年左右没有改版，而是继续沿用之前的技术，后者是一种cmd模块化解决方案，是阿里的玉伯开源的，但是目前也不是很火的。

　　问题：报错较多。

移动端：

　　布局：移动端使用的就是普通的百分比布局，rem使用的非常少，但是看上去也比较舒服。

　　特点：移动端也是浏览性质的偏多，对于item和图片使用的都是懒加载的方式，当图片还没有请求到的时候，背景是使用的企鹅的logo图片来代替的，所以用户体验较好。但是在后台中可以发现报错比较严重。

　　使用：对于其中的视频使用的也都是html5中的video元素。在没有打开视频进行播放的时候，会在上面有一个div，然后添加一张背景图片用来占位置。技术上使用了react，从app.js可以看得出来。另外，还有stats.js，通过这个js文件，我们可以检测网站的相关性能，如FPS等。

　　问题：导航栏的设计比较奇怪，共有很多的内容，但是如果希望看到更多的内容只能通过滑动的方式，如果可以添加一些按钮，将所有导航铺满全屏，这种形式在体验上可能会好很多。对于链接的下划线其实也是不好的，因为下划线是紧贴着字体下方的，有一种入侵的感觉，我更喜欢的方式还是取消下划线，使用其他hover的方式来代替。

总结:

　　　　在技术上，腾讯的qq.com并没有追求太先进的技术，整体表现也是中规中矩。在体验上，有一些地方做的还是不错。

　　　　移动端的手法也是类似的，即在点击的时候，一个list是一个整体来体现的，而不是单独的，体验还是不错的。

　　　　在登录、注册方面，一个qq号就可以进行登录腾讯的所有产品，这点还是非常赞的。

　　　　问题也是很明显，无论是腾讯的pc端还是移动端，一直呈现加载没有完成的状态。

　　　　整体感受非常的陈旧，没有新颖的感觉。

2、www.163.com

　　同样的，网易的163.com也是分为PC端和客户端来写的。

PC端：

　　布局：网易的布局在代码结构上还是没有问题的，首先使用一个div将所有的内容包裹起来。然后对于最上面的导航条使用铺满的通用方式，对于下面的内容部分使用的是960px的固定宽度，同样margin为auto。整体也是从上到下进行布局的，大多为两栏布局。

　　用户体验：

链接的体验很舒服。网易在这里将所有的hover下划线取消了，并在hover的时候使用网易标志性的红色来代替，看上去会非常舒服，并且在划过的时候可以很明显的感觉到这些都是链接可以点击。也许是一种主观上的偏爱，对于网易的红色非常喜欢。
图片的体验很好。在划过图片时，不仅有 cursor: pointer；并且图片使用了css的动画效果，感觉会舒服很多，这样可以很明显的给你一个反馈：你hover过我了。
回到顶部。和腾讯一样，这里也有回到顶部的功能，因为一般这种门户网站展示性的内容偏多，所以，回到顶部还是很有必要的。
更多内容。网易首页分为了很多模块，包括汽车、娱乐、财经等等等等，但是每一个栏目所能显示的数目有限，比如只能显示5到10条左右，怎么才能看到更多呢？网易的做法是在右下角添加了一个图片按钮（刷新标识），在hover的时候就可以放大，click之后，这些10个左右的内容就会替换，这样，在不用跳转网页的时候就可以看到最新的内容，这个体验是非常棒的。

　　性能：

刷新网页，回发出250个请求左右，因为图片比较多，所以图片就占了很大一部分内容，但是做的比较好的地方在于，在首页中使用了大量的雪碧图，能用的基本上都会使用到。这一点做的非常不错。
在250多个请求中，我们不难发现，这些请求不仅仅有这个网站运行所需要的js文件，还包括了很多其他js文件，我们在network中进行筛选js文件，然后看下面所示：

　　即对于js结尾的文件我们非常容易理解，在右方点进去之后可以看到返回的都是一些项目运行所需要的js代码，但是，还有很多js不是以js结尾的，而是添加了后缀，多是callback等于某个值、mode=2等等等等，点击这些response的数据，我们不难发现，这些返回的数据都是为了填充在首页的数据，并且不是同源的，所以这就是所谓的JSONP来进行跨域的方式，比如其中的index_pic_jsonp.js?INDEX_DATA_PIC_JSON 这个js就是一个跨域请求，返回的数据显示callback后面的这个变量实际上是一个函数，response就是在调用这个函数，然后将一个包含了我们想要的数据的对象。然后我们就可以使用这些数据了，并成功完成了跨域。对于夏敏的几个函数也都是如此，无一例外。我们这里所说的跨域就是指不是同源（同协议、同端口号、同域名）的请求，这样，我们就可以将其他源的数据拿到了。当然，有时候可能不仅仅是通过callback=某一个函数，有时候还会传递一些额外的参数进行更精确的控制: 如

INDEX_NEWS_PROVINCE({"渭南市":{"inc":"http://house.163.com/special/00078GE7/weinan_ws_news_v1.js"},"延安市":{"inc":"http://house.163.com/special/00078GE7/yanan_ws_news_v1.js"},"商洛市":{"inc":"http://house.163.com/special/00078GE7/shangluo_ws_news_v1.js"},"defaultcity":{"inc":"http://house.163.com/special/00078GE7/xian_ws_news_v1.js"},"宝鸡市":{"inc":"http://house.163.com/special/00078GE7/baoji_ws_news_v1.js"},"西安市":{"inc":"http://house.163.com/special/00078GE7/xian_ws_news_v1.js"},"安康市":{"inc":"http://house.163.com/special/00078GE7/ankang_ws_news_v1.js"},"咸阳市":{"inc":"http://house.163.com/special/00078GE7/xianyang_ws_news_v1.js"},"铜川市":{"inc":"http://house.163.com/special/00078GE7/tongchuan_ws_news_v1.js"},"汉中市":{"inc":"http://house.163.com/special/00078GE7/hanzhong_ws_news_v1.js"},"榆林市":{"inc":"http://house.163.com/special/00078GE7/yulin2_ws_news_v1.js"}})

　　当然，有些代码可能就不会使用callback的方式，既然js就是一个请求，那么我完全可以直接在js里写好数据，使用callback只是为了更加精确的确定使用哪一部分数据，如果没有这么精确，那么我们就完全可以直接请求一个js。就像之前在写socket.io的时候，一个src就是一个get请求。

　　并且这些请求往往不是你一进来就发出请求的，很多都是在你滑动页面的过程中，到了某一个版块，比如特定区域的版块如陕西然后再接着发出这么一个跨域的请求，大部分跨域都是www.163.com下面的子域名，如new.163.com，但是这些也都属于跨域，只能通过JSONP这种方式来请求了。

　　在这些js中，我们还会发现其中有一部分并不是js结尾，而是api结尾的，最后也会传递一个参数即callback=某个函数的名称，同样返回数据就是这个函数被调用，传递了某些数据。

　　在网易的netword下我们又打开了xhr，发现xhr下面竟然什么都没有！！！！也就是说，整个页面上的所有数据，都是通过js进行请求的，而没有使用xhr进行请求，即所有的请求都是get请求，毕竟这是用于展示的。

　　在source中，我们就可以看到如下所示的源：

　　其中，只有第一个www.163.com，在对这个接口发出请求的时候不是跨域的，其他的都不是同源的，但是都是和163.com类似的，所以很多采用了JSONP跨域的策略。

js使用：

　　在js的压缩层面来说，做的还是不错的。但是网易目前具体使用的是什么框架、方法还不得而知，在element中，我们可以截取到下面的片段：

　　即对于每一个模块，我们都可以看到在div中有一个属性ne-module，后面是一个js文件，至于什么时候发出请求，发出的请求得到的响应是什么，我们都不得而知，但是我认为也是js请求到的数据包含了网易首页想要填充的内容，这种方法还是第一次见到。。。但是应该也是有懒加载的成分在的，就是当我们不断向下滑的时候，然后发出更多请求，获取数据。

　　pc端js主要使用的都是网易自己封装的框架，没有什么名气的，对于我们使用的主流的框架网易似乎都没有采用。　　

移动端：

　　在布局上主要使用的时百分比布局加rem布局，都是一些比较常规的布局方式。

　　移动端使用的主要就是zepto加上网易自己的一些框架。

　　由于使用在移动端，所以使用了大量的html5的标签，这些具有语义化的标签使用还是我们非常推荐的。

　　另外，在用户体验上，也是单纯的和腾讯比较，网易确实做得不错，的确是一家有态度的企业。

　　在移动端，也是几乎没有没有用到ajax请求，和pc端一样，都是通过js来发送get请求的，并传递一些参数，这里还是可以多学习一下的。

3、www.taobao.com/

pc端：

布局：总体的布局为从上到下的布局，没有特别的规则，和腾讯的非常类似，对于每一个模块宽度限定，为990px，可以看到，这几个网站的做法基本上都是一致的，就是宽度在950px到1000px之间，然后margin设置为 0 auto。另外，淘宝的首页整体的布局颜色为橙色。看上去开始挺舒服的。

用户体验：整体较好，因为阿里巴巴的网站在加载之后，首先整体框架（从上至下）会显示出来，然后如果有更多的内容会开始渲染出来，速度还是比较快的，另外，在上下滑动的过程中，在顶部的淘宝logo和搜索栏会fixed，这样可以方便我们实时进行搜索，这里做的还是不错的。

在导航栏方面，hover之后字体的颜色和背景都会发生变化，体验较好。而对于一般的链接，方式和网易基本上是一致的，都是不会出现难看的下划线（腾讯的为什么有？很难看啊），划过的颜色为特定的黄色。
在图片hover之后，和网易的效果有异曲同工之妙，比如划过之后网易的图片会放大，而淘宝会改变图片的透明度。
另外一点比较不错的就是，在滑动的过程中，在屏幕的右边会给予及时的当前分类的反馈，这个效果和segmentfault的目录是非常类似的，都是非常可取的实践方式。
在进入页面之后，可以发现焦点就focus到了搜索的input框，这是一个非常好的实践方式，因为我们要么进来之后就进行搜索，要么就是选择其他商品，给这个一个focus是永远不会多余的。
还有一个比较贴心的地方在于：进入网站之后，在网站的右上角在推广手机淘宝，即一个二维码，我们只需要扫描这个二维码就可以顺利地下载手机淘宝，当然如果你不喜欢，你还有权利通过八叉将之删除掉，这是做的一个比较贴心的地方。但是啊，我当年喜欢前端其实就是对于广告没有直接的删除权利，如果像淘宝这么做，恐怕我就接触不到前端了，哈哈。
且大多数的产品，我们可以发现会给一个二维码，那么我们就可以很方便的在手机上查看这个商品，在当前二维码流行的时候，这个做的不错！
和很多网站都是一样的，进入之后，会有回到顶部、反馈等，这几乎成了一个PC端网站的标配。

性能：

　　在性能方面，我只能说淘宝做的真是不错。相对于腾讯、网易的首页可能需要很多的内容信息，但是淘宝的也不少啊，第一页全是内容、商品。 但是，进入首页之后，淘宝的请求数最开始也就是68个左右，就算是稳定了下来也不会超过100个请求。当然，如果你一直向下拉，那么请求就会迅速到几百个，但是这种懒加载的方式就很好地保证了首页的加载速度，这对于用户体验是至关重要的！而无论是腾讯还是网易，在进入首页的时候，请求都会直接超过200个，这差距，不言而喻！

　　在图片方面比较不错的就是雪碧图用的很多，但是还是没有完全使用，有一些缺陷！另外，在淘宝首页的底部是一些推荐、管理之类的网站，这些网站也都用了雪碧图的方式，可以很好的减少http请求，增强性能。

　　另外，对于js而言，所有的js文件都是经过了压缩和混淆的，压缩的好处很清楚，就是减少不必要的空格、字符等，这样可以减少需要传输的字节数，而混淆之后，就可以把比较长的变量使用更短的变量来代替，这样，显示也可以减少传递的字节数的。

js使用：

　　可以看到，PC端的淘宝使用的是内部的KISSY框架，虽然在github上只有2000多个star，但是在阿里内部使用的还是比较广泛的，这个框架的好处就是 跨终端、模块化、使用简单的JavaScript框架。

　　其内部的js更新的还是非常快的，今天是8月17日，但是我们可以看到8月15日的js代码，可见内部对js的升级、维护还是很快的。

　　通过看代码，可以发现，在pc端，淘宝对node也是有使用的，但是具体使用的程度还无法做出判断。

　　js代码中，很多都是使用define()这种形式来定义一个模块的，作为前端的模块化，这个在我看腾讯和网易的时候感觉是不一样的。

　　和网易一样，阿里在请求内容的时候，为什么也不使用xhr呢 ? 而是使用js、JSONP的方式？比如我们拿出来一个分析吧：

https://tui.taobao.com/recommend?_ksTS=1502949060247_252&callback=jsonp253&appid=2952&from=PCtaobao

　　实际上在network下的js中，我们只能看到?_ksTS=1502949060247_252&callback=jsonp253&appid=2952&from=PCtaobao，至于前面是怎么添加上去的，暂时不考虑。

callback=jsonp253 这是典型的使用JSONP跨域的方式进行调用，返回值也很明确，就是返回了一个jsonp253调用的东西，其中传递的值就是我们需要的数据。
appid和from分别都是为了精确定位我们想要的的，比如from是说PC端需要这些东西，并指明有明确意义的appid。
一般看域名可以知道，大部分域名是单独使用的，而在淘宝首页希望从这些子域名里获取东西，只能被迫采用JSONP的方式，当然，我们也可以使用xhr的跨域方式啊，为什么不用呢？
最后的内容如下，很艰难单，就是一些辅助性的字段，重要的时result，是一个数组，其中有一个对象，对象里面的就是我们需要的。

存在的问题：

进入页面就会出现两个轮播图，并且这两个轮播图还离得特别近，关键是还不同步，所以看上去是非常不舒服的。
整体的hover不协调，有的地方hover可能给提供感应，比如颜色、背景变化，但是有的地方就给你一个cursor: pointer；这个还是不舒服的，可以统一一下。

之所以淘宝在性能上如此追求极致，是因为淘宝用户的访问量是巨大的，所以对于性能的要求要很高，而像alibaba.com这种网站，他面对的用户都是大用户，成交金额一般都是在几百上千万的，但是访问的频率却不高，所以，对这种网站而言，并不需要像淘宝那样追求速度，而是能够保证稳定性，保证资金的安全就可以了。

今天和阿里的何幻聊了很多，收获很多。其实这一路走来，还是挺幸运的，遇到了一心一意、循循善诱的学长，遇到了主动帮忙、无私的前辈，那么自己也只有很努力，才能继续下去了。所以啊，加油向目标出发，一定可以走向远方。

移动端：

　　相比于网易使用的H5的标签，淘宝这里做的就不是很好了，淘宝并没有采用h5标签，而是使用的一般的div，这样的问题就是语义化不够。但是整体上还是比较清楚的，包括嵌套等。

　　进入网站之后，请求数还是可以的，一共也就不要50个，所以，淘宝在性能上做的还是不错的，毕竟面临着这么大的需求，这一块是不能出现问题的。

　　在js这一块，我们可以发现，淘宝还是使用了方便操作DOM的zepto的，这个和网易是类似的，并且，我们可以看到，在head中加载js，但是使用了async属性，这样就可以保证异步加载了。　并且在head中的所有js都添加了async属性。

　　另外，我们可以看到，在淘宝的head中的js的加载方式很多使用的都是cdn，即内容分发网络，这样可以保证数据的及时请求。

　　除此之外，为了保证首屏的加载速度，有些js代码直接通过内联的方式写在了html中，这样的好处肯定是直接解析了，速度比较快，但问题是这样的做法导致我们不能很好地去保证js的模块化。

　　另外，css也是如此，为了少发送一个请求，reset css也没有外联，而是通过style的方式写在了head中。并且我们看到还不只一条，而是有很多都是直接内联的。

html,body,.page-content{-webkit-overflow-scrolling:touch;}.zebra-oversea-toolbars{height:112px;}.app-download{position:fixed;left:0;bottom:0;width:100%;height:60px;padding:12px;background:rgba(0,0,0,.7)}.app-download .d-close-btn,.app-download .d-logo{float:left;margin-right:12px;height:100%;line-height:36px}.app-download .d-close-btn img{height:16px;width:16px}.app-download .d-btn{float:right;height:100%}.app-download img{max-height:100%;max-width:100%}.app-download .text{height:100%;color:#fff;overflow:hidden}.app-download .text h2{font-size:16px}.app-download .text span{display:block;font-size:12px;line-height:14px;white-space:nowrap;text-overflow:ellipsis;overflow:hidden}.appshell.hide{opacity:0;-webkit-transition:all .2s linear;-moz-transition:all .2s linear;transition:all .2s linear}

　　整体的布局用的就是百分比布局，没有更多的特色。

　　所有的js都是经过压缩和混淆的，这样才能保证一定的性能。

　　并且在移动端还使用了menifest方式，即PWA，我们在chrome浏览器中可以保存网页到手机桌面，然后再打开的时候，就会发现有一个启动logo，并且不再有浏览器的限制，而是像一个app，这就是好的体验，和饿了么是一样的。但是目前的体验还是有问题的，并不是很好。

　　如下所示：

　　另外，我们还可以看到手淘中使用了很多先进的技术，包括localstorage、sessionStorage等等，比如我们首先打开sessionStorage，可以看到：

　　即在当前源下面存储了相关的localStorage，这里存储的时 isWebpSupport: true， 即此浏览器是支持webp格式的图片的。

　　那么为什么要使用webp呢？这是因为在同样质量图片的基础上，使用webp格式的图片可以比png、jpeg格式图片的提交少25%左右，这个好处就不言而喻了，对于淘宝这种商品销售，图片的展示是不可避免的，并且数量还非常多，所以，如果我们可以在图片上减少25%的流量，这还是非常可观的。但是目前也就只有chrome和opera对webp支持的比较好。http://zhitu.isux.us/这个网站可以对图片的格式进行转化。

　　另外，不论是移动端还是pc端，w对于图片的需求都是巨大的。可以看 http://isux.tencent.com/introduction-of-webp.html 这篇文章。qq空间中的很多图片目前也都使用上了webp格式的。

　　然后我们再到源码中查看，可以发现几乎所有的展示型图片都是使用的webp格式的，这也算是提高性能的一种方式吧。并且这些图片使用的都是cdn的方式来引入的。

　　另外，我们还可以看看淘宝首页的localStorage是怎么样的？

　　这个结果一目了然，存储了一些经纬，存储了一些其他的基本信息。

　　当时cookie使用的是最多的。

　　并且在cache storage中可以看到相关的cache。

　　并且在淘宝内部还使用了service worker这个技术。

　　至于使用的框架，还不能直接判断出来。

4、mail.qq.com

　　qq邮箱使我们使用的非常广泛的网站，这里做一个简单的分析。

　　布局：就布局而言，只能说是中规中矩，毕竟这是一个完成功能的网站，不需要华丽的外表，因为整体比较简单，只有一些基本的功能，所以也做了一点响应式，但是响应式做的也是比较糙，因为在650px以上时，整体效果还是可以的（马马虎虎），但是继续缩小时，就可以发现，网站已经很难去操作了，但是qq邮箱方面对其min-width也没有做限定，所以说，这里还是有很大的改进空间的。

　　性能：一般。主要是整个网站比较简单。在css方面还是可以的，基本上都使用了压缩，在图片上面做的也不错，大部分的小的静态图片都是做了雪碧图的，只是js方面做的非常差。几乎所有的js文件都只是做了一些混淆的工作，有一个超过10000行的js文件，竟然没有压缩，其他的比较短的文件也没有压缩、更没有合并，所以在邮箱这里qq的代码质量还是比较差的。

　　请求：整个网站的xhr请求还是比较正常的，与淘宝和网易不同，这两个网站几乎没有使用xhr，而全部使用的js，但是mail.qq.com不仅使用了xhr，也是用了js，只是js都是纯的js，而没有使用jsonp，所以的跨域都使用在了xhr中进行跨域，我们可以打开其中一个跨域的请求，如下所示：

即rl.mail.qq.com和mail.qq.com显然不是同一个域的，所以使用了CORS跨域请求，相比于JSONP，使用cors可以发送post请求（这里就是），并且从响应头可以看到这里是使用了cookie的。

5、www.sohu.com

布局：在整体布局方面，搜狐也是采用的主流做法，即宽度固定，然后使用margin: 0 auto；来居中，但是搜狐在宽度方面还是和其他网站都不同的，即header采用的是完全覆盖，然后下面的内容是一个整体，使用一个div包裹起来，固定宽度为1200px，与主流网站的950px到1000px，搜狐的做法可谓与众不同，标新立异。

用户体验：

在体验这一块，搜狐可能确实做得没有腾讯、网易做得好，比如，在你下拉时，只能出现一个回到顶部的按钮，并且还不是很明显，并且在首页找不到反馈入口，这个还是比较尴尬的。
另外，搜索在文字这一块整体偏小，也就是说，大部分的链接文字都不容易让用户感知，只有hover到具体的点的时候，才会有向橘黄色的转变。
在广告上面，搜狐可谓是物尽其用啊，在一个搜狐首页，粗略算下来，有将近20个广告，这个还是挺让我吃惊的，广告包括淘宝、京东、苏宁等等若干，并且加载广告的用的还是flash，flash在很多浏览器上还加载不出来，这个就很尴尬了啊。在广告方面，我觉得做的比较好的还是国外的一些网站，就是可以选择将广告关闭，关闭之后，会收集一个反馈信息，即为什么关闭了广告，希望关闭多久等等问题，这样贴心的关心用户，还是很好的。而不只是为了赚钱。
进入之后，在右半部分有一个搜狐号，上面有一个换一换的功能，这个我觉的还是非常不错的。比如对于图片使用的时强缓存，缓存时间为3个月（从Expires和Cache-Control看都是如此，并且都是一样的），这样，用户就不会频繁的向服务器发出请求了。当然，如果用户不再是从地址栏请求，而是使用F5刷新的方式，就会跳过强缓存，而使用协商缓存的方式，即首先比较etag，如果一致，则304；如果etag不存在，就会向下兼容，使用last-modified的方式了。
在UI设计方面，搜狐做的似乎也不是很出色，包括logo的位置似乎都是偏的。

性能：

　　终于到了性能这一部分了，其实不用看network就可以猜测到搜狐整体需要加载的数据量很大，毕竟20条广告就摆在那里呢。。。

进入首页，请求数达到了惊人的537条，这个数量还是非常吓人的，相比于网易、腾讯的200多条，已经是数倍的差距了，更不用说追求性能卓越的淘宝了，淘宝的请求数只有60条左右，这差距。。。那么究竟是什么造成的这些请求呢?
- 首先，我们看xhr，只有一条json数据的请求。嗯，这个还行。
- 然后再看js，惊！js高达了175条请求！因为搜狐大量使用了JSONP，所以在xhr方面只有一个请求。
- css还是蛮不错的，只有一个请求，即main.css，这个是很有必要的。
- 接着看img， 383条，这个才是搜狐请求比较多的重要原因，但是很多是完全可以避免的，搜狐几乎是我看到的唯一一个在小的图片上面没有使用雪碧图的网站了，这个还是不应该的，需要进行改进和优化。
- img虽然多，但是加载的速度还是很快的，因为img加载的方式使用的都是搜狐的cdn进行加载的，所以在速度上还是很不错的。
- doc。由于搜狐首页中嵌入的iframe也是挺多的，所以在doc上的请求也挺多的。
- 对于ws和manifest，搜狐完全没有使用，所以啊，在技术上搜狐的追求是不高，主要还是考虑到其他方面了吧。
比较好的时，虽然请求数量巨大，但是在二次加载的时候使用的大多是本地缓存，即使用强缓存的方式，这个还是不错的，并且使用搜狐的用户大多都会是经常使用的，缓存一般也会用得上。

特点：

搜狐的广告使用的时ｆｌａｓｈ来进加载的，提醒为右键开始加载flash，这种方式应该是需要早日去除的，因为flash现在各大浏览器已经支持的越来越少，并且目前chrome浏览器默认都是禁用flash的，所示使用flash已经不是明智的做法了，在2020年，flash将完全退出历史舞台，由html5来取代，但是html5中video的兼容性怎么样呢？在 http://caniuse.com/#search=video 这个网站上我们可以看到video的兼容性：
也就是说对于IE浏览器，几乎都是不支持的，所以使用video标签在搜狐来讲是不可能的，毕竟作为门户网站，而国内IE还是占有一定比例的，不能轻易不考虑。

css使用：使用了bootstrap。

ｊｓ使用：

虽然说js很多，但是大部分js还是压缩了的，所以还是非常不错的。
js方面搜狐使用了sohu-require.js，即搜狐自己的模块加载js库。
另外，为了支持flash，搜狐还应用了自己sohuflash.js文件。看来搜狐为了通用性，也是封装了不少自己的东西，只是没有开源出来罢了。
另外，为了检测pv，搜狐还需要添加一个pv.js精心检测。
在JSONP的使用上，搜狐可以说是使用了很多，如下所示：

　　可以看到，这个就是jsonp的使用了，值得注意的是，jsonp并不意味着一定要使用js来请求，因为这里还可以看到很多json和一些直接没有后缀的请求，甚至没有js！嗯，长见识了。

　　另外，这里的jsonp有的返回格式是： code、message、data，这是一种比较合适且通用的返回格式，这个也是我经常使用的后端返回格式，通过code来做判断，通过message来表示信息，通过data来表示得到的数据，不错。

另外，搜狐使用的js主要还是jquery，暂时没有发现使用比较新的技术。
在uid方面使用了guid.js来保证id的唯一性。
但是有一种情况，就是在js加载的方面，会发现js的重复加载！这是一个很大的问题！

搜狐移动端分析：

　　首先值得关注的是搜狐在移动端使用的时https，即更安全的通信方式，这个还是不错的。而网易等却没有这么做，使用https固然好，但是也不是绝对的，虽然更加安全，但是要考虑是否有这个必要，另外，https还需要考虑服务器的增加，网速等等。

　　布局：在html中，搜狐竟然使用了大量的id，这个是非常不可思议的，另外，可以看到在命名规范上面，搜狐做的似乎也不尽如人意，还有许多需要改善的地方。但是整个代码结构还是值得鼓励的，并且注释也比较清楚，这是比较好的地方。

　　性能：只能说还好，在进入首页之后，大约会加载160个左右的请求。

对于较小的图片，搜狐采用的也是base64的方式，这个实际上是可以避免http请求的，而对于较大的图片采用的是一般的加载方式。只是所有的图片都放在了cdn上，这一点做的还是比较不错的。
xhr --- 有三个，这里还是用到了一般的请求的。并且发送过来时候就是cookie的一些设置。
js --- 64个，已经提到，搜狐在使用js的时候，用的时vue，这个还是不错的，但是没有完全依赖于vue。其中也有很多做的不好的地方，比如在请求js的时候，有一些js是实际上没有请求到数据的，但是还是发送了http请求，这就是对资源的一种浪费了吧。在一些jsonp中，可以明显的看到jquery的标识，说明这些jsonp的请求时通过jquery封装好的代码来完成的。且与jquery相关的都是返回的data、message、code的格式，而对于一般的jsonp，直接就返回了一个对象，所以啊，使用jquery封装的jsonp还是有一定的好处的。
css --- 同样，在移动端的css也就只有一个，这个还是不错的。
img --- 上百个请求，但是在图片方面，搜狐竟然没有使用懒加载，这个还是挺让我吃惊的，进入页面之后就加载了大量的数据，还是很不友好的。另外，在加载使用的过程中，也出现了很多的问题，比如搜狐整体使用的时https，但是也出现了一些图片时http请求的情况，这个问题为什么不去处理呢？
另外，查看搜狐的证书，在2018年的6月就已经过期了，为什么到现在还是没有更换的呢？这个很郁闷！

　　用户体验：一般啦

　　js使用：从element可以看出搜狐的移动端已经大量使用了vue框架，从data-v-ghlkads 这种形式就是可以看出来的，并且从js的main.js可以看出，搜狐使用了webpack进行打包，这些也都是比较好的做法，虽然在pc端使用了require.js，但是在移动端能及时作出改变还是不错的。

搜狐bug

　　搜狐在使用的过程中存在这么一个bug，就是我比如我在chrome浏览器上浏览器移动版的搜狐，然后再切换为正常的pc，再去请求网页的时候，返回的网页是pc端的，就算我在百度里搜索之后，再去打开网页版的搜狐，还是无法奏效！

6、zhihu.com

　　同样地，知乎也是分为移动端和pc端两套代码，但是让我感到非常困惑的是，看了这么多的网站为什么只有知乎的网站，

PC端：

　　pc端的知乎在代码结构上整体还是比较舒服的，至少和前面的一些网站相比是这样的，一个主要原因也是知乎在架构上不是很复杂，下面分为几个方面来具体分析。

布局：

　　布局方面知乎也未能免俗，也是使用的最为一般的做法，在header上是width: 100%的，在下面的主题部分采用的是固定宽度1000px，然后maigin: 10px auto；所以，这些主流网站的做法都是固定死宽度，并且也不会太宽，这样可以保证在小屏幕的电脑上也不会出现横向的滚动条，另外，可以发现，这种做法似乎是一种趋势，因为这样做在布局方面也会简单一些。

体验：

我谈体验，一般都是从hover这个角度来出发的，在对每一个问题进行hover的时候，title部分会变成知乎标志性的蓝色，而对内容进行hover的时候，可以发现文字会变灰，并且始终不会出现下滑线，这个感觉还是很不错的。
另外，在滑动的时候可以发现，只有左边的区域在滑动，这样的好处就是保留了上面的导航条和右边的一些常用功能，可以方便我们快速定位，并且还充分利用了位置。有些网站可能对于右边的内容在滑动的时候就一块没有了，这种体验是不好的，一是因为这样我们就不能快速定位，二是也没有充分的利用应有的空间，所以还是需要进行改进的。
这里就有一个比较巧妙的地方，就是对于不同的主题会有不同的颜色，这个是很正常的，但是知乎做的比较好的一点就是在hover的时候，文字的颜色竟然和图片的颜色一致，这还是比较美观、赏心悦目的，值得学习。
知乎竟然没有广告！这一点还是非常不错的，相较于搜狐的首页20条的广告，知乎做的还是非常良心的。
另外，如下：

　　在侧边栏，知乎推出一个相关的专题，整体颜色也非常和谐，并且，当我们鼠标hover的时候，可以看到右上角是可以删除的，这一点在体验上做的是非常棒。

在DOM上的渲染做的也是非常不错的，每次在向上滑动的时候，会使用懒加载，通过查看dom可以发现，每次添加list，也只是修改了必要的DOM，且知乎使用的时react，这个还是很好的。

　　下面，我们再看一条关于大数据的应用的：

可以看到，当我们的鼠标滑过某一个list的时候，右上角会出现一个X，然后呢，如果我们滑动到这个X上，就可以发现提示如果点击这个X就代表对这条内容不感兴趣。下面的那条就是我已经点过X的，可以发现，提示如下：

已屏蔽该条，还不想看见以下的那些内容？　　

然后给出了一些选项，另外，我们甚至还可以撤销，通过撤销，我们就可以继续回到初始的页面了！

当然，如果我们真的不想看到相关的内容，我们就可以选择其中几个不感兴趣的标签，如下：

然后，我们就可以提交了，提交之后会有一个提醒，提示不再出现相关的内容，是不是很智能呢？

请求加载：

　　首页加载的过程中，一共有大约40个请求，整体还是不错的，下面我们具体分析这些请求。

xhr 14个请求。这里的请求大部分都是同源请求，如：https://www.zhihu.com/api/v4/banners/new_home_up。其中api就表示接口相关，v4表示当前的版本，banners表示请求的数据在页面中使用的地方是banners。。当然也不全是同源请求，也是有很多跨域请求，这些都是正常的，如下所示：

　　可见，这里使用的就是CORS跨域，messaging.zhihu.com显然和www.zhihu.com不是同一个域的，另外，通过Access-Control-Allow-Credentials可以知道，这是需要发送cookie的，通过Access-Control-Allow-Origin可以知道，只有www.zhihu.com这个域才能跨域请，还有一些缓存的设置等。

js 6个请求。在js方面，由于知乎没有使用JSONP的方式跨域，所以只有一些最为基本的js问价，另外，知乎使用的时react，webpack进行打包（通过main.js的webpackJsonp这个关键字就可以看出来），所以js的数量很少，这点做的还是很好的。但是在ui方面知乎并没有ant.design这种库。
css也做得非常好，就是使用的webpack打包，最终只有一个css文件。
img、请求较多。。
ws：在知乎的网站中，我们很容易就可以发现，知乎已经使用上了websocket，如下所示：

　　可以发现，请求的url是wss， ws即websocket，第二个s表示的是secure，加密的意思。

　　可以看到一般的请求如下：

connection: upgrade

upgrade: websocket

sec-websocket-key: 4A........A==

sec-websocket-version: 13

sec-websocket-Extensions: permessage-deflate; client_max_window_bits n

　　其中 connection 和 upgrade都是使用websocket所必须的，而sec-websocket-key的作用就是作为一种通信的key。而version是指明使用的websocket的版本，这样大家通信才是顺畅的。extensions是其他的一些扩展，可以不去了解。

　　而响应如下所示：

connection: upgrade

upgrade: websocket

sec-websocket-accept: BhfhOfTOEVYvEfgEnbI9+iQr54=

　另外，通过观察，我们可以看到，每隔一分钟左右，就会发送一条websocket信息。

js使用：

从vender.js中可以看出，知乎使用的是react技术栈，包括react、react-router、redux，即react全家桶。打包方式就是典型的webpack了。即整体上使用的都是当前比较流行的技术，值得鼓励。
另外，js的请求也都比较合理，还是挺不错的。、

知乎移动端

　　移动端使用的域名同样也是 www.zhihu.com/ 。

布局：知乎总体使用的是百分比布局。整体中规中矩。

请求：

　　请求共70个左右，勉强可以接受。

xhr --- 同样使用了CORS跨域，并且跨域使用的非常广泛。

js --- 移动端主要使用的还是jquery，非常普通的方式。所有的js都是经过了压缩了的，还是可以接受的。

css --- 只有一个m.css，可以接受。

图片 --- 使用了大量的雪碧图，值得鼓励。

ws --- 移动端也使用了websocket, 这样，在推送消息的时候就会带来很好的用户体验。可以看到websocket请求也是大约1分钟会请求1次。

体验：一般。较之于pc端还是存在差距的，毕竟像hover这种移动端还是做不了。

优点：使用了https，可以很好的保证用户的数据安全。

7、http://www.mogujie.com/

PC端：

布局：整体布局搅乱，简直没有办法看。

代码规范：

html中class的命名风格不统一，有的是 - ，有的是_。
Img正常来说都是需要有title的，但是蘑菇街首页最上面就没有title，这个很郁闷。

体验:

搜索部分体验比较差，我没有输入任何文字，结果就给了一个空白的大框？逗我呢？
很多Hover不统一，有的可以是红色，有的只有下划线。
在下滑的时候，上面的搜索应该可以做一个动画的，而这里显得非常的突兀。
有些图片在hover的时候，有回馈，而有的却完全没有，体验不好。
左下方出现了一个广告，虽然这个广告是可以删除的，但是还是挡住了商品分类，这个很不爽，每次进来我都要自己再来删除。
对于这么长的网页，却没有回到顶部。如果我们希望可以回到顶部，最快的方法也只是通过左边的分类。还是有的，就是不太明显。
console没有报错，还是挺好的。

性能：

整体的加载速度还是非常快的。
进入页面之后100多个请求，也是可以接受。
xhr 完全没有使用。
js有24个请求，比较合理。整个项目的js使用的是require.js，可以看到最主要的一个js文件使用了模块化的打包方案，可以有效的减少js的数目，还是不错的。另外，看js的名称，可以看到名称是经过了加密的，或者说不想让我们看出来这是个什么文件，这个套路不错，和facebook非常像。
css文件 --- 有两个60k左右的css文件没有压缩。
img 大部分还是用了雪碧图的，所以也还不错。
网站中的图片大多采用的时cdn，所以还是不错的。

优点：

蘑菇街的大部门图片使用的都是webp格式的图片，这种图片一般在同等压缩的情况下会小一些。并且可以看到商品都是webp，而只有一些小的图片、广告等用的是png格式的图片。
另外我们也可以看到一些 base64 编码的图片。

安全：

在xss攻击上面，蘑菇街还是做了一定的工作的，比如，在搜索框中，我们输入 <script> 等，就会返回405，即方法不允许使用。

JS使用：

大部分的js都是require.js，看起来还是不错的。每个打包的js文件都用了map。对于查看和调试还是有一定的好处的。
由于没有使用xhr，所以这里使用的跨域方式主要是JSONP,并且是大量的使用，还是不错的。 JOSNP的名称也是根本看不出来是个啥。在response header中，我们还可以看到，content-encoding: gzip; 即请求的jsonp是经过了压缩了的。对于jsonp的文件，我们可以看到content-type的格式是json格式。另外，transfer-encoding: trunked可以看出来传输数据的方式是trunked的方式。如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。

移动端：

　　　不出所料，移动端的域名为 http://m.mogujie.com/ 还是非常不错的。

布局：网站整体使用的是rem布局，所以在适配方面应该还是非常不错的，html的font-size是根据js来设定的。但是没有使用html5标签，而是使用的一般的div。

体验：

应该有一个回到顶部的功能的，所以还不是很好,比如淘宝就有这些功能。
主要使用的还是zepto。
在分类界面进行分类的切换时，可以发现页面的渲染变化的很大，即抖动现象很明显。但是整个使用的懒加载还是不错的，缺点还是没有回到顶部的功能。
广告没有删除的选项，不是很友好。

性能：

整体性能还是不错的，我们可以关注一些请求。即进入页面之后发送70个请求左右。
xhr 一个也没有，所以使用的依然是jsonp跨域
js 10个，总体使用的还是zepto。 js都是经过了压缩的，还不错。从jsonp请求到的数据可以看到，整个菜单数据的获取都是动态的，使用数据填充的，而没有写死。
在移动端一样，css有一个比较大的没有压缩。
img 这个做的非常不错。使用的大多为webp，可以看到都是不错的。并且一个很大的webp图片竟然只有20k，我使用了截图工具截图之后的png，发现会有300多k，可见webp的优点。如果对于一般的展示图片，可以发现就2k的样子。所以webp的大小这一块是非常可观的。
并且img的图片使用了强缓存，使用的是cache-control :publick, max-age，31536000 即这些图片对于普通的请求，会缓存一年的时间，所以，也就是说这些图片几乎是不会改变的。那么性能的提高也就非常好了。

js使用：