日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 生活百科 > >

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

微軟OneDrive

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片

Web 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載

文章圖片


阿里妹導(dǎo)讀


本文旨在探討和分享多種預(yù)加載技術(shù)及其在提升網(wǎng)站性能、優(yōu)化用戶體驗方面的應(yīng)用 。
在性能優(yōu)化過程中 ， 開發(fā)者通常會集中精力在以下幾個方面：服務(wù)器響應(yīng)時間（RT）優(yōu)化、服務(wù)端渲染（SSR）與客戶端渲染優(yōu)化、以及靜態(tài)資源體積的減少 。 然而 ， 對于許多用戶進(jìn)入網(wǎng)站的第一個頁面（如首頁） ， 網(wǎng)絡(luò)開銷也是一個不容忽視的問題 。





由于新用戶可能從未與網(wǎng)站建立連接 ， 從DNS查詢到TCP連接 ， 再到下載服務(wù)器返回的內(nèi)容 ， 這些步驟的耗時通常遠(yuǎn)遠(yuǎn)超過服務(wù)器的響應(yīng)時間 。 而多數(shù)情況下開發(fā)者無法通過代碼優(yōu)化來減少這部分時間消耗 。
為了解決新用戶訪問網(wǎng)站時可能遇到的網(wǎng)絡(luò)開銷問題 ， 我們可以借助多種預(yù)加載技術(shù)在用戶實際需要之前提前加載資源 ， 從而減少等待時間 ， 實現(xiàn)更流暢的用戶體驗 。 接下來本文將詳細(xì)探討幾種常見的預(yù)加載方法 ， 并在 prefetch、preload等基礎(chǔ)上 ， 結(jié)合流式渲染、HTTP Early Hints、HTTP/2 push 等技術(shù) ， 對預(yù)加載技術(shù)靈活運(yùn)用 ， 從而在用戶到達(dá)網(wǎng)站的瞬間就提供無縫、快速的訪問體驗 。
CDN 動態(tài)加速


在開始介紹預(yù)加載之前 ， 其實開發(fā)者可以通過 CDN 動態(tài)加速優(yōu)化用戶與服務(wù)器的建連、內(nèi)容傳輸時間 。 CDN 通常被用來加速靜態(tài)資源的傳輸 ， 比如圖像、JavaScript 和 CSS ， 這個大部分開發(fā)者非常熟悉 ， 但現(xiàn)代的 CDN 技術(shù)已經(jīng)不僅僅局限于靜態(tài)內(nèi)容的優(yōu)化 ， 大部分 CDN 廠商可以利用其全球廣泛分布的邊緣節(jié)點(diǎn)服務(wù)器為網(wǎng)站提供動態(tài)內(nèi)容的訪問加速 。
用戶訪問網(wǎng)站動態(tài)內(nèi)容需要通過互聯(lián)網(wǎng)連接到源站服務(wù)器 ， 這個過程中數(shù)據(jù)需要經(jīng)過多個網(wǎng)絡(luò)節(jié)點(diǎn)和長距離傳輸 ， 容易受到各種網(wǎng)絡(luò)擁塞和延遲的影響 。







使用 CDN 動態(tài)加速時 ， CDN 通過在全球分布的邊緣節(jié)點(diǎn)緩存和處理用戶請求 ， 顯著縮短了從用戶到服務(wù)器的物理距離 ， 減少了傳輸延遲 。 同時 CDN 服務(wù)商會實時監(jiān)控全球的網(wǎng)絡(luò)狀態(tài) ， 通過智能路由技術(shù)選擇當(dāng)前最優(yōu)的路徑傳輸數(shù)據(jù) ， 這避免了網(wǎng)絡(luò)中的擁塞和瓶頸 ， 確保數(shù)據(jù)以最快的速度傳輸?shù)接脩舳?。





當(dāng)然如果使用了 CDN 提供的邊緣計算能力 ， 可以讓用戶直接從 CDN 邊緣節(jié)點(diǎn)獲取動態(tài)內(nèi)容 ， 進(jìn)一步加速動態(tài)內(nèi)容的訪問 。





dns-prefetch DNS 預(yù)解析


當(dāng)瀏覽器需要訪問特定域名時 ， 必須先將先將域名解析為 IP 地址 ， 這一步驟就是 DNS 解析 。 dns -prefetch 可以讓瀏覽器提前在后臺完成這一解析工作 ， 避免用戶在實際請求資源時等待 DNS 解析的時間 。
在 HTML 頂部通過<link>標(biāo)簽來指示瀏覽器對接下來要是用的靜態(tài)資源、動態(tài)接口等域名提前進(jìn)行 DNS 解析 。
<link rel=\"dns-prefetch\" href=https://mparticle.uc.cn/"http://example.com\">

preconenct 域名預(yù)建連


當(dāng)瀏覽器解析了域名后 ， 接下來需要通過TCP協(xié)議和服務(wù)器建立連接 ， 并在使用 HTTPS 的情況下進(jìn)行 TLS 握手 ， 這些步驟通常需要較多往返時間（RTT） 。 preconnect 通過提前完成這些連接步驟 ， 可以減少用戶真正需要請求資源時的等待時間 。
可以在HTML中通過<link>標(biāo)簽來指示瀏覽器進(jìn)行預(yù)連接 ， 使用 preconnect 之后瀏覽器不僅會解析域名的 DNS ， 還會提前與服務(wù)器建立 TCP 連接 ， 并完成 TLS 握手 。
<link rel=\"preconnect\" href=https://mparticle.uc.cn/"http://example.com\">

preload 與 prefetch 預(yù)加載


除了對域名進(jìn)行解析、建連 ， 還可以通過 preload 和 prefetch 對頁面將要使用的資源提前下載 。
preload 是一種聲明式資源引入方式 ， 用來強(qiáng)制瀏覽器在合適的時機(jī)加載指定資源 ， 通常用于關(guān)鍵資源（如字體、腳本、樣式表等）的預(yù)加載 ， 以確保這些資源能夠盡快被使用 。
<link rel=\"preload\" href=https://mparticle.uc.cn/"styles.css\" as=\"style\"><link rel=\"preload\" href=https://mparticle.uc.cn/"main.js\" as=\"script\"><link rel=\"preload\" href=https://mparticle.uc.cn/"image.jpg\" as=\"image\">prefetch 同樣是一種聲明式資源請求方式 ， 用于提示瀏覽器在空閑時下載未來可能用到的資源 ， 適合作為頁面未來使用的資源或者當(dāng)前頁面下一跳頁面要使用的資源預(yù)加載 。
<link rel=\"prefetch\" href=https://mparticle.uc.cn/"next-page-image.jpg\"><link rel=\"prefetch\" href=https://mparticle.uc.cn/"next-page-script.js\">兩個標(biāo)簽在優(yōu)先級上有一定的區(qū)別：

  • preload：具有高優(yōu)先級 ， 瀏覽器會立即加載這些資源；
  • prefetch：具有較低優(yōu)先級 ， 只有在瀏覽器空閑時才會加載這些資源 ， 確保不妨礙當(dāng)前頁面的正常加載；
兩者在瀏覽器支持上各有千秋：
preload
prefetch












prerender 預(yù)渲染


使用prerender 可以將目標(biāo)頁面上近乎所有資源（HTML、CSS、JavaScript、圖像等）和內(nèi)容在后臺提前下載并渲染 ， 瀏覽器在用戶首次訪問該頁面之前已經(jīng)完全準(zhǔn)備好了該頁面的視圖 。 這樣當(dāng)用戶跳轉(zhuǎn)到該頁面時 ， 使用戶在實際跳轉(zhuǎn)到這個頁面時能夠立即呈現(xiàn) ， 不需要再等待加載和渲染的時間 。
<link rel=\"prerender\" href=https://mparticle.uc.cn/"https://example.com/next-page\">聽起來 prerender 是預(yù)加載的終極方案了 ， 但在實際性能優(yōu)化方案中卻很少被使用 ， 使用 preload 有幾個弊端：
  • 不能命中時候資源開銷過大：因為 prerender 會對頁面進(jìn)行資源下載和渲染 ， 當(dāng)頁面沒有被用戶訪問時候造成的資源浪費(fèi)過大；
  • 影響頁面數(shù)據(jù)統(tǒng)計：大部分頁面在執(zhí)行時候會對頁面進(jìn)行數(shù)據(jù)上報用作后續(xù)的頁面效果分析 ， 部分頁面會有展示廣告等行為 ， 如果 prerender 后用戶沒有訪問頁面 ， 會造成數(shù)據(jù)統(tǒng)計上的混亂；
  • 瀏覽器兼容性問題：不同的瀏覽器對于 prerender 的實現(xiàn)細(xì)節(jié)可能有所不同 。 例如 ， 一些瀏覽器可能出于性能或安全考慮 ， 會對預(yù)渲染的資源類型進(jìn)行某些限制；





根據(jù)用戶行為 prefetch 下一跳頁面


無腦對頁面進(jìn)行 prefetch 會造成巨大的資源浪費(fèi) ， 但很多時候我們可以根據(jù)用戶行為更精準(zhǔn)的預(yù)測用戶接下來的動作 ， 再進(jìn)行 prefetch 可以很大程度上減少資源浪費(fèi) 。
舉個例子 ， 在 PC 頁面當(dāng)用戶鼠標(biāo)懸停在某個商品圖片上時候 ， 我們可以大膽預(yù)測用戶及大概率要點(diǎn)擊頁面 ， 這時候可以對頁面進(jìn)行 prefetch 。 如果希望進(jìn)一步細(xì)化 ， 用戶點(diǎn)擊鼠標(biāo)的動作會依次觸發(fā) mousedown、mouseup、click事件 ， 我們可以在 mousedown 事件中對頁面進(jìn)行預(yù)載 ， 這樣可以節(jié)省人點(diǎn)擊鼠標(biāo)的 200ms 左右 。
function App() {return (<div className=\"App\"><h1>Product List</h1><div className=\"product-list\"><Product id=\"1\" name=\"Product 1\" imageUrl=\"https://via.placeholder.com/150\" prefetchUrl=\"/next-page-1\" /><Product id=\"2\" name=\"Product 2\" imageUrl=\"https://via.placeholder.com/150\" prefetchUrl=\"/next-page-2\" /><Product id=\"3\" name=\"Product 3\" imageUrl=\"https://via.placeholder.com/150\" prefetchUrl=\"/next-page-3\" /></div></div>);const Product = ({ id name imageUrl prefetchUrl delay=200 ) => {const [prefetchTimeout setPrefetchTimeout
= useState(null);const handleMouseOver = () => {const timeout = setTimeout(() => {const link = document.createElement('link');link.rel = 'prefetch';link.href = https://mparticle.uc.cn/api/prefetchUrl;link.credentials ='include';document.head.appendChild(link);delay);// 防止用戶快速setPrefetchTimeout(timeout);;const handleMouseOut = () => {// 如果過度發(fā) prefetch 請求clearTimeout(prefetchTimeout);;return (<div className=\"product\"onMouseOver={handleMouseOveronMouseOut={handleMouseOut><img src=https://mparticle.uc.cn/api/{imageUrl alt={name loading=/"lazy\" /><p>{name</p></div>);

添加 credentials 屬性 ， 攜帶 cookie


安全原因 prefetch 請求默認(rèn)不攜帶 cookie ， 為了讓 prefetch 請求攜帶 cookie ，可以在 prefetch 的 link 標(biāo)簽中添加 credentials 屬性 ， 并將其設(shè)置為 \"include\" 。
<link rel=\"prefetch\" href=https://mparticle.uc.cn/"...\" as=\"script\" credentials=\"include\">

服務(wù)器設(shè)置緩存


因為大部分動態(tài)頁面為了給用戶傳輸動態(tài)內(nèi)容是禁用客戶端緩存的 ， 所以即使發(fā)了 prefetch 請求也無法做到用戶真實點(diǎn)擊的時候復(fù)用 prefetch 請求 ， 反而會重新發(fā)請求造成資源浪費(fèi) 。
因此需要在服務(wù)端識別 prefetch 請求 ， 設(shè)置短時間的客戶端緩存 ， 當(dāng)用戶很快真實訪問 prefetch 的頁面后可以復(fù)用緩存 。
瀏覽器發(fā)送的 prefetch 請求會攜帶 HTTP Header Sec-Purpose: prefetch或Purpose: prefetch ， 服務(wù)端根據(jù)這個屬性識別 prefetch 請求 。
app.get('/next-page' (req res) => {const purposeHeader = req.headers['purpose'
|| req.headers['sec-purpose'
;if (purposeHeader === 'prefetch') {res.set('Cache-Control' 'max-age=10'); // 設(shè)置緩存策略console.log('Prefetch request detected setting cache.');else {console.log('Regular request detected no cache.');res.send(`<h1>Next Page Content</h1><p>This is the next page that was prefetched.</p>`););?

頁面與首屏請求并行加載


上述方案在 SSR 頁面效果顯著 ， 但在 CSR 頁面可能優(yōu)化效果有限 ， 主要原因是 CSR 頁面內(nèi)容存儲在 CDN 甚至客戶端本地緩存 ， 本身加載很快 ， 頁面的渲染主要依賴動態(tài)接口的返回 。



??
如果我們可以知道頁面首屏渲染需要發(fā)起的請求 ， 其實可以利用和上面類似的原理 ， 在用戶點(diǎn)擊頁面的瞬間同時發(fā)起異步請求 ， 當(dāng)解析執(zhí)行 JavaScript 腳本發(fā)送異步請求時可以判斷本地已經(jīng)有緩存 ， 直接使用結(jié)果 。





原理非常類似 ， 不再代碼演示 ， 核心還是請求：
  • 設(shè)置credentials請求可以攜帶 cookie；
  • 服務(wù)端識別 prefetch 請求 ， 對接口設(shè)置短時間的緩存；
這樣的方案最大程度利用了瀏覽器的特性實現(xiàn)起來比較簡單 ， 對 Service Worker 熟悉的話可以利用 Service 做更復(fù)雜的控制 。
Speculation Rules API


Speculation Rules API 是一個新的 Web API ， 提供一種聲明式的方法來指示瀏覽器應(yīng)該對哪些鏈接進(jìn)行預(yù)取操作 ， 通過這個 API ， 開發(fā)者可以更精確地指示瀏覽器在何時和如何預(yù)取資源 ， 從而顯著提升網(wǎng)頁性能和用戶體驗 。
<!DOCTYPE html><html lang=\"en\"><head><meta charset=\"UTF-8\"><title>Speculation Rules API</title><!-- Speculation rules --><script type=\"speculationrules\">{\"prefetch\": [
</script></head><body><a href=https://mparticle.uc.cn/"/page1.html\" data-prefetch-url=\"/page1.html\">Go to Page 1</a><a href=https://mparticle.uc.cn/"/page2.html\" data-prefetch-url=\"/page2.html\">Go to Page 2</a><a href=https://mparticle.uc.cn/"/page3.html\" data-prefetch-url=\"/page3.html\">Go to Page 3</a><script>function addPrefetchRule(url) {const speculationRulesScript = document.querySelector('script[type=\"speculationrules\"
');const rules = JSON.parse(speculationRulesScript.textContent);// 檢查 rule 是不是已經(jīng)設(shè)置if (!rules.prefetch.some(rule => rule.urls.includes(url))) {rules.prefetch.push({\"source\": \"list\"\"urls\": [url
);// 更新 speculation rulesspeculationRulesScript.textContent = JSON.stringify(rules);console.log(`Prefetch rule added for: ${url`);// 鼠標(biāo) hover 時候添加document.querySelectorAll('a[data-prefetch-url
').forEach(link => {link.addEventListener('mouseover' () => {const url = link.getAttribute('data-prefetch-url');addPrefetchRule(url);););</script></body></html>Speculation Rules API 目前還處于早期階段 ， 未來可能會看到更多的瀏覽器開始支持這一 API ， 并且 API 本身也可能會引入更多的功能和配置選項 。
頁面部分內(nèi)容提前返回




流式渲染簡介


流式渲染（Streaming Rendering）是指在服務(wù)器上生成頁面內(nèi)容時 ， 逐步將已準(zhǔn)備好的部分內(nèi)容立刻發(fā)送到客戶端 ， 而不是等待頁面所有內(nèi)容全部生成才開始發(fā)送 ， 使客戶端可以更快的接收數(shù)據(jù)渲染頁面 ， 而不必等待整個頁面的內(nèi)容完全下載 ， 從而實現(xiàn)快速的頁面加載和用戶可視化體驗 。 這個過程像是水管中的水一樣流動起來源源不斷 ， 因此被稱為流式渲染 。
流式渲染實際上一個非常古老的技術(shù) ， 早在 HTTP 1.1 規(guī)范中就已經(jīng)引入了 Transfer-Encoding: chunked 頭字段 ， 允許服務(wù)器將響應(yīng)內(nèi)容分批返回給客戶端 。 服務(wù)器可以在生成響應(yīng)內(nèi)容的同時 ， 將其分成小塊 ， 逐步傳輸給客戶端 ， 而不是等待所有內(nèi)容生成完成后再返回 。
在瀏覽器端 ， 早期的瀏覽器（如 Netscape Navigator 和 IE）就已經(jīng)支持對部分 HTML 內(nèi)容進(jìn)行解析和執(zhí)行 。 當(dāng)瀏覽器接收到服務(wù)器返回的部分 HTML 內(nèi)容時 ， 它可以立即開始解析和執(zhí)行該內(nèi)容 ， 而不需要等待所有內(nèi)容加載完成 。





const http = require('http');http.createServer((req res) => {res.writeHead(200 {'Content-Type': 'text/html''Transfer-Encoding': 'chunked');function renderChunk(chunk) {res.write(`<div>${chunk</div>`);renderChunk('Loading...');setTimeout(() => {renderChunk('Chunk 1');1000);setTimeout(() => {renderChunk('Chunk 2');2000);setTimeout(() => {renderChunk('Chunk 3');3000);setTimeout(() => {renderChunk('done!');res.write('</body></html>');res.end();4000);).listen(3000 () => {console.log('Server listening on port 3000'););

開啟流式渲染后的新思路


頁面支持流式渲染之后我們可以利用等待服務(wù)器計算生成動態(tài)內(nèi)容的空檔 ， 提前返回頁面部分內(nèi)容 ， 在瀏覽器完成關(guān)鍵域名的預(yù)建連、核心資源的預(yù)加載 ， 嚴(yán)格來講下面講的很多內(nèi)容其實是 HTTP 協(xié)議實現(xiàn)的 ， 但思路上和流式渲染原理一致 ， 所以放在一塊來討論 。


提前返回 preconnenct、preload 標(biāo)簽


頁面可以對靜態(tài)部分做緩存 ， 接收到用戶請求后流式渲染直接返回（其實這種最適合利用 CDN 邊緣渲染） 。
頁面靜態(tài)部分 public/static.html
<!DOCTYPE html><html lang=\"en\"><head><meta charset=\"UTF-8\"><title>Optimized Page</title><!-- Preconnect to an external domain --><link rel=\"preconnect\" href=https://mparticle.uc.cn/"https://fonts.googleapis.com\"><link rel=\"preconnect\" href=https://mparticle.uc.cn/"https://fonts.gstatic.com\" crossorigin><!-- Preload a critical CSS file --><link rel=\"preload\" href=https://mparticle.uc.cn/"/styles/main.css\" as=\"style\"><!-- Preload an important image --><link rel=\"preload\" href=https://mparticle.uc.cn/"/images/hero-banner.jpg\" as=\"image\"></head><body>如果服務(wù)器 RT 過長 ， 甚至可以反直覺的在頁面頂部預(yù)載 JavaScript 文件 ， 但不執(zhí)行 。
server.js
const http = require('http');const path = require('path');const fs = require('fs');const filePath = path.join(__dirname 'public' 'static.html');http.createServer((req res) => {res.writeHead(200 {'Content-Type': 'text/html''Transfer-Encoding': 'chunked');function renderChunk(chunk) {res.write(`<div>${chunk</div>`);fs.readFile(filePath 'utf8' (err firstFragment) => {// 返回靜態(tài)部分 ， 瀏覽器提前建連、加載renderChunk(firstFragment););renderChunk('Loading...');setTimeout(() => {// 復(fù)雜的服務(wù)端計算renderChunk('done!');res.write('</body></html>');res.end();4000);).listen(3000 () => {console.log('Server listening on port 3000'););

根據(jù)數(shù)據(jù)生成 preload html 片段


其實我們還可以把服務(wù)器 RT 部分細(xì)分 ， ?♀? 頁面取數(shù)部分實際非常復(fù)雜 ， 而恰好首屏呈現(xiàn)的部分內(nèi)容取數(shù)很快 ， 后續(xù)取數(shù)或 SSR 很慢 。
  • 服務(wù)器首屏取數(shù)
  • 服務(wù)器取數(shù) 2
  • 服務(wù)器取數(shù) 3
  • 調(diào)用頁面 SSR
  • 返回服務(wù)武器渲染部分
這種時候可以在調(diào)用 ssr 之前 ， 解析首屏數(shù)據(jù)生成 ， 如果包含圖片 ， 可以生成 preload 標(biāo)簽 ， 提前返回到瀏覽器 ， 甚至對首屏部分調(diào)用占位的 SSR 。
const http = require('http');http.createServer((req res) => {res.writeHead(200 {'Content-Type': 'text/html''Transfer-Encoding': 'chunked');function renderChunk(chunk) {res.write(`<div>${chunk</div>`);setTimeout(async () => {const firstData = https://mparticle.uc.cn/api/await getFirstScreenData();renderChunk(`用了此類技術(shù)的頁面效果：







http header 返回后續(xù)域名 preconenct


除了在 HTML 中通過 link 標(biāo)簽支持 preconnect ， 足夠了解 HTTP 協(xié)議后我們還可以更快一些 ， 在 HTTP header 中設(shè)置 preconenct ， 這就是 HTTP Link? 。
HTTP/2 200 OKContent-Type: text/htmlLink: <https://example.com>; rel=preconnect <https://fonts.googleapis.com>; rel=preconnectserver.js
app.get('/' (req res) => {// Set Link headers for preconnectres.set('Link' ['<https://example.com>; rel=preconnect''<https://fonts.googleapis.com>; rel=preconnect'
.join(' '));// Flush headers to send them immediatelyres.flushHeaders();// Stream the HTML fileconst readStream = fs.createReadStream('content');readStream.pipe(res););

HTTP/2 push


HTTP/2 Push 是 HTTP/2 協(xié)議中的一種功能 ， 允許服務(wù)器在響應(yīng)客戶端請求時 ， 主動將多個資源推送給客戶端 ， 而無需客戶端明確請求這些資源 。





在 NGINX 中 ， http2_push 指令用于啟用或禁用 HTTP/2 push 。
server {listen 443 ssl http2;server_name localhost;ssl_certificate /path/to/your/certificate.crt;ssl_certificate_key /path/to/your/private.key;location / {root /path/to/your/web/content;index index.html;# 啟用 HTTP/2 推送http2_push_preload on;http2_push banner.jpg;?看起來怎么這么熟悉 ， 沒錯 ， HTTP/2 push 在很多時候就是利用 HTTP Link 特性實現(xiàn)的 。
server {listen 443 ssl http2;server_name localhost;ssl_certificate /path/to/your/certificate.crt;ssl_certificate_key /path/to/your/private.key;location / {root /path/to/your/web/content;# 啟用 HTTP/2 推送http2_push_preload on;# 發(fā)送 HTML 文檔的同時 ， 告訴客戶端推送資源add_header Link \"<banner.jpg.css>; as=image; rel=preload\";?不過通過 Nginx 配置來完成這個工作過于不靈活 ， 大部分時候是通過上面講的在服務(wù)代碼中實現(xiàn) 。
Early Hints


?https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103?
在 HTTP 1xx 的狀態(tài)碼用來告示客戶端繼續(xù)進(jìn)行請求或等待更詳細(xì)的響應(yīng) ， 比如在 WebSocket 交換協(xié)議期間返回的 101 。
HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: Upgrade還有一個專門用于服務(wù)器希望發(fā)送最終響應(yīng)頭部之前 ， 提供一些消息頭 ， 客戶端可以開始預(yù)加載資源的 103 —— Early Hints ， 其作用和前面提到的 http link 非常類似 。
HTTP/1.1 103 Early HintsLink: </style.css>; rel=preload; as=styleserver.js
app.get('/' (req res) => {// Send 103 Early Hints response to clientres.status(103).set({Link: ['</styles/main.css>; rel=preload; as=style''</images/example.jpg>; rel=preload; as=image'
.join(' ')).end();// Set up final responseconst readStream = fs.createReadStream('content');res.set('Content-Type' 'text/html');// Stream the final response contentreadStream.pipe(res););Early hints preconnect 已經(jīng)在主流瀏覽器都得到普遍支持 ， preload Safari 還沒有支持Web。







彈性公網(wǎng)IP滿足資源靈活管理


阿里云提供了將原ECS實例所分配的固定公網(wǎng)IP轉(zhuǎn)為彈性公網(wǎng)IP（EIP） ， 且公網(wǎng)IP地址不變的能力 。 您可以將轉(zhuǎn)換后的EIP綁定到負(fù)載均衡SLB或其他ECS實例上 ， 在不影響業(yè)務(wù)的情況下完成水平擴(kuò)容、服務(wù)遷移 。


【W(wǎng)eb 性能優(yōu)化｜了解 HTTP 協(xié)議后才能理解的預(yù)加載】點(diǎn)擊閱讀原文查看詳情 。

    推薦閱讀