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標準(結構、表現、行爲分離)有哪些優勢呢?
可用性:產品是否容易上手,用戶體驗怎麼樣,可用性好是企業的核心競爭力
可維護性:出現問題時,修復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語義化是指根據內容的結構化(內容語義化),選擇合適的標籤(代碼語義化)便於開發者閱讀和寫出更優雅的代碼的同時讓瀏覽器的爬蟲和及其很好的解析。
七、爲何要語義化呢?
十一、html文檔具備哪些特色
結構化、簡單、已維護與平臺無關
十二、HTML5 爲何只須要寫 !DOCTYPE HTML?
HTML5 不基於 SGML,所以不須要對DTD進行引用,可是須要doctype來規範瀏覽器的行爲(讓瀏覽器按照它們應該的方式來運行);
而HTML4.01基於SGML,因此須要對DTD進行引用,才能告知瀏覽器文檔所使用的文檔類型。
1三、Doctype做用?標準模式與兼容模式各有什麼區別?
!DOCTYPE聲明位於位於HTML文檔中的第一行,處於html 標籤以前。告知瀏覽器的解析器用什麼文檔標準解析這個文檔。
DOCTYPE不存在或格式不正確會致使文檔以兼容模式呈現。
標準模式的排版 和JS運做模式都是以該瀏覽器支持的最高標準運行。在兼容模式中,頁面以寬鬆的向後兼容的方式顯示,模擬老式瀏覽器的行爲以防止站點沒法工做。
1四、html5有哪些新特性、移除了那些元素?如何處理HTML5新標籤的瀏覽器兼容問題?如何區分 HTML 和html5
1五、請描述一下 cookies,sessionStorage 和 localStorage 的區別?
共同點:都是保存在瀏覽器端,且同源的。
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端優化的策略不少,如 YSlow(YSlow 是 Yahoo 發佈的一款 Firefox 插件,現 Chrome 也可安裝,能夠對網站的頁面性能進行分析,提出對該頁面性能優化的建議)原則,或者 Chrome 自帶的 Audits 等,總結起來主要包括網絡加載類、頁面渲染類、CSS 優化類、JavaScript 執行類、緩存類、圖片類、架構協議類等幾類,下面逐一介紹。
在前端頁面中,一般建議儘量合併靜態資源圖片、JavaScript 或 CSS 代碼,減小頁面請求數和資源請求消耗,這樣能夠縮短頁面首次訪問的用戶等待時間。經過構建工具合併雪碧圖、CSS、JavaScript 文件等都是爲了減小 HTTP 資源請求次數。另外也要儘可能避免重複的資源,防止增長多餘請求。
除了減小 HTTP 資源請求次數,也要儘可能減少每一個 HTTP 請求的大小。如減小不必的圖片、JavaScript、CSS 及 HTML 代碼,對文件進行壓縮優化,或者使用 gzip 壓縮傳輸內容等均可以用來減少文件大小,縮短網絡傳輸等待時延。前面咱們使用構建工具來壓縮靜態圖片資源以及移除代碼中的註釋並壓縮,目的都是爲了減少 HTTP 請求的大小。
<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>
當<link>
標籤的 href 屬性爲空,或<script>
、<img>
、<iframe>
標籤的 src 屬性爲空時,瀏覽器在渲染的過程當中仍會將 href 屬性或 src 屬性中的空內容進行加載,直至加載失敗,這樣就阻塞了頁面中其餘資源的下載進程,並且最終加載到的內容是無效的,所以要儘可能避免。
<!--不推薦-->
<img src="" alt="photo" > <a href="">點擊連接</a>
爲 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">
合理設置 Etag 和 Last-Modified 使用瀏覽器緩存,對於未修改的文件,靜態資源服務器會向瀏覽器端返回304,讓瀏覽器從緩存中讀取文件,減小 Web 資源下載的帶寬消耗並下降服務器負載。
<meta http-equiv="last-modified" content="Sun,05 Nov 2017 13:45:57 GMT">
頁面每次重定向都會延長頁面內容返回的等待延時,一次重定向大約須要200毫秒不等的時間開銷(無緩存),爲了保證用戶儘快看到頁面內容,要儘可能避免頁面重定向。
瀏覽器在同一時刻向同一個域名請求文件的並行下載數是有限的,所以能夠利用多個域名的主機來存放不一樣的靜態資源,增大頁面加載時資源的並行下載數,縮短頁面資源加載的時間。一般根據多個域名來分別存儲 JavaScript、CSS 和圖片文件。
<link rel="stylesheet" href="//cdn1.domain.com/path/main.css" > ... <script src="//cdn2.domain.com/path/main.js"></script>
若是條件容許,能夠利用 CDN 網絡加快同一個地理區域內重複靜態資源文件的響應下載速度,縮短資源請求時間。
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>
對於返回內容相同的請求,不必每次都直接從服務端拉取,合理使用 AJAX 緩存能加快 AJAX 響應速度並減輕服務器壓力。
$.ajax({
url : url,
type : 'get', cache : true, //推薦使用緩存 data : {}, success (){//...}, error (){//...} });
使用 XMLHttpRequest 時,瀏覽器中的 POST 方法會發起兩次 TCP 數據包傳輸,首先發送文件頭,而後發送 HTTP 正文數據。而使用 GET 時只發送頭部,因此在拉取服務端數據時使用 GET 請求效率更高。
$.ajax({
url : url,
type : 'get', //推薦使用get完成請求 data : {}, success (){//...}, error(){//...} });
HTTP 請求一般默認帶上瀏覽器端的 Cookie 一塊兒發送給服務器,因此在非必要的狀況下,要儘可能減小 Cookie 來減少 HTTP 請求的大小。對於靜態資源,儘可能使用不一樣的域名來存放,由於 Cookie 默認是不能跨域的,這樣就作到了不一樣域名下靜態資源請求的 Cookie 隔離。
有利於 favicon.ico 的重複加載,由於通常一個 Web 應用的 favicon.ico 是不多改變的。
異步的 JavaScript 資源不會阻塞文檔解析,因此容許在瀏覽器中優先渲染頁面,延後加載腳本執行。例如 JavaScript 的引用能夠以下設置,也可使用模塊化加載機制來實現。
<script src="main.js" defer></script> <script src="main.js" async></script>
使用 async 時,加載和渲染後續文檔元素的過程和 main.js 的加載與執行是並行的。使用 defer 時,加載後續文檔元素的過程和 main.js 的加載是並行的,可是 main.js 的執行要在頁面全部元素解析完成以後纔開始執行。
對於頁面中加載時間過長的 CSS 或 JavaScript 文件,須要進行合理拆分或延後加載,保證關鍵路徑的資源能快速加載完成。
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" >
通常推薦將全部 CSS 資源儘早指定在 HTML 文檔 <head>
中,這樣瀏覽器能夠優先下載 CSS 並儘早完成頁面渲染。
JavaScript 資源放到 HTML 文檔底部能夠防止 JavaScript 的加載和解析執行對頁面渲染形成阻塞。因爲 JavaScript 資源默認是解析阻塞的,除非被標記爲異步或者經過其餘的異步方式加載,不然會阻塞 HTML DOM 解析和 CSS 渲染的過程。
在加載大量的圖片元素時,儘可能預先限定圖片的尺寸大小,不然在圖片加載過程當中會更新圖片的排版信息,產生大量的重排
在 HTML 中直接縮放圖片會致使頁面內容的重排重繪,此時可能會使頁面中的其餘操做產生卡頓,所以要儘可能減小在頁面中直接進行圖片縮放。
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="圖片" >
CSS 解析匹配到 渲染樹的過程是從右到左的逆向匹配,在選擇器末尾添加通配符至少會增長一倍多計算量。
直接使用惟一的類名便可最大限度的提高渲染引擎繪製渲染樹等效率
JS 直接操做 DOM 極容易引發頁面的重排
儘可能使用 CSS3 的 translate、scale 屬性代替 top、left 和 height、width,避免大量的重排計算
<table>
、<iframe>
<table>
內容的渲染是將 table 的 DOM 渲染樹所有生成完並一次性繪製到頁面上的,因此在長表格渲染時很耗性能,應該儘可能避免使用它,能夠考慮使用列表元素 <ul>
代替。儘可能使用異步的方式動態添加 iframe,由於 iframe 內資源的下載進程會阻塞父頁面靜態資源的下載與 CSS 及 HTML DOM 的解析。
長時間運行的 JavaScript 會阻塞瀏覽器構建 DOM 樹、DOM 渲染樹、渲染頁面。因此,任何與頁面初次渲染無關的邏輯功能都應該延遲加載執行,這和 JavaScript 資源的異步加載思路是一致的。
CSS 表達式或 CSS 濾鏡的解析渲染速度是比較慢的,在有其餘解決方案的狀況下應該儘可能避免使用。
//不推薦 .opacity{ filter : progid : DXImageTransform.Microsoft.Alpha( opacity = 50 ); }
相對於桌面端瀏覽器,移動端 Web 瀏覽器上有一些較爲明顯的特色:設備屏幕較小、新特性兼容性較好、支持一些較新的 HTML5 和 CSS3 特性、須要與 Native 應用交互等。但移動端瀏覽器可用的 CPU 計算資源和網絡資源極爲有限,所以要作好移動端 Web 上的優化每每須要作更多的事情。首先,在移動端 Web 的前端頁面渲染中,桌面瀏覽器端上的優化規則一樣適用,此外針對移動端也要作一些極致的優化來達到更好的效果。須要注意的是,並非移動端的優化原則在桌面瀏覽器端就不適用,而是因爲兼容性和差別性的緣由,一些優化原則在移動端更具表明性。
爲了進一步提高頁面加載速度,能夠考慮將頁面的數據請求儘量提早,避免在 JavaScript 加載完成後纔去請求數據。一般數據請求是頁面內容渲染中關鍵路徑最長的部分,並且不能並行,因此若是能將數據請求提早,能夠極大程度上縮短頁面內容的渲染完成時間。
因爲移動端網絡速度相對較慢,網絡資源有限,所以爲了儘快完成頁面內容的加載,須要保證首屏加載資源最小化,非首屏內容使用滾動的方式異步加載。通常推薦移動端頁面首屏數據展現延時最長不超過3秒。目前中國聯通 3G 的網絡速度爲 338KB/s(2.71Mb/s),因此推薦首屏全部資源大小不超過 1014KB,即大約不超過 1MB。
在移動端資源加載中,儘可能保證 JavaScript 資源並行加載,主要指的是模塊化 JavaScript 資源的異步加載,例如AMD的異步模塊,使用並行的加載方式可以縮短多個文件資源的加載時間。
一般爲了在 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>
設置文件資源的 DNS 預解析,讓瀏覽器提早解析獲取靜態資源的主機 IP,避免等到請求時才發起 DNS 解析請求。一般在移動端 HTML 中能夠採用以下方式完成。
<!--cdn域名預解析-->
<meta http-equiv="x-dns-prefetch-control" content="on" > <link rel="dns-prefetch" href="//cdn.domain.com" >
對於移動端首屏加載後可能會被使用的資源,須要在首屏完成加載後儘快進行加載,保證在用戶須要瀏覽時已經加載完成,這時候若是再去異步請求就顯得很慢。
一般狀況下,咱們認爲 TCP 網絡傳輸的最大傳輸單元(Maximum Transmission Unit,MTU)爲 1500B,即一個RTT(Round-Trip Time,網絡請求往返時間)內能夠傳輸的數據量最大爲 1500 字節。所以,在先後端分離的開發模式中,儘可能保證頁面的 HTML 內容在 1KB 之內,這樣整個 HTML 的內容請求就能夠在一個 RTT 內請求完成,最大限度地提升 HTML 載入速度。
除了上面說到的使用 Cache-Control、Expires、Etag 和 Last-Modified 來設置 HTTP 緩存外,在移動端還可使用 localStorage 等來保存 AJAX 返回的數據,或者使用 localStorage 保存 CSS 或 JavaScript 靜態資源內容,實現移動端的離線應用,儘量減小網絡請求,保證靜態資源內容的快速加載。
對於移動端或 Hybrid 應用,能夠設置離線文件或離線包機制讓靜態資源請求從本地讀取,加快資源載入速度,並實現離線更新。關於這塊內容,咱們會在後面的章節中重點講解。
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>
PWA(Progressive Web Apps)是 Google 提出的用前沿的 Web 技術爲網頁提供 App 般使用體驗的一系列方案。
在移動端,一般要保證頁面中一切用到的圖片都是通過壓縮優化處理的,而不是以原圖的形式直接使用的,由於那樣很消耗流量,並且加載時間更長。
在頁面使用的背景圖片很少且較小的狀況下,能夠將圖片轉化成 base64 編碼嵌入到 HTML 頁面或 CSS 文件中,這樣能夠減小頁面的 HTTP 請求數。須要注意的是,要保證圖片較小,通常圖片大小超過 2KB 就不推薦使用 base64 嵌入顯示了。
.class-name{
background-image : url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAALCAMAAABxsOwqAAAAYFBMVEWnxwusyQukxQudwQyZvgyhxAyfwgyxzAsUHQGOuA0aJAERGAFIXwSTugyEqgtqhghQZgUwQQIpOQKbuguVtQuKrAuCowp2kQlheghTbQZHWQU7SwVAVgQ6TgQlLwMeKwFOemyQAAAAVElEQVQI1y3JVRaAIAAF0UconXbvf5ei8HfPDIQQhBAAFE10iKig3SLRNN4SP/p+N08VC0YnfIlNWtqIkhg/TPYbCvhqdHAWRXPZSp3g3CWZvVLXC6OJA3ukv0AaAAAAAElFTkSuQmCC'); }
使用具備較高壓縮比格式的圖片,如 webp(須要設計降級兼容方案)等。在同等圖片畫質的狀況下,高壓縮比格式的圖片體積更小,可以更快完成文件傳輸,節省網絡流量。
<img src="//cdn.domain.com/path/photo.webp" alt="webp格式圖片" >
爲了保證頁面內容的最小化,加速頁面的渲染,儘量節省移動端網絡流量,頁面中的圖片資源推薦使用懶加載實現,在頁面滾動時動態載入圖片。
<img data-src="//cdn.domain.com/path/photo.jpg" alt="懶加載圖片" >
在介紹響應式的章節中咱們瞭解到,針對不一樣的移動端屏幕尺寸和分辨率,輸出不一樣大小的圖片或背景圖能保證在用戶體驗不下降的前提下節省網絡流量,加快部分機型的圖片加載速度,這在移動端很是值得推薦。
在頁面中儘量使用 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"); }
加載的單張圖片通常建議不超過 30KB,避免大圖片加載時間長而阻塞頁面其餘資源的下載,所以推薦在 10KB 之內。若是用戶上傳的圖片過大,建議設置告警系統,幫助咱們觀察瞭解整個網站的圖片流量狀況,作出進一步的改善。
對於一些「永遠」不會變的圖片可使用強緩存的方式緩存在用戶的瀏覽器上。
選擇器選擇頁面 DOM 元素時儘可能使用 id 選擇器,由於 id 選擇器速度最快。
對於須要重複使用的 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');
使用事件代理能夠避免對每一個元素都進行綁定,而且能夠避免出現內存泄露及須要動態添加元素的事件綁定問題,因此儘可能不要直接使用事件綁定。
//不推薦
$('.btn').on('click',function(e){ console.log(this); }); //推薦 $('body').on('click','.btn',function(e){ console.log(this); });
因爲移動端屏幕的設計, 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); });
須要對 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); });
這些都是一些基礎的安全腳本編寫問題,儘量使用較高效率的特性來完成這些操做,避免不規範或不安全的寫法。
ECMAScript6+ 必定程度上更加安全高效,並且部分特性執行速度更快,也是將來規範的須要,因此推薦使用 ECMAScript6+ 的新特性來完成後面的開發。
通常認爲,在移動端設置 Viewport 能夠加速頁面的渲染,同時能夠避免縮放致使頁面重排重繪。在移動端固定 Viewport 設置的方法以下。
<!--設置viewport不縮放-->
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no">
頁面的重排重繪很耗性能,因此必定要儘量減小頁面的重排重繪,例如頁面圖片大小變化、元素位置變化等這些狀況都會致使重排重繪。
使用 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);
選擇 Canvas 或 requestAnimationFrame 等更高效的動畫實現方式,儘可能避免使用 setTimeout、setInterval 等方式來直接處理連續動畫。
部分狀況下能夠考慮使用 SVG 代替圖片實現動畫,由於使用 SVG 格式內容更小,並且 SVG DOM 結構方便調整。
在 DOM 渲染樹生成後的佈局渲染階段,使用 float 的元素佈局計算比較耗性能,因此儘可能減小 float 的使用,推薦使用固定佈局或 flex-box 彈性佈局的方式來實現頁面元素佈局。
過多的 font-size 聲明會增長字體的大小計算,並且也沒有必要的。
腳本容錯能夠避免「非正常環境」的執行錯誤影響頁面的加載和不相關功能的使用
在條件容許的狀況下能夠考慮使用 SPDY 協議來進行文件資源傳輸,利用鏈接複用加快傳輸過程,縮短資源加載時間。HTTP2 在將來也是能夠考慮嘗試的。
使用後端數據渲染的方式能夠加快頁面內容的渲染展現,避免空白頁面的出現,同時能夠解決移動端頁面SEO的問題。若是條件容許,後端數據渲染是一個很不錯的實踐思路。後面的章節會詳細介紹後端數據渲染的相關內容。
能夠嘗試使用 NativeView 的 MNV* 開發模式來避免 HTML DOM 性能慢的問題,目前使用 MNV* 的開發模式已經能夠將頁面內容渲染體驗作到接近客戶端 Native 應用的體驗了。但須要避免 js Framework 和 native Framework 的頻繁交互。
同源策略是由Netscape提出的著名安全策略,是瀏覽器最核心、基本的安全功能,它限制了一個源(origin)中加載文本或者腳本與來自其餘源(origin)中資源的交互方式
,所謂的同源就是指協議、域名、端口相同。
當瀏覽器執行一個腳本時會檢查是否同源,只有同源的腳本纔會執行,若是不一樣源即爲跨域
在項目中可能會須要在一個域名下請求另一個域名的資源,下面咱們來探討下跨域的幾種實現方式
最多見的一種跨域方式,其背後原理就是利用了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中打開控制檯能夠看到返回數據的輸出:
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)); } })
能夠在開發者工具裏面看到請求的詳細信息,而且在控制檯也能夠看到返回的數據輸出:
在先後端分離的項目中能夠藉助服務器實現跨域,具體作法是:前端向本地服務器發送請求,本地服務器代替前端再向�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 頁面打開控制檯能夠看到數據輸出:
在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
到顯示頁面的步驟
Expires
和Cache-Control
:script
,meta
這樣自己不可見的標籤。2)被css隱藏的節點,如display: none
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
文件與舊的manifes
t文件,若是文件沒有發生改變,就不作任何操做,若是文件改變了,那麼就會從新下載文件中的資源並進行離線存儲。
離線的狀況下,瀏覽器就直接使用離線存儲的資源。
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七、
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、