低信噪比的HTML5優化

　　百度搜索引擎建議是咱們的HTML文件最好不要超過128KB，其實如今對於那些大文件搜索引擎也是很容易就抓取到的，只不過咱們是儘可能在可能的狀況下把咱們的網頁代碼越精簡越好，咱們要知道搜索引擎抓取網頁的時候可能不去索引整個的文件，索引的僅是前面一部分的信息，若是網頁代碼冗餘過大，那麼就容易把咱們網頁文章部分推後了，對於搜索引擎抓取網頁是不利的，所以咱們要對網頁代碼精簡化。

1.如何加快HTML頁面加載速度？

• 頁面精簡：去掉html頁面沒必要要的空格、註釋，儘可能將script和css寫在外部文件中。
• 能夠借用第三方工具對頁面進行加速。
• 減小文件數量減小頁面上引用的文件數量能夠減小HTTP鏈接數(src="")
• 許多JavaScript、CSS文件能夠合併最好合並了
• 減小外部域名文件的引用
• 優化頁面元素加載順序.例如：首先加載頁面最初顯示的內容和與之相關的JavaScript和CSS，不須要的圖片文件放到後面加載，或者引用延遲加載的js
• 減小頁面中inline(嵌套)和JavaScript的數量
• 不要在table標籤中嵌套table標籤，不過如今基本上都用div+css了，HTML5也出來了
• 檢查頁面是否有js錯誤，或者空引用（檢查頁面有沒有502錯誤），有沒有js文件的重複加載

2.爲什麼要保持標籤整潔?

　　客戶端的優化近來倍受關注，但是有些較基本的方面卻被忽視。若是你仔細觀察某些頁面（即使是那些原本應該深度優化的頁面），很容易就能在他們的標籤中找到一大堆冗餘的、不高效的結構。全部這些累贅給原本應該儘量保持輕量級的頁面增長了沒必要要的負擔。來看看有哪些最容易犯的錯誤:在script標籤內放html註釋。

3.JS滑動事件實現

　　在PC的頁面上很好實現，綁定click和mouseover等事件來完成。可是在移動設備上，要實現這種輪播的效果，就須要用到核心的touch事件。處理touch事件能跟蹤到屏幕滑動的每根手指。

定義touchstart的事件處理函數，並綁定事件：

if (!!self.touch) self.slider.addEventListener('touchstart',self.events,false); 
 
//定義touchstart的事件處理函數
start: function(event) {
    event.preventDefault();  // 阻止觸摸事件的默認動做,即阻止滾屏
    var touch = event.touches[0];  // touches數組對象得到屏幕上全部的touch，取第一個touch
    // 取第一個touch的座標值
    startPos = {
        x: touch.pageX,
        y: touch.pageY,
        time: +new Date
    };    
    // 綁定事件
    this.slider.addEventListener('touchmove',this,false);
    this.slider.addEventListener('touchend',this,false);
},

觸發touchstart事件後，會產生一個event對象；
event對象裏包括觸摸列表；
得到屏幕上的第一個touch，並記下其pageX和pageY的座標；
此時綁定touchmove和touchend事件；

4.javascript中for...in語句來遍歷對象中的屬性

　　for...in 語句用於遍歷對象的屬性（對對象的屬性進行循環操做）。

JavaScript for...in 語句
for...in 語句用於對數組或者對象的屬性進行循環操做。
for ... in 循環中的代碼每執行一次，就會對數組的元素或者對象的屬性進行一次操做。
語法：
for (變量 in 對象)
{
    在此執行代碼
}
「變量」用來指定變量，指定的變量能夠是數組元素，也能夠是對象的屬性。

5.瞭解javascript解析引擎在執行代碼先後是怎麼工做的 http://www.nowamagic.net/librarys/veda

　　簡單地說，JavaScript解析引擎就是可以「讀懂」JavaScript代碼，並準確地給出代碼運行結果的一段程序。比方說，當你寫了 var a = 1 + 1; 這樣一段代碼，JavaScript引擎作的事情就是看懂（解析）你這段代碼，而且將a的值變爲2。學過編譯原理的人都知道，對於靜態語言來講（如Java、C++、C），處理上述這些事情的叫編譯器（Compiler），相應地對於JavaScript這樣的動態語言則叫解釋器（Interpreter）。這二者的區別用一句話來歸納就是：編譯器是將源代碼編譯爲另一種代碼（好比機器碼，或者字節碼），而解釋器是直接解析並將代碼運行結果輸出。 比方說，firebug的console就是一個JavaScript的解釋器。可是，如今很難去界定說，JavaScript引擎它到底算是個解釋器仍是個編譯器，由於，好比像Chrome的JS引擎，它其實爲了提升JS的運行性能，在運行以前會先將JS編譯爲本地的機器碼（native machine code），而後再去執行機器碼（這樣速度就快不少），相信你們對JIT（Just In Time Compilation）必定不陌生吧。我我的認爲，不須要過度去強調JavaScript解析引擎究竟是什麼，瞭解它究竟作了什麼事情我我的認爲就能夠了。

　　JavaScript引擎是一段程序，咱們寫的JavaScript代碼也是程序，如何讓程序去讀懂程序呢？這就須要定義規則。好比，以前提到的var a = 1 + 1;，它表示：左邊var表明了這是申明（declaration），它申明瞭a這個變量。右邊的+表示要將1和1作加法。中間的等號表示了這是個賦值語句。最後的分號表示這句語句結束了。上述這些就是規則，有了它就等於有了衡量的標準，JavaScript引擎就能夠根據這個標準去解析JavaScript代碼了。那麼這裏的ECMAScript就是定義了這些規則。其中ECMAScript 262這份文檔，就是對JavaScript這門語言定義了一整套完整的標準。其中包括：怎麼樣算是數字、怎麼樣算是字符串等等。標準的JavaScript引擎就會根據這套文檔去實現，注意這裏強調了標準，由於也有不按照標準來實現的，好比IE的JS引擎。這也是爲何JavaScript會有兼容性的問題。至於爲何IE的JS引擎不按照標準來實現，就要說到瀏覽器大戰了。簡單的說，ECMAScript定義了語言的標準，JavaScript引擎根據它來實現，這就是二者的關係。那麼，JavaScript解析引擎與瀏覽器又是什麼關係？簡單地說，JavaScript引擎是瀏覽器的組成部分之一。由於瀏覽器還要作不少別的事情，好比解析頁面、渲染頁面、Cookie管理、歷史記錄等等。那麼，既然是組成部分，所以通常狀況下JavaScript引擎都是瀏覽器開發商自行開發的。好比：IE9的Chakra、Firefox的TraceMonkey、Chrome的V8等等。從而也看出，不一樣瀏覽器都採用了不一樣的JavaScript引擎。所以，咱們只能說要深刻了解哪一個JavaScript引擎。

 6.高性能的HTML

　　避免使用Iframe,在測試中全部的DOM元素都是空的，如加載大的腳本或樣式塊可能比加載某些iframe元素耗時更長，但從基準測試結果來看，即便是空的iframe，其開銷也是很是昂貴的，鑑於iframe的高開銷，咱們應儘可能避免使用。尤爲是對於移動設備，對於目前大部分仍是隻有有限的CPU與內存的狀況下，更應避免使用iframe。

　　避免空連接屬性：空的連接屬性是指img、link、script、ifrrame元素的src或href屬性被設置了，可是屬性卻爲空。如<img src=」」>，咱們建立了一個圖片，而且暫時設置圖片的地址爲空，但願在將來動態的去修改它。可是即便圖片的地址爲空，瀏覽器依舊會以默認的規則去請求空地址。

　　避免節點深層次嵌套：深層級嵌套的節點在初始化構建時每每須要更多的內存佔用，而且在遍歷節點時也會更慢些，這與瀏覽器構建DOM文檔的機制有關。經過瀏覽器HTML解析器的解析，瀏覽器會把整個HTML文檔的結構存儲爲DOM樹結構。當文檔節點的嵌套層次越深，構建的DOM樹層次也會越深。

　　縮減HTML文檔，提升下載速度最顯而易見的方式就是減小文件的大小，特別是壓縮內嵌在HTML文檔中的JavaScript和CSS代碼，這能使得頁面體積大幅精簡。除此以外減小HTML文檔大小還能夠採起下面幾種方法：刪掉HTM文檔對執行結果無影響的空格空行和註釋；避免Table佈局；使用HTML5。

　　避免腳本阻塞加載：當瀏覽器在解析常規的script標籤時，它須要等待script下載完畢，再解析執行，然後續的HTML代碼只能等待。爲了不阻塞加載，應把腳步放到文檔的末尾，如把script標籤插入在body結束標籤以前：

 

<script src="example.js" ></script>
 </body>

 

 

　　顯式設置圖片的寬高，當瀏覽器加載頁面的HTML代碼時，有時候須要在圖片下載完成前就對頁面佈局進行定位。若是HTML裏的圖片沒有指定尺寸（寬和高），或者代碼描述的尺寸與實際圖片的尺寸不符時，瀏覽器則要在圖片下載完成後再「回溯」該圖片並從新顯示，這會消耗額外時間。因此，最好爲頁面裏的每一張圖片都指定尺寸，無論是在頁面HTML裏的<img>標籤，仍是在CSS裏。

<img src="hello.png" width="400" height="300">

7. 安全登陸怎麼生成Token？

　　在作客戶端和服務端的交互，若是客戶端每次請求都要帶用戶名和密碼很不現實，因此應該存在一種機制，服務端生成token，返回給客戶端，客戶端憑藉這個token請求相應的接口。 知道有個Oauth受權框架，可是我只涉及到本身的客戶端和服務端，並無第三方，不知道token怎麼取得。先訪問驗證接口。接口輸出一個根據用戶信息生成的token（內容格式隨意）和uid。而後後邊的每次提交提交token和uid，服務端驗證便可。token生成能夠根據useragent等客戶端信息來生成。

8. 一個好的用戶登陸功能：關係到用戶安全

　　如何管理本身的口令讓你知道怎麼管理本身的口令，破解你的口令讓你知道在現代這樣速度的計算速度下，用窮舉法破解你的口令可能會是一件很輕鬆的事。在這裏我想告訴從開發者的角度上來作設計這個用戶名和口令的事。下面一幾件規則：限制用戶輸入一些很是容易被破解的口令。如什麼qwert，123456, password之類，就像twitter限制用戶的口令同樣作一個口令的黑名單。另外，你能夠限制用戶口令的長度，是否有大小寫，是否有數字，你能夠用你的程序作一下校驗。固然，這可能會讓用戶感到很不爽，因此，如今不少網站都提供了UX讓用戶知道他的口令強度是什麼樣的（好比這個有趣的UX），這樣可讓用戶有一個選擇，目的就是告訴用戶：要想安全，先把口令設得好一點。

　　千萬不要明文保存用戶的口令。正如如何管理本身的口令所說的同樣，不少時候，用戶都會用相同的ID相同的口令來登陸不少網站。因此，若是你的網站明文保存的話，那麼，若是你的數據被你的不良員工流傳出去那對用戶是災難性的。因此，用戶的口令必定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之類的有hash算法的不可逆的加密算法。CSDN曾明文保存過用戶的口令。（另，對於國內公司的品行以及有關部門的管理方式，我不敢保證國內網站以加密的方式保存你的口令。我以爲，作爲一個有良知的人，咱們應該加密保存用戶的口令）。

　　是否讓瀏覽器保存口令。咱們有N多的方法能夠不讓瀏覽器保存用戶名和口令。可是這可能對用戶來講很不爽。由於在真實世界裏誰也記得不住那麼多的口令。不少用戶可能會使用一些密碼管理工具來保存密碼，瀏覽器只是其中一種。是否讓瀏覽器保存這個須要你作決定，重點是看一下你的系統的安全級別是否要求比較高，若是是的話，則不要讓瀏覽器保存密碼，並在網站明顯的位置告訴用戶：保存口令最安全的地方只有你的大腦。

　　口令在網上的傳輸。由於HTTP是明文協議，因此，用戶名和口令在網上也是明文發送的，這個很不安全。你能夠看看這篇文章你就明白了。要作到加密傳輸就必需使用HTTPS協議。可是，在中國仍是有不少網站的Web登陸方式還在使用ActiveX控件，這可能成爲IE6還大量存在的緣由。我一般理解爲這些ActiveX控件是爲了反鍵盤記錄程序的。 不過，我依然覺ActiveX控件不該該存在，由於在國外的衆多安全很重要的站點上都看不到ActiveX的控件的身影。

　　首先，我想告訴你們的是，由於HTTP是無狀態的協議，也就是說，這個協議是沒法記錄用戶訪問狀態的，其每次請求都是獨立的無關聯的，一筆是一筆。而咱們的網站都是設計成多個頁面的，所在頁面跳轉過程當中咱們須要知道用戶的狀態，尤爲是用戶登陸的狀態，這樣咱們在頁面跳轉後咱們才知道是否可讓用戶有權限來操做一些功能或是查看一些數據。因此，咱們每一個頁面都須要對用戶的身份進行認證。固然，咱們不可能讓用戶在每一個頁面上輸入用戶名和口令，這會讓用戶以爲咱們的網站至關的SB。爲了實現這一功能，用得最多的技術就是瀏覽器的cookie，咱們會把用戶登陸的信息存放在客戶端的cookie裏，這樣，咱們每一個頁面都從這個cookie裏得到用戶是否登陸的信息，從而達到記錄狀態，驗證用戶的目的。可是，你真的會用cookie嗎？下面是使用cookie的一些原則。千萬不要在cookie中存放用戶的密碼。加密的密碼都不行。由於這個密碼能夠被人獲取並嘗試離線窮舉。因此，你必定不能把用戶的密碼保存在cookie中。我看到太多的站點這麼幹了。正確設計「記住密碼」。這個功能簡直就是一個安全隱患，我以爲並非全部的程序員都知道怎麼設計這個事。通常的設計是：一時用戶勾選了這個功能，系統會生成一個cookie，cookie包括用戶名和一個固定的散列值，這個固定的散列值一直使用。這樣，你就能夠在全部的設備和客戶上均可以登陸，並且能夠有多個用戶同時登陸。這個並非很安全。下面是一些更爲安全的方法供你參考：在cookie中，保存三個東西——用戶名，登陸序列，登陸token。上述三個東西會存

用戶名：明文存放。
登陸序列：一個被MD5散列過的隨機數，僅當強制用戶輸入口令時更新（如：用戶修改了口令）。
登陸token：一個被MD5散列過的隨機數，僅一個登陸session內有效，新的登陸session會更新它。(每次的一個session會話，維持一個token)

在服務器上，服務器的驗證用戶須要驗證客戶端cookie裏的這三個事。這樣的設計會有什麼樣的效果，會有下面的效果：登陸token是單實例登陸。意思就是一個用戶只能有一個登陸實例；登陸序列是用來作盜用行爲檢測的。若是用戶的cookie被盜後，盜用者使用這個cookie訪問網站時，咱們的系統是覺得是合法用戶，而後更新「登陸token」，而真正的用戶回來訪問時，系統發現只有「用戶名」和「登陸序列」相同，可是「登陸token」不對，這樣的話，系統就知道，這個用戶可能出現了被盜用的狀況，因而，系統能夠清除並更改登陸序列和登陸token，這樣就能夠令全部的cookie失效，並要求用戶輸入口令。並給警告用戶系統安全。固然，上述這樣的設計仍是會有一些問題，好比：同一用戶的不一樣設備登陸，甚至在同一個設備上使用不一樣的瀏覽器保登陸。一個設備會讓另外一個設備的登陸token和登陸序列失效，從而讓其它設備和瀏覽器須要從新登陸，並會形成cookie被盜用的假象。因此，你在服務器服還須要考慮： IP 地址，若是以口令方式登陸，咱們無需更新服務器的「登陸序列」和 「登陸token」（但須要更新cookie）。由於咱們認爲口令只有真正的用戶知道。若是 IP相同 ，那麼，咱們無需更新服務器的「登陸序列」和 「登陸token」（但須要更新cookie）。由於咱們認爲是同一用戶有同一IP（固然，同一個局域網裏也有同一IP，但咱們認爲這個局域網是用戶能夠控制的。網吧內並不推薦使用這一功能）。若是 （IP不一樣 && 沒有用口令登陸），那麼，「登陸token」 就會在多個IP間發生變化（登陸token在兩個或多個ip間被來來回回的變換），當在必定時間內達到必定次數後，系統纔會真正以爲被盜用的可能性很高，此時系統在後臺清除「登陸序列」和「登陸token「，讓Cookie失效，強制用戶輸入口令（或是要求用戶更改口令），以保證多臺設備上的cookie一致。

　　不要讓cookie有權限訪問全部的操做。不然就是XSS攻擊，這個功能請參看新浪微博的XSS攻擊。下面的這些功能必定要用戶輸入口令：修改口令。修改電子郵件。（電子郵件一般用來找回用戶密碼，最好通發郵件或是發手機短信的方式修改，或者乾脆就不讓改：用電子郵件作賬號名）。用戶的隱私信息。用戶消費功能。權衡Cookie的過時時間。若是是永不過時，會有很不錯的用戶體驗，可是這也會讓用戶很快就忘了登陸密碼。若是設置上過時期限，好比2周，一個月，那麼可能會好一點，可是2周和一個月後，用戶依然會忘了密碼。尤爲是用戶在一些公共電腦上，若是保存了永久cookie的話，等於泄露了賬號。因此，對於cookie的過時時間咱們還須要權衡。

　　　詳情參考：http://coolshell.cn/articles/5353.html