単一ポイントに対する WebP スムーズトランジションツール WebP-ServerGo を推奨します

しばらく WebP のサポートに注目していなかったが、一見したところ、QQ ブラウザですら WebP を完璧にサポートしているようだ。以前から WebP-Server というトランジションツールに注目していたが、最近、糖哥がブロガーに Tencent Cloud の無忧軽量サーバーを送ってくれたので、中国国内の軽量サーバーにデプロイして、WebP がもたらす向上を体感してみた。

一、概要#

WebP は Google が開発した効率的な画像圧縮方式（Google WebP）で、無損失の png と比較して、一般的に WebP の 20% の損失圧縮で最大 75% の圧縮率を達成できる。Google が宣伝しているように、WebP の圧縮率は通常 JPEG や JPEG 2000 よりも平均 30% 高く、画像の品質を低下させることはない。

しかし、2023 年まで、純粋な WebP ストレージは依然として大きな歴史的遺産の問題に直面している。アクセスに関する問題は比較的小さく、iOS 14 以前の Safari がサポートしていないだけで、国内外の主流の現代ブラウザはすでに WebP 画像の読み込みをサポートしている（サポート統計）。しかし、Photoshop や Illustrator などの各種生産性ツールは依然として WebP 画像の読み込みをサポートしておらず、元の画像が WebP のみで保存されている場合、古いデバイスの一部を放棄し、編集の便利さを失うことを意味する。一方では WebP がもたらす極致のメディア読み込み体験があり、もう一方では一部の編集の便利さを失うことがあり、ブロガーはこれらの選択に常に悩んでいた。完璧に問題を解決できないため、新技術に対して尻込みしていた。

少し前、偶然の機会に友人が WebP-Server というトランジションツールについて言及した。これは Go 言語に基づく WebP 変換ミドルウェアで、多くの CDN が提供するトランジション戦略と同様に、元の画像をストレージに使用し、訪問者の UA を判断してブラウザのサポートを決定し、WebP または元の画像を返すことができる。対応して、WebP-Server は WebP キャッシュの生成をサポートし、CDN のようにエッジアクセスノードとしてソースサイトのリクエストを圧縮することもできる。

プロジェクトホームページ： https://webp.sh
プロジェクトドキュメント： https://docs.webp.sh/usage/basic-usage
GitHub： https://github.com/webp-sh/webp_server_go

国内のサーバー市場を見渡すと、個人の経済能力が許容できる範囲の帯域幅は最大でも 4-5M 程度だ。このような仮定に基づいて理論計算すると、5M の帯域幅は約 640k/s の送信能力を提供できる。ブロガーの経験では、平均して 1 ページあたり 8 枚の画像、100k / 画像で、単一の PV では帯域幅を 1.25 秒で満たして画像の読み込みを完了する必要がある。しかし、20% の損失 WebP 圧縮の場合、画像の平均サイズは 16-25k に減少し、1 秒以内に PV の同時処理能力を 5 倍に向上させることができる。これは、サーバーの帯域幅が非常に厳しい国内のネットワーク環境において、サイトの負荷能力を劇的に向上させる。こうした現状を踏まえ、自分用の画像ホスティングが WebP をサポートできれば、CDN に追加料金を支払う必要がなく、高品質の BGP ネットワークを通じてサービスを提供できる可能性が高い。

パンデミック後のコスト削減と効率向上の大環境の中で、Tencent Cloud の 4 月のクラウドセレクションが依然として 3 年間 408 2C/2G/4M および 628 2C/4G/5M の軽量アプリケーションサーバーを提供している。最近、糖哥が私に Tencent Cloud の無忧軽量サーバーを送ってくれた。1C/2G/5M の構成は、プロモーションの帯域幅と基本的に一致している。余談だが、最近 Tencent Cloud は無忧の有料アップグレードの通路を開放した。無忧を持っている仲間は、必要に応じてより高い構成にアップグレードすることができる。

二、WebP Server#

WebP-Server は libaom コンポーネントを必要とし、libc6>2.34 が必要なため、ブロガーは CentOS 8 / Debian 11 以上のシステムを使用することをお勧めする。古いシステムはコンパイルを通じて libc6 のバージョンをアップグレードできるが、これは非常に危険な操作であり、システムの重要なコンポーネントに問題を引き起こす可能性がある。そのため、古いシステムには、ブロガーは直接 Docker を使用してデプロイすることをお勧めする（公式ドキュメント）。ARMv7（32bit）、ARM64（Aarch64）、AMD64（x86-64）をサポートし、DockerHub で確認できる（クリックして移動）。

#  [/path/to/pics ] は画像パスを指し、 [/opt/pics ] は生成されたWebPキャッシュパスを指す
docker run -d -p 3333:3333 -v /path/to/pics:/opt/pics --name webp-server webpsh/webp-server-go

手動インストールの場合、必要なコンポーネントは libaom3 で、このコンポーネントは少し厄介で、プリコンパイルパッケージは libaom.so.3 この.soをデフォルトで読み込む。インストール後、まだ libaom3 が見つからないと表示される場合は、ln -s でソフトリンクを作成してみてください。

# libaomライブラリをインストール
apt install libaom-dev
yum install libaom-devel
# RHEL系（CentOS）で依存関係が見つからない問題を解決
ln -s /usr/lib64/libaom.so.0 /usr/lib64/libaom.so.3
# Debian系で依存関係が見つからない問題を解決
ln -s /usr/lib/x86_64-linux-gnu/libaom.so.0 /usr/lib64/libaom.so.3

プリコンパイルパッケージは GitHub からダウンロードできる（クリックして移動）。設定ファイルは実際のニーズに応じてモードを選択し、パラメータを変更してください。以下の各パラメータの説明はコメントに記載されており、変更後は config.json ファイルとして保存できます。

# プロキシモード
{
  "HOST": "127.0.0.1", //ローカルホストをリッスンし、0.0.0.0を使用するとすべてをリッスン
  "PORT": "3333", //WebP Serverが使用するローカルポート
  "QUALITY": "80", //圧縮品質、低いほど画像の圧縮比が高くなる
  "IMG_PATH": "https://test.webp.sh", //リバースプロキシのサイト
  "EXHAUST_PATH": "/path/to/exhaus", //WebPキャッシュの保存パス
  "ALLOWED_TYPES": ["jpg","png","jpeg","bmp","gif"], //圧縮する拡張子のタイプ
}
# ローカルモード
{
  "HOST": "127.0.0.1", //ローカルホストをリッスンし、0.0.0.0を使用するとすべてをリッスン
  "PORT": "3333", //WebP Serverが使用するローカルポート
  "QUALITY": "80", //圧縮品質、低いほど画像の圧縮比が高くなる
  "IMG_PATH": "/path/to/pics", //ローカル画像パス、一般的にサイトのルートディレクトリに設定
  "EXHAUST_PATH": "/path/to/exhaust", //WebPキャッシュの保存パス
  "ALLOWED_TYPES": ["jpg","png","jpeg","bmp","gif"], //圧縮する拡張子のタイプ
  "ENABLE_AVIF": false //av1圧縮サポート、現在は使用を推奨しない
}

直接インストールする場合は、systemd を使用してサービスを起動することをお勧めします。以下は webp.service を一括で書き込む例で、webp-server のバイナリファイルと config.json ファイルのパスを修正し、直接 SSH ウィンドウに貼り付けることができます。

cat > /etc/systemd/system/webp.service <<EOF
[Unit]
Description=WebP Server
Documentation=https://github.com/n0vad3v/webp_server_go
After=nginx.target

[Service]
Type=simple
StandardError=journal
AmbientCapabilities=CAP_NET_BIND_SERVICE
WorkingDirectory=/[プログラムディレクトリ]/webp-server
ExecStart=/[プログラムディレクトリ]/webp-server/webp-server-linux-amd64 --config /[プログラムディレクトリ]/webp-server/config.json
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=3s

[Install]
WantedBy=multi-user.target
EOF

これで、service webp start|stop|status を使用して WebP Server の実行を制御できるようになり、確認が完了したら systemctl enable webp を使用して自動起動を許可します。

三、NGINX 設定#

WebP-Server が正常に動作した後、NGINX でリバースプロキシを設定し、jpg|jpeg|gif|png|bmp の拡張子を持つメディアファイルを WebP-Server に処理させる必要があります。以下はその例で、NGINX の対応する vhost に追加するだけです。WebP の自動返却を有効にした後、vhost 内で NGINX が関連メディア拡張子のキャッシュ内容を削除する必要があることに注意してください。そうしないと、WebP がサポートされていないデバイスに返されることになります。

# jpg|jpeg|gif|png|bmpリクエストをローカルの3333ポートに転送
location ~* \.(?:jpg|jpeg|gif|png|bmp)$ {
    proxy_pass http://127.0.0.1:3333;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_hide_header X-Powered-By;
    proxy_set_header HOST $http_host;
    add_header Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
}

四、補足＆まとめ#

記事を執筆する過程で、友人からこのプログラムにメモリリークの問題があることを指摘された（クリックして移動）。著者は Docker を使用してメモリ使用量を制限することでこの問題を回避することを推奨している。この問題は、複数のユーザーが単一のメディアリソースに同時にアクセスする際に、WebP Server が同じファイルに対して複数の圧縮プロセスを起動し、異常なメモリ使用を引き起こすことによって発生する。直接インストールする場合、より良い体験のためにキャッシュのプリヒートは非常に賢明な選択である。

# 4プロセスを有効にして設定ディレクトリをキャッシュプリヒート
./webp-server -prefetch -jobs=4 --config /[プログラムディレクトリ]/webp-server/config.json

著者の GitHub のプリコンパイルパッケージは 64 ビット x86 アーキテクチャのみを提供しており、著者は RHEL8 系でプリコンパイルパッケージを構築したと感じている。他のプラットフォームで使用したい場合は、Docker を使用するか、ドキュメントに従って（クリックして移動）コンパイルすることを検討してください。全体のプロセスはそれほど複雑ではない。設定が完了したら、F12 の Network タブを開き、タイプオプションをチェックするか、画像の content-type で確認すると、実際にアクセスした画像が WebP に圧縮されていることがわかる。最後に、著者がこのような便利なツールを作成してくれたことに感謝します。

原文リンク： https://luotianyi.vc/6907.html

何か問題があれば、皆さんの批判や指摘を歓迎します～