將Brotli壓縮提高到11級|從源服務(wù)器提供Brotli壓縮并推出“壓縮規(guī)則”

在今年Speed Week期間，我們已經(jīng)討論了優(yōu)化性能的重要性。壓縮可減小在互聯(lián)網(wǎng)上傳輸?shù)奈募笮。l(fā)揮著至關(guān)重要的作用。壓縮文件越少，下載速度越快，網(wǎng)站加載速度越快，用戶體驗更佳。

以家庭清潔產(chǎn)品為例。據(jù)估計，“一瓶典型的清潔劑中有90%的水，實際有價值的成分不到10%。”從典型的500毫升瓶裝家庭清潔劑中移除90％，其重量從600克減少到60克。這樣做意味著只需要發(fā)送一個60克的包裹，并附上重新添加水的說明。將這種削減擴大到加侖，很快就會為企業(yè)帶來巨大的運輸成本節(jié)省，更不用說對環(huán)境的影響了。

這就是壓縮的工作原理。發(fā)送方將文件壓縮至可能的最小體量，然后發(fā)送較小的文件并提供有關(guān)接收后如何處理它的說明。通過減小發(fā)送的文件大小，壓縮確保發(fā)送文件所需的帶寬量大大減少。如果文件存儲于例如AWS的昂貴云服務(wù)提供商，減小發(fā)送的文件大小將直接等同于顯著的帶寬成本節(jié)約。

傳輸較小的文件體量尤其有利于互聯(lián)網(wǎng)連接資源相對有限的終端用戶，例如在蜂窩網(wǎng)絡(luò)上的移動設(shè)備或在網(wǎng)絡(luò)速度較慢地區(qū)的用戶。

Cloudflare一直支持Gzip壓縮。Gzip是一種廣泛使用的壓縮算法，自1992年以來一直存在，為所有Cloudflare用戶提供文件壓縮。然而，Google在2013年推出了Brotli，它支持更高的壓縮級別，并且整體性能更好。從Gzip切換到Brotli會使網(wǎng)頁文件更小、加載時間更快。我們自2017年起就支持在Cloudflare和客戶端瀏覽器之間使用Brotli?，F(xiàn)在Cloudflare已全面端到端Brotli壓縮：支持從源服務(wù)器到客戶端的最高級別Brotli壓縮。

如果您的源服務(wù)器支持Brotli，請打開它，提高壓縮級別，暢享性能提升。

將Brotli壓縮提高到11級

Brotli有12個壓縮級別，從0到11，其中0提供最快的壓縮速度但壓縮比最低，而11提供最高的壓縮比但需要更多的計算資源和時間。在5年前最初實施Brotli時，我們確定4級壓縮提供了節(jié)省字節(jié)和壓縮時間的平衡，同時還不會影響性能。

自2017年以來，Cloudflare針對所有可壓縮的資產(chǎn)，根據(jù)最終用戶的“accept-encoding”標(biāo)頭，使用最大4級Brotli壓縮。然而，一個問題是Cloudflare在源段僅請求Gzip壓縮，即使源支持Brotli。此外，Cloudflare總是解壓從源接收到的內(nèi)容，然后將其再次壓縮并發(fā)送到最終用戶，導(dǎo)致額外的處理時間。因此，客戶無法充分利用Brotli壓縮所提供的優(yōu)勢。

采用端到端的Brotli壓縮之前

現(xiàn)在，由于Cloudflare已完全支持端到端的Brotli壓縮，客戶將開始看到我們更新的“accept-encoding”標(biāo)頭到達他們的源。一旦可用，客戶可以直接將高度壓縮（最高的11級）的Brotli文件傳輸、緩存和提供給我們。這將有助于減少延遲和帶寬消耗。如果最終用戶設(shè)備不支持Brotli壓縮，我們將自動解壓文件，以解壓縮格式或Gzip壓縮文件的形式提供，具體取決于Accept-Encoding標(biāo)頭。

完全端到端Brotli壓縮支持

最終用戶不支持Brotli壓縮

客戶可以通過參考適當(dāng)?shù)脑诰€資料在其源上實現(xiàn)Brotli壓縮。例如，使用NGINX的客戶可以按照這個教程按如下方式在其`nginx.conf`配置文件中設(shè)置11級壓縮：

brotli on;

brotli_comp_level 11;

brotli_static on;

brotli_types text/plain text/css application/javascript application/x-javascript text/xml

application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon

image/bmp image/svg+xml;

然后，Cloudflare將以完全相同的壓縮級別（11）為匹配文件brotli_types向客戶端提供這些資產(chǎn)。這意味著任何SVG或BMP圖像都將以Brotli 11壓縮級別發(fā)送到客戶端。

相關(guān)測試

我們對一個簡單的CSS文件應(yīng)用了壓縮，并測試了不同壓縮算法和級別的影響。我們的目標(biāo)是通過優(yōu)化壓縮技術(shù)來確定用戶可能體驗到的潛在改進。這些結(jié)果可以在以下表格中看到：

通過壓縮到Brotli 11級，相比最佳的Gzip壓縮級別，用戶可以將文件大小進一步減少19%。此外，最強的Brotli壓縮級別相比Cloudflare默認(rèn)使用級別可以將文件大小進一步減少約18%。這凸顯了利用Brotli壓縮可顯著減少文件大小，特別是在其最高級別下，從而提高網(wǎng)站性能、加快頁面加載時間并減少總體出站費用。

為了利用更高的端到端壓縮率，需要禁用以下Cloudflare代理功能。

Email Obfuscation

Rocket Loader

服務(wù)器端排除（SSE）

Mirage

HTML最小化—JavaScript和CSS可繼續(xù)啟用。

Automatic HTTPS Rewrites

這是因為Cloudflare需要解壓縮并訪問主體部分以滿足應(yīng)用請求的設(shè)置?；蛘?，客戶可以使用配置規(guī)則為特定路徑禁用這些功能。

如果啟用了這些重寫功能之一，您的源仍然可以更高的級別發(fā)送Brotli壓縮。但是，我們將實時解壓、應(yīng)用啟用的Cloudflare功能，并使用Cloudflare的默認(rèn)Brotli 4級或Gzip 8級重新壓縮，具體取決于用戶的accept-encoding標(biāo)頭。

對于不接受Brotli壓縮的瀏覽器，我們將繼續(xù)解壓縮并發(fā)送Gzip響應(yīng)或不壓縮的響應(yīng)。

端到端Brotli壓縮的實施

要實現(xiàn)來自源的Brotli壓縮，初始步驟涉及構(gòu)建一個解壓縮模塊，該模塊可以集成到Cloudflare軟件堆棧中。它允許我們將從源接收到的壓縮字節(jié)高效轉(zhuǎn)換為原始、未壓縮文件。這一步驟非常關(guān)鍵，因為許多功能（例如Email Obfuscation和Cloudflare Workers）都依賴于訪問響應(yīng)正文以滿足應(yīng)用自定義設(shè)置。

我們將解壓器集成到Cloudflare核心反向Web代理中。這種集成確保所有Cloudflare產(chǎn)品和功能都可以輕松地訪問Brotli解壓縮。這也使我們的Cloudflare Workers團隊能夠直接將Brotli納入Cloudflare Workers中，使我們的Workers用戶能夠與以Brotli返回的響應(yīng)交互，或者直接傳遞給最終用戶而不進行修改。

推出壓縮規(guī)則——精細化控制到最終用戶的壓縮

默認(rèn)情況下，Cloudflare根據(jù)文件的Content-Type標(biāo)頭壓縮某些內(nèi)容類型。此外，我們還推出了面向Enterprise客戶的壓縮規(guī)則，以允許您進一步控制Cloudflare將如何壓縮和壓縮什么內(nèi)容。通過特定壓縮規(guī)則，您可以獲得對Cloudflare壓縮能力的增強控制，使您能夠自定義Cloudflare壓縮哪些內(nèi)容以及如何壓縮，以優(yōu)化網(wǎng)站的性能。

例如，通過使用Cloudflare針對.ktx文件的壓縮規(guī)則，客戶可以優(yōu)化在WebGL應(yīng)用程序中紋理的交付，從而增強整體用戶體驗。啟用壓縮可以最大限度地減少帶寬使用，并確保WebGL應(yīng)用程序快速流暢地加載，即使處理大型、詳細紋理時也不例外。

客戶也可以禁用壓縮或指定有關(guān)我們?nèi)绾螇嚎s的偏好。另一個例子可能是，基礎(chǔ)設(shè)施公司只想支持其物聯(lián)網(wǎng)設(shè)備的Gzip壓縮，但允許所有其他主機名使用Brotli壓縮。

壓縮規(guī)則使用我們其他規(guī)則產(chǎn)品所使用的過濾器，并增加了媒體類型和擴展類型字段。這允許用戶可以輕松指定要壓縮的內(nèi)容。

棄用Brotli切換設(shè)置模塊

自2016年以來，一些Web瀏覽器長期支持Brotli，而Cloudflare自2017年開始支持Brotli。與所有新的Web技術(shù)一樣，當(dāng)時Brotli是未知的，我們通過API和用戶界面向客戶提供了選擇性啟用或禁用Brotli的能力。

如今，Brotli已經(jīng)演變并得到了所有瀏覽器的支持，我們計劃在未來幾個月默認(rèn)在所有區(qū)域啟用Brotli。這與我們當(dāng)前支持的Gzip行為相同，并從我們的儀表板中刪除了切換設(shè)置模塊。如果瀏覽器不支持Brotli，則Cloudflare將繼續(xù)支持其能夠接受的編碼類型，例如Gzip或不壓縮，企業(yè)客戶仍將能夠使用壓縮規(guī)則，以精細化控制我們?nèi)绾蜗蚱浣K端用戶壓縮數(shù)據(jù)。

Web壓縮的未來

我們已經(jīng)看到Brotli作為新的Web壓縮技術(shù)得到了更廣泛的采用，并具備優(yōu)秀的性能。展望未來，我們正在密切關(guān)注趨勢和新的壓縮算法，例如zstd，作為可能的下一代壓縮算法。

與此同時，我們正在尋求直接改進Brotli的方法。我們特別關(guān)注的一個發(fā)展是與Brotli共享字典。無論何時壓縮資源，都要使用“字典”來幫助提高壓縮效率。一個簡單的類比是在iPhone消息中輸入OMW。iPhone會使用自己的內(nèi)部詞典自動將其翻譯成On My Way。

這個內(nèi)部字典將3個字符轉(zhuǎn)換成9個字符（包括空格）。內(nèi)部字典節(jié)省了6個字符，這為用戶提供性能上的優(yōu)化。

默認(rèn)情況下，Brotli RFC定義了一個客戶端和原始服務(wù)器都使用的靜態(tài)字典。靜態(tài)字典被設(shè)計成通用的，適用于所有人。優(yōu)化字典的大小，使其不會太大，同時能夠產(chǎn)生最佳的壓縮結(jié)果。然而，如果一個源可為某個特定網(wǎng)站生成一個定制字典呢？例如，Cloudflare專用詞典將允許我們壓縮在網(wǎng)站上反復(fù)出現(xiàn)的單詞和短語，例如“Cloudflare”。定制的詞典將被設(shè)計成盡可能地壓縮這些內(nèi)容，而使用相同詞典的瀏覽器將能夠把這些內(nèi)容翻譯回來。

Web Incubator CG的一份新提案旨在做到這一點，允許您指定自己的字典，以便瀏覽器用來對網(wǎng)站做進一步的優(yōu)化壓縮。我們很高興能為這個提案做出貢獻，并計劃不久后發(fā)表我們的研究。

馬上試試吧

壓縮規(guī)則現(xiàn)已可用！端到端Brotli壓縮將在未來幾周內(nèi)推出。允許您提高性能，減少帶寬，并精細地控制Cloudflare如何處理到最終用戶的壓縮。