整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
參考回答：
https 的 SSL 加密是在傳輸層實現的。
(1)http 和 https 的基本概念
http: 超文本傳輸協議， 是互聯網上應用最為廣泛的一種網絡協議， 是一個客戶端和服 務器端請求和應答的標準 (TCP) ， 用于從 WWW 服務器傳輸超文本到本地瀏覽器的傳 輸協議， 它可以使瀏覽器更加高效， 使網絡傳輸減少。
https: 是以安全為目標的 HTTP 通道， 簡單講是 HTTP 的安全版， 即 HTTP 下加入 SSL 層， HTTPS 的安全基礎是 SSL， 因此加密的詳細內容就需要 SSL。
https 協議的主要作用是：建立一個信息安全通道，來確保數組的傳輸，確保網站的真實 性。
(2)http 和 https 的區別？
http 傳輸的數據都是未加密的，也就是明文的， 網景公司設置了 SSL 協議來對 http 協議 傳輸的數據進行加密處理，簡單來說 https 協議是由 http 和 ssl 協議構建的可進行加密傳 輸和身份認證的網絡協議， 比 http 協議的安全性更高。
主要的區別如下：
Https 協議需要 ca 證書， 費用較高。
http 是超文本傳輸協議， 信息是明文傳輸， https 則是具有安全性的 ssl 加密傳輸協議。 使用不同的鏈接方式， 端口也不同， 一般而言， http 協議的端口為 80， https 的端口為443。
http 的連接很簡單，是無狀態的；HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳 輸 、身份認證的網絡協議， 比 http 協議安全。
(3)https 協議的工作原理
客戶端在使用 HTTPS 方式與 Web 服務器通信時有以下幾個步驟， 如圖所示。 客戶使用 https url 訪問服務器， 則要求web 服務器建立 ssl 鏈接。
web 服務器接收到客戶端的請求之后， 會將網站的證書 (證書中包含了公鑰) ， 返回或 者說傳輸給客戶端。
客戶端和 web 服務器端開始協商 SSL 鏈接的安全等級， 也就是加密等級。
客戶端瀏覽器通過雙方協商一致的安全等級，建立會話密鑰，然后通過網站的公鑰來加 密會話密鑰， 并傳送給網站。
web 服務器通過自己的私鑰解密出會話密鑰。
web 服務器通過會話密鑰加密與客戶端之間的通信。
(4)https 協議的優點
使用HTTPS 協議可認證用戶和服務器， 確保數據發送到正確的客戶機和服務器；
HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸 、身份認證的網絡協議， 要比 http 協議安全， 可防止數據在傳輸過程中不被竊取 、改變， 確保數據的完整性 。 HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻 擊的成本。
谷歌曾在 2014 年 8 月份調整搜索引擎算法， 并稱“比起同等 HTTP 網站， 采用 HTTPS 加密的網站在搜索結果中的排名將會更高”。
(5)https 協議的缺點
https 握手階段比較費時， 會使頁面加載時間延長 50%， 增加 10%~20%的耗電。
https 緩存不如 http 高效， 會增加數據開銷。
SSL 證書也需要錢， 功能越強大的證書費用越高。
SSL 證書需要綁定 IP， 不能再同一個 ip 上綁定多個域名， ipv4 資源支持不了這種消耗。
參考回答：
客戶端和服務端都需要直到各自可收發， 因此需要三次握手。
簡化三次握手：
<img width="487" alt="2018-07-10 3 42 11" src="https://user-images.githubusercontent.com/ 17233651/42496289-1c6d668a-8458-11e8-98b3-65db50f64d48.png">從圖片可以得到三次握手可以簡化為：C 發起請求連接 S 確認，也發起連接 C 確認我們 再看看每次握手的作用： 第一次握手： S 只可以確認 自己可以接受 C 發送的報文段第 二次握手： C 可以確認 S 收到了自己發送的報文段， 并且可以確認 自己可以接受 S 發 送的報文段第三次握手： S 可以確認 C 收到了自己發送的報文段。
參考回答：
( 1) TCP 是面向連接的， udp 是無連接的即發送數據前不需要先建立鏈接。
( 2) TCP 提供可靠的服務 。也就是說， 通過 TCP 連接傳送的數據， 無差錯， 不丟失， 不重復， 且按序到達;UDP 盡最大努力交付， 即不保證可靠交付 。 并且因為 tcp 可靠， 面向連接， 不會丟失數據因此適合大數據量的交換。
( 3) TCP 是面向字節流，UDP 面向報文，并且網絡出現擁塞不會使得發送速率降低 (因 此會出現丟包， 對實時的應用比如 IP 電話和視頻會議等) 。
( 4) TCP 只能是 1 對 1 的， UDP 支持 1 對 1,1 對多。
( 5) TCP 的首部較大為 20 字節， 而 UDP 只有 8 字節。
( 6) TCP 是面向連接的可靠性傳輸， 而 UDP 是不可靠的。
參考回答：
(1)什么是 WebSocket?
WebSocket 是 HTML5 中的協議， 支持持久連續， http 協議不支持持久性連接 。Http1.0 和 HTTP1.1 都不支持持久性的鏈接， HTTP1.1 中的 keep-alive， 將多個 http 請求合并為 1 個
(2)WebSocket 是什么樣的協議， 具體有什么優點？
HTTP 的生命周期通過 Request 來界定， 也就是 Request 一個 Response， 那么在 Http1.0 協議中， 這次 Http 請求就結束了 。在 Http1.1 中進行了改進， 是的有一個 connection： Keep-alive，也就是說，在一個 Http 連接中，可以發送多個 Request，接收多個 Response。 但是必須記住， 在 Http 中一個 Request 只能對應有一個 Response， 而且這個 Response 是被動的， 不能主動發起。
WebSocket 是基于 Http 協議的，或者說借用了 Http 協議來完成一部分握手，在握手階段 與 Http 是相同的。我們來看一個 websocket 握手協議的實現，基本是 2 個屬性，upgrade， connection。
基本請求如下：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
多了下面 2 個屬性：
Upgrade:webSocket
Connection:Upgrade告訴服務器發送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13參考回答：
head： 類似于 get 請求， 只不過返回的響應中沒有具體的內容， 用戶獲取報頭 options： 允許客戶端查看服務器的性能， 比如說服務器支持的請求方式等等。
參考回答：
請求的返回頭里面， 用于瀏覽器解析的重要參數就是 OSS 的 API 文檔里面的返回http 頭， 決定用戶下載行為的參數。
下載的情況下：
x-oss-object-type: Normal
x-oss-request-id: 598D5ED34F29D01FE2925F41
x-oss-storage-class: Standard參考回答：
能夠被殘障人士使用的網站才能稱得上一個易用的 (易訪問的) 網站。 殘障人士指的是那些帶有殘疾或者身體不健康的用戶。
使用 alt 屬性：
<img src="person.jpg" alt="this is a person"/>有時候瀏覽器會無法顯示圖像 。具體的原因有：
用戶關閉了圖像顯示
瀏覽器是不支持圖形顯示的迷你瀏覽器
瀏覽器是語音瀏覽器 (供盲人和弱視人群使用)
如果您使用了alt 屬性， 那么瀏覽器至少可以顯示或讀出有關圖像的描述。
參考回答：
什么是 Bom? Bom 是瀏覽器對象 。有哪些常用的 Bom 屬性呢？
(1)location 對象
location.href-- 返回或設置當前文檔的 URL
location.search -- 返回 URL 中的查詢字符串部分 。 例
如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內 容?id=5&name=dreamdu
location.hash -- 返回 URL#后面的內容， 如果沒有#， 返回空
location.host -- 返回 URL 中的域名部分， 例如 www.dreamdu.com
location.hostname -- 返回 URL 中的主域名部分， 例如 dreamdu.com
location.pathname -- 返回 URL 的域名后的部分 。例如 http://www.dreamdu.com/xhtml/ 返 回/xhtml/
location.port -- 返回 URL 中的端口部分 。 例如 http://www.dreamdu.com:8080/xhtml/ 返回8080
location.protocol -- 返回 URL 中的協議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返 回(//)前面的內容 http:
location.assign -- 設置當前文檔的 URL
location.replace() -- 設置當前文檔的 URL， 并且在 history 對象的地址列表中移除這個 URL location.replace(url);
location.reload() -- 重載當前頁面
(2)history 對象
history.go() -- 前進或后退指定的頁面數 history.go(num);
history.back() -- 后退一頁
history.forward() -- 前進一頁
(3)Navigator 對象
navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字 符串)。
navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie。
參考回答：
dragstart： 事件主體是被拖放元素， 在開始拖放被拖放元素時觸發， 。
darg： 事件主體是被拖放元素， 在正在拖放被拖放元素時觸發。
dragenter： 事件主體是目標元素， 在被拖放元素進入某元素時觸發。
dragover： 事件主體是目標元素， 在被拖放在某元素內移動時觸發。
dragleave： 事件主體是目標元素， 在被拖放元素移出目標元素是觸發。
drop： 事件主體是目標元素， 在目標元素完全接受被拖放元素時觸發。
dragend： 事件主體是被拖放元素， 在整個拖放操作結束時觸發。
參考回答：
首先補充一下， http 和 https 的區別， 相比于 http,https 是基于 ssl 加密的 http 協議
簡要概括： http2.0 是基于 1999 年發布的 http1.0 之后的首次更新。
提升訪問速度 (可以對于， 請求資源所需時間更少， 訪問速度更快， 相比 http1.0)
允許多路復用：多路復用允許同時通過單一的 HTTP/2 連接發送多重請求-響應信息。改 善了： 在 http1.1 中， 瀏覽器客戶端在同一時間， 針對同一域名下的請求有一定數量限 制 (連接數量) ， 超過限制會被阻塞。
二進制分幀：HTTP2.0 會將所有的傳輸信息分割為更小的信息或者幀，并對他們進行二 進制編碼、首部壓縮、服務器端推送。
參考回答：
(1)400 狀態碼： 請求無效
產生原因：
前端提交數據的字段名稱和字段類型與后臺的實體沒有保持一致。
前端提交到后臺的數據應該是 json 字符串類型， 但是前端沒有將對象 JSON.stringify 轉化成字符串。
解決方法：
對照字段的名稱， 保持一致性，將 obj 對象通過 JSON.stringify 實現序列化。
(2)401 狀態碼： 當前請求需要用戶驗證
(3)403 狀態碼： 服務器已經得到請求， 但是拒絕執行
參考回答：
fetch 發送 post 請求的時候， 總是發送 2 次， 第一次狀態碼是 204， 第二次才成功？
原因很簡單， 因為你用 fetch 的 post 請求的時候， 導致 fetch 第一次發送了一個 Options 請求，詢問服務器是否支持修改的請求頭，如果服務器支持，則在第二次中發送真正的 請求。
參考回答：
在 HTML 頁面中，如果在執行腳本時，頁面的狀態是不可相應的，直到腳本執行完成后， 頁面才變成可相應 。web worker 是運行在后臺的 js， 獨立于其他腳本， 不會影響頁面你 的性能 。并且通過 postMessage 將結果回傳到主線程 。這樣在進行復雜操作的時候， 就 不會阻塞主線程了。
如何創建 web worker：
檢測瀏覽器對于 web worker 的支持性
創建 web worker 文件 (js， 回傳函數等)
創建 web worker 對象
參考回答：
HTML5 語義化標簽是指正確的標簽包含了正確的內容，結構良好，便于閱讀， 比如nav 表示導航條， 類似的還有 article 、header 、footer 等等標簽。
參考回答：
定義： iframe 元素會創建包含另一個文檔的內聯框架
提示： 可以將提示文字放在<iframe></iframe>之間， 來提示某些不支持 iframe 的瀏覽器 缺點： 會阻塞主頁面的 onload 事件 搜索引擎無法解讀這種頁面， 不利于 SEO iframe 和主頁面共享連接池， 而瀏覽器對相同區域有限制所以會影響性能。
參考回答：
Doctype 聲明于文檔最前面， 告訴瀏覽器以何種方式來渲染頁面， 這里有兩種模式， 嚴 格模式和混雜模式。
嚴格模式的排版和 JS 運作模式是 以該瀏覽器支持的最高標準運行。
混雜模式， 向后兼容， 模擬老式瀏覽器， 防止瀏覽器無法兼容頁面。
參考回答：
XSS (跨站腳本攻擊) 是指攻擊者在返回的 HTML 中嵌入 javascript 腳本，為了減輕這些 攻擊， 需要在 HTTP 頭部配上， set-cookie：
httponly-這個屬性可以防止 XSS,它會禁止 javascript 腳本來訪問 cookie。
secure - 這個屬性告訴瀏覽器僅在請求為 https 的時候發送 cookie。
結果應該是這樣的： Set-Cookie=<cookie-value>.....
參考回答：
就是用URL 定位資源， 用 HTTP 描述操作。
參考回答：
可以參考這篇文章：
響應式布局的常用解決方案對比(媒體查詢、百分比、rem 和 vw/vh)
參考回答：
(1)粗暴型， 禁用縮放
<meta name="viewport" content="width=device-width, user-scalable=no">(2)利用 FastClick， 其原理是：
檢測到 touchend 事件后， 立刻出發模擬 click 事件， 并且把瀏覽器 300 毫秒之后真正出 發的事件給阻斷掉。
參考回答：
addEventListener(event, function, useCapture)其中， event 指定事件名； function 指定要事件觸發時執行的函數； useCapture 指定事件 是否在捕獲或冒泡階段執行。
參考回答：
100 Continue 繼續 ?？蛻舳藨^續其請求。
101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更 高級的協議， 例如， 切換到HTTP 的新版本協議。
200 OK 請求成功 。一般用于 GET 與 POST 請求。
201 Created 已創建 。成功請求并創建了新的資源。
202 Accepted 已接受 。 已經接受請求， 但未處理完成。
203 Non-Authoritative Information 非授權信息。請求成功。但返回的 meta 信息不在原 始的服務器， 而是一個副本。
204 No Content 無內容 。服務器成功處理， 但未返回內容 。在未更新網頁的情況下， 可確保瀏覽器繼續顯示當前文檔。
205 Reset Content 重置內容。服務器處理成功， 用戶終端 (例如： 瀏覽器) 應重置文 檔視圖 ?？赏ㄟ^此返回碼清除瀏覽器的表單域。
206 Partial Content 部分內容 。服務器成功處理了部分 GET 請求。
300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特 征與地址的列表用于用戶終端 (例如： 瀏覽器) 選擇。
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新 URI，返回信息會 包括新的 URI，瀏覽器會自動定向到新 URI。今后任何新的請求都應使用新的 URI 代替。
302 Found 臨時移動。與 301 類似。但資源只是臨時被移動?？蛻舳藨^續使用原有 URI。
303 See Other 查看其它地址 。與 301 類似 。使用 GET 和 POST 請求查看。
304 Not Modified 未修改 。所請求的資源未修改， 服務器返回此狀態碼時， 不會返回 任何資源?？蛻舳送ǔ彺嬖L問過的資源，通過提供一個頭信息指出客戶端希望只返 回在指定日期之后修改的資源。
305 Use Proxy 使用代理 。所請求的資源必須通過代理訪問。
306 Unused 已經被廢棄的 HTTP 狀態碼。
307 Temporary Redirect 臨時重定向 。與 302 類似 。使用 GET 請求重定向。
400 Bad Request 客戶端請求的語法錯誤， 服務器無法理解。
401 Unauthorized 請求要求用戶的身份認證。
402 Payment Required 保留， 將來使用。
403 Forbidden 服務器理解請求客戶端的請求， 但是拒絕執行此請求。
404 Not Found 服務器無法根據客戶端的請求找到資源 (網頁) 。通過此代碼， 網站 設計人員可設置"您所請求的資源無法找到"的個性頁面。
405 Method Not Allowed 客戶端請求中的方法被禁止。
406 Not Acceptable 服務器無法根據客戶端請求的內容特性完成請求。
407 Proxy Authentication Required 請求要求代理的身份認證， 與 401 類似， 但請求者 應當使用代理進行授權。
408 Request Time-out 服務器等待客戶端發送的請求時間過長， 超時。
409 Conflict 服務器完成客戶端的 PUT 請求是可能返回此代碼，服務器處理請求時發 生了沖突。
410 Gone 客戶端請求的資源已經不存在。410 不同于 404，如果資源以前有現在被永 久刪除了可使用410 代碼， 網站設計人員可通過 301 代碼指定資源的新位置。
411 Length Required 服務器無法處理客戶端發送的不帶 Content-Length 的請求信息。
412 Precondition Failed 客戶端請求信息的先決條件錯誤。
413 Request Entity Too Large 由于請求的實體過大，服務器無法處理， 因此拒絕請求。 為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則 會包含一個 Retry-After 的響應信息。
414 Request-URI Too Large 請求的 URI 過長 ( URI 通常為網址) ， 服務器無法處理。
415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式。
416 Requested range not satisfiable 客戶端請求的范圍無效。
417 Expectation Failed 服務器無法滿足 Expect 的請求頭信息。
500 Internal Server Error 服務器內部錯誤， 無法完成請求。
501 Not Implemented 服務器不支持請求的功能， 無法完成請求。
502 Bad Gateway 作為網關或者代理工作的服務器嘗試執行請求時， 從遠程服務器接 收到了一個無效的響應。
503 Service Unavailable 由于超載或系統維護，服務器暫時的無法處理客戶端的請求。 延時的長度可包含在服務器的 Retry-After 頭信息中。
504 Gateway Time-out 充當網關或代理的服務器， 未及時從遠端服務器獲取請求。
505 HTTP Version not supported 服務器不支持請求的 HTTP 協議的版本， 無法完成處 理。
參考回答：
協議頭 | 說明 |
Accept | 可接受的響應內容類型 (Content-Types) 。 |
Accept-Charset | 可接受的字符集。 |
Accept-Encoding | 可接受的響應內容的編碼方式。 |
Accept-Language | 可接受的響應內容語言列表。 |
Accept-Datetime | 可接受的按照時間來表示的響應內容版本。 |
Authorization | 用于表示 HTTP 協議中需要認證資源的認證信息。 |
Cache-Control | 用來指定當前的請求/回復中的， 是否使用緩存機制。 |
Connection | 客戶端 (瀏覽器) 想要優先使用的連接類型。 |
Cookie | 由之前服務器通過 Set-Cookie(見下文)設置的一個 HTTP 協議 Cookie。 |
Content-Length | 以 8 進制表示的請求體的長度。 |
Content-MD5 | 請求體的內容的二進制 MD5 散列值 (數字簽名) ， 以 Base64 編碼的結果。 |
Content-Type | 請求體的 MIME 類型 (用于 POST 和 PUT 請求中)。 |
Date | 發送該消息的日期和時間 (以RFC 7231中定義的"HTTP 日期"格式 來發送)。 |
Expect | 表示客戶端要求服務器做出特定的行為。 |
From | 發起此請求的用戶的郵件地址。 |
Host | 表示服務器的域名以及服務器所監聽的端口號 。如果所請求的端口 是對應的服務的標準端口 ( 80) ， 則端口號可以省略。 |
If-Match | 僅當客戶端提供的實體與服務器上對應的實體相匹配時， 才進行對應的操作 。主要用于像 PUT 這樣的方法中， 僅當從用戶上次更新 某個資源后， 該資源未被修改的情況下， 才更新該資源。 |
If-Modified-Since | 允許在對應的資源未被修改的情況下返回304 未修改 |
If-None-Match | 允許在對應的內容未被修改的情況下返回304 未修改 ( 304 Not Modified ) ， 參考 超文本傳輸協議 的實體標記 |
If-Range | 如果該實體未被修改過， 則向返回所缺少的那一個或多個部分 。否 則， 返回整個新的實體。 |
If-Unmodified-Since | 僅當該實體自某個特定時間以來未被修改的情況下， 才發送回應。 |
Max-Forwards | 限制該消息可被代理及網關轉發的次數。 |
Origin | 發起一個針對跨域資源共享的請求 (該請求要求服務器在響應中加入一個 Access-Control-Allow-Origin 的消息頭，表示訪問控制所允許 的來源) 。 |
Pragma | 與具體的實現相關， 這些字段可能在請求/回應鏈中的任何時候產 生。 |
Proxy-Authorization | 用于向代理進行認證的認證信息。 |
Range | 表示請求某個實體的一部分， 字節偏移以 0 開始。 |
Referer | 表示瀏覽器所訪問的前一個頁面， 可以認為是之前訪問頁面的鏈接將瀏覽器帶到了當前頁面。Referer 其實是 Referrer 這個單詞，但 RFC 制作標準時給拼錯了， 后來也就將錯就錯使用 Referer 了。 |
TE | 瀏覽器預期接受的傳輸時的編碼方式： 可使用回應協議頭 Transfer-Encoding 中的值 (還可以使用"trailers"表示數據傳輸時的分 塊方式) 用來表示瀏覽器希望在最后一個大小為 0 的塊之后還接收到一些額外的字段。 |
User-Agent | 瀏覽器的身份標識字符串。 |
Upgrade | 要求服務器升級到一個高版本協議。 |
Via | 告訴服務器， 這個請求是由哪些代理發出的。 |
Warning | 一個一般性的警告， 表示在實體內容體中可能存在錯誤。 |
參考回答：
緩存分為兩種： 強緩存和協商緩存， 根據響應的header 內容來決定。
獲取資源形式 | 狀態碼 | 發送請求到服務器 | |
強緩存 | 從緩存取 | 200 (from cache) | 否， 直接從緩存取 |
協商緩存 | 從緩存取 | 304 (not modified) | 是，通過服務器來告知緩存是否可 用 |
強緩存相關字段有 expires， cache-control 。如果 cache-control 與 expires 同時存在的話， cache-control 的優先級高于 expires。
協商緩存相關字段有 Last-Modified/If-Modified-Since， Etag/If-None-Match。
參考回答：
304：如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容 (自 上次訪問以來或者根據請求的條件) 并沒有改變， 則服務器應當返回這個 304 狀態碼。
參考回答：
因為服務器上的資源不是一直固定不變的，大多數情況下它會更新，這個時候如果我們 還訪問本地緩存，那么對用戶來說，那就相當于資源沒有更新，用戶看到的還是舊的資 源；所以我們希望服務器上的資源更新了瀏覽器就請求新的資源，沒有更新就使用本地 的緩存， 以最大程度的減少因網絡請求而產生的資源浪費。
參考 https://segmentfault.com/a/1190000008956069
參考回答：
降低請求量： 合并資源， 減少 HTTP 請求數， minify / gzip 壓縮， webP， lazyLoad。
加快請求速度： 預解析 DNS， 減少域名數， 并行加載， CDN 分發。
緩存： HTTP 協議緩存請求， 離線緩存 manifest， 離線數據緩存 localStorage。
渲染： JS/CSS 優化， 加載順序， 服務端渲染， pipeline。
WebP 是一種同時提供了有損壓縮與無損壓縮的圖片文件格式?？梢源蟠髩嚎s圖片的大小，并且圖片的質量和 png、jpeg 等相同。WebP 的無損壓縮比 png 格式的文件平均少了 45％ 的大小。
這里是使用了同一張圖片轉換為不同格式的圖片后，對圖片的大小進行對比的測試結果：
格式 | webp | jpeg | png | gif |
大小 | 1.65MB | 2.24MB | 7.51MB | 4.64MB |
使用 webp 壓縮后圖片大小減少百分比 | ↓ 26% | ↓ 78% | ↓ 64% |
目前大約 95.77% 的瀏覽器都支持 WebP 格式的圖片，其中 Safari 瀏覽器僅在 Big Sur 及以上的macOS 系統才支持 WebP；針對不兼容的情況下，我們需要進行相應的降級措施。
降級處理原則
降級處理方式
降級處理示例
拿淘寶首頁舉個例子
圖片 URL：img.alicdn.com/imgextra/i2…
在 chrome 中加載的是 webp 格式的圖片：
在 IE 中加載的則是 jpg 格式的圖片：
可以看出淘寶是對圖片的 URL 進行了特殊處理，通過在原始圖片后加上 _.webp 后綴來做降級處理，如果當前瀏覽器支持 webp 格式的圖片，則加載 webp 格式的圖片，若不支持則去掉 _.webp 的后綴加載 jpg 格式的圖片。
如果你覺得此文對你有一丁點幫助，點個贊?；蛘呖梢约尤胛业拈_發交流群：1025263163相互學習，我們會有專業的技術答疑解惑
如果你覺得這篇文章對你有點用的話，麻煩請給我們的開源項目點點star: https://gitee.com/ZhongBangKeJi/CRMEB不勝感激 ！
像是web上提供的最基本的內容類型之一。他們說一張圖片勝過千言萬語。但是如果你不小心的話，圖片大小有時高達幾十兆。
因此，雖然網絡圖像需要清晰明快，但它們尺寸可以縮小壓縮的，使用加載時間保持在可接受的水平。
在我的網站上，我注意到我的主頁的頁面大小 超過了 1.1MB，圖片占了約88%，我還注意到我提供的圖像比它們需要的大(在分辨率方面)，顯然，還有很多改進的空間。
我開始閱讀 Addy Osmani 的優秀 Essential Image Optimization電子書，并開始在我的網站上按照他們的建議做了一些圖片的優化。，然后再對響應式圖像進行了一些研究并應用了它。
這使得頁面大小減少到 445kb，約 62% !
什么是圖像壓縮?
壓縮圖像就是在圖片保持在可接受的清晰度范圍內同時減少文件大小，我使用 imagemin 來壓縮站點上的圖像。
要使用 imagemin，確保你已經安裝了 Node.js，然后打開一個終端窗口，cd 進入項目，并運行以下命令:
npm install imagemin
然后創建一個名為 imagemin.js 的新文件，寫入下面的內容：
constimagemin =require('imagemin');constPNGImages ='assets/images/*.png';constJPEGImages ='assets/images/*.jpg';constoutput ='build/images';
你可以根據自己的需要更改 PNGImages、JPEGImages 和 output 的值，以符合你的項目結構。
此外要執行圖片壓縮，還需要根據要壓縮的圖像類型安裝對應的插件。
JPEG/JPG
JPG 的優點
JPG 最大的特點是 有損壓縮。這種高效的壓縮算法使它成為了一種非常輕巧的圖片格式。另一方面，即使被稱為“有損”壓縮，JPG的壓縮方式仍然是一種高質量的壓縮方式：當我們把圖片體積壓縮至原有體積的 50% 以下時，JPG 仍然可以保持住 60% 的品質。此外，JPG 格式以 24 位存儲單個圖，可以呈現多達 1600 萬種顏色，足以應對大多數場景下對色彩的要求，這一點決定了它壓縮前后的質量損耗并不容易被我們人類的肉眼所察覺——前提是你用對了業務場景。
JPG 使用場景
JPG 適用于呈現色彩豐富的圖片，在我們日常開發中，JPG 圖片經常作為大的背景圖、輪播圖或 Banner 圖出現。
JPG 的缺陷
有損壓縮在上文所展示的輪播圖上確實很難露出馬腳，但當它處理矢量圖形和 Logo 等線條感較強、顏色對比強烈的圖像時，人為壓縮導致的圖片模糊會相當明顯。
此外，JPEG 圖像不支持透明度處理，透明圖片需要召喚 PNG 來呈現。
使用 MozJPEG 壓縮 jpeg
這里使用 Mozilla 的 MozJPEG 工具，該工具可以通過 imagemin-mozjpeg 作為 Imagemin 插件使用。你可以通過運行以下命令來安裝它:
npm install imagemin-mozjpeg
然后將以下內容添加到的 imagemin.js 中:
constimageminMozjpeg =require('imagemin-mozjpeg');constoptimiseJPEGImages =()=>imagemin([JPEGImages], output, {plugins: [ imageminMozjpeg({quality:70, }), ] });optimiseJPEGImages() .catch(error=>console.log(error));
可以通過在終端中運行 node imagemin.js 來運行腳本。這將處理所有JPEG圖像，并將優化后的版本放 build/images 文件夾中。
我發現將 quality 設置為 70 在大多數情況下可以產生足夠清晰的圖像，但你的項目需求可能不同，可以自行設置合適的值。
默認情況下，MozJPEG 生成漸進式 jpeg，這會導致圖像從低分辨率逐漸加載到高分辨率，直到圖片完全加載為止。由于它們的編碼方式，它們也比原始的 jpeg 略小。
你可以使用 Sindre Sorhus 提供的這個命令行工具來檢查JPEG圖像是否是漸進式的。
Addy Osmani 已經很好地總結了使用漸進式 jpeg 的優缺點。對我來說，我覺得利大于弊，所以我堅持使用默認設置。
如果你更喜歡使用原始的jpeg，可以在 options 對象中將 progressive 設置為 false。另外，請確保 imagemin-mozjpeg版本的變化，請重新查看對應文檔。
PNG (PNG-8 與 PNG-24)
PNG 的優缺點
PNG（可移植網絡圖形格式）是一種無損壓縮的高保真的圖片格式。8 和 24，這里都是二進制數的位數。按照我們前置知識里提到的對應關系，8 位的 PNG 最多支持 256 種顏色，而 24 位的可以呈現約 1600 萬種顏色。
PNG 圖片具有比 JPG 更強的色彩表現力，對線條的處理更加細膩，對透明度有良好的支持。它彌補了上文我們提到的 JPG 的局限性，唯一的缺點就是體積太大。
PNG 應用場景
前面我們提到，復雜的、色彩層次豐富的圖片，用 PNG 來處理的話，成本會比較高，我們一般會交給 JPG 去存儲。
考慮到 PNG 在處理線條和顏色對比度方面的優勢，我們主要用它來呈現小的 Logo、顏色簡單且對比強烈的圖片或背景等。
使用 pngquant 優化 PNG 圖像
pngquant 是我優化PNG圖像的首選工具，你可以通過 imagemin-pngquant 使用它:
npm install imagemin-pngquant
然后將以下內容添加到 imagemin.js 文件中:
constimageminPngquant =require('imagemin-pngquant');constoptimisePNGImages =()=>imagemin([PNGImages], output, {plugins: [ imageminPngquant({quality:'65-80'}) ], });optimiseJPEGImages() .then(()=>optimisePNGImages()) .catch(error=>console.log(error));
我發現將 quality 設置為 65-80 可以在文件大小和圖像質量之間較好的折衷方案。
有了這些設置，我可以得到一個屏幕截圖，我的網站從 913kb 到 187kb，沒有任何明顯的視覺損失，驚人的79% 的降幅!
這是兩個文件?？匆豢矗约号袛嘁幌?
原圖(913kb)
優化后的圖像(187kb)
代碼部署后可能存在的BUG沒法實時知道，事后為了解決這些BUG，花了大量的時間進行log 調試，這邊順便給大家推薦一個好用的BUG監控工具 Fundebug。
WebP
WebP 的優點
WebP 像 JPEG 一樣對細節豐富的圖片信手拈來，像 PNG 一樣支持透明，像 GIF 一樣可以顯示動態圖片——它集多種圖片文件格式的優點于一身。
WebP 的官方介紹對這一點有著更權威的闡述：
與 PNG 相比，WebP 無損圖像的尺寸縮小了 26％。在等效的 SSIM 質量指數下，WebP 有損圖像比同類 JPEG 圖像小25-34％。 無損 WebP 支持透明度（也稱為 alpha 通道），僅需 22％ 的額外字節。對于有損 RGB 壓縮可接受的情況，有損 WebP 也支持透明度，與 PNG 相比，通常提供 3 倍的文件大小。
將 WebP 圖像提供給支持它們的瀏覽器
WebP 是谷歌引入的一種相對較新的格式，它的目標是通過以無損和有損格式編碼圖像來提供更小的文件大小，使其成為 JPEG 和 PNG 的一個很好的替代方案。
WebP 圖像的清晰度通常可以與 JPEG 和 PNG相提并論，而且文件大小要小得多。例如，當我將屏幕截圖從上面轉換到 WebP 時，我得到了一個 88kb 的文件，其質量與 913kb 的原始圖像相當，減少了90% !
看看這三張圖片，你能說出區別嗎?
原圖PNG (913kb)
優化PNG圖像(187kb)
WebP圖像(88kb，可在Chrome或Opera瀏覽器中瀏覽)
就我個人而言，我認為視覺效果是可以比較的，而且節省下來的大小是不容忽視的。
既然我們已經認識到在可能的情況下使用WebP格式是有價值的，那么很重要的一點是—它不能完全替代 JPEG 和 PNG，因為瀏覽器對 WebP 支持并不普遍。
在撰寫本文時，Firefox、Safari 和 Edge 都是不支持WebP的瀏覽器。
然而，根據 caniuse.com 的數據，全球超過70%的用戶使用支持WebP的瀏覽器。這意味著，通過使用 WebP 圖像，可以為大約 70% 的客戶提供更快的 web 頁面及更好的體驗。
安裝它，運行以下命令：
npm install imagemin-webp
然后將以下內容添加到你的 imagemin.js 文件中:
constimageminWebp =require('imagemin-webp');constconvertPNGToWebp =()=>imagemin([PNGImages], output, {use: [ imageminWebp({quality:85, }), ] });constconvertJPGToWebp =()=>imagemin([JPGImages], output, {use: [ imageminWebp({quality:75, }), ] });optimiseJPEGImages() .then(()=>optimisePNGImages()) .then(()=>convertPNGToWebp()) .then(()=>convertJPGToWebp()) .catch(error=>console.log(error));
我發現，將 quality 設置為 85 會生成質量與 PNG 相當但小得多的 WebP 圖像。對于 jpeg，我發現將 quality 設置為 75 可以在視覺和文件大小之間取得很好的平衡。
提供 HTML格式的WebP圖像
一旦有了 WebP 圖像，可以使用以下標記將它們提供給可以使用它們的瀏覽器，同時向不兼容 WebP 的瀏覽器使用 png 或者 jpeg。
使用此標記，理解 image/webp 媒體類型的瀏覽器將下載 Webp 圖片并顯示它，而其他瀏覽器將下載 JPEG 圖片。
任何不支持 <picture> 的瀏覽器都將跳過所有 source 標簽，并加載底部 img 標簽。因此，我們通過提供對所有瀏覽器類的支持，逐步增強了我們的頁面。
請注意，在所有情況下，img 標記都是實際呈現給頁面的內容，因此它確實是語法的必需部分。 如果省略 img 標記，則不會渲染任何圖像。
標簽和其中定義的所有 source 都在那里，以便瀏覽器可以選擇要使用的圖片的路徑。 選擇源圖像后，其 URL 將傳給 img 標記，這就是顯示的內容。
這意味著你無需設置 <picture> 或 source 標記的樣式，因為瀏覽器不會渲染這些標記。 因此，你可以像以前一樣繼續使用 img 標簽進行樣式設置。
總結
正如你所看到的，優化 web 上使用的圖像的過程并不復雜，通過減少頁面加載時間，可以為客戶帶來更好的用戶體驗，希望本文對你有所幫助，共進步！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
