本文主要從工作效率、速度性能、穩(wěn)定性、響應(yīng)式、兼容性、搜索SEO、信息無(wú)障礙等方面進(jìn)行講解。前端優(yōu)化是一個(gè)讓人技術(shù)提升的point，希望你也能從這里學(xué)到一些東西。

1 工作效率

你是否經(jīng)常處于這樣的場(chǎng)景：從早上忙到晚上八九點(diǎn)，一會(huì)與產(chǎn)品經(jīng)理溝通，一會(huì)在部門群聊一下新奇的東西，一會(huì)被設(shè)計(jì)美眉糾纏住拖不了身，有時(shí)還開不了部門的會(huì)議因?yàn)轫?yè)面急著上線，然后繼續(xù)加班~~~

怎么提高我們的工作效率？下面從四個(gè)方面講解：

• 時(shí)間管理

• 利用工具
  

• 經(jīng)驗(yàn)和閱歷

• 使用新技術(shù)
  

1.1 時(shí)間管理

凡是時(shí)間管理，都會(huì)聯(lián)想到計(jì)劃這個(gè)詞。我們先看看別人家的月計(jì)劃表和周計(jì)劃表，之所以周計(jì)劃表為空，是希望你能把它下載并打印出來(lái)，行動(dòng)從計(jì)劃開始：

月計(jì)劃表：

周計(jì)劃表：

當(dāng)然計(jì)劃不要做得過(guò)于瑣碎，且不要占用自己太多時(shí)間。做好計(jì)劃之余，在執(zhí)行過(guò)程中需要注意幾點(diǎn)：

• 正確的時(shí)間點(diǎn)做正確的事，比如早上比較精神，可選擇比較難的項(xiàng)目開展，可容易達(dá)到高效率。

• 專注一件事情，盡量不要被瑣碎或其他事情影響，而且不要頻繁地去看計(jì)劃表，最好是做完一件再去看，否則容易焦慮導(dǎo)致無(wú)法專心。
  

1.2 利用工具

第一樣工具，比如程序員杯子：

利用工具有什么好處呢？

• 減少重復(fù)性工作。

• 減少繁瑣工作流程，一鍵式化。
  

1.2.1 編輯器

選擇好一個(gè)前端編輯器是比較重要的。目前sublime、webstorm和vim是比較常見的，建議不使用Dreamweaver。

sublime目前還是不錯(cuò)的選擇，可以安裝插件，比如BracketHighlighter 高亮顯示、JsFormat、Emmet html/CSS快速編輯以及DocBlockr插件，快速輸入jsDoc注釋等，還可以自定義代碼段snippets。

無(wú)論你使用哪種編輯器，你需要的是熟悉這個(gè)編輯器并熟練它的快捷鍵。

1.2.2 瀏覽器開發(fā)者工具

作為前端人員，首選的瀏覽器當(dāng)然是chrome。推薦閱讀Chrome開發(fā)者工具不完全指南一系列文章（http://web./82558/），它從一些基礎(chǔ)的功能開始到它的一些高級(jí)性能分析器（Timeline、Profiles），熟悉chrome對(duì)我們的開發(fā)工作有很大的作用。

1.2.3 其他常用工具

• 切圖工具：photoshop cc切圖之智能切圖、 cutterman

• 量色、測(cè)距工具：FastStone Capture、馬克鰻 - 設(shè)計(jì)稿標(biāo)注

• 圖片壓縮：tinypng、智圖

• 生成雪碧圖：spritebox、CSS Sprite Generator、cssgaga

• 調(diào)試工具：Fiddler 、weinre 、微信調(diào)試工具；
  

1.2.4 前端工程化

凡是重復(fù)的，必須使用工具自動(dòng)完成。工具眾多，我們就有一種想法，能不能有一種工具能幫我們自動(dòng)生成雪碧圖、 css壓縮、圖片壓縮等等，然后就出現(xiàn)了前端工程化。前端工程化一般可分為五個(gè)步驟：

（1） 初始，生成基礎(chǔ)目錄結(jié)構(gòu)和樣式庫(kù)。
（2） 開發(fā)，實(shí)時(shí)預(yù)覽、預(yù)編譯。
（3） 構(gòu)建，預(yù)編譯、合并、壓縮。
（4） 發(fā)布，將構(gòu)建后靜態(tài)文件發(fā)布上線。
（5） 打包，資源路徑轉(zhuǎn)換，源碼打包 。

這里推薦一個(gè)工具fis（http://fis.baidu.com/），解決前端開發(fā)中自動(dòng)化工具、性能優(yōu)化、模塊化框架、開發(fā)規(guī)范、代碼部署、開發(fā)流程等問(wèn)題。還有凹凸實(shí)驗(yàn)室研發(fā)的athena（http:///athena/），O2Team構(gòu)建項(xiàng)目流程工具，可以生成相應(yīng)目錄和代碼，同時(shí)對(duì)項(xiàng)目進(jìn)行編譯， 一次安裝，到處運(yùn)行。

1.3 閱歷和經(jīng)驗(yàn)

我所理解的程序員兼并聰明以及“懶惰”精神，推崇懶惰式開發(fā)，即把問(wèn)題理解清楚，確保將要寫的代碼能真正的解決問(wèn)題，這將會(huì)避免之后寫出大量無(wú)用的代碼，正所謂“懶”出效率。
我們的閱歷和經(jīng)驗(yàn)可以大大提高開發(fā)效率，思考代碼的時(shí)間增加從而選出最優(yōu)方案，因此寫代碼速度更快以及代碼長(zhǎng)度更短，對(duì)問(wèn)題的透徹理解使調(diào)試代碼的速度也更快。

根據(jù)閱歷和經(jīng)驗(yàn)，或借助其他人的，我們進(jìn)行整理從而形成自己或團(tuán)隊(duì)的規(guī)范，這可大大提高我們的寫碼速度。

1.4 使用新技術(shù)

使用新技術(shù)如何提高我們的工作效率。一貫我們都使用我們熟悉的技術(shù)去開發(fā)一個(gè)技術(shù)處理方案，畢竟學(xué)習(xí)新技術(shù)的時(shí)間成本還是存在的。但是還是不能忽略一些新技術(shù)的存在，一般新技術(shù)包含了一些很棒的新特性，可以更加方便的實(shí)現(xiàn)很多復(fù)雜的操作，提高開發(fā)人員的效率，比如ES6。用你的慧眼去積累新技術(shù)，會(huì)派上用場(chǎng)的。

2 速度性能

為什么需要前端性能優(yōu)化？性能優(yōu)化可以從哪幾個(gè)方面入手？
遇到一個(gè)頁(yè)面，5秒還沒(méi)加載完成，那個(gè)菊花轉(zhuǎn)啊轉(zhuǎn)，或者頁(yè)面完全白屏，那簡(jiǎn)直把人逼瘋了。從用戶體驗(yàn)的角度看，前端性能優(yōu)化是非常有必要的。網(wǎng)頁(yè)最長(zhǎng)加載時(shí)間一般不能超過(guò)3秒。
首先我們需要確定網(wǎng)頁(yè)的性能指標(biāo)，可量化的目標(biāo)以及可持續(xù)跟蹤的優(yōu)化數(shù)據(jù)是性能優(yōu)化工作得以持續(xù)進(jìn)行的保障，同時(shí)也是源動(dòng)力！比如：

• 首屏加載時(shí)長(zhǎng)

• DOM加載時(shí)長(zhǎng)
  

• 頁(yè)面白屏?xí)r長(zhǎng)
  

我們一般通過(guò)三種方式來(lái)檢驗(yàn)我們的網(wǎng)頁(yè)性能：

• 通過(guò)瀏覽器開發(fā)者工具或?yàn)g覽器插件、Fiddler、Charles等查看頁(yè)面加載情況。原理是通過(guò)追蹤HTTP請(qǐng)求與響應(yīng)的時(shí)間，以圖形的方式列出所有資源的下載情況。缺點(diǎn)是人為操作，難以實(shí)現(xiàn)批量測(cè)試與統(tǒng)計(jì)。

• 在頁(yè)面中引入額外的代碼鉤子來(lái)記錄時(shí)間等相關(guān)數(shù)據(jù)。缺點(diǎn)是加重了開發(fā)者與測(cè)試人員的負(fù)擔(dān)，還有可能因?yàn)闄z測(cè)代碼本身的潛在問(wèn)題影響頁(yè)面的性能。如果好一點(diǎn)的話，會(huì)接入一個(gè)性能數(shù)據(jù)收集系統(tǒng)，采取并分析數(shù)據(jù)。

• 使用第三方的工具如Page Speed、YSlow和WebPagetest，能夠選擇在不同瀏覽器和不同地域進(jìn)行測(cè)試，并且給出各方面的評(píng)分以及提供一些優(yōu)化建議。但某些服務(wù)需要排隊(duì)等待，并且難以實(shí)現(xiàn)批量測(cè)試與統(tǒng)計(jì)。下面是使用WebPagetest測(cè)試京東首頁(yè)的情況：
  

可喜可賀，W3C推出了一套性能API標(biāo)準(zhǔn)，目的是簡(jiǎn)化開發(fā)者對(duì)網(wǎng)站性能進(jìn)行精確分析與控制的過(guò)程，最終實(shí)現(xiàn)性能的提高。比如通過(guò)Navigation Timing記錄的關(guān)鍵時(shí)間點(diǎn)來(lái)統(tǒng)計(jì)頁(yè)面完成所用的時(shí)間，部分使用方法：

持續(xù)追蹤性能數(shù)據(jù)，要選擇合適的頁(yè)面性能測(cè)量工具或API，一旦選定后，不再更換，以保證歷史數(shù)據(jù)的可參照性。我們還要形成一種意識(shí)，達(dá)成性能聯(lián)盟小組，對(duì)于重要的業(yè)務(wù)或者頁(yè)面，一定要從性能的角度考慮問(wèn)題，有理有據(jù)地拒絕有損于前端性能的業(yè)務(wù)需求或改動(dòng)。

人人都知道雅虎軍規(guī)，那我就來(lái)個(gè)截圖吧！

以下，我們從服務(wù)端、網(wǎng)絡(luò)、客戶端三個(gè)方面來(lái)一一突破速度性能的提升。

2.1 沒(méi)事少煩我-服務(wù)端

2.1.1 使用內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）

通過(guò)在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的 cache服務(wù)器內(nèi)，通過(guò)DNS負(fù)載均衡的技術(shù)，判斷用戶來(lái)源就近訪問(wèn)cache服務(wù)器取得所需的內(nèi)容。深圳用戶訪問(wèn)遙遠(yuǎn)的美國(guó)服務(wù)器，當(dāng)然不理想了。把靜態(tài)內(nèi)容分布到CDN可以減少用戶響應(yīng)時(shí)間20%或更多。

2.1.2 靜態(tài)資源緩存，移動(dòng)端離線緩存

如果可以減少服務(wù)端的負(fù)擔(dān)，在應(yīng)用離線時(shí)可使用資源或加載資源更快，豈不樂(lè)哉？
緩存利用可包括：添加 Expires 頭，配置 ETag，使 Ajax 可緩存等。其實(shí)，恰當(dāng)?shù)木彺嬖O(shè)置可以大大的減少 HTTP請(qǐng)求，也可以節(jié)省帶寬 。

• 配置 ETag：即If-None-Match: 上次 ETag 的內(nèi)容。瀏覽器會(huì)發(fā)出請(qǐng)求詢問(wèn)服務(wù)端，資源是否過(guò)期；服務(wù)端發(fā)現(xiàn),沒(méi)有過(guò)期，直接返回一個(gè)狀態(tài)碼為 304、正文為空的響應(yīng)，告知瀏覽器使用本地緩存；如果資源有更新，服務(wù)端返回狀態(tài)碼 200、Etag 和正文。這個(gè)過(guò)程被稱之為 HTTP 的協(xié)商緩存，通常也叫做弱緩存。

  
  

• 添加 Expires 頭：服務(wù)端通過(guò)響應(yīng)頭告訴瀏覽器，在什么時(shí)間之前（Expires）或在多長(zhǎng)時(shí)間之內(nèi)（Cache-Control: Max-age=xxx），不要再請(qǐng)求服務(wù)器了。這個(gè)機(jī)制我們通常稱之為 HTTP 的強(qiáng)緩存。一般會(huì)對(duì) CSS、JS、圖片等資源使用強(qiáng)緩存，而入口文件（HTML）一般使用協(xié)商緩存或不緩存。

  
  

• AppCache：
  

        AppCache主要利用manifest 文本文件，告知瀏覽器被緩存的內(nèi)容以及不緩存的內(nèi)容。

    manifest 文件可分為三個(gè)部分：

    （1） CACHE MANIFEST - 在此標(biāo)題下列出的文件將在首次下載后進(jìn)行緩存，等價(jià)于CACHE
    （2） NETWORK - 在此標(biāo)題下列出的文件需要與服務(wù)器的連接，且不會(huì)被緩存
    （3） FALLBACK - 在此標(biāo)題下列出的文件規(guī)定當(dāng)頁(yè)面無(wú)法訪問(wèn)時(shí)的回退頁(yè)面

    使用AppCache方案的步驟：

    （1） 整理出需要緩存的靜態(tài)文件列表，如juqery.js和gb.css。
    （2） 配置服務(wù)器支持。
    （3） 確定內(nèi)容更新機(jī)制和瀏覽器兼容方案。

• LocalStorage：用于持久化的本地存儲(chǔ)，除非主動(dòng)刪除數(shù)據(jù)，否則數(shù)據(jù)是永遠(yuǎn)不會(huì)過(guò)期的。

2.2 省著點(diǎn)用-網(wǎng)絡(luò)

2.2.1 減少請(qǐng)求數(shù)

可通過(guò)以下方式減少請(qǐng)求數(shù)：

• 小圖片合并雪碧圖；

• JS、CSS文件選擇性合并；

• 避免重復(fù)的資源請(qǐng)求。
  

減少請(qǐng)求數(shù)對(duì)于速度優(yōu)化來(lái)說(shuō)最重要最有效的，特別是網(wǎng)絡(luò)差的用戶。一個(gè)完整的請(qǐng)求需要經(jīng)過(guò)域名解析以及DNS尋址、與服務(wù)器建立連接、發(fā)送數(shù)據(jù)、等待服務(wù)器響應(yīng)、接收數(shù)據(jù)的過(guò)程；每個(gè)請(qǐng)求都需要攜帶數(shù)據(jù)，因此每個(gè)請(qǐng)求都需要占用帶寬；瀏覽器進(jìn)行并發(fā)請(qǐng)求的請(qǐng)求數(shù)是有上限的。請(qǐng)求多了的情況，明顯增加了網(wǎng)頁(yè)的響應(yīng)時(shí)間。一個(gè)頁(yè)面由多個(gè)模塊拼接而成，幾個(gè)模塊中請(qǐng)求了同樣的資源時(shí)，就會(huì)導(dǎo)致資源的重復(fù)請(qǐng)求。

2.2.2 減少文件大小（減少請(qǐng)求帶寬）

• 壓縮CSS、JS、圖片；

• 盡可能控制DOM節(jié)點(diǎn)數(shù)；

• 精簡(jiǎn)css、 JavaScript，移除注釋、空格、重復(fù)css和腳本。

• 開啟Gzip，Gzip的思想就是把文件先在服務(wù)器端進(jìn)行壓縮，且壓縮率達(dá)到85%，然后再傳輸，傳輸完畢后瀏覽器會(huì) 重新對(duì)壓縮過(guò)的內(nèi)容進(jìn)行解壓縮，并執(zhí)行。。好處在于Gzip的支持已經(jīng)很好，且爬蟲可識(shí)別，壓縮率達(dá)到66%-85%顯著減少了文件傳輸?shù)拇笮　Ａ硗?，gzip對(duì)pdf文件的壓縮效果不大，而且會(huì)浪費(fèi)CPU。
  

2.2.3 合理使用靜態(tài)資源域名

域名的要求是短小且獨(dú)立。

短小可以減少頭部開銷，因?yàn)橛蛎蕉陶?qǐng)求頭起始行的 URI 就越短。之所以要求獨(dú)立，因?yàn)楠?dú)立域名不會(huì)共享主域的 Cookie，可以有效減小請(qǐng)求頭大小，這個(gè)策略一般稱之為 Cookie-Free Domain；另外一個(gè)原因是瀏覽器對(duì)相同域名的并發(fā)連接數(shù)限制，一般允許同域名并發(fā) 6~8 個(gè)連接，域名不是越多越好，每個(gè)域名的第一個(gè)連接都要經(jīng)歷 DNS 查詢（DNS Lookup），導(dǎo)致會(huì)耗費(fèi)一定的時(shí)間，控制域名使用在2-4個(gè)之間。另外注意：同一靜態(tài)資源在不同頁(yè)面被散列到不同子域下，會(huì)導(dǎo)致無(wú)法利用 HTTP 緩存。

2.2.4 使用HTTP 2

HTTP 2 相比 HTTP 1.1 的更新大部分集中于：

• 多路復(fù)用：多路復(fù)用很好地解決如何讓重要資源盡快加載這個(gè)問(wèn)題。同域名下或者不同域但是同時(shí)滿足同一個(gè) IP以及使用同一個(gè)證書的這兩個(gè)條件中的所有通信都在單個(gè)連接上完成，此連接上同時(shí)打開任意數(shù)量的雙向數(shù)據(jù)流（ HTTP 1.1 有連接數(shù)限制）。使用多域名加上相同的 IP 和證書部署 Web 服務(wù)有特殊的意義：讓支持 HTTP/2 的終端只建立一個(gè)連接，用上 HTTP/2 協(xié)議帶來(lái)的各種好處；而只支持 HTTP/1.1 的終端則會(huì)建立多個(gè)連接，達(dá)到同時(shí)更多并發(fā)請(qǐng)求的目的。

  
  

• HEAD 壓縮：HTTP/2 將請(qǐng)求和響應(yīng)數(shù)據(jù)分割為更小的幀，并對(duì)它們采用二進(jìn)制編碼（ Binary Framing ）。在 HTTP/1 中，HTTP 請(qǐng)求和響應(yīng)都是由「狀態(tài)行、請(qǐng)求 / 響應(yīng)頭部、消息主體」三部分組成，狀態(tài)行和頭部卻沒(méi)有經(jīng)過(guò)任何壓縮，直接以純文本傳輸。如下圖的比較：
  

在 HTTP/2 中，每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成。多個(gè)幀之間可以亂序發(fā)送，因?yàn)楦鶕?jù)幀首部的流標(biāo)識(shí)可以重新組裝。

• 請(qǐng)求優(yōu)先級(jí)：服務(wù)器可以根據(jù)流的優(yōu)先級(jí)，控制資源分配(CPU、內(nèi)存、帶寬)，而在響應(yīng)數(shù)據(jù)準(zhǔn)備好之后，優(yōu)先將最高優(yōu)先級(jí)的幀發(fā)送給客戶端。

  
  

• 服務(wù)器推送：?jiǎn)?dòng)Server Push，意味著服務(wù)端可以在發(fā)送頁(yè)面HTML時(shí)主動(dòng)推送其它資源，有自己獨(dú)立的URL，可以被瀏覽器緩存；如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過(guò)，瀏覽器可以通過(guò)發(fā)送 RST_STREAM 幀來(lái)拒收。
  

2.2 學(xué)會(huì)持家，讓家變得簡(jiǎn)潔漂亮-客戶端

• 使用外鏈CSS和JS，CSS放頭，JS放尾，防止阻塞以減少對(duì)并發(fā)下載的影響，盡早刷新文檔的輸出。

• html的代碼優(yōu)化，如：

• 避免空的圖片src；

• 協(xié)議自適應(yīng)，減少html文件大小，將https://和http://都替換成//。

• css的代碼優(yōu)化，如：

• 建議使用類選擇器，訪問(wèn)比較快；

• 不建議使用很長(zhǎng)的base64；

• 避免CSS表達(dá)式；

• 避免使用Filters。

• js的代碼優(yōu)化，如：

• 避免使用eval和width；

• 減少作用域鏈查找；

• 減少DOM訪問(wèn)，盡量緩存DOM；

• 充分利用事件委托；

• 減少Repaint（重繪）和Reflow（重排）最好通過(guò)批量更新元素減少重排次數(shù)，如設(shè)置類class統(tǒng)一更新樣式，在添加多個(gè)li

• 元素將會(huì)觸發(fā)多次頁(yè)面重排的情況下使用 DOM fargment 在內(nèi)存中創(chuàng)建完整的 DOM 節(jié)點(diǎn)，然后再一次性添加到 DOM 中。

• 圖片格式的選擇：

• 顏色較為豐富的圖片而且文件比較大的（40KB - 200KB）或者有內(nèi)容的圖片優(yōu)先考慮 jpg；圖標(biāo)等顏色比較簡(jiǎn)單、文件體積不大、起修飾作用的圖片，優(yōu)先考慮使用 PNG8 格式；圖像顏色豐富而且圖片文件不太大的（40KB 以下）或有半透明效果的優(yōu)先考慮 PNG24 格式。

• 條件允許的，使用新格式WEBP和BPG。

• 用SVG和ICONFONT代替簡(jiǎn)單的圖標(biāo)。

• 用字蛛來(lái)代替藝術(shù)字體切圖，它可剔除沒(méi)有使用的字符，從而解決中文字體過(guò)大的問(wèn)題，并編碼成跨平臺(tái)兼容的格式。

• 合理分配資源加載時(shí)間，按需加載，包括CSS、JS文件以及圖片、業(yè)務(wù)模塊等。根據(jù)我們網(wǎng)頁(yè)最初加載需要的最小內(nèi)容集推斷其他內(nèi)容延遲加載；無(wú)條件提前加載公共內(nèi)容或根據(jù)用戶行為推斷提前加載某些內(nèi)容，如根據(jù)搜索框輸入的文字來(lái)判斷加載的內(nèi)容。加載機(jī)制如下：

• 預(yù)加載

• Dom Ready后加載

• onLoad后加載

• 滾動(dòng)加載

• 減少DNS 查詢：DNS 查詢一般需要幾毫秒到幾百毫秒，移動(dòng)環(huán)境下會(huì)更慢。我們可以預(yù)先讀取DNS，減少用戶等待時(shí)間。

  
  

  

3 穩(wěn)定性

穩(wěn)定性的第一要求是可用。最起碼的要求是頁(yè)面得出來(lái)，要不然沒(méi)法用了。

其次講究的是頁(yè)面的可維護(hù)性，假如頁(yè)面掛了，多久可以恢復(fù)過(guò)來(lái)，另外考慮頁(yè)面掛的期間是否可以采取靜態(tài)頁(yè)面處理等方式。

頁(yè)面的穩(wěn)定性其實(shí)和前端安全掛鉤，即使頁(yè)面可以出來(lái)了，但是不能保證不會(huì)被黑掉，下文從前端安全的方面講解。

3.1 常見攻擊：

• XSS (Cross Site Script) ，跨站腳本攻擊，往Web頁(yè)面里插入惡意html代碼。特點(diǎn)是攻擊者的代碼必須能獲取用戶瀏覽器端的執(zhí)行權(quán)限，要杜絕此類攻擊出現(xiàn)可以在入口和出口進(jìn)行嚴(yán)格的過(guò)濾。
  

    三種類型：
    （1） 反射型XSS：一次性；將包含注入腳本的惡意鏈接發(fā)送給受害者。
    （2） 持久型XSS：用戶輸入的數(shù)據(jù)“存儲(chǔ)”在服務(wù)器端，比如一條包含XSS代碼的留言。
    （3） DOM XSS：使用一些eval等有輸出的語(yǔ)句意味著多了一份被XSS的風(fēng)險(xiǎn)。

    應(yīng)對(duì)策略：

• 當(dāng)惡意代碼值被作為某一標(biāo)簽的內(nèi)容顯示：在不需要html輸入的地方對(duì)html 標(biāo)簽及一些特殊字符( ” <> & 等等 )做過(guò)濾，將其轉(zhuǎn)化為不被瀏覽器解釋執(zhí)行的字符。
  

• 當(dāng)惡意代碼被作為某一標(biāo)簽的屬性顯示，通過(guò)用 “將屬性截?cái)鄟?lái)開辟新的屬性或惡意方法：屬性本身存在的 單引號(hào)和雙引號(hào)都需要進(jìn)行轉(zhuǎn)碼；對(duì)用戶輸入的html 標(biāo)簽及標(biāo)簽屬性做白名單過(guò)濾，也可以對(duì)一些存在漏洞的標(biāo)簽和屬性進(jìn)行專門過(guò)濾。
  

• CSRF(Cross Site Request Forgery)，跨站點(diǎn)偽造請(qǐng)求，通過(guò)偽造連接請(qǐng)求在用戶不知情的情況下，讓用戶以自己的身份來(lái)完成攻擊者需要達(dá)到的一些目的。

  
  

• cookie劫持，通過(guò)獲取頁(yè)面的權(quán)限，在頁(yè)面中寫一個(gè)簡(jiǎn)單的到惡意站點(diǎn)的請(qǐng)求，并獲取用戶的cookie登錄某些站點(diǎn)。

對(duì)于crsf 和cookie 劫持的策略：

• 通過(guò) referer、token 或者 驗(yàn)證碼 來(lái)檢測(cè)用戶提交。

• 盡量不要在頁(yè)面的鏈接中暴露用戶隱私信息。
  

• 對(duì)于用戶修改刪除等操作最好都使用post 操作 。

• 避免全站通用的cookie，嚴(yán)格設(shè)置cookie的域。
  

3.2 數(shù)據(jù)通道安全

國(guó)內(nèi)的眾多網(wǎng)站都沒(méi)有實(shí)現(xiàn)全站HTTPS。這是目前為止最重要的一步，所有的數(shù)據(jù)在發(fā)送之前就會(huì)被加密，攻擊者無(wú)法查看或篡改數(shù)據(jù)包的內(nèi)容。HTTPS可以理解為HTTP+SSL/TLS，通過(guò)數(shù)據(jù)加密、校驗(yàn)數(shù)據(jù)完整性和身份認(rèn)證三種機(jī)制來(lái)保障安全。

HTTPS的缺點(diǎn)是網(wǎng)站在加上TLS證書時(shí)，可能導(dǎo)致RTT往返時(shí)延增加，并且 HTTPS通信過(guò)程的非對(duì)稱和對(duì)稱加解密計(jì)算會(huì)產(chǎn)生更多的服務(wù)器性能和時(shí)間上的消耗，但是這是可以優(yōu)化的，這里就不細(xì)說(shuō)了。

3.3瀏覽器安全

3.3.1 同源策略

首先了解一下同源策略：

• 源指的是有相同的HOST、相同的協(xié)議、相同的端口。
  

• 同源策略以源為單位，把資源天然分隔，保護(hù)了用戶的信息安全。
  

• 繞過(guò)同源策略讓javascript訪問(wèn)其他源的資源的方法，如：JSONP、CORS、flash等。
  

• 同源策略不是絕對(duì)安全的，面對(duì)很多攻擊是無(wú)能為力的，比如XSS，因?yàn)榇藭r(shí)攻擊者就在同源之內(nèi)。
  

不建議使用JSONP，因?yàn)镴SONP通常在腳本中寫一個(gè)回調(diào)函數(shù)，然后把回調(diào)函數(shù)的名字寫在請(qǐng)求的URL中，因此如果請(qǐng)求數(shù)據(jù)的服務(wù)器被黑了，那么黑客就能在返回的數(shù)據(jù)中植入惡意代碼，從而竊取用戶的隱私信息。

跨域資源共享CORS允許資源提供方在響應(yīng)頭中加入一個(gè)特殊的標(biāo)記，使你能通過(guò)XHR來(lái)獲取、解析并驗(yàn)證數(shù)據(jù)。這樣就能避免惡意代碼在你的應(yīng)用中執(zhí)行。在響應(yīng)頭中加入的標(biāo)記如下：

Access-Control-Allow-Origin: allowed origins

如果對(duì)Access–Control-Allow-Origin設(shè)置為*其實(shí)是比較危險(xiǎn)的，如果沒(méi)有攜帶會(huì)話認(rèn)證意味著信息被公開在全網(wǎng)，建議設(shè)置具體的域名，而且跨域的時(shí)候記得帶上session id；嚴(yán)格審查請(qǐng)求信息，比如請(qǐng)求參數(shù)，還有http頭信息，因?yàn)?http頭可以偽造。

3.3.2 CSP(Content Security Policy)

CSP指定網(wǎng)站上所有腳本和圖片等資源的源站點(diǎn)，也能阻止所有內(nèi)聯(lián)（inline）的腳本和樣式。即使有人在頁(yè)面評(píng)論或者留言中嵌入了腳本標(biāo)簽，這些腳本代碼也不會(huì)被執(zhí)行?？赏ㄟ^(guò)兩種方式設(shè)置，如果 HTTP 頭與 Meta 定義同時(shí)存在，則優(yōu)先采用 HTTP 頭中的定義：

• 通過(guò) HTTP 頭，比如只允許腳本從本源加載：Content-Security-Policy: script-src 'self’，其中script-src 'self’是策略。

  
  

• 通過(guò)HTML的Meta標(biāo)簽，比如只允許腳本從本源加載：
  

其他策略：

    script-src – 設(shè)置可以接受的JavaScript代碼的源站點(diǎn)
    style-src – 設(shè)置可以接受的CSS樣式代碼的源站點(diǎn)
    connect-src – 定義瀏覽器可以通過(guò)XHR、WebSocket或者 EventSource訪問(wèn)哪些站點(diǎn)
    font-src – 設(shè)置可以接受的字體文件的源站點(diǎn)
    frame-src – 定義瀏覽器可以通過(guò)iframe訪問(wèn)哪些站點(diǎn)
    img-src – 設(shè)置可以接受的圖片的源站點(diǎn)
    media-src – 設(shè)置可以接受的音頻和視頻文件的源站點(diǎn)
    object-src – 設(shè)置可以接受的Flash和其它插件的源站點(diǎn)

缺點(diǎn)：

默認(rèn)情況下，所有的內(nèi)聯(lián)JavaScript腳本都不會(huì)被執(zhí)行，因?yàn)闉g覽器無(wú)法區(qū)分自己的內(nèi)聯(lián)腳本和黑客注入的腳本。

CSP還會(huì)默認(rèn)阻止所有eval()風(fēng)格的代碼的執(zhí)行，包括setInterval/setTimeout中的字符串和類似于new Function('return false’)之類的代碼。

3.3.3 iframe 沙箱環(huán)境

利用iframe進(jìn)行跨源：HTML5為iframe提供了安全屬性 sandbox，iframe的能力將會(huì)被限制。

3.3.4 Secure和HttpOnly屬性

Secure能確保cookie的內(nèi)容只能通過(guò)SSL連接進(jìn)行傳輸。Secure和HttpOnly屬性告訴瀏覽器cookie的內(nèi)容只能分別通過(guò)HTTP(S)協(xié)議進(jìn)行訪問(wèn)，從而避免了被輕易竊取，比如禁止從JavaScript中的document.cookie訪問(wèn)，因此cookie在瀏覽器document中不可見了。如果單獨(dú)使用的話，無(wú)法全面抵御跨站點(diǎn)腳本攻擊，通常和其他技術(shù)組合使用。使用方法如下：

Set-Cookie: =[; =] [; expires=][; domain=][; path=][; secure][; HttpOnly]

3.3.5 其他安全相關(guān)的HTTP 頭

• X-Content-Type-Options 告訴瀏覽器相信此服務(wù)器下發(fā)的資源的類型，防止類型嗅探攻擊。

  
  

• HPKP(Public Key Pinning) Public Key Pinning 是一個(gè)response 頭，用來(lái)檢測(cè)一個(gè)證書的公鑰是否發(fā)生了改變，防止中間人攻擊。

  
  

• HSTS (HTTP Strict-Transport-Security) 強(qiáng)制使用TSL作為數(shù)據(jù)通道。
  

3.4 HTML5 對(duì)web安全的影響

html5有很多新的特性能力，然而能力越大，被攻破后的危險(xiǎn)就越大。
HTML5 對(duì)xss的影響主要體現(xiàn)在:

• 攻擊面更大，html5帶來(lái)更多的標(biāo)簽和更多的屬性如[video],[audio],[canvas]等；[/canvas][/audio][/video]

• 危害更大，HTML5更多的資源可以被xss利用。黑客可以利用瀏覽器的一切權(quán)限，比如本地存儲(chǔ)、GEO、服務(wù)器推送機(jī)制WebSocket，js多線程執(zhí)行Webworker等。
  

比如localstorage只能通過(guò)js設(shè)置和獲取，導(dǎo)致的結(jié)果是不能像cookie一樣設(shè)置httponly等屬性，所以localstorage中不能存放敏感信息，最好能夠在服務(wù)端進(jìn)行加密，可以配合CORS來(lái)獲取網(wǎng)站的localstorage的信息。

4 響應(yīng)式

響應(yīng)式布局簡(jiǎn)而言之，就是一個(gè)網(wǎng)站能夠兼容多個(gè)終端，可以為不同終端的用戶提供更加舒適的界面和更好的用戶體驗(yàn)。

• 基于柵格布局規(guī)劃響應(yīng)式設(shè)計(jì)，每個(gè)模塊盡可能嚴(yán)格遵循柵格布局，符合柵格的小模塊能很靈活的適應(yīng)多個(gè)分辨率的展示。

• 擁抱flexbox。
  

• 使用動(dòng)態(tài)的字體大小單位+rem單位使用。

• 使用CSS3 mediaQuery 技術(shù)響應(yīng)用戶設(shè)備。

• 利用百分比。

• 對(duì)低版本瀏覽器使用JS動(dòng)態(tài)響應(yīng)。

• 一套“自適應(yīng)”素材兼容各種分辨率，提升頁(yè)面性能，比如自適應(yīng)的圖片/視頻素材。
  

比如凹凸實(shí)驗(yàn)室博客頁(yè)面在PC端、iPad、手機(jī)端的排版：

PC端：

iPad：

手機(jī)端：

5 兼容性

估計(jì)很多人對(duì)這句話都有體會(huì)：IE虐我千百遍，我待IE如初戀。當(dāng)然，除了 IE 上有兼容性問(wèn)題，其他瀏覽器比如 Android 上的低版本瀏覽器也有較多問(wèn)題。

是否繼續(xù)保持對(duì)低端瀏覽器的兼容性，我們可以用數(shù)據(jù)跟產(chǎn)品經(jīng)理或者老板說(shuō)話，減少我們的工作量，最好在項(xiàng)目之前就定下來(lái)支持最低支持的版本是什么，然后設(shè)計(jì)一個(gè)對(duì)應(yīng)兼容方案。以下是百度統(tǒng)計(jì)的2015年的瀏覽器市場(chǎng)份額數(shù)據(jù)：

兼容性的原則：漸進(jìn)增強(qiáng)與平穩(wěn)退化。就是說(shuō)，在低級(jí)瀏覽器能夠保證其可用性和可訪問(wèn)性；漸進(jìn)增強(qiáng)，在保證代碼、頁(yè)面在低級(jí)瀏覽器中的可用性及可訪問(wèn)性的基礎(chǔ)上，逐步增加功能及用戶體驗(yàn)。

如果出現(xiàn)兼容性問(wèn)題了，怎么處理：

• 確認(rèn)觸發(fā)場(chǎng)景，什么瀏覽器、版本、什么情況下會(huì)出現(xiàn)這個(gè)問(wèn)題，做到穩(wěn)定復(fù)現(xiàn)。
  

• 找到問(wèn)題原因，為什么會(huì)出現(xiàn)這樣的問(wèn)題（自己琢磨、網(wǎng)上搜、問(wèn)同事）。
  

• 確定解決辦法：參考現(xiàn)成的規(guī)范，比如某些屬性不能使用以及一些hack的處理。
  

• 積累兼容性處理方法。
  

淘寶首頁(yè)在兼容性上做了一個(gè)小創(chuàng)新：Html鉤子
在html上加上操作系統(tǒng)、瀏覽器內(nèi)核、瀏覽器類型、CSS3動(dòng)畫支持、IE各版本類，好處在于：

• 漸進(jìn)增強(qiáng) 可以實(shí)現(xiàn)不同瀏覽器下差異化體驗(yàn)。

• 能快速定位并修復(fù)某個(gè)瀏覽器下的特定bug。
  

淘寶首頁(yè)html鉤子：

兼容性問(wèn)題是老生常談的問(wèn)題了，團(tuán)隊(duì)之間共同努力形成一個(gè)bug兼容性積累文檔，是最好不過(guò)的了。

6 搜索SEO

6.1 語(yǔ)義化

• 標(biāo)簽語(yǔ)義化對(duì)搜索引擎友好，良好的結(jié)構(gòu)和語(yǔ)義容易被搜索引擎抓取。

• 善用標(biāo)題h1，h2，h3，h4，h5，h6，特別是h1和h2；H(x)標(biāo)簽中使用關(guān)鍵字，可提升排名。同時(shí)設(shè)置 rel=“nofollow”避免權(quán)重流失。

• 使用 HTML5 中的 Microdata 對(duì) Web 頁(yè)面上已經(jīng)存在的數(shù)據(jù)提供附加的語(yǔ)義。Microdata 由名字 / 值（name/value）對(duì)組成，每一個(gè)詞匯表定義一組命名的屬性。對(duì) Microdata 的支持可以影響搜索結(jié)果的顯示，使得顯示結(jié)果更加豐富，雖然不能影響搜索結(jié)果的排名，但是網(wǎng)站的流量可能會(huì)有所增加。類似的技術(shù)還有資源描述框架RDF、微格式Microformat 。
  

6.2 衡量站點(diǎn)關(guān)鍵詞優(yōu)化

• 站點(diǎn)內(nèi)容以及關(guān)鍵詞的選擇。
  

• 描述標(biāo)簽、關(guān)鍵詞標(biāo)簽、代替屬性。
  

• 長(zhǎng)尾關(guān)鍵詞：非目標(biāo)關(guān)鍵詞但也可以帶來(lái)搜索流量的關(guān)鍵詞；例如，目標(biāo)關(guān)鍵詞是服裝，其長(zhǎng)尾關(guān)鍵詞可以是男士服裝、冬裝、戶外運(yùn)動(dòng)裝等。長(zhǎng)尾關(guān)鍵詞基本屬性是：可延伸性，針對(duì)性強(qiáng)，范圍廣。
  

• 關(guān)鍵詞的分布情況。
  

• 關(guān)鍵詞密度、看重：合理的關(guān)鍵字密度可獲得較高的排名位置，密度過(guò)大會(huì)起到相反的效果。一般說(shuō)來(lái)，在大多數(shù)的搜索引擎中，關(guān)鍵詞密度在2%~8%是一個(gè)較為適當(dāng)?shù)姆秶?，有利于網(wǎng)站在搜索引擎中排名。
  

• 是否存在作弊行為。
  

6.3 鏈接

• 優(yōu)化文件目錄結(jié)構(gòu)和URL。URL應(yīng)該有語(yǔ)義性，簡(jiǎn)短易懂。
  

• 通過(guò)推廣暴露自己的鏈接，增加信任度。鏈接分為外向鏈接和內(nèi)向（反向）鏈接，外向鏈接就是從本站點(diǎn)到其他站點(diǎn)，內(nèi)向鏈接就是從其他站點(diǎn)到我的站點(diǎn)，可以嘗試使用反向鏈接生成器（http://www./）?；蛘咄ㄟ^(guò)寫軟文、發(fā)布分類信息、發(fā)布博客文章來(lái)推廣自己的網(wǎng)站。
  

• 錨文本 ：把關(guān)鍵詞做一個(gè)鏈接，指向別的網(wǎng)頁(yè)，這種形式的鏈接就叫作錨文本。搜索引擎可以根據(jù)指向某一個(gè)網(wǎng)頁(yè)的鏈接的錨文本描述來(lái)判斷該網(wǎng)頁(yè)的內(nèi)容屬性。
  

6.4 良好的網(wǎng)站導(dǎo)航和sitemap

網(wǎng)站需要有一個(gè)良好的導(dǎo)航，控制根目錄和各子目錄的關(guān)鍵，通過(guò)sitemap可以幫助網(wǎng)站主了解網(wǎng)站結(jié)構(gòu)，也方便搜索引擎收錄整個(gè)站點(diǎn)。

7 其他優(yōu)化

7.1 信息無(wú)障礙

信息無(wú)障礙一般可以從以下幾點(diǎn)入手：

• 添加landmark角色，在頁(yè)面主要操作區(qū)域（搜索框、登錄框、列表內(nèi)容）添加“role”標(biāo)簽加以說(shuō)明。landmark值一般有：banner（banner）、complementary（輔助內(nèi)容區(qū)）、contentinfo（網(wǎng)站信息和版權(quán)）、form（表單）、main（主內(nèi)容區(qū)）、navigation（導(dǎo)航區(qū)）、search（搜索區(qū)），如：
  

• 提供文字替代方案。比如給圖片或其他元素提供適當(dāng)?shù)腶lt屬性或者title屬性的值。
  

• 表單使用label標(biāo)簽。
  

• 使用heading做信息架構(gòu)。讀屏軟件提供了快捷鍵切換heading，相關(guān)用戶可通過(guò)讀屏軟件了解我們的網(wǎng)站信息架構(gòu)。
  

• 給頁(yè)面里重要區(qū)塊和功能添加accesskey，可以快速定位。
  

• 觸發(fā)界面轉(zhuǎn)換需設(shè)置焦點(diǎn)。比如，對(duì)于浮層需要注意避免“Tab”焦點(diǎn)中斷。
  

• 考慮到老年眼睛老花，因此需要保證字體夠大，或者網(wǎng)站可縮放。
  
  具體可參考無(wú)障礙閱讀（http://www.qq.com/demo/accessibility.htm）
  

7.2 微動(dòng)畫

通過(guò)前端動(dòng)畫技術(shù)給頁(yè)面進(jìn)行優(yōu)化，比如：

• 商品圖片hover效果
  

• 小圖標(biāo)旋轉(zhuǎn)效果
  

• 購(gòu)物車微動(dòng)畫
  

• loading動(dòng)畫，當(dāng)加載頁(yè)面需要一定時(shí)間，特別是移動(dòng)端，可以通過(guò)有趣的loading動(dòng)畫吸引用戶，這里有一些有趣的loading動(dòng)畫
  

7.3 requireJs

requireJs框架特性：

• 前端設(shè)計(jì)及開發(fā)人員統(tǒng)一代碼規(guī)范。
  

• 按需加載。
  

• AMD規(guī)范：以簡(jiǎn)單而優(yōu)雅的方式統(tǒng)一了JavaScript的模塊定義和加載機(jī)制，降低了學(xué)習(xí)和使用各種框架的門檻，能夠以一種統(tǒng)一的方式去定義和使用模塊，提高開發(fā)效率，降低了應(yīng)用維護(hù)成本。
  

• 與Grunt結(jié)合可實(shí)現(xiàn)一站式工作流。
  

7.4 多標(biāo)簽狀態(tài)同步

場(chǎng)景如下：
頁(yè)面一：去一個(gè)網(wǎng)站買東西，未登錄狀態(tài)下，進(jìn)入首頁(yè)；
頁(yè)面二：然后新窗口打開任意頁(yè)面，登錄并成功返回。
再次訪問(wèn)頁(yè)面一，發(fā)現(xiàn)頁(yè)面還是未登錄狀態(tài)，實(shí)際上用戶已經(jīng)登錄了，這種體驗(yàn)是很差的。我們是不是有什么辦法可以實(shí)現(xiàn)多標(biāo)簽狀態(tài)同步呢？有的，利用Page Visibility：

• 頁(yè)面可見性API就是表示網(wǎng)頁(yè)可見還是不可見的。頁(yè)面可見性API有兩個(gè)屬性，一個(gè)事件，如下：
  

• document.hidden: Boolean值，表示當(dāng)前頁(yè)面可見還是不可見
  

• document.visibilityState: 返回當(dāng)前頁(yè)面的可見狀態(tài)，狀態(tài)值有hidden、visible、prerender、preview。
  

• visibilitychange: 當(dāng)可見狀態(tài)改變時(shí)候觸發(fā)的事件。
  

• 瀏覽器支持：IE10+、Chrome、FireFox。
  

• 多標(biāo)簽狀態(tài)同步demo: 網(wǎng)頁(yè)可見性API與登錄同步（http://www./study/201211/page-visibility-api-login-same-step-1.html）
  

7.5 個(gè)性化推薦

    HTML5 Geolocation API獲得用戶的地理位置，進(jìn)行基于地理位置的運(yùn)營(yíng)。