面試準備（常見問題）

一.網頁製做流程

版本一

內容分析：分清展示在網絡中內容的層次和邏輯關係

結構代碼：寫出合理的html結構代碼

佈局設計：使用html+css進行佈局

樣式設計：首先要使用reset.css

交互設計：鼠標特效

行爲設計：js代碼，ajax頁面行爲和從服務器獲取數據

測試兼容性：

優化性能：

版本二

1）根據需求，肯定主題。透徹深刻所作網站的核心功能和關鍵。

2）收集資料。從對比相同類型的網站（慣用而熟悉的樣式，用戶更樂意接受），參照別人可行的實現方法。

3）規劃網站。抽離出相似的模塊和可重用的部件。若是是響應式網站就須要設定斷點，根據不一樣寬度屏幕設定樣式。

4）設計數據庫。

5）搭建基本的框架。引入重置樣式表reset.css和字體樣式表font.css，風格統一的圖標還有後天須要用到的包。

6）編碼和調試。注意統一命名和編碼規範。當多人開發時，還須要制定規範文檔。

7）上傳測試。利用ftp工具，把網站發佈到本身申請的主頁存放服務器上。網站上傳之後，你要在瀏覽器中打開本身的網站，逐個鏈接的進行測試，發現問題，及時修改，而後再上傳測試。

8）推廣宣傳。不斷宣傳，提升網站的訪問率和知名度。推廣的方法有不少，例如到搜索引擎上註冊、與別的網站交換連接、加入廣告鏈等。

9）維護更新。網站要注意常常維護更新內容，纔可以吸引住瀏覽者。

 

版本三

1.內容分析：仔細研究須要在網頁中的展示的內容，梳理其中的邏輯關係，分清層次，以及重要程度。

2.結構設計：根據內容分析的成果，搭建出合理的html結構，保證在沒有任何css樣式的狀況下，在瀏覽器保持高度可讀性。

3.原型設計：根據網頁結構，繪製出原型線框圖，對頁面進行合理的分區的佈局，原型線框圖是設計負責與客戶交流的最佳媒介。

4.方案設計：在肯定的原型線框圖基礎上，使用美工軟件，設計出具備良好視覺效果的頁面設計方法。

5.佈局設計：使用html和css對頁面進行佈局。

6.視覺設計：使用css並配合美工設計元素，完成由設計方法到網頁的轉化。

7.交互設計：爲網頁增添交互效果，如鼠標指針通過時的一些特效等。

 

2、倘若你有5個不一樣的樣式文件，整合進網站的最好方式是？

文件合併，減小http請求。

用一個大的css文件代替多個小體積css文件，這是一個很好的實踐，能夠得到更好的可維護性，可是在網站性能方面會產生必定影響（這是指的是隨文件體積的增大，隨之消耗服務器的內存也會增長）。儘管你應該把css文件拆分紅小塊，可是當瀏覽器請求這些文件時，會產生同等數量的http請求。每一個http請求都會產生一次從你的瀏覽器到服務器端網絡往返過程，而且致使推遲到達服務器和返回瀏覽器端的時間，咱們稱之爲延遲。

 

3、漸進加強（progressive enhancement）和優雅降級（graceful degradation）之間的不一樣。

.transition{
  -webkit-transition: all .5s;
     -moz-transition: all .5s;
       -o-transition: all .5s;
          transition: all .5s;  
}

.transition{ 
　　     transition: all .5s;
　　  -o-transition: all .5s;
  　-moz-transition: all .5s;
 -webkit-transition: all .5s;
}

優雅降級和漸進加強印象中是隨着css3流出來的一個概念。因爲低級別瀏覽器不支持css3，但css3的效果又太優秀不忍放棄，因此在高級瀏覽器中使用css3而低級別瀏覽器只保證最基本的功能。咋一看兩個概念差很少，都是在關注不一樣瀏覽器下的不一樣體驗，關鍵的區別是他們所側重的內容，以及這種不一樣形成的工做流程的差別。

　　

漸進加強 progressive enhancement：針對低版本瀏覽器進行構建頁面，保證最基本的功能，而後再針對高級瀏覽器進行效果、交互等改進和追加功能達到更好的用戶體驗。

　　優雅降級 graceful degradation：一開始就構建完整的功能，而後再針對低版本瀏覽器進行兼容。

　　區別：優雅降級是從複雜的現狀開始，並試圖減小用戶體驗的供給，而漸進加強則是從一個很是基礎的，可以起做用的版本開始，並不斷擴充，以適應將來環境的須要。降級（功能衰減）意味着往回看；而漸進加強則意味着朝前看，同時保證其根基處於安全地帶。

 4、對網站的文件和資源進行優化

版本一

1.文件合併、壓縮

2.使用cdn（內容分發網絡）來託管資源；

"其基本思路是儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。經過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。"   形象點說：古代打仗你們必定都知道，因爲古代的交通很不發達，因此當外族進攻的時候每每不能及時的反擊，等朝廷徵完兵再把兵派往邊境的時候那些侵略者倒是早已不見了蹤跡，這個讓古代的帝王非常鬱悶。後來帝王們學聰明瞭，都將大量的兵員提早派往邊境駐紮，讓他們平時屯田，戰時當兵，這樣的策略起到了很顯著的做用。

3.緩存的使用

版本二

1.圖片優化

首先，你須要優化你網站上的圖片，來得到絲毫加速網站的機會。從原圖上移除額外的註解、沒必要要的空間和無用的顏色，將圖片保存爲JPEG格式，由於它即便佔用空間小，也能保證圖片的高質量。

對於WordPress網站，建議使用smush.it插件來自動優化網站的圖片。若是圖片是PNG格式，可使用tinypng 優化圖片，提升圖片質量。

2.開啓GZip壓縮

被用於減小HTTP請求的大小來縮短響應時間。由於這容許你發送GZip壓縮文件而不是HTML文件給瀏覽器，它將縮短頁面等待時間和加載時間。

3.服務器響應時間

即便網站已經格外優化，可是除非服務器響應時間很是快，不然就不會有什麼大的效果。當涉及到提升網站的速度，服務器響應時間起着重要的做用。下面是一些提升服務器響應時間的建議。

1. 有獨立的服務器，而不是選擇共享/託管服務器。
2. 提升Web服務器的質量。
3. 移除沒必要要的插件，只有那些必要的插件，才須要一直保持啓用狀態。

4.瀏覽器緩存

瀏覽器具備緩存的功能，能夠存儲指定的文件，減小HTTP請求，從而提升網站的加載速度。

注意：若是過時時間與文件掛鉤，而此時文件中的內容須要更改的話，那必須先重命名文件，以便瀏覽器能夠獲取新添加的代碼。

5.開啓長鏈接（Keep-Alive）

Keep-Alive頭對縮短瀏覽器和服務器之間的分佈式請求的潛伏期是很是重要的。當用戶經過瀏覽器請求網頁時，瀏覽器會讀取服務器發送的特定的HTML文件，若是請求的頁面中包含了外部的CSS和JavaScript文件，瀏覽器會再次發送獨立的請求來獲取這些文件。正如你想的，這會延長頁面的加載時間。

使用Keep-Alive頭能夠一直保持鏈接，直到瀏覽器從服務器獲取到全部與這個頁面相關的資源。

6.使用cdn

https://segmentfault.com/a/1190000002956639

 

5、瀏覽器容許的併發請求資源數

首先，是基於端口數量和線程切換開銷的考慮，瀏覽器不可能無限量的併發請求，所以衍生出來併發限制和http/1.1的keep alive。 因此，ie6/7在http/1.1下的併發才2，但http/1.0倒是4 。而隨着技術的發展，負載均衡和各種nosql的大量應用，基本已經足以應對c10k的問題。但並非每一個網站都懂得利用domain hash也就是多域名來加速訪問。所以，新的瀏覽器加大了併發數的限制，但卻仍控制在8之內。

瀏覽器即便放棄保護本身，將全部請求一塊兒發給服務器，也極可能會引起服務器的併發閾值控制而被ban，而另一個控制在8之內的緣由也是keep alive 技術的存在使得瀏覽器複用現有鏈接和服務器通訊比建立新鏈接的性能要更好一些。

因此，瀏覽器的併發數其實並不只僅只是良知的要求，而是雙方都須要保護本身的默契，並在可靠的狀況下提供更好的性能。

 

題外——

前端技術的逐漸成熟，還衍生了domain hash，cookie free，css sprites，js/css combine，max expire time，loading images on demand等等技術。這些技術的出現和大量使用都和併發資源數有光。

1.按照普通設計，當網站cookie信息有1kb、網站首頁共150個資源時，用戶在請求過程當中須要發送150kB的cookie信息，在512kbps的常見上行寬帶下，須要長達3秒左右才能所有發送完畢。儘管這個過程能夠和頁面下載資源的時間併發，但畢竟對速度形成了影響。 並且這些信息在js/css/images/flash等靜態資源上，幾乎是沒有任何須要的。 解決方案是啓用和主站不一樣的域名來放置靜態資源，也就是cookie free。

2.將css放置在頁面最上方應該是很天然的習慣，但第一個css內引入的圖片下載是頗有可能堵塞後續的其餘js的下載。而在目前廣泛過百的整頁請求數的前提下，瀏覽器提供的僅僅數個併發，對於進行了良好優化甚至前面有cdn系統而言，是極大的性能瓶頸。這也就衍生了domain hash技術來使用多個域名加大併發量（由於瀏覽器是基於domain 的併發控制，而不是page），不過過多的散佈會致使dns解析上付出額外的代價，因此通常也是控制在2-4之間。這裏常見的一個性能小坑是沒有機制去確保url的哈希一致性（即同一個靜態資源應該被哈希到同一個域名下），而致使資源被屢次下載。

3.再怎麼提速，頁面上過百的總資源數也仍然是很可觀的，若是能將其中一些不少頁面都用到的元素如經常使用元素如按鈕、導航、Tab等的背景圖，指示圖標等等合併爲一張大圖，並利用css background的定位來使多個樣式引用同一張圖片，那也就能夠大大的減小總請求數了，這就是css sprites的由來。

4.全站的js/css本來並很少，其合併技術的產生倒是有着和圖片不一樣的考慮。 因爲cs/js一般可能對dom佈局甚至是內容形成影響，在瀏覽器解析上，不連貫的載入是會形成屢次從新渲染的。所以，在網站變大須要保持模塊化來提升可維護性的前提下，js/css combine也就天然衍生了，同時也是minify、compress等對內容進行多餘空格、空行、註釋的整理和壓縮的技術出現的緣由。

5.隨着cookie free和domain hash的引入，網站總體的打開速度將會大大的上一個臺階。 這時咱們一般看到的問題是大量的請求因爲全站公有header/footer/nav等關係，其對應文件早已在本地緩存裏存在了，但爲了確保這個內容沒有發生修改，瀏覽器仍是須要請求一次服務器，拿到一個304 Not Modified才能放心。 一些比較大型的網站在創建了比較規範的發佈制度後，會將大部分靜態資源的有效期設置爲最長，也就是Cache-Control max-age爲10年。 這樣設置後，瀏覽器就不再會在有緩存的前提下去確認文件是否有修改了。 超長的有效期可讓用戶在訪問曾訪問過的網站或網頁時，得到最佳的體驗。 帶來的複雜性則體如今每次對靜態資源進行更新時，必須發佈爲不一樣的URL來確保用戶從新加載變更的資源。

6.即便是這樣作完，仍然還存在着一個很大的優化空間，那就是不少頁面瀏覽量很大，但其實用戶直接很大比例直接就跳走了，第一屏如下的內容用戶根本就不感興趣。 對於超大流量的網站如淘寶、新浪等，這個問題尤爲重要。 這個時候通常是經過將圖片的src標籤設置爲一個loading或空白的樣式，在用戶翻頁將圖片放入可見區或即將放入可見區時再去載入。 不過這個優化其實和併發資源數的關係就比較小了，只是對一些散佈不合理，或第一頁底部的資源會有必定的幫助。 主要意圖仍是下降帶寬費用。

總的來講，各種技術都是爲了能讓用戶更快的看到頁面進行下一步操做，但卻沒必要將寶貴的資源浪費在沒有必要的重複請求、不看的內容上。

 

6、減小頁面加載時間的方法

優化圖片 

   優化圖片文件，減少其尺寸，特別是縮略圖，必定要按尺寸生成縮略圖而後調用，不要在網頁中用resize方法實現，雖然這樣看到的圖片外形笑了，可是其加載的數據量一點也沒減小。曾經見過有人在網頁中加載的縮略圖，其真實尺寸有10M之巨。普通圖像、icon也要儘量壓縮後，能夠採用web圖像保存、減小顏色數等等方法實現。

 圖像格式的選擇 

    除了優化圖片，選擇正確的圖片格式也是很重要的。JPEG格式適合於照片或真彩圖片。GIF格式適用於標誌或按鈕等平面彩色圖片。PNG相似於GIF，但支持更多的色彩。GIF提供的顏色較少，可用在一些對顏色要求不高的地方。 

壓縮Javascript、CSS代碼 

    通常js、css文件中存在大量的空格、換行、註釋，這些利於閱讀，若是可以壓縮掉，將會頗有利於網絡傳輸。（壓縮合並css，如margin-top,margin-left...) 

css和js文件在文檔位置 

  css格式定義放置在文件頭部：用戶端是慢速網絡或網頁內容比較龐大的狀況，網頁逐步呈現的同時仍會保持格式信息，不影響網頁美感。 
  Javascript腳本放在文件末尾：在主體網頁加載完成後再加載，防止其影響到主體網頁的加載速度。 

標明高度和寬度 

   若是瀏覽器沒有找到這兩個參數，它須要一邊下載圖片一邊計算大小，若是圖片不少，瀏覽器須要不斷地調整頁面。這不但影響速度，也影響瀏覽體驗。 
   當瀏覽器知道了高度和寬度參數後，即便圖片暫時沒法顯示，頁面上也會騰出圖片的空位，而後繼續加載後面的內容。從而加載時間快了，瀏覽體驗也更好了。 

減小http請求（合併文件，合併圖片）。 

   當加載一個網頁時，網頁上的每個對象（圖象、文字和線等）將請求服務器的迴應。這種請求會延長加載時間。所以要儘可能減小對象的數量，而且把CSS的文件和腳本進行結合。 
   1）例如：載入圖形文件時使用css sprites技術。 
   2）Ajax調用盡可能採用GET方法調用：實際使用XMLHttpRequest時，若是使用POST方法實現，會發生2次HTTP請求，而使用GET方法只會發生1次HTTP請求。若是改用GET方法，HTTP請求減小50%。 

使用CDN(Content Delivery Network)網絡加速 
   
    如今國內作CDN加速業務的公司不少，簡單講，就是將你的圖片、視頻擴散到CDN網絡所能到達之處，讓用戶訪問時能就近下載到這些文件，從而達到網絡提速的目的，這樣作，同時能減輕你本身網站的負載。 

網址後加斜槓 

   當用戶打開一個連接時，服務器會推測連接這個地址包含哪一種文件或頁面。若是在鏈接後加上斜線（ / ），服務器就知道這是一個目錄頁，這樣作能夠減小頁面的加載時間。如www.campr.com/目錄，會判斷這個「目錄是什麼文件類型，或者是目錄。 

網址後加斜槓 

   當用戶打開一個連接時，服務器會推測連接這個地址包含哪一種文件或頁面。若是在鏈接後加上斜線（ / ），服務器就知道這是一個目錄頁，這樣作能夠減小頁面的加載時間。如www.campr.com/目錄，會判斷這個「目錄是什麼文件類型，或者是目錄。 

再怎麼提速，頁面上過百的總資源數也仍然是很可觀的，若是能將其中一些不少頁面都用到的元素如經常使用元素如按鈕、導航、Tab等的背景圖，指示圖標等等合併爲一張大圖，並利用css background的定位來使多個樣式引用同一張圖片，那也就能夠大大的減小總請求數了，這就是css sprites的由來。

 

7、請解釋 CSS 動畫和 JavaScript 動畫的優缺點。

根據Google Developer， Chromium渲染線程分爲main thread 和 compositor thread。

若是css動畫只是改變transforms和opacity，這時整個css動畫得以在compositor thread完成（而js動畫則會在main thread執行，而後觸發compositor進行下一步操做）

在js執行一些昂貴的任務時，main thread繁忙，css動畫因爲使用了compositor thread能夠保持流暢。（在主線程中，維護了一顆layer樹（LayerTreeHost），在compositor thread，維護了一樣一顆LayerTreeHostImpl，管理了LayerImpl，這倆顆樹的內容是拷貝關係。所以能夠彼此不干擾，當JavaScript在main thread操做LayerTreeHost的同時，compositor thread 能夠用LayerTreeHostImpl作渲染。當JavaScript繁忙致使主線程卡主時，合成到屏幕的過程也是流暢的。

爲了實現防假死，鼠標鍵盤消息會被首先分發到compositor thread，而後再到main thread。這樣，當main thread繁忙時，compositor thread仍是可以響應一部分消息，例如，鼠標滾動時，加入main thread繁忙，compositor thread也會處理滾動消息，滾動已經被提交的頁面部分（未被提交的部分將被刷白）。）

 

css動畫比js流暢的前提：

1.在Chromium基礎上的瀏覽器中

2.js在執行一些昂貴的任務

3.同時css動畫不觸發layout或paint

在css動畫或js動畫觸發了paint或layout時，須要main thread進行Layer樹重計算，這時css動畫或js動畫都會阻塞後續操做。

 

只有以下屬性的修改才符合「僅觸發Composite，不觸發layout或paint」：

1.backface-visibility

2.opacity

3.perspective

4.perspective-origin

5.transform

因此只有用上了3d加速或修改opacity時，纔有機會用得上css動畫的這一優點。

所以，在大部分應用場景下，效率角度更值得關注的仍是下列問題。

• 是否致使layout
• repaint的面積
• 是不是有高消耗的屬性（css shadow等）
• 是否啓用硬件加速

現今CSS動畫和JS動畫主要的不一樣點是

• 功能涵蓋面，JS比CSS3大
  
  
  • 定義動畫過程的@keyframes不支持遞歸定義，若是有多種相似的動畫過程，須要調節多個參數來生成的話，將會有很大的冗餘（好比jQuery Mobile的動畫方案），而JS則自然能夠以一套函數實現多個不一樣的動畫過程
  • 時間尺度上，@keyframes的動畫粒度粗，而JS的動畫粒度控制能夠很細
  • CSS3動畫裏被支持的時間函數很是少，不夠靈活
  • 以現有的接口，CSS3動畫沒法作到支持兩個以上的狀態轉化
• 實現/重構難度不一，CSS3比JS更簡單，性能調優方向固定
• 對於幀速表現很差的低版本瀏覽器，CSS3能夠作到天然降級，而JS則須要撰寫額外代碼
• CSS動畫有自然事件支持（TransitionEnd、AnimationEnd，可是它們都須要針對瀏覽器加前綴），JS則須要本身寫事件
• CSS3有兼容性問題，而JS大多時候沒有兼容性問題