asp.net core文件壓縮常見使用誤區(qū)(最佳實踐)

前言

　　在微軟官方文檔中，未明確指出文件壓縮功能的使用誤區(qū)。

　　本文將對 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

圖 2-1 fastest 模式下，三種算法的壓縮率等同

誤區(qū)3：使用 optimal 級別的 brotli 壓縮

　　compressionlevel 只有三個枚舉值：fastest / nocompression / optimal。

　　既然 fastest 級別沒有用，那我們只能換成 optimal 了。

圖 3-1 壓縮級別枚舉

　　非常不幸，brotil 的 optimal 壓縮級別存在嚴重的性能問題，在實際網(wǎng)站應用中幾乎沒有適用的場景。

圖 3-2 optimal 壓縮耗時對比

最佳實踐：使用 4 或 5 級別的 brotli 壓縮

　　在introducing support for brotli compression這篇文章中，作者對不同級別 brotil 的壓縮耗時做了評測，也就是下面這幅圖。

圖 4-1 不同壓縮級別下 brotli 的壓縮耗時

　　觀察這副圖，brotil 的壓縮質(zhì)量其實有 1~11 個級別。

　　那我們?nèi)绾巫远x brotli 的壓縮級別呢，答案是直接將級別對應的整數(shù)轉(zhuǎn)成 compressionlevel 枚舉。

　　參考：setting a specific brotli compression level when using response compression in asp.net core

圖 4-2 指定 brotli 的壓縮級別

　　盡管這種寫法看起來十分古怪，但通過考察 .net 源碼，可以確鑿這種寫法是可行的。

　　參考：system.io.compression.brotliutils.cs

圖 4-3 compressionlevel 枚舉強制轉(zhuǎn)換整數(shù)

　　現(xiàn)在我們可以自定義壓縮級別了，但注意上方源碼，只能指定 3 以上的級別，3 包括 3 以下的值有其他對應的轉(zhuǎn)換邏輯。

　　回到本節(jié)第一副圖 4-1，通過實測，發(fā)現(xiàn)在 4 / 5 級別下，brotli 確實可以獲得最佳的壓縮率和較低的壓縮損耗。

總結

　　在 asp.net core 中，我們應該同時啟用 gzip 和 brotil 壓縮功能，其中 brotil 的壓縮級別應該自定義到 4 或 5。

public void configureservices(iservicecollection services)
      {
          services.addresponsecompression(options =>
          {
              options.providers.add<brotlicompressionprovider>();
              options.providers.add<gzipcompressionprovider>();
              options.mimetypes =
                  responsecompressiondefaults.mimetypes.concat(
                      new[] { "image/svg+xml" });
          });

          services.configure<brotlicompressionprovideroptions>(options =>
          {
              options.level = (compressionlevel)4; // 4 or 5 is ok
          });
      }
      public void configure(iapplicationbuilder app, iwebhostenvironment env)
      {
          app.useresponsecompression();
      }

以上就是asp.net core文件壓縮最佳實踐的詳細內(nèi)容，更多關于asp.net core文件壓縮的資料請關注碩編程其它相關文章！