Web用の画像最適化

インターネットには、画像のサイズを変更するのに十分な記事とプロジェクトがあります。 なぜもう1つ必要ですか？ この記事では、現在のソリューションに満足できず、独自のソリューションを削減しなければならなかった理由を説明します。

問題

まず、写真のサイズを変更した理由を理解しましょう。 私たちは、Webサービスとして、ユーザーにとって最も高速なページ読み込みに関心を持っています。 ユーザーはこれを好み、コンバージョンを増やします。 ユーザーが低速またはモバイルインターネットを使用している場合、ページが軽量であり、ユーザートラフィックとプロセッサリソースを浪費しないことが非常に重要です。 これに役立つポイントの1つは、画像のサイズ変更です。

2つの問題を解決します。 最初の問題は、画像が必要な解像度に絞り込まれないことが多いことです。つまり、クライアントは必要のないデータをダウンロードするだけでなく、ブラウザを使用して画像のサイズ変更にCPUリソースを費やす必要があります。 解決策：ブラウザーに表示される解像度でユーザーの写真を提供します。

2番目の問題は、通常、画像が十分に圧縮されていないことです。つまり、画像をより最適にエンコードできるため、画質を主観的に損なうことなくページの読み込み速度が向上します。 解決策：クライアントに戻る前に画像を最適化します。

その方法の例として、 github.comのような有名なサイトのメインページを見る必要はありません。 2 MBのページウェイトでは、そのうちの1.2は最適化されてダウンロードできない役に立たないイメージです。



2番目の例はHabrです。 記事を引き伸ばさないように、スクリーンショットは提供しません。結果は参照によるものです。 写真にhabraで許可を必要に変更しますが、それらを最適化しません。 これにより、サイズが650 Kb（50％）削減されます。

サイトの多くの場所では、たとえばニュースフィードでニュースの写真の縮小版を表示するために、写真の小さいバージョンが必要です。 これを次のように実装します。最高品質の画像のみがサーバーに保存され、必要に応じて更新バージョンを挿入し、「@」でURLの末尾に必要な解像度を追加します。 次に、ファイルではなく、サイズ変更バックエンドにリクエストが送信され、画像の更新され最適化されたバージョンが返されます。

一般的なソリューション

以下に述べることはすべて、JPEGおよびPNG画像に適用されます。 これらはインターネットで最も人気のある形式です。

「画像サイズ変更バックエンド」のようなものをグーグルに押し込んだ後、Nginxの使用が推奨されるケースの半分で、他の部分はさまざまな自己記述型サービス、ほとんどの場合Node.jsであることがわかります。

nginxから、またはむしろnginxモジュールで使用されるlibgdから、 テスト画像で63 RPSを圧縮できましたが、これは悪くはありませんが、より高速で柔軟性が必要です。 Graphicsmagickも適切ではありません。 速度が遅すぎます。 さらに、これらのソリューションはどちらも最適化されていない画像を生成します。 Nodeなどの他のほとんどのソリューションでは、サイズ変更にSharpを使用し、JPEG画像を最適化するためにMozJPEGを使用し、PNGを最適化するためにpngquantを使用することをお勧めします。

長い間、私たちはpngquantでNod'y、Libvips、MozJPEGのサモピズニー束を使用していましたが、ある日、「サイズ変更をより速く、リソースをあまり必要としないようにすることはできますか？」

ネタバレ：可能です。 ;）

これで、アプリケーションを高速化する方法を見つけることができました。 アプリケーションコードを調べた後、最適化に使用されたimagemin、特にMozJPEGおよびpngquantプラグインを実行すると、os.Execを介して同じ名前のユーティリティがプルされることがわかりました。 このケースは間違いなく切り取り、C'shnyhライブラリへのバインディングのみを使用します。 サイズ変更には、Libvips CライブラリへのバインディングであるSharpモジュールが使用されました。

私たちの実装

Guglezhは、Libvipsが依然として速度のリーダーであり、OpenCVだけがそれと競合できることを示しました。 そのため、実装にはLibvipsを使用します。これは既に実証済みのソリューションであり、Goの既製のバインディングがあります。 プロトタイプを書き、何が起こるかを試してみましょう。

この問題を解決するためにGolangが選ばれた理由についてのいくつかの言葉。 第一に、それは十分に速いですが、あなたはまだ私達が速いサイズ変更をしたいことを覚えています。 その上にあるコードは読みやすく、保守も簡単です。 最後の要件は、Cライブラリを操作できることでした。これは便利です。

プロトタイプをすばやく作成してテストし、シャープよりも内部のねじれが多いにもかかわらず、Libvipsは最適化されていない画像を生成することに気付きました。 これで何かする必要があります。 再び全能のGoogleに目を向けると、最良の選択肢はまだMozJPEGであることがわかります。 ここで、疑いが忍び込み始めます。Nodeにあったものと同じものをGoにのみ書きます。 しかし、MoZJPEGの説明を注意深く読んだ後、それがlibjpeg-turboのフォークであり、互換性があることがわかります。

とても有望に見えます。 事は小さい-独自のバージョンのLibvipsを構築するために、jpeg-turboがMozilaのバージョンに置き換えられます。 アセンブリには、Alpine Linuxを選択しました。 アプリケーションはDockerを使用して公開される予定であり、AlpineはArch Linuxで使用されるものと非常に似た非常に優れたパッケージ構成形式を持っています。

画像の最適化により、目に見える品質の低下なしにサイズが4倍に縮小されました。

元のJPEG 351x527 79 kb	最適化 351x527 17 Kb

収集、テスト済み。 Libvipsは、サイズ変更により最適化されたバージョンが提供されるとすぐに。 つまり、バージョンのNodeバージョンでは、最初にサイズを変更してから、デコーダーエンコーダーを介して再び画像を渡しました。 現在、サイズ変更のみを行っています。

JPEGと、pngの処理方法を理解しました。 この問題を解決するために、libpngquantライブラリが見つかりました。 それに基づいているコンソールユーティリティpngquantが多くのソリューションで使用されているという事実にもかかわらず、それはあまり人気がありません。 また、Goのバインディングが見つかりましたが、少し放棄され、メモリリークが発生したため、それを修正し、ドキュメントやその他の適切なプロジェクトにふさわしいすべてのものを追加する必要がありました。 また、簡単にインストールできるようにlibpngquantをAlpineパッケージとしてコンパイルしました。

pngquantを使用して処理するために画像をファイルに保存する必要がなくなったため、プロセスを少し最適化できます。 たとえば、Libvipsでサイズ変更するときは画像を圧縮せず、pngquantで処理した後にのみ圧縮します。 これにより、わずかに貴重なプロセッサ時間が節約されます。 言うまでもなく、Cライブラリの呼び出しはコンソールユーティリティの実行よりもはるかに高速であるため、大幅に節約できます。

サイズの違いは3倍ですが、アーティファクトが表示される場合があります（写真によって異なります）。

オリジナルPNG 450x300 200 Kb	最適化 450x300 61 Kb

圧縮中にアーティファクトが現れる、あまり良くない画像の例。

オリジナルPNG 351x527 270 kb	最適化 351x527 40 Kb

プロトタイプを作成し、PCでテストし、モバイル2核プロセスで適切な25 RPSを実行し、CPU全体を消費した後、通常のハードウェアでどれだけ絞り出すことができるかを確認したいと思いました。 コードを6台の核機で実行し、JmeterとWTFを設定します??? 30 RPSを取得します。 私たちはどのようなゴミを見つけようとしています。

Libvips自体はマルチスレッドを実装しています。つまり、ライブラリを初期化するだけでよく、将来はどのストリームからでも安全にアクセスできます。 しかし、何らかの理由でLibvipsは1つのスレッドで機能するため、1つのコアに制限されます。 もう1つのコアはpngquantです。 合計すると、当社の超高速リサイザーは開発者のラップトップでのみ完全に機能し、他のマシンではすべてのリソースを利用できないことがわかります。 ;）

Libvipsのソースコードを見ると、Libvipsのデータ競合により、CONCURRENCYがデフォルトで1に設定されていることがわかります。 しかし、バグトラッカーによると、これらの問題は長い間修正されています。 CONCURRENCYを戻し、テストします。 何も変わっていませんが、Libvipsはまだマルチスレッド化された画像のサイズ変更を拒否しました。 この問題を克服しようとする試みはすべて失敗し、実を言うと、私はそれを解決することにうんざりし、別のレベルで問題を回避することにしました。

多かれ少なかれ最新のLinuxカーネル（CentOS 6では3.9+および2.6.32-417 +）はすべて、SO_REUSEオプションをサポートしています。これにより、アプリケーションの複数のインスタンスが同じポートを使用できます。 このアプローチは、HAProxyなどのサードパーティソフトウェアとのバランスを取るよりも便利です。 設定は不要で、インスタンスをすばやく追加および削除できます。
そのため、Docker composeでSO_REUSEおよび「--scale」オプションを使用しました。これにより、実行するインスタンスの数を指定できます。

測定する時間

私たちの労働の結果を評価する時が来ました。

構成：

• CPU：Intel Xeon E5-1650 v3 @ 3.50GHz 6コア（12 vCPU）
• RAM：64 Gb（約1-2 Gbを使用）
• 労働者数：12

結果：

ファイル	出力解像度	ノードRPS	Go rps
bird_1920x1279.jpg	800x533	34	73
clock_1280x853.jpg	400x267	69	206
clock_6000x4000.jpg	4000x2667	1.9	5.6
fireworks_640x426.jpg	100x67	114	532
cc_705x453.png	405x260	21	33
penguin_380x793.png	280x584	28	69
wine_800x800.png	600x600	27	49
wine_800x800.png	200x200	55	114

Wikiページでのより多くのベンチマーク（ノードバージョンとの比較はありませんが）。
ご覧のとおり、サイズ変更を無駄にやり直すことはありませんでした。速度の増加は30から400％でした（場合によっては）。 さらに高速にサイズ変更する必要がある場合は、libimagequantの「速度」および「品質」ノブを回すことができます。 サイズをさらに小さくしたり、画質を犠牲にしてエンコード速度を上げたりできます。

GitHubプロジェクトコード。
GitHubでもlibimagequantにバインドします 。