y-1.前端優化不徹底

時間 2019-11-07

標籤前端優化不徹底简体版

原文原文鏈接

前端優化不徹底指南

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

1 工做效率

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

怎麼提升咱們的工做效率？下面從四個方面講解：html

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

1.1 時間管理

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

周計劃表：
前端

固然計劃不要作得過於瑣碎，且不要佔用本身太多時間。作好計劃之餘，在執行過程當中須要注意幾點：html5

正確的時間點作正確的事，好比早上比較精神，可選擇比較難的項目開展，可容易達到高效率。
專一一件事情，儘可能不要被瑣碎或其餘事情影響，並且不要頻繁地去看計劃表，最好是作完一件再去看，不然容易焦慮致使沒法專心。

1.2 利用工具

第同樣工具，好比程序員杯子：
java

利用工具備什麼好處呢？css3

減小重複性工做。
減小繁瑣工做流程，一鍵式化。

1.2.1 編輯器

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

1.2.2 瀏覽器開發者工具

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

1.2.3 其餘經常使用工具

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

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記錄的關鍵時間點來統計頁面完成所用的時間，部分使用方法：

6

 
     var timing = window.performance.timing 
    
      timing.domLoading 
     //瀏覽器開始解析 HTML 文檔第一批收到的字節 
    
      timing.domInteractive 
     // 瀏覽器完成解析而且全部 HTML 和 DOM 構建完畢 
    
      timing.domContentLoadedEventStart 
     //DOM 解析完成後，網頁內資源加載開始的時間 
    
      timing.domContentLoadedEventEnd 
     // DOM 解析完成後，網頁內資源加載完成的時間（如 JS 腳本加載執行完畢） 
    
      timing.domComplete 
     //網頁上全部資源（圖片等）下載完成,且準備就緒的時間

持續追蹤性能數據，要選擇合適的頁面性能測量工具或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 的內容。瀏覽器會發出請求詢問服務端，資源是否過時；服務端發現,沒有過時，直接返回一個狀態碼爲 30四、正文爲空的響應，告知瀏覽器使用本地緩存；若是資源有更新，服務端返回狀態碼 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來獲取、解析並驗證數據。這樣就能避免惡意代碼在你的應用中執行。在響應頭中加入的標記以下：

1	Access-Control-Allow-Origin: allowed origins

若是對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中不可見了。若是單獨使用的話，沒法全面抵禦跨站點腳本攻擊，一般和其餘技術組合使用。使用方法以下：

1	Set-Cookie: <name>=<value>[; <name>=<value>] [; expires=<date>][; domain=<domain_name>][; path=<some_path>][; secure][; HttpOnly]

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年的瀏覽器市場份額數據：

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

確認觸發場景，什麼瀏覽器、版本、什麼狀況下會出現這個問題，作到穩定復現。
找到問題緣由，爲何會出現這樣的問題（本身琢磨、網上搜、問同事）。
肯定解決辦法：參考現成的規範，好比某些屬性不能使用以及一些hack的處理。
積累兼容性處理方法。

淘寶首頁在兼容性上作了一個小創新：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與登陸同步