網站分析

時間 2019-12-01

原文原文鏈接

一、www.qq.com

　　在pc端和移動端是分爲兩套代碼來寫的。css

pc端：html

　　佈局：總體的佈局是從上往下的佈局方式，沒有特定的兩欄、三欄佈局，而是從上到下交錯式排列。總體的思想是width固定爲1000px（無響應式），兩邊的margin是auto，這樣，能夠在瀏覽器大小發生變化時，實現一部分margin的響應式，可是內容沒有實現響應式。總體看上去仍是比較樸素。前端

　　用戶體驗：vue

搜索。在進入首頁，就能夠在最上面發現搜狗搜索，這個搜索雖然看上去不錯，可是和個人預期是不同的，點擊搜索以後，是隨即跳轉到了搜索的網站，而不是在站內搜索有用的信息，意義何在？
提供的服務不錯。在下拉網頁時，能夠在右下角發現回到頂部、用戶反饋、下載客戶端經常使用功能，避免用戶浪費時間尋找。
爲何騰訊首頁上的標籤頁的圖片一直在旋轉呢？仍是有不少問題的。
每個模塊之間對於設計方面親密性原則把控的不是很好。因此總體看起來會比較混亂，另外，雖然模塊比較多，可是每個模塊下展現的數目並很少，若是但願再看多一點內容，惟一辦法就是進入相應的欄目，而網易在這一部分就作的很好，提供了‘換一換’的功能。

　　性能：總體加載網頁的速度較快，可是也是存在一個問題。首頁的加載，發送了各類請求287個。而且去查看圖片的請求能夠發現多達134個，因此這個請求量仍是很是巨大的，由於其中只有部分常常不變的圖片使用了雪碧圖的方式，還有不少沒有使用雪碧圖的方式，致使請求量較大。而且雪碧圖的合併也是有問題的，佔用了較多的空間。 html5

　　js使用：經過查看network，能夠發現js的數量爲40個左右，仍是比較多的，比較好的是大部分js都是通過壓縮的，只有一些沒有壓縮。能夠看到www.qq.com首頁使用的主要是jquery以及sea.js，前者使用的時1.11左右的版本，能夠看出qq首頁已經至少3年左右沒有改版，而是繼續沿用以前的技術，後者是一種cmd模塊化解決方案，是阿里的玉伯開源的，可是目前也不是很火的。 node

　　問題：報錯較多。 react

移動端：jquery

　　佈局：移動端使用的就是普通的百分比佈局，rem使用的很是少，可是看上去也比較舒服。webpack

　　特色：移動端也是瀏覽性質的偏多，對於item和圖片使用的都是懶加載的方式，當圖片尚未請求到的時候，背景是使用的企鵝的logo圖片來代替的，因此用戶體驗較好。可是在後臺中能夠發現報錯比較嚴重。git

　　使用：對於其中的視頻使用的也都是html5中的video元素。在沒有打開視頻進行播放的時候，會在上面有一個div，而後添加一張背景圖片用來佔位置。技術上使用了react，從app.js能夠看得出來。另外，還有stats.js，經過這個js文件，咱們能夠檢測網站的相關性能，如FPS等。

　　問題：導航欄的設計比較奇怪，共有不少的內容，可是若是但願看到更多的內容只能經過滑動的方式，若是能夠添加一些按鈕，將全部導航鋪滿全屏，這種形式在體驗上可能會好不少。對於連接的下劃線其實也是很差的，由於下劃線是緊貼着字體下方的，有一種入侵的感受，我更喜歡的方式仍是取消下劃線，使用其餘hover的方式來代替。

總結:

　　　　在技術上，騰訊的qq.com並無追求太先進的技術，總體表現也是中規中矩。在體驗上，有一些地方作的仍是不錯。

　　　　移動端的手法也是相似的，即在點擊的時候，一個list是一個總體來體現的，而不是單獨的，體驗仍是不錯的。

　　　　在登陸、註冊方面，一個qq號就能夠進行登陸騰訊的全部產品，這點仍是很是讚的。

　　　　問題也是很明顯，不管是騰訊的pc端仍是移動端，一直呈現加載沒有完成的狀態。

　　　　總體感覺很是的陳舊，沒有新穎的感受。

二、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請求的，並傳遞一些參數，這裏仍是能夠多學習一下的。

三、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這個技術。

　　至於使用的框架，還不能直接判斷出來。

四、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的。

五、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端的，就算我在百度裏搜索以後，再去打開網頁版的搜狐，仍是沒法奏效！

六、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，能夠很好的保證用戶的數據安全。

七、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使用：