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