[TOC] ### 1 前端需要注意哪些SEO * 合理的`title`、`description`、`keywords`：搜索對著三項的權重逐個減小，`title`值強調重點即可，重要關鍵詞出現不要超過2次，而且要靠前，不同頁面`title`要有所不同；`description`把頁面內容高度概括，長度合適，不可過分堆砌關鍵詞，不同頁面`description`有所不同；`keywords`列舉出重要關鍵詞即可 * 語義化的`HTML`代碼，符合W3C規范：語義化代碼讓搜索引擎容易理解網頁 * 重要內容`HTML`代碼放在最前：搜索引擎抓取`HTML`順序是從上到下，有的搜索引擎對抓取長度有限制，保證重要內容一定會被抓取 * 重要內容不要用`js`輸出：爬蟲不會執行js獲取內容 * 少用`iframe`：搜索引擎不會抓取`iframe`中的內容 * 非裝飾性圖片必須加`alt` * 提高網站速度：網站速度是搜索引擎排序的一個重要指標 ### 2 `<img>`的`title`和`alt`有什么區別 * 通常當鼠標滑動到元素上的時候顯示 * `alt`是`<img>`的特有屬性，是圖片內容的等價描述，用于圖片無法加載時顯示、讀屏器閱讀圖片。可提圖片高可訪問性，除了純裝飾圖片外都必須設置有意義的值，搜索引擎會重點分析。 ### 3 HTTP的幾種請求方法用途 * `GET`方法 * 發送一個請求來取得服務器上的某一資源 * `POST`方法 * 向`URL`指定的資源提交數據或附加新的數據 * `PUT`方法 * 跟`POST`方法很像，也是想服務器提交數據。但是，它們之間有不同。`PUT`指定了資源在服務器上的位置，而`POST`沒有 * `HEAD`方法 * 只請求頁面的首部 * `DELETE`方法 * 刪除服務器上的某資源 * `OPTIONS`方法 * 它用于獲取當前`URL`所支持的方法。如果請求成功，會有一個`Allow`的頭包含類似`“GET,POST”`這樣的信息 * `TRACE`方法 * `TRACE`方法被用于激發一個遠程的，應用層的請求消息回路 * `CONNECT`方法 * 把請求連接轉換到透明的`TCP/IP`通道 ### 4 從瀏覽器地址欄輸入url到顯示頁面的步驟 **基礎版本** * 瀏覽器根據請求的`URL`交給`DNS`域名解析，找到真實`IP`，向服務器發起請求； * 服務器交給后臺處理完成后返回數據，瀏覽器接收文件（`HTML、JS、CSS`、圖象等）； * 瀏覽器對加載到的資源（`HTML、JS、CSS`等）進行語法解析，建立相應的內部數據結構（如`HTML`的`DOM`）； * 載入解析到的資源文件，渲染頁面，完成。 **詳細版** 1. 在瀏覽器地址欄輸入URL 2. 瀏覽器查看**緩存**，如果請求資源在緩存中并且新鮮，跳轉到轉碼步驟 1. 如果資源未緩存，發起新請求 2. 如果已緩存，檢驗是否足夠新鮮，足夠新鮮直接提供給客戶端，否則與服務器進行驗證。 3. 檢驗新鮮通常有兩個HTTP頭進行控制`Expires`和`Cache-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. 發布可視節點的內容和計算樣式 2. **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事件 3. **顯示頁面**（HTML解析過程中會逐步顯示頁面） **詳細簡版** 1. 從瀏覽器接收`url`到開啟網絡請求線程（這一部分可以展開瀏覽器的機制以及進程與線程之間的關系） 2. 開啟網絡線程到發出一個完整的`HTTP`請求（這一部分涉及到dns查詢，`TCP/IP`請求，五層因特網協議棧等知識） 3. 從服務器接收到請求到對應后臺接收到請求（這一部分可能涉及到負載均衡，安全攔截以及后臺內部的處理等等） 4. 后臺和前臺的`HTTP`交互（這一部分包括`HTTP`頭部、響應碼、報文結構、`cookie`等知識，可以提下靜態資源的`cookie`優化，以及編碼解碼，如`gzip`壓縮等） 5. 單獨拎出來的緩存問題，`HTTP`的緩存（這部分包括http緩存頭部，`ETag`，`catch-control`等） 6. 瀏覽器接收到`HTTP`數據包后的解析流程（解析`html`\-詞法分析然后解析成`dom`樹、解析`css`生成`css`規則樹、合并成`render`樹，然后`layout`、`painting`渲染、復合圖層的合成、`GPU`繪制、外鏈資源的處理、`loaded`和`DOMContentLoaded`等） 7. `CSS`的可視化格式模型（元素的渲染規則，如包含塊，控制框，`BFC`，`IFC`等概念） 8. `JS`引擎解析過程（`JS`的解釋階段，預處理階段，執行階段生成執行上下文，`VO`，作用域鏈、回收機制等等） 9. 其它（可以拓展不同的知識模塊，如跨域，web安全，`hybrid`模式等等內容） ### 5 如何進行網站性能優化 * `content`方面 * 減少`HTTP`請求：合并文件、`CSS`精靈、`inline Image` * 減少`DNS`查詢：`DNS`緩存、將資源分布到恰當數量的主機名 * 減少`DOM`元素數量 * `Server`方面 * 使用`CDN` * 配置`ETag` * 對組件使用`Gzip`壓縮 * `Cookie`方面 * 減小`cookie`大小 * `css`方面 * 將樣式表放到頁面頂部 * 不使用`CSS`表達式 * 使用`<link>`不使用`@import` * `Javascript`方面 * 將腳本放到頁面底部 * 將`javascript`和`css`從外部引入 * 壓縮`javascript`和`css` * 刪除不需要的腳本 * 減少`DOM`訪問 * 圖片方面 * 優化圖片：根據實際顏色需要選擇色深、壓縮 * 優化`css`精靈 * 不要在`HTML`中拉伸圖片 **你有用過哪些前端性能優化的方法？** * 減少http請求次數：CSS Sprites, JS、CSS源碼壓縮、圖片大小控制合適；網頁Gzip，CDN托管，data緩存 ，圖片服務器。 * 前端模板 JS+數據，減少由于HTML標簽導致的帶寬浪費，前端用變量保存AJAX請求結果，每次操作本地變量，不用請求，減少請求次數 * 用innerHTML代替DOM操作，減少DOM操作次數，優化javascript性能。 * 當需要設置的樣式很多時設置className而不是直接操作style * 少用全局變量、緩存DOM節點查找的結果。減少IO讀取操作 * 避免使用CSS Expression（css表達式)又稱Dynamic properties(動態屬性) * 圖片預加載，將樣式表放在頂部，將腳本放在底部 加上時間戳 * 避免在頁面的主體布局中使用table，table要等其中的內容完全下載之后才會顯示出來，顯示比div+css布局慢 **談談性能優化問題** * 代碼層面：避免使用css表達式，避免使用高級選擇器，通配選擇器 * 緩存利用：緩存Ajax，使用CDN，使用外部js和css文件以便緩存，添加Expires頭，服務端配置Etag，減少DNS查找等 * 請求數量：合并樣式和腳本，使用css圖片精靈，初始首屏之外的圖片資源按需加載，靜態資源延遲加載 * 請求帶寬：壓縮文件，開啟GZIP **前端性能優化最佳實踐？** * 性能評級工具（PageSpeed 或 YSlow） * 合理設置 HTTP 緩存：Expires 與 Cache-control * 靜態資源打包，開啟 Gzip 壓縮（節省響應流量） * CSS3 模擬圖像，圖標base64（降低請求數） * 模塊延遲(defer)加載/異步(async)加載 * Cookie 隔離（節省請求流量） * localStorage（本地存儲） * 使用 CDN 加速（訪問最近服務器） * 啟用 HTTP/2（多路復用，并行加載） * 前端自動化（gulp/webpack） ### 6 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` 服務器端暫時無法處理請求（可能是過載或維護）。 ### 7 語義化的理解 * 用正確的標簽做正確的事情！ * `HTML`語義化就是讓頁面的內容結構化，便于對瀏覽器、搜索引擎解析； * 在沒有樣式`CSS`情況下也以一種文檔格式顯示，并且是容易閱讀的。 * 搜索引擎的爬蟲依賴于標記來確定上下文和各個關鍵字的權重，利于 `SEO`。 * 使閱讀源代碼的人對網站更容易將網站分塊，便于閱讀維護理解 ### 8 介紹一下你對瀏覽器內核的理解？ * 主要分成兩部分：渲染引擎(`layout engineer`或`Rendering Engine`)和`JS`引擎 * 渲染引擎：負責取得網頁的內容（`HTML`、`XML`、圖像等等）、整理訊息（例如加入`CSS`等），以及計算網頁的顯示方式，然后會輸出至顯示器或打印機。瀏覽器的內核的不同對于網頁的語法解釋會有不同，所以渲染的效果也不相同。所有網頁瀏覽器、電子郵件客戶端以及其它需要編輯、顯示網絡內容的應用程序都需要內核 * `JS`引擎則：解析和執行`javascript`來實現網頁的動態效果 * 最開始渲染引擎和`JS`引擎并沒有區分的很明確，后來JS引擎越來越獨立，內核就傾向于只指渲染引擎 **常見的瀏覽器內核有哪些** * `Trident`內核：`IE,MaxThon,TT,The World,360`,搜狗瀏覽器等。\[又稱MSHTML\] * `Gecko`內核：`Netscape6`及以上版本，`FF,MozillaSuite/SeaMonkey`等 * `Presto`內核：`Opera7`及以上。 \[`Opera`內核原為：Presto，現為：`Blink`;\] * `Webkit`內核：`Safari,Chrome`等。 \[ `Chrome`的`Blink`（`WebKit`的分支）\] ### 9 html5有哪些新特性、移除了那些元素？ * `HTML5` 現在已經不是 `SGML` 的子集，主要是關于圖像，位置，存儲，多任務等功能的增加 * 新增選擇器 `document.querySelector`、`document.querySelectorAll` * 拖拽釋放(`Drag and drop`) API * 媒體播放的 `video` 和 `audio` * 本地存儲 `localStorage` 和 `sessionStorage` * 離線應用 `manifest` * 桌面通知 `Notifications` * 語意化標簽 `article`、`footer`、`header`、`nav`、`section` * 增強表單控件 `calendar`、`date`、`time`、`email`、`url`、`search` * 地理位置 `Geolocation` * 多任務 `webworker` * 全雙工通信協議 `websocket` * 歷史管理 `history` * 跨域資源共享(CORS) `Access-Control-Allow-Origin` * 頁面可見性改變事件 `visibilitychange` * 跨窗口通信 `PostMessage` * `Form Data` 對象 * 繪畫 `canvas` * 移除的元素： * 純表現的元素：`basefont`、`big`、`center`、`font`、 `s`、`strike`、`tt`、`u` * 對可用性產生負面影響的元素：`frame`、`frameset`、`noframes` * 支持`HTML5`新標簽： * `IE8/IE7/IE6`支持通過`document.createElement`方法產生的標簽 * 可以利用這一特性讓這些瀏覽器支持`HTML5`新標簽 * 瀏覽器支持新標簽后，還需要添加標簽默認的樣式 * 當然也可以直接使用成熟的框架、比如`html5shim` **如何區分 HTML 和 HTML5** * `DOCTYPE`聲明、新增的結構元素、功能元素 ### 10 `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 ~~~ ### 11 瀏覽器是怎么對`HTML5`的離線儲存資源進行管理和加載的呢 * 在線的情況下，瀏覽器發現`html`頭部有`manifest`屬性，它會請求`manifest`文件，如果是第一次訪問`app`，那么瀏覽器就會根據manifest文件的內容下載相應的資源并且進行離線存儲。如果已經訪問過`app`并且資源已經離線存儲了，那么瀏覽器就會使用離線的資源加載頁面，然后瀏覽器會對比新的`manifest`文件與舊的`manifest`文件，如果文件沒有發生改變，就不做任何操作，如果文件改變了，那么就會重新下載文件中的資源并進行離線存儲。 * 離線的情況下，瀏覽器就直接使用離線存儲的資源。 ### 12 請描述一下 `cookies`，`sessionStorage` 和 `localStorage` 的區別？ * `cookie`是網站為了標示用戶身份而儲存在用戶本地終端（Client Side）上的數據（通常經過加密） * cookie數據始終在同源的http請求中攜帶（即使不需要），記會在瀏覽器和服務器間來回傳遞 * `sessionStorage`和`localStorage`不會自動把數據發給服務器，僅在本地保存 * 存儲大小： * `cookie`數據大小不能超過4k * `sessionStorage`和`localStorage`雖然也有存儲大小的限制，但比`cookie`大得多，可以達到5M或更大 * 有期時間： * `localStorage` 存儲持久數據，瀏覽器關閉后數據不丟失除非主動刪除數據 * `sessionStorage` 數據在當前瀏覽器窗口關閉后自動刪除 * `cookie` 設置的`cookie`過期時間之前一直有效，即使窗口或瀏覽器關閉 ### 13 iframe有那些缺點？ * `iframe`會阻塞主頁面的`Onload`事件 * 搜索引擎的檢索程序無法解讀這種頁面，不利于`SEO` * `iframe`和主頁面共享連接池，而瀏覽器對相同域的連接有限制，所以會影響頁面的并行加載 * 使用`iframe`之前需要考慮這兩個缺點。如果需要使用`iframe`，最好是通過`javascript`動態給`iframe`添加`src`屬性值，這樣可以繞開以上兩個問題 ### 14 WEB標準以及W3C標準是什么? * 標簽閉合、標簽小寫、不亂嵌套、使用外鏈`css`和`js`、結構行為表現的分離 ### 15 xhtml和html有什么區別? * 一個是功能上的差別 * 主要是`XHTML`可兼容各大瀏覽器、手機以及`PDA`，并且瀏覽器也能快速正確地編譯網頁 * 另外是書寫習慣的差別 * `XHTML` 元素必須被正確地嵌套，閉合，區分大小寫，文檔必須擁有根元素 ### 16 Doctype作用? 嚴格模式與混雜模式如何區分？它們有何意義? * 頁面被加載的時，`link`會同時被加載，而`@imort`頁面被加載的時，`link`會同時被加載，而`@import`引用的`CSS`會等到頁面被加載完再加載 `import`只在`IE5`以上才能識別，而`link`是`XHTML`標簽，無兼容問題 `link`方式的樣式的權重 高于`@import`的權重 * `<!DOCTYPE>` 聲明位于文檔中的最前面，處于 `<html>` 標簽之前。告知瀏覽器的解析器， 用什么文檔類型 規范來解析這個文檔 * 嚴格模式的排版和 `JS` 運作模式是 以該瀏覽器支持的最高標準運行 * 在混雜模式中，頁面以寬松的向后兼容的方式顯示。模擬老式瀏覽器的行為以防止站點無法工作。 `DOCTYPE`不存在或格式不正確會導致文檔以混雜模式呈現 ### 17 行內元素有哪些？塊級元素有哪些？ 空(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>` * 行內元素不可以設置寬高，不獨占一行 * 塊級元素可以設置寬高，獨占一行 ### 18 HTML全局屬性(global attribute)有哪些 * `class`:為元素設置類標識 * `data-*`: 為元素增加自定義屬性 * `draggable`: 設置元素是否可拖拽 * `id`: 元素`id`，文檔內唯一 * `lang`: 元素內容的的語言 * `style`: 行內`css`樣式 * `title`: 元素相關的建議信息 ### 19 Canvas和SVG有什么區別？ * `svg`繪制出來的每一個圖形的元素都是獨立的`DOM`節點，能夠方便的綁定事件或用來修改。`canvas`輸出的是一整幅畫布 * `svg`輸出的圖形是矢量圖形，后期可以修改參數來自由放大縮小，不會失真和鋸齒。而`canvas`輸出標量畫布，就像一張圖片一樣，放大會失真或者鋸齒 ### 20 HTML5 為什么只需要寫 * `HTML5` 不基于 `SGML`，因此不需要對`DTD`進行引用，但是需要`doctype`來規范瀏覽器的行為 * 而`HTML4.01`基于`SGML`,所以需要對`DTD`進行引用，才能告知瀏覽器文檔所使用的文檔類型 ### 21 如何在頁面上實現一個圓形的可點擊區域？ * `svg` * `border-radius` * 純`js`實現 需要求一個點在不在圓上簡單算法、獲取鼠標坐標等等 ### 22 網頁驗證碼是干嘛的，是為了解決什么安全問題 * 區分用戶是計算機還是人的公共全自動程序。可以防止惡意破解密碼、刷票、論壇灌水 * 有效防止黑客對某一個特定注冊用戶用特定程序暴力破解方式進行不斷的登陸嘗試 ### 23 viewport ~~~html <meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no" /> // width 設置viewport寬度，為一個正整數，或字符串‘device-width’ // device-width 設備寬度 // height 設置viewport高度，一般設置了寬度，會自動解析出高度，可以不用設置 // initial-scale 默認縮放比例（初始縮放比例），為一個數字，可以帶小數 // minimum-scale 允許用戶最小縮放比例，為一個數字，可以帶小數 // maximum-scale 允許用戶最大縮放比例，為一個數字，可以帶小數 // user-scalable 是否允許手動縮放 ~~~ * 延伸提問 * 怎樣處理 移動端 `1px` 被 渲染成 `2px`問題 **局部處理** * `meta`標簽中的 `viewport`屬性 ，`initial-scale` 設置為 `1` * `rem`按照設計稿標準走，外加利用`transfrome` 的`scale(0.5)` 縮小一倍即可； **全局處理** * `mate`標簽中的 `viewport`屬性 ，`initial-scale` 設置為 `0.5` * `rem` 按照設計稿標準走即可 ### 24 渲染優化 * 禁止使用`iframe`（阻塞父文檔`onload`事件） * `iframe`會阻塞主頁面的`Onload`事件 * 搜索引擎的檢索程序無法解讀這種頁面，不利于SEO * `iframe`和主頁面共享連接池，而瀏覽器對相同域的連接有限制，所以會影響頁面的并行加載 * 使用`iframe`之前需要考慮這兩個缺點。如果需要使用`iframe`，最好是通過`javascript` * 動態給`iframe`添加`src`屬性值，這樣可以繞開以上兩個問題 * 禁止使用`gif`圖片實現`loading`效果（降低`CPU`消耗，提升渲染性能） * 使用`CSS3`代碼代替`JS`動畫（盡可能避免重繪重排以及回流） * 對于一些小圖標，可以使用base64位編碼，以減少網絡請求。但不建議大圖使用，比較耗費`CPU` * 小圖標優勢在于 * 減少`HTTP`請求 * 避免文件跨域 * 修改及時生效 * 頁面頭部的`<style></style>` `<script></script>` 會阻塞頁面；（因為 `Renderer`進程中 `JS`線程和渲染線程是互斥的） * 頁面中空的 `href` 和 `src` 會阻塞頁面其他資源的加載 (阻塞下載進程) * 網頁`gzip`，`CDN`托管，`data`緩存 ，圖片服務器 * 前端模板 JS+數據，減少由于`HTML`標簽導致的帶寬浪費，前端用變量保存AJAX請求結果，每次操作本地變量，不用請求，減少請求次數 * 用`innerHTML`代替`DOM`操作，減少`DOM`操作次數，優化`javascript`性能 * 當需要設置的樣式很多時設置`className`而不是直接操作`style` * 少用全局變量、緩存`DOM`節點查找的結果。減少`IO`讀取操作 * 圖片預加載，將樣式表放在頂部，將腳本放在底部 加上時間戳 * 對普通的網站有一個統一的思路，就是盡量向前端優化、減少數據庫操作、減少磁盤`IO` ### 25 meta viewport相關 ~~~html <!DOCTYPE html> <!--H5標準聲明，使用 HTML5 doctype，不區分大小寫--> <head lang=”en”> <!--標準的 lang 屬性寫法--> <meta charset=’utf-8′> <!--聲明文檔使用的字符編碼--> <meta http-equiv=”X-UA-Compatible” content=”IE=edge,chrome=1″/> <!--優先使用 IE 最新版本和 Chrome--> <meta name=”description” content=”不超過150個字符”/> <!--頁面描述--> <meta name=”keywords” content=””/> <!-- 頁面關鍵詞--> <meta name=”author” content=”name, email@gmail.com”/> <!--網頁作者--> <meta name=”robots” content=”index,follow”/> <!--搜索引擎抓取--> <meta name=”viewport” content=”initial-scale=1, maximum-scale=3, minimum-scale=1, user-scalable=no”> <!--為移動設備添加 viewport--> <meta name=”apple-mobile-web-app-title” content=”標題”> <!--iOS 設備 begin--> <meta name=”apple-mobile-web-app-capable” content=”yes”/> <!--添加到主屏后的標題（iOS 6 新增） 是否啟用 WebApp 全屏模式，刪除蘋果默認的工具欄和菜單欄--> <meta name=”apple-itunes-app” content=”app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL”> <!--添加智能 App 廣告條 Smart App Banner（iOS 6+ Safari）--> <meta name=”apple-mobile-web-app-status-bar-style” content=”black”/> <meta name=”format-detection” content=”telphone=no, email=no”/> <!--設置蘋果工具欄顏色--> <meta name=”renderer” content=”webkit”> <!-- 啟用360瀏覽器的極速模式(webkit)--> <meta http-equiv=”X-UA-Compatible” content=”IE=edge”> <!--避免IE使用兼容模式--> <meta http-equiv=”Cache-Control” content=”no-siteapp” /> <!--不讓百度轉碼--> <meta name=”HandheldFriendly” content=”true”> <!--針對手持設備優化，主要是針對一些老的不識別viewport的瀏覽器，比如黑莓--> <meta name=”MobileOptimized” content=”320″> <!--微軟的老式瀏覽器--> <meta name=”screen-orientation” content=”portrait”> <!--uc強制豎屏--> <meta name=”x5-orientation” content=”portrait”> <!--QQ強制豎屏--> <meta name=”full-screen” content=”yes”> <!--UC強制全屏--> <meta name=”x5-fullscreen” content=”true”> <!--QQ強制全屏--> <meta name=”browsermode” content=”application”> <!--UC應用模式--> <meta name=”x5-page-mode” content=”app”> <!-- QQ應用模式--> <meta name=”msapplication-tap-highlight” content=”no”> <!--windows phone 點擊無高亮 設置頁面不緩存--> <meta http-equiv=”pragma” content=”no-cache”> <meta http-equiv=”cache-control” content=”no-cache”> <meta http-equiv=”expires” content=”0″> ~~~ ### 26 你做的頁面在哪些流覽器測試過？這些瀏覽器的內核分別是什么? * `IE`: `trident`內核 * `Firefox`：`gecko`內核 * `Safari`:`webkit`內核 * `Opera`:以前是`presto`內核，`Opera`現已改用Google - `Chrome`的`Blink`內核 * `Chrome:Blink`(基于`webkit`，Google與Opera Software共同開發) ### 27 div+css的布局較table布局有什么優點？ * 改版的時候更方便 只要改`css`文件。 * 頁面加載速度更快、結構化清晰、頁面顯示簡潔。 * 表現與結構相分離。 * 易于優化（`seo`）搜索引擎更友好，排名更容易靠前。 ### 28 a：img的alt與title有何異同？b：strong與em的異同？ * `alt(alt text)`:為不能顯示圖像、窗體或`applets`的用戶代理（`UA`），`alt`屬性用來指定替換文字。替換文字的語言由`lang`屬性指定。(在IE瀏覽器下會在沒有`title`時把`alt`當成 `tool tip`顯示) * `title(tool tip)`:該屬性為設置該屬性的元素提供建議性的信息 * `strong`:粗體強調標簽，強調，表示內容的重要性 * `em`:斜體強調標簽，更強烈強調，表示內容的強調點 ### 29 你能描述一下漸進增強和優雅降級之間的不同嗎 * 漸進增強：針對低版本瀏覽器進行構建頁面，保證最基本的功能，然后再針對高級瀏覽器進行效果、交互等改進和追加功能達到更好的用戶體驗。 * 優雅降級：一開始就構建完整的功能，然后再針對低版本瀏覽器進行兼容。 > 區別：優雅降級是從復雜的現狀開始，并試圖減少用戶體驗的供給，而漸進增強則是從一個非常基礎的，能夠起作用的版本開始，并不斷擴充，以適應未來環境的需要。降級（功能衰減）意味著往回看；而漸進增強則意味著朝前看，同時保證其根基處于安全地帶 ### 30 為什么利用多個域名來存儲網站資源會更有效？ * `CDN`緩存更方便 * 突破瀏覽器并發限制 * 節約`cookie`帶寬 * 節約主域名的連接數，優化頁面響應速度 * 防止不必要的安全問題 ### 31 簡述一下src與href的區別 * `src`用于替換當前元素，href用于在當前文檔和引用資源之間確立聯系。 * `src`是`source`的縮寫，指向外部資源的位置，指向的內容將會嵌入到文檔中當前標簽所在位置；在請求`src`資源時會將其指向的資源下載并應用到文檔內，例如`js`腳本，`img`圖片和`frame`等元素 > `<script src ="js.js"></script>` 當瀏覽器解析到該元素時，會暫停其他資源的下載和處理，直到將該資源加載、編譯、執行完畢，圖片和框架等元素也如此，類似于將所指向資源嵌入當前標簽內。這也是為什么將js腳本放在底部而不是頭部 * `href`是`Hypertext Reference`的縮寫，指向網絡資源所在位置，建立和當前元素（錨點）或當前文檔（鏈接）之間的鏈接，如果我們在文檔中添加 * `<link href="common.css" rel="stylesheet"/>`那么瀏覽器會識別該文檔為`css`文件，就會并行下載資源并且不會停止對當前文檔的處理。這也是為什么建議使用`link`方式來加載`css`，而不是使用`@import`方式 ### 32 知道的網頁制作會用到的圖片格式有哪些？ * `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`成為下一代動態圖標準 ### 33 在css/js代碼上線之后開發人員經常會優化性能，從用戶刷新網頁開始，一次js請求一般情況下有哪些地方會有緩存處理？ > `dns`緩存，`cdn`緩存，瀏覽器緩存，服務器緩存 ### 33 一個頁面上有大量的圖片（大型電商網站），加載很慢，你有哪些方法優化這些圖片的加載，給用戶更好的體驗。 * 圖片懶加載，在頁面上的未可視區域可以添加一個滾動事件，判斷圖片位置與瀏覽器頂端的距離與頁面的距離，如果前者小于后者，優先加載。 * 如果為幻燈片、相冊等，可以使用圖片預加載技術，將當前展示圖片的前一張和后一張優先下載。 * 如果圖片為css圖片，可以使用`CSSsprite`，`SVGsprite`，`Iconfont`、`Base64`等技術。 * 如果圖片過大，可以使用特殊編碼的圖片，加載時會先加載一張壓縮的特別厲害的縮略圖，以提高用戶體驗。 * 如果圖片展示區域小于圖片的真實大小，則因在服務器端根據業務需要先行進行圖片壓縮，圖片壓縮后大小與展示一致。 ### 34 常見排序算法的時間復雜度,空間復雜度  ### 35 web開發中會話跟蹤的方法有哪些 * `cookie` * `session` * `url`重寫 * 隱藏`input` * `ip`地址 ### 36 HTTP request報文結構是怎樣的 1. 首行是**Request-Line**包括：**請求方法**，**請求URI**，**協議版本**，**CRLF** 2. 首行之后是若干行**請求頭**，包括**general-header**，**request-header**或者**entity-header**，每個一行以CRLF結束 3. 請求頭和消息實體之間有一個**CRLF分隔** 4. 根據實際請求需要可能包含一個**消息實體** 一個請求報文例子如下： ~~~ GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1 Host: www.w3.org Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 Referer: https://www.google.com.hk/ Accept-Encoding: gzip,deflate,sdch Accept-Language: zh-CN,zh;q=0.8,en;q=0.6 Cookie: authorstyle=yes If-None-Match: "2cc8-3e3073913b100" If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT name=qiu&age=25 ~~~ ### 37 HTTP response報文結構是怎樣的 * 首行是狀態行包括：**HTTP版本，狀態碼，狀態描述**，后面跟一個CRLF * 首行之后是**若干行響應頭**，包括：**通用頭部，響應頭部，實體頭部** * 響應頭部和響應實體之間用**一個CRLF空行**分隔 * 最后是一個可能的**消息實體** 響應報文例子如下： ~~~ HTTP/1.1 200 OK Date: Tue, 08 Jul 2014 05:28:43 GMT Server: Apache/2 Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT ETag: "40d7-3e3073913b100" Accept-Ranges: bytes Content-Length: 16599 Cache-Control: max-age=21600 Expires: Tue, 08 Jul 2014 11:28:43 GMT P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml" Content-Type: text/html; charset=iso-8859-1 {"name": "qiu", "age": 25} ~~~ ### 38 title與h1的區別、b與strong的區別、i與em的區別 * `title`屬性沒有明確意義只表示是個標題，H1則表示層次明確的標題，對頁面信息的抓取也有很大的影響 * `strong`是標明重點內容，有語氣加強的含義，使用閱讀設備閱讀網絡時：`<strong>`會重讀，而`<B>`是展示強調內容 * i內容展示為斜體，em表示強調的文本 ### 39 請你談談Cookie的弊端 > `cookie`雖然在持久保存客戶端數據提供了方便，分擔了服務器存儲的負擔，但還是有很多局限性的 * 每個特定的域名下最多生成`20`個`cookie` * `IE6`或更低版本最多`20`個`cookie` * `IE7`和之后的版本最后可以有`50`個`cookie` * `Firefox`最多50個`cookie` * `chrome`和`Safari`沒有做硬性限制 * IE 和 Opera 會清理近期最少使用的 `cookie`，`Firefox` 會隨機清理 `cookie` * `cookie` 的最大大約為 `4096` 字節，為了兼容性，一般設置不超過 `4095` 字節 * 如果 `cookie` 被人攔截了，就可以取得所有的 `session` 信息 ### 40 git fetch和git pull的區別 * `git pull`：相當于是從遠程獲取最新版本并`merge`到本地 * `git fetch`：相當于是從遠程獲取最新版本到本地，不會自動`merge`