本文主要從工作效率、速度性能、穩(wěn)定性、響應(yīng)式、兼容性、搜索SEO、信息無障礙等方面進(jìn)行講解。前端優(yōu)化是一個(gè)讓人技術(shù)提升的point，希望你也能從這里學(xué)到一些東西。
1 工作效率
你是否經(jīng)常處于這樣的場景：從早上忙到晚上八九點(diǎn)，一會(huì)與產(chǎn)品經(jīng)理溝通，一會(huì)在部門群聊一下新奇的東西，一會(huì)被設(shè)計(jì)美眉糾纏住拖不了身，有時(shí)還開不了部門的會(huì)議因?yàn)轫撁婕敝暇€，然后繼續(xù)加班~~~
怎么提高我們的工作效率？下面從四個(gè)方面講解：
時(shí)間管理
利用工具
經(jīng)驗(yàn)和閱歷
使用新技術(shù)
1.1 時(shí)間管理
凡是時(shí)間管理，都會(huì)聯(lián)想到計(jì)劃這個(gè)詞。我們先看看別人家的月計(jì)劃表和周計(jì)劃表，之所以周計(jì)劃表為空，是希望你能把它下載并打印出來，行動(dòng)從計(jì)劃開始：
月計(jì)劃表：
周計(jì)劃表：
當(dāng)然計(jì)劃不要做得過于瑣碎，且不要占用自己太多時(shí)間。做好計(jì)劃之余，在執(zhí)行過程中需要注意幾點(diǎn)：
正確的時(shí)間點(diǎn)做正確的事，比如早上比較精神，可選擇比較難的項(xiàng)目開展，可容易達(dá)到高效率。
專注一件事情，盡量不要被瑣碎或其他事情影響，而且不要頻繁地去看計(jì)劃表，最好是做完一件再去看，否則容易焦慮導(dǎo)致無法專心。
1.2 利用工具
第一樣工具，比如程序員杯子：
利用工具有什么好處呢？
減少重復(fù)性工作。
減少繁瑣工作流程，一鍵式化。
1.2.1 編輯器
選擇好一個(gè)前端編輯器是比較重要的。目前sublime、webstorm和vim是比較常見的，建議不使用Dreamweaver。
sublime目前還是不錯(cuò)的選擇，可以安裝插件，比如BracketHighlighter 高亮顯示、JsFormat、Emmet html/CSS快速編輯以及DocBlockr插件，快速輸入jsDoc注釋等，還可以自定義代碼段snippets。
無論你使用哪種編輯器，你需要的是熟悉這個(gè)編輯器并熟練它的快捷鍵。
1.2.2 瀏覽器開發(fā)者工具
作為前端人員，首選的瀏覽器當(dāng)然是chrome。推薦閱讀Chrome開發(fā)者工具不完全指南一系列文章（http://web.jobbole.com/82558/），它從一些基礎(chǔ)的功能開始到它的一些高級性能分析器（Timeline、Profiles），熟悉chrome對我們的開發(fā)工作有很大的作用。
1.2.3 其他常用工具
切圖工具：photoshop cc切圖之智能切圖、 cutterman
量色、測距工具：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)和樣式庫。
（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ā)流程等問題。還有凹凸實(shí)驗(yàn)室研發(fā)的athena（http://aotu.io/athena/），O2Team構(gòu)建項(xiàng)目流程工具，可以生成相應(yīng)目錄和代碼，同時(shí)對項(xiàng)目進(jìn)行編譯， 一次安裝，到處運(yùn)行。
1.3 閱歷和經(jīng)驗(yàn)
我所理解的程序員兼并聰明以及“懶惰”精神，推崇懶惰式開發(fā)，即把問題理解清楚，確保將要寫的代碼能真正的解決問題，這將會(huì)避免之后寫出大量無用的代碼，正所謂“懶”出效率。
我們的閱歷和經(jīng)驗(yàn)可以大大提高開發(fā)效率，思考代碼的時(shí)間增加從而選出最優(yōu)方案，因此寫代碼速度更快以及代碼長度更短，對問題的透徹理解使調(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ì)派上用場的。
2 速度性能
為什么需要前端性能優(yōu)化？性能優(yōu)化可以從哪幾個(gè)方面入手？
遇到一個(gè)頁面，5秒還沒加載完成，那個(gè)菊花轉(zhuǎn)啊轉(zhuǎn)，或者頁面完全白屏，那簡直把人逼瘋了。從用戶體驗(yàn)的角度看，前端性能優(yōu)化是非常有必要的。網(wǎng)頁最長加載時(shí)間一般不能超過3秒。
首先我們需要確定網(wǎng)頁的性能指標(biāo)，可量化的目標(biāo)以及可持續(xù)跟蹤的優(yōu)化數(shù)據(jù)是性能優(yōu)化工作得以持續(xù)進(jìn)行的保障，同時(shí)也是源動(dòng)力！比如：
首屏加載時(shí)長
DOM加載時(shí)長
頁面白屏?xí)r長
我們一般通過三種方式來檢驗(yàn)我們的網(wǎng)頁性能：
通過瀏覽器開發(fā)者工具或?yàn)g覽器插件、Fiddler、Charles等查看頁面加載情況。原理是通過追蹤HTTP請求與響應(yīng)的時(shí)間，以圖形的方式列出所有資源的下載情況。缺點(diǎn)是人為操作，難以實(shí)現(xiàn)批量測試與統(tǒng)計(jì)。
在頁面中引入額外的代碼鉤子來記錄時(shí)間等相關(guān)數(shù)據(jù)。缺點(diǎn)是加重了開發(fā)者與測試人員的負(fù)擔(dān)，還有可能因?yàn)闄z測代碼本身的潛在問題影響頁面的性能。如果好一點(diǎn)的話，會(huì)接入一個(gè)性能數(shù)據(jù)收集系統(tǒng)，采取并分析數(shù)據(jù)。
使用第三方的工具如Page Speed、YSlow和WebPagetest，能夠選擇在不同瀏覽器和不同地域進(jìn)行測試，并且給出各方面的評分以及提供一些優(yōu)化建議。但某些服務(wù)需要排隊(duì)等待，并且難以實(shí)現(xiàn)批量測試與統(tǒng)計(jì)。下面是使用WebPagetest測試京東首頁的情況：
可喜可賀，W3C推出了一套性能API標(biāo)準(zhǔn)，目的是簡化開發(fā)者對網(wǎng)站性能進(jìn)行精確分析與控制的過程，最終實(shí)現(xiàn)性能的提高。比如通過Navigation Timing記錄的關(guān)鍵時(shí)間點(diǎn)來統(tǒng)計(jì)頁面完成所用的時(shí)間，部分使用方法：
持續(xù)追蹤性能數(shù)據(jù)，要選擇合適的頁面性能測量工具或API，一旦選定后，不再更換，以保證歷史數(shù)據(jù)的可參照性。我們還要形成一種意識(shí)，達(dá)成性能聯(lián)盟小組，對于重要的業(yè)務(wù)或者頁面，一定要從性能的角度考慮問題，有理有據(jù)地拒絕有損于前端性能的業(yè)務(wù)需求或改動(dòng)。
人人都知道雅虎軍規(guī)，那我就來個(gè)截圖吧！
以下，我們從服務(wù)端、網(wǎng)絡(luò)、客戶端三個(gè)方面來一一突破速度性能的提升。
2.1 沒事少煩我-服務(wù)端
2.1.1 使用內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）
通過在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的 cache服務(wù)器內(nèi)，通過DNS負(fù)載均衡的技術(shù)，判斷用戶來源就近訪問cache服務(wù)器取得所需的內(nèi)容。深圳用戶訪問遙遠(yuǎn)的美國服務(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í)可使用資源或加載資源更快，豈不樂哉？
緩存利用可包括：添加 Expires 頭，配置 ETag，使 Ajax 可緩存等。其實(shí)，恰當(dāng)?shù)木彺嬖O(shè)置可以大大的減少 HTTP請求，也可以節(jié)省帶寬 。
配置 ETag：即If-None-Match: 上次 ETag 的內(nèi)容。瀏覽器會(huì)發(fā)出請求詢問服務(wù)端，資源是否過期；服務(wù)端發(fā)現(xiàn),沒有過期，直接返回一個(gè)狀態(tài)碼為 304、正文為空的響應(yīng)，告知瀏覽器使用本地緩存；如果資源有更新，服務(wù)端返回狀態(tài)碼 200、Etag 和正文。這個(gè)過程被稱之為 HTTP 的協(xié)商緩存，通常也叫做弱緩存。
添加 Expires 頭：服務(wù)端通過響應(yīng)頭告訴瀏覽器，在什么時(shí)間之前（Expires）或在多長時(shí)間之內(nèi)（Cache-Control: Max-age=xxx），不要再請求服務(wù)器了。這個(gè)機(jī)制我們通常稱之為 HTTP 的強(qiáng)緩存。一般會(huì)對 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)頁面無法訪問時(shí)的回退頁面
使用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ì)過期的。
2.2 省著點(diǎn)用-網(wǎng)絡(luò)
2.2.1 減少請求數(shù)
可通過以下方式減少請求數(shù)：
小圖片合并雪碧圖；
JS、CSS文件選擇性合并；
避免重復(fù)的資源請求。
減少請求數(shù)對于速度優(yōu)化來說最重要最有效的，特別是網(wǎng)絡(luò)差的用戶。一個(gè)完整的請求需要經(jīng)過域名解析以及DNS尋址、與服務(wù)器建立連接、發(fā)送數(shù)據(jù)、等待服務(wù)器響應(yīng)、接收數(shù)據(jù)的過程；每個(gè)請求都需要攜帶數(shù)據(jù)，因此每個(gè)請求都需要占用帶寬；瀏覽器進(jìn)行并發(fā)請求的請求數(shù)是有上限的。請求多了的情況，明顯增加了網(wǎng)頁的響應(yīng)時(shí)間。一個(gè)頁面由多個(gè)模塊拼接而成，幾個(gè)模塊中請求了同樣的資源時(shí)，就會(huì)導(dǎo)致資源的重復(fù)請求。
2.2.2 減少文件大?。p少請求帶寬）
壓縮CSS、JS、圖片；
盡可能控制DOM節(jié)點(diǎn)數(shù)；
精簡css、 JavaScript，移除注釋、空格、重復(fù)css和腳本。
開啟Gzip，Gzip的思想就是把文件先在服務(wù)器端進(jìn)行壓縮，且壓縮率達(dá)到85%，然后再傳輸，傳輸完畢后瀏覽器會(huì) 重新對壓縮過的內(nèi)容進(jìn)行解壓縮，并執(zhí)行。。好處在于Gzip的支持已經(jīng)很好，且爬蟲可識(shí)別，壓縮率達(dá)到66%-85%顯著減少了文件傳輸?shù)拇笮?。另外，gzip對pdf文件的壓縮效果不大，而且會(huì)浪費(fèi)CPU。
2.2.3 合理使用靜態(tài)資源域名
域名的要求是短小且獨(dú)立。
短小可以減少頭部開銷，因?yàn)橛蛎蕉陶埱箢^起始行的 URI 就越短。之所以要求獨(dú)立，因?yàn)楠?dú)立域名不會(huì)共享主域的 Cookie，可以有效減小請求頭大小，這個(gè)策略一般稱之為 Cookie-Free Domain；另外一個(gè)原因是瀏覽器對相同域名的并發(fā)連接數(shù)限制，一般允許同域名并發(fā) 6~8 個(gè)連接，域名不是越多越好，每個(gè)域名的第一個(gè)連接都要經(jīng)歷 DNS 查詢（DNS Lookup），導(dǎo)致會(huì)耗費(fèi)一定的時(shí)間，控制域名使用在2-4個(gè)之間。另外注意：同一靜態(tài)資源在不同頁面被散列到不同子域下，會(huì)導(dǎo)致無法利用 HTTP 緩存。
2.2.4 使用HTTP 2
HTTP 2 相比 HTTP 1.1 的更新大部分集中于：
多路復(fù)用：多路復(fù)用很好地解決如何讓重要資源盡快加載這個(gè)問題。同域名下或者不同域但是同時(shí)滿足同一個(gè) IP以及使用同一個(gè)證書的這兩個(gè)條件中的所有通信都在單個(gè)連接上完成，此連接上同時(shí)打開任意數(shù)量的雙向數(shù)據(jù)流（ HTTP 1.1 有連接數(shù)限制）。使用多域名加上相同的 IP 和證書部署 Web 服務(wù)有特殊的意義：讓支持 HTTP/2 的終端只建立一個(gè)連接，用上 HTTP/2 協(xié)議帶來的各種好處；而只支持 HTTP/1.1 的終端則會(huì)建立多個(gè)連接，達(dá)到同時(shí)更多并發(fā)請求的目的。
HEAD 壓縮：HTTP/2 將請求和響應(yīng)數(shù)據(jù)分割為更小的幀，并對它們采用二進(jìn)制編碼（ Binary Framing ）。在 HTTP/1 中，HTTP 請求和響應(yīng)都是由「狀態(tài)行、請求 / 響應(yīng)頭部、消息主體」三部分組成，狀態(tài)行和頭部卻沒有經(jīng)過任何壓縮，直接以純文本傳輸。如下圖的比較：
在 HTTP/2 中，每個(gè)數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個(gè)或多個(gè)幀組成。多個(gè)幀之間可以亂序發(fā)送，因?yàn)楦鶕?jù)幀首部的流標(biāo)識(shí)可以重新組裝。
請求優(yōu)先級：服務(wù)器可以根據(jù)流的優(yōu)先級，控制資源分配(CPU、內(nèi)存、帶寬)，而在響應(yīng)數(shù)據(jù)準(zhǔn)備好之后，優(yōu)先將最高優(yōu)先級的幀發(fā)送給客戶端。
服務(wù)器推送：啟動(dòng)Server Push，意味著服務(wù)端可以在發(fā)送頁面HTML時(shí)主動(dòng)推送其它資源，有自己獨(dú)立的URL，可以被瀏覽器緩存；如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送 RST_STREAM 幀來拒收。
2.2 學(xué)會(huì)持家，讓家變得簡潔漂亮-客戶端
使用外鏈CSS和JS，CSS放頭，JS放尾，防止阻塞以減少對并發(fā)下載的影響，盡早刷新文檔的輸出。
html的代碼優(yōu)化，如：
避免空的圖片src；
協(xié)議自適應(yīng)，減少html文件大小，將https://和http://都替換成//。
css的代碼優(yōu)化，如：
建議使用類選擇器，訪問比較快；
不建議使用很長的base64；
避免CSS表達(dá)式；
避免使用Filters。
js的代碼優(yōu)化，如：
避免使用eval和width；
減少作用域鏈查找；
減少DOM訪問，盡量緩存DOM；
充分利用事件委托；
減少Repaint（重繪）和Reflow（重排）最好通過批量更新元素減少重排次數(shù)，如設(shè)置類class統(tǒng)一更新樣式，在添加多個(gè)li
元素將會(huì)觸發(fā)多次頁面重排的情況下使用 DOM fargment 在內(nèi)存中創(chuàng)建完整的 DOM 節(jié)點(diǎn)，然后再一次性添加到 DOM 中。
圖片格式的選擇：
顏色較為豐富的圖片而且文件比較大的（40KB - 200KB）或者有內(nèi)容的圖片優(yōu)先考慮 jpg；圖標(biāo)等顏色比較簡單、文件體積不大、起修飾作用的圖片，優(yōu)先考慮使用 PNG8 格式；圖像顏色豐富而且圖片文件不太大的（40KB 以下）或有半透明效果的優(yōu)先考慮 PNG24 格式。
條件允許的，使用新格式WEBP和BPG。
用SVG和ICONFONT代替簡單的圖標(biāo)。
用字蛛來代替藝術(shù)字體切圖，它可剔除沒有使用的字符，從而解決中文字體過大的問題，并編碼成跨平臺(tái)兼容的格式。
合理分配資源加載時(shí)間，按需加載，包括CSS、JS文件以及圖片、業(yè)務(wù)模塊等。根據(jù)我們網(wǎng)頁最初加載需要的最小內(nèi)容集推斷其他內(nèi)容延遲加載；無條件提前加載公共內(nèi)容或根據(jù)用戶行為推斷提前加載某些內(nèi)容，如根據(jù)搜索框輸入的文字來判斷加載的內(nèi)容。加載機(jī)制如下：
預(yù)加載
Dom Ready后加載
onLoad后加載
滾動(dòng)加載
減少DNS 查詢：DNS 查詢一般需要幾毫秒到幾百毫秒，移動(dòng)環(huán)境下會(huì)更慢。我們可以預(yù)先讀取DNS，減少用戶等待時(shí)間。
3 穩(wěn)定性
穩(wěn)定性的第一要求是可用。最起碼的要求是頁面得出來，要不然沒法用了。
其次講究的是頁面的可維護(hù)性，假如頁面掛了，多久可以恢復(fù)過來，另外考慮頁面掛的期間是否可以采取靜態(tài)頁面處理等方式。
頁面的穩(wěn)定性其實(shí)和前端安全掛鉤，即使頁面可以出來了，但是不能保證不會(huì)被黑掉，下文從前端安全的方面講解。
3.1 常見攻擊：
XSS (Cross Site Script) ，跨站腳本攻擊，往Web頁面里插入惡意html代碼。特點(diǎn)是攻擊者的代碼必須能獲取用戶瀏覽器端的執(zhí)行權(quán)限，要杜絕此類攻擊出現(xiàn)可以在入口和出口進(jìn)行嚴(yán)格的過濾。
三種類型：
（1） 反射型XSS：一次性；將包含注入腳本的惡意鏈接發(fā)送給受害者。
（2） 持久型XSS：用戶輸入的數(shù)據(jù)“存儲(chǔ)”在服務(wù)器端，比如一條包含XSS代碼的留言。
（3） DOM XSS：使用一些eval等有輸出的語句意味著多了一份被XSS的風(fēng)險(xiǎn)。
應(yīng)對策略：
當(dāng)惡意代碼值被作為某一標(biāo)簽的內(nèi)容顯示：在不需要html輸入的地方對html 標(biāo)簽及一些特殊字符( ” <> & 等等 )做過濾，將其轉(zhuǎn)化為不被瀏覽器解釋執(zhí)行的字符。
當(dāng)惡意代碼被作為某一標(biāo)簽的屬性顯示，通過用 “將屬性截?cái)鄟黹_辟新的屬性或惡意方法：屬性本身存在的 單引號(hào)和雙引號(hào)都需要進(jìn)行轉(zhuǎn)碼；對用戶輸入的html 標(biāo)簽及標(biāo)簽屬性做白名單過濾，也可以對一些存在漏洞的標(biāo)簽和屬性進(jìn)行專門過濾。
CSRF(Cross Site Request Forgery)，跨站點(diǎn)偽造請求，通過偽造連接請求在用戶不知情的情況下，讓用戶以自己的身份來完成攻擊者需要達(dá)到的一些目的。
cookie劫持，通過獲取頁面的權(quán)限，在頁面中寫一個(gè)簡單的到惡意站點(diǎn)的請求，并獲取用戶的cookie登錄某些站點(diǎn)。
對于crsf 和cookie 劫持的策略：
通過 referer、token 或者 驗(yàn)證碼 來檢測用戶提交。
盡量不要在頁面的鏈接中暴露用戶隱私信息。
對于用戶修改刪除等操作最好都使用post 操作 。
避免全站通用的cookie，嚴(yán)格設(shè)置cookie的域。
3.2 數(shù)據(jù)通道安全
國內(nèi)的眾多網(wǎng)站都沒有實(shí)現(xiàn)全站HTTPS。這是目前為止最重要的一步，所有的數(shù)據(jù)在發(fā)送之前就會(huì)被加密，攻擊者無法查看或篡改數(shù)據(jù)包的內(nèi)容。HTTPS可以理解為HTTP+SSL/TLS，通過數(shù)據(jù)加密、校驗(yàn)數(shù)據(jù)完整性和身份認(rèn)證三種機(jī)制來保障安全。
HTTPS的缺點(diǎn)是網(wǎng)站在加上TLS證書時(shí)，可能導(dǎo)致RTT往返時(shí)延增加，并且 HTTPS通信過程的非對稱和對稱加解密計(jì)算會(huì)產(chǎn)生更多的服務(wù)器性能和時(shí)間上的消耗，但是這是可以優(yōu)化的，這里就不細(xì)說了。
3.3瀏覽器安全
3.3.1 同源策略
首先了解一下同源策略：
源指的是有相同的HOST、相同的協(xié)議、相同的端口。
同源策略以源為單位，把資源天然分隔，保護(hù)了用戶的信息安全。
繞過同源策略讓javascript訪問其他源的資源的方法，如：JSONP、CORS、flash等。
同源策略不是絕對安全的，面對很多攻擊是無能為力的，比如XSS，因?yàn)榇藭r(shí)攻擊者就在同源之內(nèi)。
不建議使用JSONP，因?yàn)镴SONP通常在腳本中寫一個(gè)回調(diào)函數(shù)，然后把回調(diào)函數(shù)的名字寫在請求的URL中，因此如果請求數(shù)據(jù)的服務(wù)器被黑了，那么黑客就能在返回的數(shù)據(jù)中植入惡意代碼，從而竊取用戶的隱私信息。
跨域資源共享CORS允許資源提供方在響應(yīng)頭中加入一個(gè)特殊的標(biāo)記，使你能通過XHR來獲取、解析并驗(yàn)證數(shù)據(jù)。這樣就能避免惡意代碼在你的應(yīng)用中執(zhí)行。在響應(yīng)頭中加入的標(biāo)記如下：
Access-Control-Allow-Origin: allowed origins
如果對Access–Control-Allow-Origin設(shè)置為*其實(shí)是比較危險(xiǎn)的，如果沒有攜帶會(huì)話認(rèn)證意味著信息被公開在全網(wǎng)，建議設(shè)置具體的域名，而且跨域的時(shí)候記得帶上session id；嚴(yán)格審查請求信息，比如請求參數(shù)，還有http頭信息，因?yàn)?http頭可以偽造。
3.3.2 CSP(Content Security Policy)
CSP指定網(wǎng)站上所有腳本和圖片等資源的源站點(diǎn)，也能阻止所有內(nèi)聯(lián)（inline）的腳本和樣式。即使有人在頁面評論或者留言中嵌入了腳本標(biāo)簽，這些腳本代碼也不會(huì)被執(zhí)行?？赏ㄟ^兩種方式設(shè)置，如果 HTTP 頭與 Meta 定義同時(shí)存在，則優(yōu)先采用 HTTP 頭中的定義：
通過 HTTP 頭，比如只允許腳本從本源加載：Content-Security-Policy: script-src 'self’，其中script-src 'self’是策略。
通過HTML的Meta標(biāo)簽，比如只允許腳本從本源加載：
其他策略：
script-src – 設(shè)置可以接受的JavaScript代碼的源站點(diǎn)
style-src – 設(shè)置可以接受的CSS樣式代碼的源站點(diǎn)
connect-src – 定義瀏覽器可以通過XHR、WebSocket或者 EventSource訪問哪些站點(diǎn)
font-src – 設(shè)置可以接受的字體文件的源站點(diǎn)
frame-src – 定義瀏覽器可以通過iframe訪問哪些站點(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覽器無法區(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)容只能通過SSL連接進(jìn)行傳輸。Secure和HttpOnly屬性告訴瀏覽器cookie的內(nèi)容只能分別通過HTTP(S)協(xié)議進(jìn)行訪問，從而避免了被輕易竊取，比如禁止從JavaScript中的document.cookie訪問，因此cookie在瀏覽器document中不可見了。如果單獨(dú)使用的話，無法全面抵御跨站點(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 頭，用來檢測一個(gè)證書的公鑰是否發(fā)生了改變，防止中間人攻擊。
HSTS (HTTP Strict-Transport-Security) 強(qiáng)制使用TSL作為數(shù)據(jù)通道。
3.4 HTML5 對web安全的影響
html5有很多新的特性能力，然而能力越大，被攻破后的危險(xiǎn)就越大。
HTML5 對xss的影響主要體現(xiàn)在:
攻擊面更大，html5帶來更多的標(biāo)簽和更多的屬性如[video],[audio],[canvas]等；[/canvas][/audio][/video]
危害更大，HTML5更多的資源可以被xss利用。黑客可以利用瀏覽器的一切權(quán)限，比如本地存儲(chǔ)、GEO、服務(wù)器推送機(jī)制WebSocket，js多線程執(zhí)行Webworker等。
比如localstorage只能通過js設(shè)置和獲取，導(dǎo)致的結(jié)果是不能像cookie一樣設(shè)置httponly等屬性，所以localstorage中不能存放敏感信息，最好能夠在服務(wù)端進(jìn)行加密，可以配合CORS來獲取網(wǎng)站的localstorage的信息。
4 響應(yīng)式
響應(yīng)式布局簡而言之，就是一個(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è)備。
利用百分比。
對低版本瀏覽器使用JS動(dòng)態(tài)響應(yīng)。
一套“自適應(yīng)”素材兼容各種分辨率，提升頁面性能，比如自適應(yīng)的圖片/視頻素材。
比如凹凸實(shí)驗(yàn)室博客頁面在PC端、iPad、手機(jī)端的排版：
PC端：
iPad：
手機(jī)端：
5 兼容性
估計(jì)很多人對這句話都有體會(huì)：IE虐我千百遍，我待IE如初戀。當(dāng)然，除了 IE 上有兼容性問題，其他瀏覽器比如 Android 上的低版本瀏覽器也有較多問題。
是否繼續(xù)保持對低端瀏覽器的兼容性，我們可以用數(shù)據(jù)跟產(chǎn)品經(jīng)理或者老板說話，減少我們的工作量，最好在項(xiàng)目之前就定下來支持最低支持的版本是什么，然后設(shè)計(jì)一個(gè)對應(yīng)兼容方案。以下是百度統(tǒng)計(jì)的2015年的瀏覽器市場份額數(shù)據(jù)：
兼容性的原則：漸進(jìn)增強(qiáng)與平穩(wěn)退化。就是說，在低級瀏覽器能夠保證其可用性和可訪問性；漸進(jìn)增強(qiáng)，在保證代碼、頁面在低級瀏覽器中的可用性及可訪問性的基礎(chǔ)上，逐步增加功能及用戶體驗(yàn)。
如果出現(xiàn)兼容性問題了，怎么處理：
確認(rèn)觸發(fā)場景，什么瀏覽器、版本、什么情況下會(huì)出現(xiàn)這個(gè)問題，做到穩(wěn)定復(fù)現(xiàn)。
找到問題原因，為什么會(huì)出現(xiàn)這樣的問題（自己琢磨、網(wǎng)上搜、問同事）。
確定解決辦法：參考現(xiàn)成的規(guī)范，比如某些屬性不能使用以及一些hack的處理。
積累兼容性處理方法。
淘寶首頁在兼容性上做了一個(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。
淘寶首頁html鉤子：
兼容性問題是老生常談的問題了，團(tuán)隊(duì)之間共同努力形成一個(gè)bug兼容性積累文檔，是最好不過的了。
6 搜索SEO
6.1 語義化
標(biāo)簽語義化對搜索引擎友好，良好的結(jié)構(gòu)和語義容易被搜索引擎抓取。
善用標(biāo)題h1，h2，h3，h4，h5，h6，特別是h1和h2；H(x)標(biāo)簽中使用關(guān)鍵字，可提升排名。同時(shí)設(shè)置 rel=“nofollow”避免權(quán)重流失。
使用 HTML5 中的 Microdata 對 Web 頁面上已經(jīng)存在的數(shù)據(jù)提供附加的語義。Microdata 由名字 / 值（name/value）對組成，每一個(gè)詞匯表定義一組命名的屬性。對 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)簽、代替屬性。
長尾關(guān)鍵詞：非目標(biāo)關(guān)鍵詞但也可以帶來搜索流量的關(guān)鍵詞；例如，目標(biāo)關(guān)鍵詞是服裝，其長尾關(guān)鍵詞可以是男士服裝、冬裝、戶外運(yùn)動(dòng)裝等。長尾關(guān)鍵詞基本屬性是：可延伸性，針對性強(qiáng)，范圍廣。
關(guān)鍵詞的分布情況。
關(guān)鍵詞密度、看重：合理的關(guān)鍵字密度可獲得較高的排名位置，密度過大會(huì)起到相反的效果。一般說來，在大多數(shù)的搜索引擎中，關(guān)鍵詞密度在2%~8%是一個(gè)較為適當(dāng)?shù)姆秶?，有利于網(wǎng)站在搜索引擎中排名。
是否存在作弊行為。
6.3 鏈接
優(yōu)化文件目錄結(jié)構(gòu)和URL。URL應(yīng)該有語義性，簡短易懂。
通過推廣暴露自己的鏈接，增加信任度。鏈接分為外向鏈接和內(nèi)向（反向）鏈接，外向鏈接就是從本站點(diǎn)到其他站點(diǎn)，內(nèi)向鏈接就是從其他站點(diǎn)到我的站點(diǎn)，可以嘗試使用反向鏈接生成器（http://www.backlinkpro.net/）?；蛘咄ㄟ^寫軟文、發(fā)布分類信息、發(fā)布博客文章來推廣自己的網(wǎng)站。
錨文本 ：把關(guān)鍵詞做一個(gè)鏈接，指向別的網(wǎng)頁，這種形式的鏈接就叫作錨文本。搜索引擎可以根據(jù)指向某一個(gè)網(wǎng)頁的鏈接的錨文本描述來判斷該網(wǎng)頁的內(nèi)容屬性。
6.4 良好的網(wǎng)站導(dǎo)航和sitemap
網(wǎng)站需要有一個(gè)良好的導(dǎo)航，控制根目錄和各子目錄的關(guān)鍵，通過sitemap可以幫助網(wǎng)站主了解網(wǎng)站結(jié)構(gòu)，也方便搜索引擎收錄整個(gè)站點(diǎn)。
7 其他優(yōu)化
7.1 信息無障礙
信息無障礙一般可以從以下幾點(diǎn)入手：
添加landmark角色，在頁面主要操作區(qū)域（搜索框、登錄框、列表內(nèi)容）添加“role”標(biāo)簽加以說明。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)用戶可通過讀屏軟件了解我們的網(wǎng)站信息架構(gòu)。
給頁面里重要區(qū)塊和功能添加accesskey，可以快速定位。
觸發(fā)界面轉(zhuǎn)換需設(shè)置焦點(diǎn)。比如，對于浮層需要注意避免“Tab”焦點(diǎn)中斷。
考慮到老年眼睛老花，因此需要保證字體夠大，或者網(wǎng)站可縮放。
具體可參考無障礙閱讀（http://www.qq.com/demo/accessibility.htm）
7.2 微動(dòng)畫
通過前端動(dòng)畫技術(shù)給頁面進(jìn)行優(yōu)化，比如：
商品圖片hover效果
小圖標(biāo)旋轉(zhuǎn)效果
購物車微動(dòng)畫
loading動(dòng)畫，當(dāng)加載頁面需要一定時(shí)間，特別是移動(dòng)端，可以通過有趣的loading動(dòng)畫吸引用戶，這里有一些有趣的loading動(dòng)畫
7.3 requireJs
requireJs框架特性：
前端設(shè)計(jì)及開發(fā)人員統(tǒng)一代碼規(guī)范。
按需加載。
AMD規(guī)范：以簡單而優(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)同步
場景如下：
頁面一：去一個(gè)網(wǎng)站買東西，未登錄狀態(tài)下，進(jìn)入首頁；
頁面二：然后新窗口打開任意頁面，登錄并成功返回。
再次訪問頁面一，發(fā)現(xiàn)頁面還是未登錄狀態(tài)，實(shí)際上用戶已經(jīng)登錄了，這種體驗(yàn)是很差的。我們是不是有什么辦法可以實(shí)現(xiàn)多標(biāo)簽狀態(tài)同步呢？有的，利用Page Visibility：
頁面可見性API就是表示網(wǎng)頁可見還是不可見的。頁面可見性API有兩個(gè)屬性，一個(gè)事件，如下：
document.hidden: Boolean值，表示當(dāng)前頁面可見還是不可見
document.visibilityState: 返回當(dāng)前頁面的可見狀態(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)頁可見性API與登錄同步（http://www.zhangxinxu.com/study/201211/page-visibility-api-login-same-step-1.html）
7.5 個(gè)性化推薦
HTML5 Geolocation API獲得用戶的地理位置，進(jìn)行基于地理位置的運(yùn)營。
聯(lián)系客服
