前端面試題 ---- html篇


 

1、htmljavascript

  一、html和xhtml區別css

    1. html:超文本標記語言,hyper text markup languagehtml

         xhtml: 可拓展的超文本標記語言 extensible hyper text markup language 前端

         它是一種置標語言,表現方式和超文本標記語言html相似不過語法更加嚴格html5

    2.  xhtml 全部標籤必須小寫  在XHTML中,全部的標籤都必須小寫,不能大小寫穿插其中,也不能所有都是大寫。java

    3.  xhtml 標籤必須成對出現  像是<p>...</p>、<a>...</a>、<div>...</div>標籤等,當出現一個標籤時,必需要有對應的結束標籤,缺一不可,就像在任何程序語言中的括號同樣node

    4.  xhtml 標籤必須正確嵌套  標籤由外到內,一層層包覆着,因此假設你先寫div後寫h1,結尾就要先寫h1後寫div。只要記住一個原則「先進後出」,先彈出的標籤要後結尾。web

    5. xhtml 全部屬性必須使用雙引號   在XHTML 1.0中規定連單引號也不能使用,因此全程都得用雙引號。面試

    6. XHTML 文檔必須擁有根元素。ajax


 

  二、web標準

    WEB標準不是某一個標準,而是一系列標準的集合。網頁主要由三部分組成:結構(Structure)、表現(Presentation)和行爲(Behavior)。對應的標準也分三方面:

    結構化標準語言主要包括XHTML和XML,表現標準語言主要包括CSS,行爲標準主要包括對象模型(如W3C DOM)、ECMAScript等。這些標準大部分由萬維網聯盟

    (起草和發佈,也有一些是其餘標準組織制訂的標準,好比ECMA(European Computer Manufacturers Association)的ECMAScript標準。

    1.  結構 -- xhtml html

    2. 表現 -- css

    3. 行爲 -- dom ecmascript


 

  三、WEB標準(結構、表現、行爲分離)有哪些優勢呢?

  • 易於維護:只需更改CSS文件,就能夠改變整站的樣式
  • 頁面響應快:HTML文檔體積變小,響應時間短
  • 可訪問性:語義化的HTML(結構和表現相分離的HTML)編寫的網頁文件,更容易被屏幕閱讀器識別
  • 設備兼容性:不一樣的樣式表可讓網頁在不一樣的設備上呈現不一樣的樣式
  • 搜索引擎:語義化的HTML能更容易被搜索引擎解析,提高排名    

 

   四、 可用性、可維護性、可訪問性

    可用性:產品是否容易上手,用戶體驗怎麼樣,可用性好是企業的核心競爭力
    可維護性:出現問題時,修復bug的成本低則維護性好,還有一點是代碼可以被其餘開發人員理解,畢竟咱們不是一我的再作產品
    可訪問性:就是全部人(盲人)都能理解你的網頁。


 

  五、對web標準和w3c的理解和認識

    web標準簡單來講能夠分爲結構、表現和行爲。其中結構主要是有HTML標籤組成。或許通俗點說,在頁面body裏面咱們寫入的標籤都是爲了頁面的結構。

    表現即指css樣式表,經過css  能夠是頁面的結構標籤更具美感。行爲是指頁面和用戶具備必定的交互,同時頁面結構或者表現發生變化,主要是有js組成。

    web標準通常是將該三部分獨立分開,使其更具備模塊化。但通常產生行爲時,就會有結構或者表現的變化,也使這三者的界限並不那麼清晰。

    W3C對web標準提出了規範化的要求,也就是在實際編程中的一些代碼規範:包含以下幾點

    1.對於結構要求:(標籤規範能夠提升搜索引擎對頁面的抓取效率,對SEO頗有幫助)

      1)。標籤字母要小寫

      2)。標籤要閉合

      3)。標籤不容許隨意嵌套

    2.對於css和js來講

      1)。儘可能使用外鏈css樣式表和js腳本。是結構、表現和行爲分爲三塊,符合規範。同時提升頁面渲染速度,提升用戶的體驗。

      2)。樣式儘可能少用行間樣式表,使結構與表現分離,標籤的id和class等屬性命名要作到見文知義,標籤越少,加載越快,用戶體驗提升,代碼維護簡單,便於改版

      3)。不須要變更頁面內容,即可提供打印版本而不須要複製內容,提升網站易用性。


 

  六、什麼是語義化的HTML?

    Html語義化是指根據內容的結構化(內容語義化),選擇合適的標籤(代碼語義化)便於開發者閱讀和寫出更優雅的代碼的同時讓瀏覽器的爬蟲和及其很好的解析。

  


 

  七、爲何要語義化呢?  

    清晰的頁面結構
      去掉或樣式丟失的時候,也能讓頁面呈現清晰的結構,增長頁面的可讀性。
    支持更多的設備
      屏幕閱讀器(若是訪客有視障)會徹底根據你的標記來「讀」你的網頁。若是你使用的含語義的標記,屏幕閱讀會根據你的標籤來判斷網頁的內容,而不是一個字母一個字母的拼寫出來。
    有利於SEO
      和搜索引擎創建良好的溝通,有助於爬蟲抓取更多的有效信息,搜索引擎的爬蟲也依賴於標記來肯定上下文和各個關鍵字的權重。
    便於團隊開發和維護
      在團隊中你們都遵循同一個標準,能夠減小不少差別化的東西,方便開發和維護,提升開發效率,甚至實現模塊化開發。
    有利於用戶體驗

  八、文件名的命名規範
    小寫英文字母、數字、下劃線,其中不得包含漢字、空格、和特殊字符,必須以英文字母開頭。

  九、html頁面組成
    由標籤和屬性組成,一塊兒用於標識文檔各個部件

  十、一個html文檔包含哪些內容
    對這個文件簡單的描述區head,和文檔自己的內容區 body

 

  十一、html文檔具備哪些特色

    結構化、簡單、已維護與平臺無關


 

  十二、HTML5 爲何只須要寫 !DOCTYPE HTML?

    HTML5 不基於 SGML,所以不須要對DTD進行引用,可是須要doctype來規範瀏覽器的行爲(讓瀏覽器按照它們應該的方式來運行);

    而HTML4.01基於SGML,因此須要對DTD進行引用,才能告知瀏覽器文檔所使用的文檔類型。


  1三、Doctype做用?標準模式與兼容模式各有什麼區別?

    !DOCTYPE聲明位於位於HTML文檔中的第一行,處於html 標籤以前。告知瀏覽器的解析器用什麼文檔標準解析這個文檔。

    DOCTYPE不存在或格式不正確會致使文檔以兼容模式呈現。  

    標準模式的排版 和JS運做模式都是以該瀏覽器支持的最高標準運行。在兼容模式中,頁面以寬鬆的向後兼容的方式顯示,模擬老式瀏覽器的行爲以防止站點沒法工做。


 

  1四、html5有哪些新特性、移除了那些元素?如何處理HTML5新標籤的瀏覽器兼容問題?如何區分 HTML 和html5

    • HTML5 如今已經不是 SGML 的子集,主要是關於圖像,位置,存儲,多任務等功能的增長。
    • 繪畫 canvas
    • 用於媒介回放的 video 和 audio 元素
    • 本地離線存儲 localStorage 長期存儲數據,瀏覽器關閉後數據不丟失;
    • sessionStorage 的數據在瀏覽器關閉後自動刪除
    • 語意化更好的內容元素,好比 article、footer、header、nav、section
    • 表單控件,calendar、date、time、email、url、search
    • 新的技術webworker, websockt, Geolocation
      移除的元素
    • 純表現的元素:basefont,big,center,font, s,strike,tt,u;
    • 對可用性產生負面影響的元素:frame,frameset,noframes;
      支持HTML5新標籤:
    • IE8/IE7/IE6支持經過document.createElement方法產生的標籤,
    • 能夠利用這一特性讓這些瀏覽器支持HTML5新標籤,
    • 瀏覽器支持新標籤後,還須要添加標籤默認的樣式:

 

  1五、請描述一下 cookies,sessionStorage 和 localStorage 的區別?

    共同點:都是保存在瀏覽器端,且同源的。

    區別:
    1.   cookie數據始終在同源的http請求中攜帶(即便不須要),即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數據發給服務器,僅在本地保存。cookie數據還有路徑(path)的概念,能夠限制cookie只屬於某個路徑下。
    2.   存儲大小限制也不一樣,cookie數據不能超過4k,同時由於每次http請求都會攜帶cookie,因此cookie只適合保存很小的數據,如會話標識。sessionStorage和localStorage 雖然也有存儲大小的限制,但比cookie大得多,能夠達到5M或更大。
    3.   數據有效期不一樣,sessionStorage:僅在當前瀏覽器窗口關閉前有效,天然也就不可能持久保持;localStorage:始終有效,窗口或瀏覽器關閉也一直保存,所以用做持久數據;cookie只在設置的cookie過時時間以前一直有效,即便窗口或瀏覽器關閉。
    4.   做用域不一樣,sessionStorage不在不一樣的瀏覽器窗口中共享,即便是同一個頁面;localStorage 在全部同源窗口中都是共享的;cookie也是在全部同源窗口中都是共享的。
    5.   Web Storage 支持事件通知機制,能夠將數據更新的通知發送給監聽者。
    6.   Web Storage 的 api 接口使用更方便。 

  


 

  1六、如何實現瀏覽器內多個標籤頁之間的通訊? 

      調用localstorge、cookies等本地存儲方式


 

  1七、瀏覽器內核有哪些和表明的瀏覽器

    一、Trident內核:表明做品是IE,因IE捆綁在Windows中,因此佔有極高的份額,又稱爲IE內核或MSHTML,此內核只能用於Windows平臺,且不是開源的。

      表明做品還有騰訊、Maxthon(遨遊)、360瀏覽器等。但因爲市場份額比較大,曾經出現脫離了W3C標準的時候,同時IE版本比較多,

      存在不少的兼容性問題。

    二、Gecko內核:表明做品是Firefox,即火狐瀏覽器。因火狐是最多的用戶,故常被稱爲firefox內核它是開源的,最大優點是跨平臺,

    在Microsoft Windows、Linux、MacOs X等主 要操做系統中使用。

    三、Webkit內核:表明做品是Safari、曾經的Chrome,是開源的項目。

    四、Presto內核:表明做品是Opera,Presto是由Opera Software開發的瀏覽器排版引擎,它是世界公認最快的渲染速度的引擎。

    在13年以後,Opera宣佈加入谷歌陣營,棄用了    Presto

    五、Blink內核:由Google和Opera Software開發的瀏覽器排版引擎,2013年4月發佈。如今Chrome內核是Blink。谷歌還開發了本身的JS引擎,V8,使JS運行速度極大地提升了


  1八、html5哪些操做能夠SEO優化

    頭部代碼
      一、標題標籤(title標籤)

      在HTML5中標題標籤依然存在,其仍然具備不可替代的做用;不過咱們看到還有更多的可供搜索引擎識別的代碼,咱們將改代碼的等級微降。

      二、元標籤(meta標籤)

    字符集編碼聲明標籤

      該標籤本來就是搜索引擎必看且首先要看的標籤,其餘屬性都省略惟獨留下charset屬性能看到google公司用心良苦。

    網頁描述標籤

      該標籤雖然沒有什麼提示,可是該區域的內容將會在SERP顯示,其重要性不該該被忽略。

    正文代碼
      一、頭部標籤(header標籤)

      這塊區域以前以logo居多,而從目前的狀況來看,不少資料都建議在這類使用標題1或2標籤,即H1或H2標籤。咱們認爲將來每一個網頁只會出現一個H1標籤,

      而他的位置就是位於header標籤內。該區域咱們不建議使用strong標籤,不要使用b標籤。

      二、導航標籤(nav標籤)

      nav標籤內基本上都是a標籤,而HTML5中不該該靠添加title標籤來進行優化,咱們建議是用strong標籤。

      三、文章標籤(article標籤)

      article標籤區域,咱們可使用h2標籤,而不建議使用h1標籤。基本上有多少個article標籤就可使用多少個h2標籤。PS:可把SEO樂死了,估計黑帽又找到做弊的地方了。

      而article標籤區域的section標籤將會替代h2標籤連接過去的URL的title屬性,這塊區域的文字有可能將成爲目標URL的description內容,

      即有可能會影響目標URL在SERP中的描述。

      四、左或右側標籤(aside標籤)

      aside標籤的文字信息與article標籤區域的文字信息須要匹配,若是關聯程度不大,可能會影響到該頁面以及目標頁面的排名。這是在HTML4中不少SEO忽視的一塊區域,

      而這塊區域的關鍵詞對本頁面可能影響不是很大。由於aside標籤的內容基本上都屬於公共內容,即會有N多的頁面都有該內容。

      五、底部標籤(footer標籤)

      footer標籤區域的內容對首頁的排名將會增長,而對於內頁來講搜索引擎將有可能會視而不見。不建議每一個web的footer信息都是獨立的,這或許意味着新的黑帽手段將會出現。

      六、其餘標籤等

      video標籤中間區域的文字信息將會讓搜索引擎讀懂視頻,這是一次飛躍。不過也爲黑帽SEO節約了一筆不菲的時間。

      audio標籤做爲相似img同樣的單標籤來處理感受的確有點過度,這樣對於音樂可能會有不少障礙,不過音樂裏面基本上沒有幾個關鍵詞,

      也就再也不網頁搜索引擎優化的研究範圍了。注意下該標籤上下文的關鍵詞便可。

      time標籤可能會做爲一個來判斷網頁文字源,也就是可以經過time標籤來識別那篇文章是原創的。而time標籤可能將是成爲HTML5時代SEO們整理不休的一個標籤。

      noscript標籤將會被大量使用,由於HTML5時代將會是一個富媒體時代。傳統的文字、圖片、連接、視頻、音頻可能已經知足不了用戶的需求,

      大量的腳本可以編輯出豐富的信息,包括遊戲、個性化設計等等。


   1九、性能的優化

PC瀏覽器前端優化策略

PC端優化的策略不少,如 YSlow(YSlow 是 Yahoo 發佈的一款 Firefox 插件,現 Chrome 也可安裝,能夠對網站的頁面性能進行分析,提出對該頁面性能優化的建議)原則,或者 Chrome 自帶的 Audits 等,總結起來主要包括網絡加載類、頁面渲染類、CSS 優化類、JavaScript 執行類、緩存類、圖片類、架構協議類等幾類,下面逐一介紹。

網絡加載類

1.減小 HTTP 資源請求次數

在前端頁面中,一般建議儘量合併靜態資源圖片、JavaScript 或 CSS 代碼,減小頁面請求數和資源請求消耗,這樣能夠縮短頁面首次訪問的用戶等待時間。經過構建工具合併雪碧圖、CSS、JavaScript 文件等都是爲了減小 HTTP 資源請求次數。另外也要儘可能避免重複的資源,防止增長多餘請求。

2.減少 HTTP 請求大小

除了減小 HTTP 資源請求次數,也要儘可能減少每一個 HTTP 請求的大小。如減小不必的圖片、JavaScript、CSS 及 HTML 代碼,對文件進行壓縮優化,或者使用 gzip 壓縮傳輸內容等均可以用來減少文件大小,縮短網絡傳輸等待時延。前面咱們使用構建工具來壓縮靜態圖片資源以及移除代碼中的註釋並壓縮,目的都是爲了減少 HTTP 請求的大小。

3.將 CSS 或 JavaScript 放到外部文件中,避免使用<style><script>標籤直接引入

在 HTML 文件中引用外部資源能夠有效利用瀏覽器的靜態資源緩存,但有時候在移動端頁面 CSS 或 JavaScript 比較簡單的狀況下爲了減小請求,也會將 CSS 或 JavaScript 直接寫到 HTML 裏面,具體要根據 CSS 或 JavaScript 文件的大小和業務的場景來分析。若是 CSS 或 JavaScript 文件內容較多,業務邏輯較複雜,建議放到外部文件引入。

<link rel="stylesheet" href="//cdn.domain.com/path/main.css" > ... <script src="//cdn.domain.com/path/main.js"></script>

4.避免頁面中空的 href 和 src

<link>標籤的 href 屬性爲空,或<script><img><iframe>標籤的 src 屬性爲空時,瀏覽器在渲染的過程當中仍會將 href 屬性或 src 屬性中的空內容進行加載,直至加載失敗,這樣就阻塞了頁面中其餘資源的下載進程,並且最終加載到的內容是無效的,所以要儘可能避免。

<!--不推薦-->
<img src="" alt="photo" > <a href="">點擊連接</a>

5.爲 HTML 指定 Cache-Control 或 Expires

爲 HTML 內容設置 Cache-Control 或 Expires 能夠將 HTML 內容緩存起來,避免頻繁向服務器端發送請求。前面講到,在頁面 Cache-Control 或 Expires 頭部有效時,瀏覽器將直接從緩存中讀取內容,不向服務器端發送請求。

<meta http-equiv="Cache-Control" content="max-age=7200"> <meta http-equiv="Expires" content="Mon,20Jul201623:00:00GMT">

6.合理設置 Etag 和 Last-Modified

合理設置 Etag 和 Last-Modified 使用瀏覽器緩存,對於未修改的文件,靜態資源服務器會向瀏覽器端返回304,讓瀏覽器從緩存中讀取文件,減小 Web 資源下載的帶寬消耗並下降服務器負載。

<meta http-equiv="last-modified" content="Sun,05 Nov 2017 13:45:57 GMT">

7.減小頁面重定向

頁面每次重定向都會延長頁面內容返回的等待延時,一次重定向大約須要200毫秒不等的時間開銷(無緩存),爲了保證用戶儘快看到頁面內容,要儘可能避免頁面重定向。

8.使用靜態資源分域存放來增長下載並行數

瀏覽器在同一時刻向同一個域名請求文件的並行下載數是有限的,所以能夠利用多個域名的主機來存放不一樣的靜態資源,增大頁面加載時資源的並行下載數,縮短頁面資源加載的時間。一般根據多個域名來分別存儲 JavaScript、CSS 和圖片文件。

<link rel="stylesheet" href="//cdn1.domain.com/path/main.css" > ... <script src="//cdn2.domain.com/path/main.js"></script>

9.使用靜態資源 CDN 來存儲文件

若是條件容許,能夠利用 CDN 網絡加快同一個地理區域內重複靜態資源文件的響應下載速度,縮短資源請求時間。

10.使用 CDN Combo 下載傳輸內容

CDN Combo 是在 CDN 服務器端將多個文件請求打包成一個文件的形式來返回的技術,這樣能夠實現 HTTP 鏈接傳輸的一次性複用,減小瀏覽器的 HTTP 請求數,加快資源下載速度。例如同一個域名 CDN 服務器上的 a.js,b.js,c.js 就能夠按以下方式在一個請求中下載。

<script src="//cdn.domain.com/path/a.js,b.js,c.js"></script>

11.使用可緩存的 AJAX

對於返回內容相同的請求,不必每次都直接從服務端拉取,合理使用 AJAX 緩存能加快 AJAX 響應速度並減輕服務器壓力。

$.ajax({
    url : url,
    type : 'get', cache : true, //推薦使用緩存 data : {}, success (){//...}, error (){//...} });

12.使用 GET 來完成 AJAX 請求

使用 XMLHttpRequest 時,瀏覽器中的 POST 方法會發起兩次 TCP 數據包傳輸,首先發送文件頭,而後發送 HTTP 正文數據。而使用 GET 時只發送頭部,因此在拉取服務端數據時使用 GET 請求效率更高。

$.ajax({
    url : url,
    type : 'get', //推薦使用get完成請求 data : {}, success (){//...}, error(){//...} });

13.減小 Cookie 的大小並進行 Cookie 隔離

HTTP 請求一般默認帶上瀏覽器端的 Cookie 一塊兒發送給服務器,因此在非必要的狀況下,要儘可能減小 Cookie 來減少 HTTP 請求的大小。對於靜態資源,儘可能使用不一樣的域名來存放,由於 Cookie 默認是不能跨域的,這樣就作到了不一樣域名下靜態資源請求的 Cookie 隔離。

14.縮小 favicon.ico 並緩存

有利於 favicon.ico 的重複加載,由於通常一個 Web 應用的 favicon.ico 是不多改變的。

15.推薦使用異步 JavaScript 資源

異步的 JavaScript 資源不會阻塞文檔解析,因此容許在瀏覽器中優先渲染頁面,延後加載腳本執行。例如 JavaScript 的引用能夠以下設置,也可使用模塊化加載機制來實現。

<script src="main.js" defer></script> <script src="main.js" async></script>

使用 async 時,加載和渲染後續文檔元素的過程和 main.js 的加載與執行是並行的。使用 defer 時,加載後續文檔元素的過程和 main.js 的加載是並行的,可是 main.js 的執行要在頁面全部元素解析完成以後纔開始執行。

16.消除阻塞渲染的 CSS 及 JavaScript

對於頁面中加載時間過長的 CSS 或 JavaScript 文件,須要進行合理拆分或延後加載,保證關鍵路徑的資源能快速加載完成。

17.避免使用 CSS import 引用加載 CSS

CSS 中的 @import 能夠從另外一個樣式文件中引入樣式,但應該避免這種用法,由於這樣會增長 CSS 資源加載的關鍵路徑長度,帶有 @import 的 CSS 樣式須要在 CSS 文件串行解析到 @import 時纔會加載另外的 CSS 文件,大大延後 CSS 渲染完成的時間。

<!--不推薦-->
<style>
    @import "path/main.css"; </style> <!--推薦--> <link rel="stylesheet" href="//cdn1.domain.com/path/main.css" >

頁面渲染類

1.把 CSS 資源引用放到 HTML 文件頂部

通常推薦將全部 CSS 資源儘早指定在 HTML 文檔 <head> 中,這樣瀏覽器能夠優先下載 CSS 並儘早完成頁面渲染。

2.JavaScript 資源引用放到 HTML 文件底部

JavaScript 資源放到 HTML 文檔底部能夠防止 JavaScript 的加載和解析執行對頁面渲染形成阻塞。因爲 JavaScript 資源默認是解析阻塞的,除非被標記爲異步或者經過其餘的異步方式加載,不然會阻塞 HTML DOM 解析和 CSS 渲染的過程。

3.儘可能預先設定圖片等大小

在加載大量的圖片元素時,儘可能預先限定圖片的尺寸大小,不然在圖片加載過程當中會更新圖片的排版信息,產生大量的重排

4.不要在 HTML 中直接縮放圖片

在 HTML 中直接縮放圖片會致使頁面內容的重排重繪,此時可能會使頁面中的其餘操做產生卡頓,所以要儘可能減小在頁面中直接進行圖片縮放。

5.減小 DOM 元素數量和深度

HTML 中標籤元素越多,標籤的層級越深,瀏覽器解析 DOM 並繪製到瀏覽器中所花的時間就越長,因此應儘量保持 DOM 元素簡潔和層級較少。

<!--不推薦-->
<div>
    <span>
        <a href="javascript:void(0);"> <img src="./path/photo.jpg" alt="圖片"> </a> </span> </div> <!--推薦--> <img src="./path/photo.jpg" alt="圖片" >

6.儘可能避免在選擇器末尾添加通配符

CSS 解析匹配到 渲染樹的過程是從右到左的逆向匹配,在選擇器末尾添加通配符至少會增長一倍多計算量。

7.減小使用關係型樣式表的寫法

直接使用惟一的類名便可最大限度的提高渲染引擎繪製渲染樹等效率

8.儘可能減小使用JS動畫

JS 直接操做 DOM 極容易引發頁面的重排

9.CSS 動畫使用 translate、scale 代替 top、height

儘可能使用 CSS3 的 translate、scale 屬性代替 top、left 和 height、width,避免大量的重排計算

10.儘可能避免使用<table><iframe>

<table> 內容的渲染是將 table 的 DOM 渲染樹所有生成完並一次性繪製到頁面上的,因此在長表格渲染時很耗性能,應該儘可能避免使用它,能夠考慮使用列表元素 <ul> 代替。儘可能使用異步的方式動態添加 iframe,由於 iframe 內資源的下載進程會阻塞父頁面靜態資源的下載與 CSS 及 HTML DOM 的解析。

11.避免運行耗時的 JavaScript

長時間運行的 JavaScript 會阻塞瀏覽器構建 DOM 樹、DOM 渲染樹、渲染頁面。因此,任何與頁面初次渲染無關的邏輯功能都應該延遲加載執行,這和 JavaScript 資源的異步加載思路是一致的。

12.避免使用 CSS 表達式或 CSS 濾鏡

CSS 表達式或 CSS 濾鏡的解析渲染速度是比較慢的,在有其餘解決方案的狀況下應該儘可能避免使用。

//不推薦
.opacity{
    filter : progid : DXImageTransform.Microsoft.Alpha( opacity = 50 );
}

移動端瀏覽器前端優化策略

相對於桌面端瀏覽器,移動端 Web 瀏覽器上有一些較爲明顯的特色:設備屏幕較小、新特性兼容性較好、支持一些較新的 HTML5 和 CSS3 特性、須要與 Native 應用交互等。但移動端瀏覽器可用的 CPU 計算資源和網絡資源極爲有限,所以要作好移動端 Web 上的優化每每須要作更多的事情。首先,在移動端 Web 的前端頁面渲染中,桌面瀏覽器端上的優化規則一樣適用,此外針對移動端也要作一些極致的優化來達到更好的效果。須要注意的是,並非移動端的優化原則在桌面瀏覽器端就不適用,而是因爲兼容性和差別性的緣由,一些優化原則在移動端更具表明性。

網絡加載類

1.首屏數據請求提早,避免 JavaScript 文件加載後才請求數據

爲了進一步提高頁面加載速度,能夠考慮將頁面的數據請求儘量提早,避免在 JavaScript 加載完成後纔去請求數據。一般數據請求是頁面內容渲染中關鍵路徑最長的部分,並且不能並行,因此若是能將數據請求提早,能夠極大程度上縮短頁面內容的渲染完成時間。

2.首屏加載和按需加載,非首屏內容滾屏加載,保證首屏內容最小化

因爲移動端網絡速度相對較慢,網絡資源有限,所以爲了儘快完成頁面內容的加載,須要保證首屏加載資源最小化,非首屏內容使用滾動的方式異步加載。通常推薦移動端頁面首屏數據展現延時最長不超過3秒。目前中國聯通 3G 的網絡速度爲 338KB/s(2.71Mb/s),因此推薦首屏全部資源大小不超過 1014KB,即大約不超過 1MB。

3.模塊化資源並行下載

在移動端資源加載中,儘可能保證 JavaScript 資源並行加載,主要指的是模塊化 JavaScript 資源的異步加載,例如AMD的異步模塊,使用並行的加載方式可以縮短多個文件資源的加載時間。

4.inline 首屏必備的 CSS 和 JavaScript

一般爲了在 HTML 加載完成時能使瀏覽器中有基本的樣式,須要將頁面渲染時必備的 CSS 和 JavaScript 經過 <script><style> 內聯到頁面中,避免頁面 HTML 載入完成到頁面內容展現這段過程當中頁面出現空白。

<!DOCTYPE html>
<html lang="en"> <head> <meta charset="UTF-8"> <title>樣例</title> <meta name="viewport" content="width=device-width,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no"> <style> /*必備的首屏CSS*/ html,body{ margin:0; padding:0; background-color:#ccc; } </style> </head> <body> </body> </html>

5.meta dns prefetch 設置 DNS 預解析

設置文件資源的 DNS 預解析,讓瀏覽器提早解析獲取靜態資源的主機 IP,避免等到請求時才發起 DNS 解析請求。一般在移動端 HTML 中能夠採用以下方式完成。

<!--cdn域名預解析-->
<meta http-equiv="x-dns-prefetch-control" content="on" > <link rel="dns-prefetch" href="//cdn.domain.com" >

6.資源預加載

對於移動端首屏加載後可能會被使用的資源,須要在首屏完成加載後儘快進行加載,保證在用戶須要瀏覽時已經加載完成,這時候若是再去異步請求就顯得很慢。

7.合理利用MTU策略

一般狀況下,咱們認爲 TCP 網絡傳輸的最大傳輸單元(Maximum Transmission Unit,MTU)爲 1500B,即一個RTT(Round-Trip Time,網絡請求往返時間)內能夠傳輸的數據量最大爲 1500 字節。所以,在先後端分離的開發模式中,儘可能保證頁面的 HTML 內容在 1KB 之內,這樣整個 HTML 的內容請求就能夠在一個 RTT 內請求完成,最大限度地提升 HTML 載入速度。

緩存類

1.合理利用瀏覽器緩存

除了上面說到的使用 Cache-Control、Expires、Etag 和 Last-Modified 來設置 HTTP 緩存外,在移動端還可使用 localStorage 等來保存 AJAX 返回的數據,或者使用 localStorage 保存 CSS 或 JavaScript 靜態資源內容,實現移動端的離線應用,儘量減小網絡請求,保證靜態資源內容的快速加載。

2.靜態資源離線方案

對於移動端或 Hybrid 應用,能夠設置離線文件或離線包機制讓靜態資源請求從本地讀取,加快資源載入速度,並實現離線更新。關於這塊內容,咱們會在後面的章節中重點講解。

3.嘗試使用 AMP HTML

AMP HTML 能夠做爲優化前端頁面性能的一個解決方案,使用 AMP Component 中的元素來代替原始的頁面元素進行直接渲染。

<!--不推薦-->
<video width="400" height="300" src="http://www.domain.com/videos/myvideo.mp4" poster="path/poster.jpg"> <div fallback> <p>Your browser doesn’t support HTML5 video</p> </div> <source type="video/mp4" src="foo.mp4"> <source type="video/webm" src="foo.webm"> </video> <!--推薦--> <amp-video width="400" height="300" src="http://www.domain.com/videos/myvideo.mp4" poster="path/poster.jpg"> <div fallback> <p>Your browser doesn’t support HTML5 video</p> </div> <source type="video/mp4" src="foo.mp4"> <source type="video/webm" src="foo.webm"> </amp-video>

4.嘗試使用 PWA 模式

PWA(Progressive Web Apps)是 Google 提出的用前沿的 Web 技術爲網頁提供 App 般使用體驗的一系列方案。

圖片類

1.圖片壓縮處理

在移動端,一般要保證頁面中一切用到的圖片都是通過壓縮優化處理的,而不是以原圖的形式直接使用的,由於那樣很消耗流量,並且加載時間更長。

2.使用較小的圖片,合理使用 base64 內嵌圖片

在頁面使用的背景圖片很少且較小的狀況下,能夠將圖片轉化成 base64 編碼嵌入到 HTML 頁面或 CSS 文件中,這樣能夠減小頁面的 HTTP 請求數。須要注意的是,要保證圖片較小,通常圖片大小超過 2KB 就不推薦使用 base64 嵌入顯示了。

.class-name{
    background-image : url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAALCAMAAABxsOwqAAAAYFBMVEWnxwusyQukxQudwQyZvgyhxAyfwgyxzAsUHQGOuA0aJAERGAFIXwSTugyEqgtqhghQZgUwQQIpOQKbuguVtQuKrAuCowp2kQlheghTbQZHWQU7SwVAVgQ6TgQlLwMeKwFOemyQAAAAVElEQVQI1y3JVRaAIAAF0UconXbvf5ei8HfPDIQQhBAAFE10iKig3SLRNN4SP/p+N08VC0YnfIlNWtqIkhg/TPYbCvhqdHAWRXPZSp3g3CWZvVLXC6OJA3ukv0AaAAAAAElFTkSuQmCC'); }

3.使用更高壓縮比格式的圖片

使用具備較高壓縮比格式的圖片,如 webp(須要設計降級兼容方案)等。在同等圖片畫質的狀況下,高壓縮比格式的圖片體積更小,可以更快完成文件傳輸,節省網絡流量。

<img src="//cdn.domain.com/path/photo.webp" alt="webp格式圖片" >

4.圖片懶加載

爲了保證頁面內容的最小化,加速頁面的渲染,儘量節省移動端網絡流量,頁面中的圖片資源推薦使用懶加載實現,在頁面滾動時動態載入圖片。

<img data-src="//cdn.domain.com/path/photo.jpg" alt="懶加載圖片" >

5.使用 MediaQuery 或 srcset 根據不一樣屏幕加載不一樣大小圖片

在介紹響應式的章節中咱們瞭解到,針對不一樣的移動端屏幕尺寸和分辨率,輸出不一樣大小的圖片或背景圖能保證在用戶體驗不下降的前提下節省網絡流量,加快部分機型的圖片加載速度,這在移動端很是值得推薦。

6.使用 iconfont 代替圖片圖標

在頁面中儘量使用 iconfont 來代替圖片圖標,這樣作的好處有如下幾個:

    • 使用 iconfont 體積較小,並且是矢量圖,所以縮放時不會失真;
    • 能夠方便地修改圖片大小尺寸和呈現顏色。

可是須要注意的是,iconfont 引用不一樣 webfont 格式時的兼容性寫法,根據經驗推薦儘可能按照如下順序書寫,不然不容易兼容到全部的瀏覽器上。

@font-face{
    font-family:iconfont;
    src:url("./iconfont.eot"); src:url("./iconfont.eot?#iefix") format("eot"), url("./iconfont.woff") format("woff"), url("./iconfont.ttf") format("truetype"); }

7.定義圖片大小限制

加載的單張圖片通常建議不超過 30KB,避免大圖片加載時間長而阻塞頁面其餘資源的下載,所以推薦在 10KB 之內。若是用戶上傳的圖片過大,建議設置告警系統,幫助咱們觀察瞭解整個網站的圖片流量狀況,作出進一步的改善。

8.強緩存策略

對於一些「永遠」不會變的圖片可使用強緩存的方式緩存在用戶的瀏覽器上。

腳本類

1.儘可能使用 id

選擇器選擇頁面 DOM 元素時儘可能使用 id 選擇器,由於 id 選擇器速度最快。

2.合理緩存 DOM 對象

對於須要重複使用的 DOM 對象,要優先設置緩存變量,避免每次使用時都要從整個DOM樹中從新查找。

//不推薦
$('#mod.active').remove('active'); $('#mod.not-active').addClass('active'); //推薦 let $mod=$('#mod'); $mod.find('.active').remove('active'); $mod.find('.not-active').addClass('active');

3.頁面元素儘可能使用事件代理,避免直接事件綁定

使用事件代理能夠避免對每一個元素都進行綁定,而且能夠避免出現內存泄露及須要動態添加元素的事件綁定問題,因此儘可能不要直接使用事件綁定。

//不推薦
$('.btn').on('click',function(e){ console.log(this); }); //推薦 $('body').on('click','.btn',function(e){ console.log(this); });

4.使用 touchstart 代替 click

因爲移動端屏幕的設計, touchstart 事件和 click 事件觸發時間之間存在 300 毫秒的延時,因此在頁面中沒有實現 touchmove 滾動處理的狀況下,可使用 touchstart 事件來代替元素的 click 事件,加快頁面點擊的響應速度,提升用戶體驗。但同時咱們也要注意頁面重疊元素 touch 動做的點擊穿透問題。

//不推薦
$('body').on('click','.btn',function(e){ console.log(this); }); //推薦 $('body').on('touchstart','.btn',function(e){ console.log(this); });

5.避免 touchmove、scroll 連續事件處理

須要對 touchmove、scroll 這類可能連續觸發回調的事件設置事件節流,例如設置每隔 16ms(60 幀的幀間隔爲 16.7ms,所以能夠合理地設置爲 16ms )才進行一次事件處理,避免頻繁的事件調用致使移動端頁面卡頓。

//不推薦
$('.scroller').on('touchmove','.btn',function(e){ console.log(this); }); //推薦 $('.scroller').on('touchmove','.btn',function(e){ let self=this; setTimeout(function(){ console.log(self); },16); });

6.避免使用 eval、with,使用 join 代替鏈接符+,推薦使用 ECMAScript6 的字符串模板

這些都是一些基礎的安全腳本編寫問題,儘量使用較高效率的特性來完成這些操做,避免不規範或不安全的寫法。

7.儘可能使用 ECMAScript6+的特性來編程

ECMAScript6+ 必定程度上更加安全高效,並且部分特性執行速度更快,也是將來規範的須要,因此推薦使用 ECMAScript6+ 的新特性來完成後面的開發。

渲染類

1.使用 Viewport 固定屏幕渲染,能夠加速頁面渲染內容

通常認爲,在移動端設置 Viewport 能夠加速頁面的渲染,同時能夠避免縮放致使頁面重排重繪。在移動端固定 Viewport 設置的方法以下。

<!--設置viewport不縮放-->
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no">

2.避免各類形式重排重繪

頁面的重排重繪很耗性能,因此必定要儘量減小頁面的重排重繪,例如頁面圖片大小變化、元素位置變化等這些狀況都會致使重排重繪。

3.使用 CSS3 動畫,開啓GPU加速

使用 CSS3 動畫時能夠設置 transform:translateZ(0) 來開啓移動設備瀏覽器的GPU圖形處理加速,讓動畫過程更加流暢,但須要注意的是,在 Native WebView 下 GPU 加速有概率產生 App Crash。

-webkit-transform:translateZ(0);
    -ms-transform:translateZ(0);
     -o-transform:translateZ(0);
        transform:translateZ(0);

4.合理使用 Canvas 和 requestAnimationFrame

選擇 Canvas 或 requestAnimationFrame 等更高效的動畫實現方式,儘可能避免使用 setTimeout、setInterval 等方式來直接處理連續動畫。

5.SVG 代替圖片

部分狀況下能夠考慮使用 SVG 代替圖片實現動畫,由於使用 SVG 格式內容更小,並且 SVG DOM 結構方便調整。

6.不濫用 float

在 DOM 渲染樹生成後的佈局渲染階段,使用 float 的元素佈局計算比較耗性能,因此儘可能減小 float 的使用,推薦使用固定佈局或 flex-box 彈性佈局的方式來實現頁面元素佈局。

7.不濫用 web 字體或過多 font-size 聲明

過多的 font-size 聲明會增長字體的大小計算,並且也沒有必要的。

8.作好腳本容錯

腳本容錯能夠避免「非正常環境」的執行錯誤影響頁面的加載和不相關功能的使用

架構協議類

1.嘗試使用 SPDY 和 HTTP2

在條件容許的狀況下能夠考慮使用 SPDY 協議來進行文件資源傳輸,利用鏈接複用加快傳輸過程,縮短資源加載時間。HTTP2 在將來也是能夠考慮嘗試的。

2.使用後端數據渲染

使用後端數據渲染的方式能夠加快頁面內容的渲染展現,避免空白頁面的出現,同時能夠解決移動端頁面SEO的問題。若是條件容許,後端數據渲染是一個很不錯的實踐思路。後面的章節會詳細介紹後端數據渲染的相關內容。

3.使用 NativeView 代替 DOM 的性能劣勢

能夠嘗試使用 NativeView 的 MNV* 開發模式來避免 HTML DOM 性能慢的問題,目前使用 MNV* 的開發模式已經能夠將頁面內容渲染體驗作到接近客戶端 Native 應用的體驗了。但須要避免 js Framework 和 native Framework 的頻繁交互。

 


 

 

 

什麼是跨域?

同源策略是由Netscape提出的著名安全策略,是瀏覽器最核心、基本的安全功能,它限制了一個源(origin)中加載文本或者腳本與來自其餘源(origin)中資源的交互方式
,所謂的同源就是指協議、域名、端口相同。
當瀏覽器執行一個腳本時會檢查是否同源,只有同源的腳本纔會執行,若是不一樣源即爲跨域

跨域的幾種方式

在項目中可能會須要在一個域名下請求另一個域名的資源,下面咱們來探討下跨域的幾種實現方式

一、jsonp

最多見的一種跨域方式,其背後原理就是利用了script標籤不受同源策略的限制,在頁面中動態插入了script,script標籤的src屬性就是後端api接口的地址,而且以get的方式將前端回調處理函數名稱告訴後端,後端在響應請求時會將回調返還,而且將數據以參數的形式傳遞回去。

前端:

//http://127.0.0.1:8888/jsonp.html var script = document.createElement('script'); script.src = 'http://127.0.0.1:2333/jsonpHandler?callback=_callback' document.body.appendChild(script); //插入script標籤 //回調處理函數 _callback var _callback = function(obj){ for(key in obj){ console.log('key: ' + key +' value: ' + obj[key]); } } 

後端:

//http://127.0.0.1:2333/jsonpHandler app.get('/jsonpHandler', (req,res) => { let callback = req.query.callback; let obj = { type : 'jsonp', name : 'weapon-x' }; res.writeHead(200, {"Content-Type": "text/javascript"}); res.end(callback + '(' + JSON.stringify(obj) + ')'); }) 

在jsonp.html中打開控制檯能夠看到返回數據的輸出:


 
jsonp.png

二、CORS

Cross-Origin Resource Sharing(跨域資源共享)是一種容許當前域(origin)的資源(好比html/js/web service)被其餘域(origin)的腳本請求訪問的機制。
當使用XMLHttpRequest發送請求時,瀏覽器若是發現違反了同源策略就會自動加上一個請求頭:origin,後端在接受到請求後肯定響應後會在Response Headers中加入一個屬性:Access-Control-Allow-Origin,值就是發起請求的源地址(http://127.0.0.1:8888),瀏覽器獲得響應會進行判斷Access-Control-Allow-Origin的值是否和當前的地址相同,只有匹配成功後才進行響應處理。

現代瀏覽器中和移動端都支持CORS(除了opera mini),IE下須要8+

前端:

//http://127.0.0.1:8888/cors.html var xhr = new XMLHttpRequest(); xhr.onload = function(data){ var _data = JSON.parse(data.target.responseText) for(key in _data){ console.log('key: ' + key +' value: ' + _data[key]); } }; xhr.open('POST','http://127.0.0.1:2333/cors',true); xhr.setRequestHeader('Content-Type','application/x-www-form-urlencoded'); xhr.send(); 

後端:

//http://127.0.0.1:2333/cors app.post('/cors',(req,res) => { if(req.headers.origin){ res.writeHead(200,{ "Content-Type": "text/html; charset=UTF-8", "Access-Control-Allow-Origin":'http://127.0.0.1:8888' }); let people = { type : 'cors', name : 'weapon-x' } res.end(JSON.stringify(people)); } }) 

能夠在開發者工具裏面看到請求的詳細信息,而且在控制檯也能夠看到返回的數據輸出:


 
response header.png
 
cors console.png

三、服務器跨域

在先後端分離的項目中能夠藉助服務器實現跨域,具體作法是:前端向本地服務器發送請求,本地服務器代替前端再向�api服務器接口發送請求進行服務器間通訊,本地服務器其實就是個中轉站的角色,再將響應的數據返回給前端,下面用node.js作一個示例

前端:

//http://127.0.0.1:8888/server var xhr = new XMLHttpRequest(); xhr.onload = function(data){ var _data = JSON.parse(data.target.responseText) for(key in _data){ console.log('key: ' + key +' value: ' + _data[key]); } }; xhr.open('POST','http://127.0.0.1:8888/feXhr',true); //向本地服務器發送請求 xhr.setRequestHeader('Content-Type','application/x-www-form-urlencoded'); xhr.send("url=http://127.0.0.1:2333/beXhr"); //以參數形式告知須要請求的後端接口 

後端:

//http://127.0.0.1:8888/feXhr app.post('/feXhr',(req,res) => { let url = req.body.url; superagent.get(url) //使用superagent想api接口發送請求 .end(function (err,docs) { if(err){ console.log(err); return } res.end(docs.res.text); //返回到前端 }) }) //http://127.0.0.1:2333/beXhr app.get('/beXhr',(req,res) => { let obj = { type : 'superagent', name : 'weapon-x' }; res.writeHead(200, {"Content-Type": "text/javascript"}); res.end(JSON.stringify(obj)); //響應 }) 

回到 http://127.0.0.1:8888/server 頁面打開控制檯能夠看到數據輸出:

 
console.png

 

四、postmessage跨域

在HTML5中新增了postMessage方法,postMessage能夠實現跨文檔消息傳輸(Cross Document Messaging),Internet Explorer 8, Firefox 3, Opera 9, Chrome 3和 Safari 4都支持postMessage。
該方法能夠經過綁定window的message事件來監聽發送跨文檔消息傳輸內容。
使用postMessage實現跨域的話原理就相似於jsonp,動態插入iframe標籤,再從iframe裏面拿回數據
,私認爲用做跨頁面通訊更加適合


  2一、HTML全局屬性(global attribute)有哪些

accesskey 規定激活元素的快捷鍵。
class 規定元素的一個或多個類名(引用樣式表中的類)。
contenteditable 規定元素內容是否可編輯。
contextmenu 規定元素的上下文菜單。上下文菜單在用戶點擊元素時顯示。
data-* 用於存儲頁面或應用程序的私有定製數據。
dir 規定元素中內容的文本方向。
draggable 規定元素是否可拖動。
dropzone 規定在拖動被拖動數據時是否進行復制、移動或連接。
hidden 規定元素仍未或再也不相關。
id 規定元素的惟一 id。
lang 規定元素內容的語言。
spellcheck 規定是否對元素進行拼寫和語法檢查。
style 規定元素的行內 CSS 樣式。
tabindex 規定元素的 tab 鍵次序。
title 規定有關元素的額外信息。
translate 規定是否應該翻譯元素內容。

 


 

  2二、HTTP狀態碼及其含義

  • 1XX:信息狀態碼
    • 100 Continue 繼續,通常在發送post請求時,已發送了http header以後服務端將返回此信息,表示確認,以後發送具體參數信息
  • 2XX:成功狀態碼
    • 200 OK 正常返回信息
    • 201 Created 請求成功而且服務器建立了新的資源
    • 202 Accepted 服務器已接受請求,但還沒有處理
  • 3XX:重定向
    • 301 Moved Permanently 請求的網頁已永久移動到新位置。
    • 302 Found 臨時性重定向。
    • 303 See Other 臨時性重定向,且老是使用 GET 請求新的 URI
    • 304 Not Modified 自從上次請求後,請求的網頁未修改過。
  • 4XX:客戶端錯誤
    • 400 Bad Request 服務器沒法理解請求的格式,客戶端不該當嘗試再次使用相同的內容發起請求。
    • 401 Unauthorized 請求未受權。
    • 403 Forbidden 禁止訪問。
    • 404 Not Found 找不到如何與 URI 相匹配的資源。
  • 5XX: 服務器錯誤
    • 500 Internal Server Error 最多見的服務器端錯誤。
    • 503 Service Unavailable 服務器端暫時沒法處理請求(多是過載或維護)。

  2三、從瀏覽器地址欄輸入url到顯示頁面的步驟

    1. 在瀏覽器地址欄輸入URL
    2. 瀏覽器查看緩存,若是請求資源在緩存中而且新鮮,跳轉到轉碼步驟
      1. 若是資源未緩存,發起新請求
      2. 若是已緩存,檢驗是否足夠新鮮,足夠新鮮直接提供給客戶端,不然與服務器進行驗證。
      3. 檢驗新鮮一般有兩個HTTP頭進行控制ExpiresCache-Control
      • HTTP1.0提供Expires,值爲一個絕對時間表示緩存新鮮日期
      • HTTP1.1增長了Cache-Control: max-age=,值爲以秒爲單位的最大新鮮時間
    3. 瀏覽器解析URL獲取協議,主機,端口,path
    4. 瀏覽器組裝一個HTTP(GET)請求報文
    5. 瀏覽器獲取主機ip地址,過程以下:
      1. 瀏覽器緩存
      2. 本機緩存
      3. hosts文件
      4. 路由器緩存
      5. ISP DNS緩存
      6. DNS遞歸查詢(可能存在負載均衡致使每次IP不同)
    6. 打開一個socket與目標IP地址,端口創建TCP連接,三次握手以下:
      1. 客戶端發送一個TCP的SYN=1,Seq=X的包到服務器端口
      2. 服務器發回SYN=1, ACK=X+1, Seq=Y的響應包
      3. 客戶端發送ACK=Y+1, Seq=Z
    7. TCP連接創建後發送HTTP請求
    8. 服務器接受請求並解析,將請求轉發到服務程序,如虛擬主機使用HTTP Host頭部判斷請求的服務程序
    9. 服務器檢查HTTP請求頭是否包含緩存驗證信息若是驗證緩存新鮮,返回304等對應狀態碼
    10. 處理程序讀取完整請求並準備HTTP響應,可能須要查詢數據庫等操做
    11. 服務器將響應報文經過TCP鏈接發送回瀏覽器
    12. 瀏覽器接收HTTP響應,而後根據狀況選擇關閉TCP鏈接或者保留重用,關閉TCP鏈接的四次握手以下:
      1. 主動方發送Fin=1, Ack=Z, Seq= X報文
      2. 被動方發送ACK=X+1, Seq=Z報文
      3. 被動方發送Fin=1, ACK=X, Seq=Y報文
      4. 主動方發送ACK=Y, Seq=X報文
    13. 瀏覽器檢查響應狀態嗎:是否爲1XX,3XX, 4XX, 5XX,這些狀況處理與2XX不一樣
    14. 若是資源可緩存,進行緩存
    15. 對響應進行解碼(例如gzip壓縮)
    16. 根據資源類型決定如何處理(假設資源爲HTML文檔)
    17. 解析HTML文檔,構件DOM樹,下載資源,構造CSSOM樹,執行js腳本,這些操做沒有嚴格的前後順序,如下分別解釋
    18. 構建DOM樹:
      1. Tokenizing:根據HTML規範將字符流解析爲標記
      2. Lexing:詞法分析將標記轉換爲對象並定義屬性和規則
      3. DOM construction:根據HTML標記關係將對象組成DOM樹
    19. 解析過程當中遇到圖片、樣式表、js文件,啓動下載
    20. 構建CSSOM樹:
      1. Tokenizing:字符流轉換爲標記流
      2. Node:根據標記建立節點
      3. CSSOM:節點建立CSSOM樹
    21. 根據DOM樹和CSSOM樹構建渲染樹:
      1. 從DOM樹的根節點遍歷全部可見節點,不可見節點包括:1)script,meta這樣自己不可見的標籤。2)被css隱藏的節點,如display: none
      2. 對每個可見節點,找到恰當的CSSOM規則並應用
      3. 發佈可視節點的內容和計算樣式
    22. js解析以下:
      1. 瀏覽器建立Document對象並解析HTML,將解析到的元素和文本節點添加到文檔中,此時document.readystate爲loading
      2. HTML解析器遇到沒有async和defer的script時,將他們添加到文檔中,而後執行行內或外部腳本。這些腳本會同步執行,而且在腳本下載和執行時解析器會暫停。這樣就能夠用document.write()把文本插入到輸入流中。同步腳本常常簡單定義函數和註冊事件處理程序,他們能夠遍歷和操做script和他們以前的文檔內容
      3. 當解析器遇到設置了async屬性的script時,開始下載腳本並繼續解析文檔。腳本會在它下載完成後儘快執行,可是解析器不會停下來等它下載。異步腳本禁止使用document.write(),它們能夠訪問本身script和以前的文檔元素
      4. 當文檔完成解析,document.readState變成interactive
      5. 全部defer腳本會按照在文檔出現的順序執行,延遲腳本能訪問完整文檔樹,禁止使用document.write()
      6. 瀏覽器在Document對象上觸發DOMContentLoaded事件
      7. 此時文檔徹底解析完成,瀏覽器可能還在等待如圖片等內容加載,等這些內容完成載入而且全部異步腳本完成載入和執行,document.readState變爲complete,window觸發load事件
    23. 顯示頁面(HTML解析過程當中會逐步顯示頁面)

  2四、行內元素有哪些?塊級元素有哪些? 空(void)元素有那些?行內元素和塊級元素有什麼區別?

    • 行內元素有:a b span img input select strong
    • 塊級元素有:div ul ol li dl dt dd h1 h2 h3 h4…p
    • 空元素:<br> <hr> <img> <input> <link> <meta>
    • 行內元素不能夠設置寬高,不獨佔一行
    • 塊級元素能夠設置寬高,獨佔一行

 

  2五、瀏覽器是怎麼對HTML5的離線儲存資源進行管理和加載的呢

    • 在線的狀況下,瀏覽器發現html頭部有manifest屬性,它會請求manifest文件,若是是第一次訪問app,那麼瀏覽器就會根據manifest文件的內容下載相應的資源而且進行離線存儲。若是已經訪問過app而且資源已經離線存儲了,那麼瀏覽器就會使用離線的資源加載頁面,而後瀏覽器會對比新的manifest文件與舊的manifest文件,若是文件沒有發生改變,就不作任何操做,若是文件改變了,那麼就會從新下載文件中的資源並進行離線存儲。

    • 離線的狀況下,瀏覽器就直接使用離線存儲的資源。

 

  


  2六、HTML5的離線儲存怎麼使用,工做原理能不能解釋一下?

    

    • 在用戶沒有與因特網鏈接時,能夠正常訪問站點或應用,在用戶與因特網鏈接時,更新用戶機器上的緩存文件

    • 原理:HTML5的離線存儲是基於一個新建的.appcache文件的緩存機制(不是存儲技術),經過這個文件上的解析清單離線存儲資源,這些資源就會像cookie同樣被存儲了下來。以後當網絡在處於離線狀態下時,瀏覽器會經過被離線存儲的數據進行頁面展現

    • 如何使用:

      • 頁面頭部像下面同樣加入一個manifest的屬性;
      • cache.manifest文件的編寫離線存儲的資源
      • 在離線狀態時,操做window.applicationCache進行需求實現
CACHE MANIFEST
#v0.11 CACHE: js/app.js css/style.css NETWORK: resourse/logo.png FALLBACK: / /offline.html

簡述一下 src 與 href 的區別? 2七、
  • href 是指向網絡資源所在位置,創建和當前元素(錨點)或當前文檔(連接)之間的連接,用於超連接
  • src是指向外部資源的位置,指向的內容將會嵌入到文檔中當前標籤所在位置;在請求src資源時會將其指向的資源下載並應用到文檔內,例如js腳本,img圖片和frame等元素。當瀏覽器解析到該元素時,會暫停其餘資源的下載和處理,直到將該資源加載、編譯、執行完畢,圖片和框架等元素也如此,相似於將所指向資源嵌入當前標籤內。這也是爲何將js腳本放在底部而不是頭部

 


 

2八、你能描述一下漸進加強和優雅降級之間的不一樣嗎?

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

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

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

「優雅降級」觀點

「優雅降級」觀點認爲應該針對那些最高級、最完善的瀏覽器來設計網站。而將那些被認爲「過期」或有功能缺失的瀏覽器下的測試工做安排在開發週期的最後階段,並把測試對象限定爲主流瀏覽器(如 IE、Mozilla 等)的前一個版本。

在這種設計範例下,舊版的瀏覽器被認爲僅能提供「簡陋卻無妨 (poor, but passable)」 的瀏覽體驗。你能夠作一些小的調整來適應某個特定的瀏覽器。但因爲它們並不是咱們所關注的焦點,所以除了修復較大的錯誤以外,其它的差別將被直接忽略。

 

「漸進加強」觀點

「漸進加強」觀點則認爲應關注於內容自己。

內容是咱們創建網站的誘因。有的網站展現它,有的則收集它,有的尋求,有的操做,還有的網站甚至會包含以上的種種,但相同點是它們全都涉及到內容。這使得「漸進加強」成爲一種更爲合理的設計範例。這也是它當即被 Yahoo! 所採納並用以構建其「分級式瀏覽器支持 (Graded Browser Support)」策略的緣由所在。

那麼問題了。如今產品經理看到IE6,7,8網頁效果相對高版本現代瀏覽器少了不少圓角,陰影(CSS3),要求兼容(使用圖片背景,放棄CSS3),你會如何說服他?


 

2九、知道的網頁製做會用到的圖片格式有哪些?

png-8,png-24,jpeg,gif,svg。

可是上面的那些都不是面試官想要的最後答案。面試官但願聽到是Webp,Apng。(是否有關注新技術,新鮮事物)

 

科普一下Webp

WebP格式,谷歌(google)開發的一種旨在加快圖片加載速度的圖片格式。圖片壓縮體積大約只有JPEG的2/3,並能節省大量的服務器帶寬資源和數據空間。Facebook Ebay等知名網站已經開始測試並使用WebP格式。

在質量相同的狀況下,WebP格式圖像的體積要比JPEG格式圖像小40%。

Apng:全稱是「Animated Portable Network Graphics」, 是PNG的位圖動畫擴展,能夠實現png格式的動態圖片效果。04年誕生,但一直得不到各大瀏覽器廠商的支持,直到日前獲得 iOS safari 8的支持,有望代替GIF成爲下一代動態圖標準。


30、

相關文章
相關標籤/搜索