前端優化不完全指南

歷時144000000毫秒出山的前端優化篇，若你問我有什麽感悟？
那我告訴你，看到毫秒啊，火箭啊，這些與優化相關的詞，都有莫名的親切感。
本文主要從工作效率、速度性能、穩定性、響應式、兼容性、搜索SEO、信息無障礙等方面進行講解。
前端優化是一個讓人技術提升的point，希望你也能從這裏學到一些東西。

1 工作效率

你是否經常處於這樣的場景：從早上忙到晚上八九點，一會與產品經理溝通，一會在部門群聊一下新奇的東西，一會被設計美眉糾纏住拖不了身，有時還開不了部門的會議因為頁面急著上線，然後繼續加班~~~

怎麽提高我們的工作效率？下面從四個方面講解：

• 時間管理
• 利用工具
• 經驗和閱歷
• 使用新技術

1.1 時間管理

凡是時間管理，都會聯想到計劃這個詞。我們先看看別人家的月計劃表和周計劃表，之所以周計劃表為空，是希望你能把它下載並打印出來，行動從計劃開始：
月計劃表：

周計劃表：

當然計劃不要做得過於瑣碎，且不要占用自己太多時間。做好計劃之余，在執行過程中需要註意幾點：

• 正確的時間點做正確的事，比如早上比較精神，可選擇比較難的項目開展，可容易達到高效率。
• 專註一件事情，盡量不要被瑣碎或其他事情影響，而且不要頻繁地去看計劃表，最好是做完一件再去看，否則容易焦慮導致無法專心。

1.2 利用工具

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

利用工具有什麽好處呢？

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

1.2.1 編輯器

選擇好一個前端編輯器是比較重要的。目前sublime、webstorm和vim是比較常見的，建議不使用Dreamweaver。
sublime目前還是不錯的選擇，可以安裝插件，比如BracketHighlighter 高亮顯示、JsFormat、Emmet html/CSS快速編輯以及DocBlockr插件，快速輸入jsDoc註釋等，還可以自定義代碼段snippets。
無論你使用哪種編輯器，你需要的是熟悉這個編輯器並熟練它的快捷鍵。

1.2.2 瀏覽器開發者工具

作為前端人員，首選的瀏覽器當然是chrome。推薦閱讀Chrome開發者工具不完全指南一系列文章，它從一些基礎的功能開始到它的一些高級性能分析器（Timeline、Profiles），熟悉chrome對我們的開發工作有很大的作用。

1.2.3 其他常用工具

切圖工具：photoshop cc切圖之智能切圖、 cutterman
量色、測距工具：FastStone Capture、馬克鰻 - 設計稿標註
圖片壓縮：tinypng、智圖
生成雪碧圖：spritebox、CSS Sprite Generator、cssgaga
調試工具：Fiddler 、weinre 、微信調試工具；

1.2.4 前端工程化

凡是重復的，必須使用工具自動完成。
工具眾多，我們就有一種想法，能不能有一種工具能幫我們自動生成雪碧圖、 css壓縮、圖片壓縮等等，然後就出現了前端工程化。前端工程化一般可分為五個步驟：
（1） 初始，生成基礎目錄結構和樣式庫。
（2） 開發，實時預覽、預編譯。
（3） 構建，預編譯、合並、壓縮。
（4） 發布，將構建後靜態文件發布上線。
（5） 打包，資源路徑轉換，源碼打包 。

這裏推薦一個工具fis，解決前端開發中自動化工具、性能優化、模塊化框架、開發規範、代碼部署、開發流程等問題。還有凹凸實驗室研發的athena，O2Team構建項目流程工具，可以生成相應目錄和代碼，同時對項目進行編譯， 一次安裝，到處運行。

1.3 閱歷和經驗

我所理解的程序員兼並聰明以及“懶惰”精神，推崇懶惰式開發，即把問題理解清楚，確保將要寫的代碼能真正的解決問題，這將會避免之後寫出大量無用的代碼，正所謂“懶”出效率。
我們的閱歷和經驗可以大大提高開發效率，思考代碼的時間增加從而選出最優方案，因此寫代碼速度更快以及代碼長度更短，對問題的透徹理解使調試代碼的速度也更快。
根據閱歷和經驗，或借助其他人的，我們進行整理從而形成自己或團隊的規範，這可大大提高我們的寫碼速度。

1.4 使用新技術

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

2 速度性能

為什麽需要前端性能優化？性能優化可以從哪幾個方面入手？
遇到一個頁面，5秒還沒加載完成，那個菊花轉啊轉，或者頁面完全白屏，那簡直把人逼瘋了。從用戶體驗的角度看，前端性能優化是非常有必要的。網頁最長加載時間一般不能超過3秒。
首先我們需要確定網頁的性能指標，可量化的目標以及可持續跟蹤的優化數據是性能優化工作得以持續進行的保障，同時也是源動力！比如：

• 首屏加載時長
• DOM加載時長
• 頁面白屏時長

我們一般通過三種方式來檢驗我們的網頁性能：

• 通過瀏覽器開發者工具或瀏覽器插件、Fiddler、Charles等查看頁面加載情況。原理是通過追蹤HTTP請求與響應的時間，以圖形的方式列出所有資源的下載情況。缺點是人為操作，難以實現批量測試與統計。
• 在頁面中引入額外的代碼鉤子來記錄時間等相關數據。缺點是加重了開發者與測試人員的負擔，還有可能因為檢測代碼本身的潛在問題影響頁面的性能。如果好一點的話，會接入一個性能數據收集系統，采取並分析數據。
• 使用第三方的工具如Page Speed、YSlow和WebPagetest，能夠選擇在不同瀏覽器和不同地域進行測試，並且給出各方面的評分以及提供一些優化建議。但某些服務需要排隊等待，並且難以實現批量測試與統計。下面是使用WebPagetest測試京東首頁的情況：
  

可喜可賀，W3C推出了一套性能API標準，目的是簡化開發者對網站性能進行精確分析與控制的過程，最終實現性能的提高。比如通過Navigation Timing記錄的關鍵時間點來統計頁面完成所用的時間，部分使用方法：

持續追蹤性能數據，要選擇合適的頁面性能測量工具或API，一旦選定後，不再更換，以保證歷史數據的可參照性。我們還要形成一種意識，達成性能聯盟小組，對於重要的業務或者頁面，一定要從性能的角度考慮問題，有理有據地拒絕有損於前端性能的業務需求或改動。

人人都知道雅虎軍規，那我就來個截圖吧！

以下，我們從服務端、網絡、客戶端三個方面來一一突破速度性能的提升。

2.1 沒事少煩我-服務端

2.1.1 使用內容分發網絡（Content Delivery Network，CDN）

通過在現有的Internet中增加一層新的網絡架構，將網站的內容發布到最接近用戶的 cache服務器內，通過DNS負載均衡的技術，判斷用戶來源就近訪問cache服務器取得所需的內容。深圳用戶訪問遙遠的美國服務器，當然不理想了。把靜態內容分布到CDN可以減少用戶響應時間20%或更多。

2.1.2 靜態資源緩存，移動端離線緩存

如果可以減少服務端的負擔，在應用離線時可使用資源或加載資源更快，豈不樂哉？
緩存利用可包括：添加 Expires 頭，配置 ETag，使 Ajax 可緩存等。其實，恰當的緩存設置可以大大的減少 HTTP請求，也可以節省帶寬 。

• 配置 ETag：即If-None-Match: 上次 ETag 的內容。瀏覽器會發出請求詢問服務端，資源是否過期；服務端發現,沒有過期，直接返回一個狀態碼為 304、正文為空的響應，告知瀏覽器使用本地緩存；如果資源有更新，服務端返回狀態碼 200、Etag 和正文。這個過程被稱之為 HTTP 的協商緩存，通常也叫做弱緩存。
• 添加 Expires 頭：服務端通過響應頭告訴瀏覽器，在什麽時間之前（Expires）或在多長時間之內（Cache-Control: Max-age=xxx），不要再請求服務器了。這個機制我們通常稱之為 HTTP 的強緩存。一般會對 CSS、JS、圖片等資源使用強緩存，而入口文件（HTML）一般使用協商緩存或不緩存。

• AppCache：

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

  manifest 文件可分為三個部分：
  （1） CACHE MANIFEST - 在此標題下列出的文件將在首次下載後進行緩存，等價於CACHE
  （2） NETWORK - 在此標題下列出的文件需要與服務器的連接，且不會被緩存
  （3） FALLBACK - 在此標題下列出的文件規定當頁面無法訪問時的回退頁面

  使用AppCache方案的步驟：
  （1） 整理出需要緩存的靜態文件列表，如juqery.js和gb.css。
  （2） 配置服務器支持。
  （3） 確定內容更新機制和瀏覽器兼容方案。

• LocalStorage：用於持久化的本地存儲，除非主動刪除數據，否則數據是永遠不會過期的。

2.2 省著點用-網絡

2.2.1 減少請求數

可通過以下方式減少請求數：

• 小圖片合並雪碧圖；
• JS、CSS文件選擇性合並；
• 避免重復的資源請求。

減少請求數對於速度優化來說最重要最有效的，特別是網絡差的用戶。一個完整的請求需要經過域名解析以及DNS尋址、與服務器建立連接、發送數據、等待服務器響應、接收數據的過程；每個請求都需要攜帶數據，因此每個請求都需要占用帶寬；瀏覽器進行並發請求的請求數是有上限的。請求多了的情況，明顯增加了網頁的響應時間。一個頁面由多個模塊拼接而成，幾個模塊中請求了同樣的資源時，就會導致資源的重復請求。

2.2.2 減少文件大小（減少請求帶寬）

• 壓縮CSS、JS、圖片；
• 盡可能控制DOM節點數；
• 精簡css、 JavaScript，移除註釋、空格、重復css和腳本。
• 開啟Gzip，Gzip的思想就是把文件先在服務器端進行壓縮，且壓縮率達到85%，然後再傳輸，傳輸完畢後瀏覽器會 重新對壓縮過的內容進行解壓縮，並執行。。好處在於Gzip的支持已經很好，且爬蟲可識別，壓縮率達到66%-85%顯著減少了文件傳輸的大小。另外，gzip對pdf文件的壓縮效果不大，而且會浪費CPU。

2.2.3 合理使用靜態資源域名

域名的要求是短小且獨立。
短小可以減少頭部開銷，因為域名越短請求頭起始行的 URI 就越短。之所以要求獨立，因為獨立域名不會共享主域的 Cookie，可以有效減小請求頭大小，這個策略一般稱之為 Cookie-Free Domain；另外一個原因是瀏覽器對相同域名的並發連接數限制，一般允許同域名並發 6~8 個連接，域名不是越多越好，每個域名的第一個連接都要經歷 DNS 查詢（DNS Lookup），導致會耗費一定的時間，控制域名使用在2-4個之間。另外註意：同一靜態資源在不同頁面被散列到不同子域下，會導致無法利用 HTTP 緩存。

2.2.4 使用HTTP 2

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

• 多路復用：多路復用很好地解決如何讓重要資源盡快加載這個問題。同域名下或者不同域但是同時滿足同一個 IP以及使用同一個證書的這兩個條件中的所有通信都在單個連接上完成，此連接上同時打開任意數量的雙向數據流（ HTTP 1.1 有連接數限制）。使用多域名加上相同的 IP 和證書部署 Web 服務有特殊的意義：讓支持 HTTP/2 的終端只建立一個連接，用上 HTTP/2 協議帶來的各種好處；而只支持 HTTP/1.1 的終端則會建立多個連接，達到同時更多並發請求的目的。
• HEAD 壓縮：HTTP/2 將請求和響應數據分割為更小的幀，並對它們采用二進制編碼（ Binary Framing ）。在 HTTP/1 中，HTTP 請求和響應都是由「狀態行、請求 / 響應頭部、消息主體」三部分組成，狀態行和頭部卻沒有經過任何壓縮，直接以純文本傳輸。如下圖的比較：
  
  在 HTTP/2 中，每個數據流都以消息的形式發送，而消息又由一個或多個幀組成。多個幀之間可以亂序發送，因為根據幀首部的流標識可以重新組裝。
• 請求優先級：服務器可以根據流的優先級，控制資源分配(CPU、內存、帶寬)，而在響應數據準備好之後，優先將最高優先級的幀發送給客戶端。
• 服務器推送：啟動Server Push，意味著服務端可以在發送頁面HTML時主動推送其它資源，有自己獨立的URL，可以被瀏覽器緩存；如果服務端推送的資源已經被瀏覽器緩存過，瀏覽器可以通過發送 RST_STREAM 幀來拒收。

2.2 學會持家，讓家變得簡潔漂亮-客戶端

• 使用外鏈CSS和JS，CSS放頭，JS放尾，防止阻塞以減少對並發下載的影響，盡早刷新文檔的輸出。
• html的代碼優化，如：
  • 避免空的圖片src；
  • 協議自適應，減少html文件大小，將https://和http://都替換成//。
• css的代碼優化，如：
  • 建議使用類選擇器，訪問比較快；
  • 不建議使用很長的base64；
  • 避免CSS表達式；
  • 避免使用Filters。
• js的代碼優化，如：
  • 避免使用eval和width；
  • 減少作用域鏈查找；
  • 減少DOM訪問，盡量緩存DOM；
  • 充分利用事件委托；
  • 減少Repaint（重繪）和Reflow（重排）最好通過批量更新元素減少重排次數，如設置類class統一更新樣式，在添加多個li
  • 元素將會觸發多次頁面重排的情況下使用 DOM fargment 在內存中創建完整的 DOM 節點，然後再一次性添加到 DOM 中。
• 圖片格式的選擇：
  • 顏色較為豐富的圖片而且文件比較大的（40KB - 200KB）或者有內容的圖片優先考慮 jpg；圖標等顏色比較簡單、文件體積不大、起修飾作用的圖片，優先考慮使用 PNG8 格式；圖像顏色豐富而且圖片文件不太大的（40KB 以下）或有半透明效果的優先考慮 PNG24 格式。
  • 條件允許的，使用新格式WEBP和BPG。
  • 用SVG和ICONFONT代替簡單的圖標。
  • 用字蛛來代替藝術字體切圖，它可剔除沒有使用的字符，從而解決中文字體過大的問題，並編碼成跨平臺兼容的格式。
• 合理分配資源加載時間，按需加載，包括CSS、JS文件以及圖片、業務模塊等。
  根據我們網頁最初加載需要的最小內容集推斷其他內容延遲加載；無條件提前加載公共內容或根據用戶行為推斷提前加載某些內容，如根據搜索框輸入的文字來判斷加載的內容。加載機制如下：
  • 預加載
  • Dom Ready後加載
  • onLoad後加載
  • 滾動加載
• 減少DNS 查詢：DNS 查詢一般需要幾毫秒到幾百毫秒，移動環境下會更慢。我們可以預先讀取DNS，減少用戶等待時間。
  

3 穩定性

穩定性的第一要求是可用。最起碼的要求是頁面得出來，要不然沒法用了。
其次講究的是頁面的可維護性，假如頁面掛了，多久可以恢復過來，另外考慮頁面掛的期間是否可以采取靜態頁面處理等方式。
頁面的穩定性其實和前端安全掛鉤，即使頁面可以出來了，但是不能保證不會被黑掉，下文從前端安全的方面講解。

3.1 常見攻擊：

• XSS (Cross Site Script) ，跨站腳本攻擊，往Web頁面裏插入惡意html代碼。特點是攻擊者的代碼必須能獲取用戶瀏覽器端的執行權限，要杜絕此類攻擊出現可以在入口和出口進行嚴格的過濾。
  三種類型：
  （1） 反射型XSS：一次性；將包含註入腳本的惡意鏈接發送給受害者。
  （2） 持久型XSS：用戶輸入的數據“存儲”在服務器端，比如一條包含XSS代碼的留言。
  （3） DOM XSS：使用一些eval等有輸出的語句意味著多了一份被XSS的風險。

  應對策略：

  • 當惡意代碼值被作為某一標簽的內容顯示：在不需要html輸入的地方對html 標簽及一些特殊字符( ” < > & 等等 )做過濾，將其轉化為不被瀏覽器解釋執行的字符。
  • 當惡意代碼被作為某一標簽的屬性顯示，通過用 “將屬性截斷來開辟新的屬性或惡意方法：屬性本身存在的 單引號和雙引號都需要進行轉碼；對用戶輸入的html 標簽及標簽屬性做白名單過濾，也可以對一些存在漏洞的標簽和屬性進行專門過濾。

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

• cookie劫持，通過獲取頁面的權限，在頁面中寫一個簡單的到惡意站點的請求，並獲取用戶的cookie登錄某些站點。

對於crsf 和cookie 劫持的策略：

• 通過 referer、token 或者 驗證碼 來檢測用戶提交。
• 盡量不要在頁面的鏈接中暴露用戶隱私信息。
• 對於用戶修改刪除等操作最好都使用post 操作 。
• 避免全站通用的cookie，嚴格設置cookie的域。

3.2 數據通道安全

國內的眾多網站都沒有實現全站HTTPS。這是目前為止最重要的一步，所有的數據在發送之前就會被加密，攻擊者無法查看或篡改數據包的內容。HTTPS可以理解為HTTP+SSL/TLS，通過數據加密、校驗數據完整性和身份認證三種機制來保障安全。HTTPS的缺點是網站在加上TLS證書時，可能導致RTT往返時延增加，並且 HTTPS通信過程的非對稱和對稱加解密計算會產生更多的服務器性能和時間上的消耗，但是這是可以優化的，這裏就不細說了。

3.3瀏覽器安全

3.3.1 同源策略

首先了解一下同源策略：

• 源指的是有相同的HOST、相同的協議、相同的端口。
• 同源策略以源為單位，把資源天然分隔，保護了用戶的信息安全。
• 繞過同源策略讓javascript訪問其他源的資源的方法，如：JSONP、CORS、flash等。
• 同源策略不是絕對安全的，面對很多攻擊是無能為力的，比如XSS，因為此時攻擊者就在同源之內。

不建議使用JSONP，因為JSONP通常在腳本中寫一個回調函數，然後把回調函數的名字寫在請求的URL中，因此如果請求數據的服務器被黑了，那麽黑客就能在返回的數據中植入惡意代碼，從而竊取用戶的隱私信息。

跨域資源共享CORS允許資源提供方在響應頭中加入一個特殊的標記，使你能通過XHR來獲取、解析並驗證數據。這樣就能避免惡意代碼在你的應用中執行。在響應頭中加入的標記如下：

如果對Access–Control-Allow-Origin設置為*其實是比較危險的，如果沒有攜帶會話認證意味著信息被公開在全網，建議設置具體的域名，而且跨域的時候記得帶上session id；嚴格審查請求信息，比如請求參數，還有http頭信息，因為 http頭可以偽造。

3.3.2 CSP(Content Security Policy)

CSP指定網站上所有腳本和圖片等資源的源站點，也能阻止所有內聯（inline）的腳本和樣式。即使有人在頁面評論或者留言中嵌入了腳本標簽，這些腳本代碼也不會被執行。可通過兩種方式設置，如果 HTTP 頭與 Meta 定義同時存在，則優先采用 HTTP 頭中的定義：

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

• 通過HTML的Meta標簽，比如只允許腳本從本源加載：

  1	<meta http-equiv="Content-Security-Policy" content="script-src ‘self‘">

其他策略：

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

缺點：
默認情況下，所有的內聯JavaScript腳本都不會被執行，因為瀏覽器無法區分自己的內聯腳本和黑客註入的腳本。
CSP還會默認阻止所有eval()風格的代碼的執行，包括setInterval/setTimeout中的字符串和類似於new Function(‘return false’)之類的代碼。

3.3.3 iframe 沙箱環境

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

3.3.4 Secure和HttpOnly屬性

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

3.3.5 其他安全相關的HTTP 頭

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

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

• HSTS (HTTP Strict-Transport-Security) 強制使用TSL作為數據通道。

3.4 HTML5 對web安全的影響

html5有很多新的特性能力，然而能力越大，被攻破後的危險就越大。
HTML5 對xss的影響主要體現在:

• 攻擊面更大，html5帶來更多的標簽和更多的屬性如<video>,<audio>,<canvas>等；
• 危害更大，HTML5更多的資源可以被xss利用。黑客可以利用瀏覽器的一切權限，比如本地存儲、GEO、服務器推送機制WebSocket，js多線程執行Webworker等。

比如localstorage只能通過js設置和獲取，導致的結果是不能像cookie一樣設置httponly等屬性，所以localstorage中不能存放敏感信息，最好能夠在服務端進行加密，可以配合CORS來獲取網站的localstorage的信息。

4 響應式

響應式布局簡而言之，就是一個網站能夠兼容多個終端，可以為不同終端的用戶提供更加舒適的界面和更好的用戶體驗。

• 基於柵格布局規劃響應式設計，每個模塊盡可能嚴格遵循柵格布局，符合柵格的小模塊能很靈活的適應多個分辨率的展示。
• 擁抱flexbox。
• 使用動態的字體大小單位+rem單位使用。
• 使用CSS3 mediaQuery 技術響應用戶設備。
• 利用百分比。
• 對低版本瀏覽器使用JS動態響應。
• 一套“自適應”素材兼容各種分辨率，提升頁面性能，比如自適應的圖片/視頻素材。

比如凹凸實驗室博客頁面在PC端、iPad、手機端的排版：
PC端：

iPad：

手機端：

5 兼容性

估計很多人對這句話都有體會：IE虐我千百遍，我待IE如初戀。當然，除了 IE 上有兼容性問題，其他瀏覽器比如 Android 上的低版本瀏覽器也有較多問題。
是否繼續保持對低端瀏覽器的兼容性，我們可以用數據跟產品經理或者老板說話，減少我們的工作量，最好在項目之前就定下來支持最低支持的版本是什麽，然後設計一個對應兼容方案。以下是百度統計的2015年的瀏覽器市場份額數據：

兼容性的原則：漸進增強與平穩退化。就是說，在低級瀏覽器能夠保證其可用性和可訪問性；漸進增強，在保證代碼、頁面在低級瀏覽器中的可用性及可訪問性的基礎上，逐步增加功能及用戶體驗。
如果出現兼容性問題了，怎麽處理：

1. 確認觸發場景，什麽瀏覽器、版本、什麽情況下會出現這個問題，做到穩定復現。
2. 找到問題原因，為什麽會出現這樣的問題（自己琢磨、網上搜、問同事）。
3. 確定解決辦法：參考現成的規範，比如某些屬性不能使用以及一些hack的處理。
4. 積累兼容性處理方法。

淘寶首頁在兼容性上做了一個小創新：Html鉤子
在html上加上操作系統、瀏覽器內核、瀏覽器類型、CSS3動畫支持、IE各版本類，好處在於：

• 漸進增強 可以實現不同瀏覽器下差異化體驗。
• 能快速定位並修復某個瀏覽器下的特定bug。

淘寶首頁html鉤子：

兼容性問題是老生常談的問題了，團隊之間共同努力形成一個bug兼容性積累文檔，是最好不過的了。

6 搜索SEO

6.1 語義化

• 標簽語義化對搜索引擎友好，良好的結構和語義容易被搜索引擎抓取。
• 善用標題h1，h2，h3，h4，h5，h6，特別是h1和h2；H(x)標簽中使用關鍵字，可提升排名。同時設置 rel=“nofollow”避免權重流失。
• 使用 HTML5 中的 Microdata 對 Web 頁面上已經存在的數據提供附加的語義。Microdata 由名字 / 值（name/value）對組成，每一個詞匯表定義一組命名的屬性。對 Microdata 的支持可以影響搜索結果的顯示，使得顯示結果更加豐富，雖然不能影響搜索結果的排名，但是網站的流量可能會有所增加。類似的技術還有資源描述框架RDF、微格式Microformat 。

6.2 衡量站點關鍵詞優化

• 站點內容以及關鍵詞的選擇。
• 描述標簽、關鍵詞標簽、代替屬性。
• 長尾關鍵詞：非目標關鍵詞但也可以帶來搜索流量的關鍵詞；例如，目標關鍵詞是服裝，其長尾關鍵詞可以是男士服裝、冬裝、戶外運動裝等。長尾關鍵詞基本屬性是：可延伸性，針對性強，範圍廣。
• 關鍵詞的分布情況。
• 關鍵詞密度、看重：合理的關鍵字密度可獲得較高的排名位置，密度過大會起到相反的效果。一般說來，在大多數的搜索引擎中，關鍵詞密度在2%~8%是一個較為適當的範圍，有利於網站在搜索引擎中排名。
• 是否存在作弊行為。

6.3 鏈接

• 優化文件目錄結構和URL。URL應該有語義性，簡短易懂。
• 通過推廣暴露自己的鏈接，增加信任度。鏈接分為外向鏈接和內向（反向）鏈接，外向鏈接就是從本站點到其他站點，內向鏈接就是從其他站點到我的站點，可以嘗試使用反向鏈接生成器。或者通過寫軟文、發布分類信息、發布博客文章來推廣自己的網站。
• 錨文本 ：把關鍵詞做一個鏈接，指向別的網頁，這種形式的鏈接就叫作錨文本。搜索引擎可以根據指向某一個網頁的鏈接的錨文本描述來判斷該網頁的內容屬性。

6.4 良好的網站導航和sitemap

網站需要有一個良好的導航，控制根目錄和各子目錄的關鍵，通過sitemap可以幫助網站主了解網站結構，也方便搜索引擎收錄整個站點。

7 其他優化

7.1 信息無障礙

信息無障礙一般可以從以下幾點入手：

• 添加landmark角色，在頁面主要操作區域（搜索框、登錄框、列表內容）添加“role”標簽加以說明。landmark值一般有：banner（banner）、complementary（輔助內容區）、contentinfo（網站信息和版權）、form（表單）、main（主內容區）、navigation（導航區）、search（搜索區），如：
  
• 提供文字替代方案。比如給圖片或其他元素提供適當的alt屬性或者title屬性的值。
• 表單使用label標簽。
• 使用heading做信息架構。讀屏軟件提供了快捷鍵切換heading，相關用戶可通過讀屏軟件了解我們的網站信息架構。
• 給頁面裏重要區塊和功能添加accesskey，可以快速定位。
• 觸發界面轉換需設置焦點。比如，對於浮層需要註意避免“Tab”焦點中斷。
• 考慮到老年眼睛老花，因此需要保證字體夠大，或者網站可縮放。

具體可參考無障礙閱讀

7.2 微動畫

通過前端動畫技術給頁面進行優化，比如：

• 商品圖片hover效果
• 小圖標旋轉效果
• 購物車微動畫
• loading動畫，當加載頁面需要一定時間，特別是移動端，可以通過有趣的loading動畫吸引用戶，這裏有一些有趣的loading動畫

7.3 requireJs

requireJs框架特性：

• 前端設計及開發人員統一代碼規範。
• 按需加載。
• AMD規範：以簡單而優雅的方式統一了JavaScript的模塊定義和加載機制，降低了學習和使用各種框架的門檻，能夠以一種統一的方式去定義和使用模塊，提高開發效率，降低了應用維護成本。
• 與Grunt結合可實現一站式工作流。

7.4 多標簽狀態同步

場景如下：
頁面一：去一個網站買東西，未登錄狀態下，進入首頁；
頁面二：然後新窗口打開任意頁面，登錄並成功返回。
再次訪問頁面一，發現頁面還是未登錄狀態，實際上用戶已經登錄了，這種體驗是很差的。我們是不是有什麽辦法可以實現多標簽狀態同步呢？有的，利用Page Visibility：

• 頁面可見性API就是表示網頁可見還是不可見的。頁面可見性API有兩個屬性，一個事件，如下：
  • document.hidden: Boolean值，表示當前頁面可見還是不可見
  • document.visibilityState: 返回當前頁面的可見狀態，狀態值有hidden、visible、prerender、preview。
  • visibilitychange: 當可見狀態改變時候觸發的事件。
• 瀏覽器支持：IE10+、Chrome、FireFox。
• 多標簽狀態同步demo: 網頁可見性API與登錄同步

7.5 個性化推薦

• HTML5 Geolocation API獲得用戶的地理位置，進行基於地理位置的運營。

8 參考

能提高前端工作效率的那些事
基於Gulp的前端自動化
繁星網的前端性能優化之路
前端性能優化—-yahoo前端性能團隊總結的35條黃金定律
前端性能數據之采集和分析
Web性能API——幫你分析Web前端性能
前端工程師如何系統地整理和累積兼容性相關的知識？
玩轉HTML5移動頁面(優化篇)
HTTP/2 與 WEB 性能優化（一）
HTTP/2 與 WEB 性能優化（二）
HTTP/2 與 WEB 性能優化（三）
HTTP/2 頭部壓縮技術介紹
從零開始學web安全（1）
關於Web安全，99%的網站都忽略了這些
網頁前端常見的攻擊方式和預防攻擊的方法
Web客戶端安全性最佳實踐
HTML5 安全問題解析
10步大幅提升網站可訪問性
Page Visibility(頁面可見性)API介紹、微拓展

y-1.前端優化不完全