ASP.NET Core 文件響應壓縮的常見使用誤區(qū)
誤區(qū)1:未使用 Brotil 壓縮
幾乎不需要任何額外的代價,Brotil 壓縮算法可以幫助你的網(wǎng)站提升約 20% 靜態(tài)資源加載性能。
同時啟用 Gzip / Brotil 壓縮
Gzip 有更好的 user-agent 兼容性,而 Brotli 有更好的性能。
所以我們通常需要在 ASP.NET Core 網(wǎng)站中同時啟用這兩種壓縮。
如何區(qū)分 Gzip 壓縮和 Brotli 壓縮
網(wǎng)站啟用 Brotli 壓縮時,服務器請求返回頭 Content-Encoding 中會包含 br 字樣,否則是 gzip。
誤區(qū)2:使用 Fastest 級別的 Brotli 壓縮
如果你閱讀并參考了微軟官方文檔或者其他中文資源,比如:
ASP.NET Core 中的響應壓縮 - MS Doc
在ASP.NET Core中使用brotli壓縮 - Cnblogs
那么你可能會在代碼中像下面這樣使用壓縮功能:
寫法1:使用默認的壓縮行為(框架將隱式添加 Brotli 和 Gzip 功能)
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCompression();
}
}
寫法2:顯式添加壓縮功能
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression(options =>
{
options.Providers.Add<BrotliCompressionProvider>();
options.Providers.Add<GzipCompressionProvider>();
options.Providers.Add<CustomCompressionProvider>();
options.MimeTypes =
ResponseCompressionDefaults.MimeTypes.Concat(
new[] { "image/svg+xml" });
});
services.Configure<BrotliCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
}
寫法3:自定義 BrotliCompressionProvider
public class BrotliCompressionProvider : ICompressionProvider
{
public string EncodingName => "br";
public bool SupportsFlush => true
public Stream CreateStream(Stream outputStream)
{
return new BrotliStream(outputStream,CompressionLevel.Fastest);
}
}
不幸的是,以上三種寫法都沒有發(fā)揮出 Brotil 壓縮算法的優(yōu)勢。
它們的共同點是均使用了 CompressionLevel.Fastest 壓縮級別。
而在 CompressionLevel.Fastest 級別時,Brotil 與 Gzip 壓縮性能幾乎無異。
參考:Introducing Support for Brotli Compression

誤區(qū)3:使用 Optimal 級別的 Brotli 壓縮
CompressionLevel 只有三個枚舉值:Fastest / NoCompression / Optimal。
既然 Fastest 級別沒有用,那我們只能換成 Optimal 了。


最佳實踐:使用 4 或 5 級別的 Brotli 壓縮
在 Introducing Support for Brotli Compression 這篇文章中,作者對不同級別 Brotil 的壓縮耗時做了評測,也就是下面這幅圖。

觀察這副圖,Brotil 的壓縮質(zhì)量其實有 1~11 個級別。
那我們?nèi)绾巫远x Brotli 的壓縮級別呢,答案是直接將級別對應的整數(shù)轉(zhuǎn)成 CompressionLevel 枚舉。

盡管這種寫法看起來十分古怪,但通過考察 .NET 源碼,可以確鑿這種寫法是可行的。
以上就是ASP.NET Core 文件響應壓縮的常見使用誤區(qū)的詳細內(nèi)容,更多關于ASP.NET Core 文件響應壓縮的資料請關注腳本之家其它相關文章!
- ASP.NET Core中的響應壓縮的實現(xiàn)
- asp.net core為IHttpClientFactory添加動態(tài)命名配置
- 如何在ASP.NET Core中使用HttpClientFactory
- 在ASP.NET Core中用HttpClient發(fā)送POST, PUT和DELETE請求
- .NET CORE HttpClient的使用方法
- .NET Core使用HttpClient進行表單提交時遇到的問題
- .Net Core下HTTP請求IHttpClientFactory示例詳解
- Asp.Net Core2.1前后使用HttpClient的兩種方式
- ASP.NET Core針對一個使用HttpClient對象的類編寫單元測試詳解
- .NET Core中HttpClient的正確打開方式
- .NET Core中使用HttpClient的正確姿勢
- .NET Core 2.1中HttpClientFactory的最佳實踐記錄
- .Net Core HttpClient處理響應壓縮詳細
相關文章
asp.net下實現(xiàn)輸入數(shù)字的冒泡排序
.net下實現(xiàn)輸入數(shù)字的冒泡排序2010-03-03
Asp.Net Core MVC項目實現(xiàn)多語言實例(Globalization/Localization)
本篇文章主要介紹了Asp.Net Core MVC項目實現(xiàn)多語言實例(Globalization/Localization) ,具有一定的參考價值,有興趣的可以了解一下2017-06-06
sql server中批量插入與更新兩種解決方案分享(asp.net)
xml和表值函數(shù)的相對復雜些這里簡單貼一下bcp和SqlDataAdapter進行批量跟新插入方法,未經(jīng)整理還望見諒2012-05-05
ASP.NET MVC懶加載如何逐步加載數(shù)據(jù)庫信息
在ASP.NET MVC中實現(xiàn)數(shù)據(jù)庫的逐步加載可通過懶加載技術(shù)完成,首先,在EntityFramework中配置數(shù)據(jù)庫上下文,使用對應的實體類映射數(shù)據(jù)庫表,本文給大家介紹ASP.NET MVC懶加載如何逐步加載數(shù)據(jù)庫信息,感興趣的朋友跟隨小編一起看看吧2024-10-10
簡單使用BackgroundWorker創(chuàng)建多個線程的教程
簡單使用BackgroundWorker創(chuàng)建多個線程的教程,需要的朋友可以參考一下2013-03-03

