前端優化不完全指南

篇幅可能有點長，我想先聊一聊閱讀的方式，我希望你閱讀的時候，能夠把我當作你的競爭對手，你的夢想是超越我。你想超越我，就得了解我懂什麼對吧，好，開始閱讀~ ~ 哈哈哈 ~ ~ ~

歷時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標籤，比如只允許指令碼從本源載入：
  
  XHTML

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

  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介紹、微擴充