アップロードなし, 100%ローカル, アカウントなし

記事

サイトのメディアを速度と Core Web Vitals のために最適化する

画像は通常、ウェブページの総容量の約40パーセントを占め、他のどのリソース種別よりも多く、メディアを多用するページでは動画がさらに大きく加わります。これを正しく扱うことが、読み込み速度、Core Web Vitals のスコア、検索順位に対してできる最も効果の高い一手です。良い知らせは、どれも専用ソフトやサーバーを必要とせず、ファイルが端末を離れる必要もないことです。

何よりもまず正しい形式を選ぶ

形式の選択は、どんな品質スライダーよりも重要です。ウェブページの写真には WebP が適した既定値です。同じ見た目の品質で JPEG より25~35パーセント小さく、現代のあらゆるブラウザが対応しています。AVIF はさらに進んで JPEG より最大50パーセント優れた圧縮をしますが、エンコードが遅くなります。一度だけ圧縮するヒーロー画像や商品写真には AVIF を、バッチ処理するものや素早く必要なものには WebP を使いましょう。PNG は可逆の精度や透過背景が必要な場合にのみ向いています。ロゴ、アイコン、イラストには SVG が唯一の理にかなった選択肢です。あらゆるサイズに拡大縮小でき、ラスター化した同等品が数百キロバイトになるところを数キロバイトで済むことも多いからです。

見た目の画質を落とさずに画像を圧縮する

まずは実際の表示寸法にリサイズしましょう。横1280ピクセルで表示されるヒーロー画像に4000ピクセル分のデータは要りません。先にリサイズし、その後で圧縮します。写真では WebP や JPEG の品質80が、一般的な閲覧者が違いに気づき始める現実的な下限なので、75~85を狙い、公開前に最大ズームで出力を確認しましょう。文字や単色のベタ塗りを含むグラフィックには、非可逆形式がにじませてしまう鋭さを PNG 可逆や SVG が保ちます。このサイトの画像圧縮ツールはこれらすべての形式を扱い、完全にブラウザ内で動作し、専用のデスクトップツールと同じアルゴリズムを適用します。

動画をアップロードせずにウェブ向けに変換する

背景ループや埋め込み動画は、ウェブメディアの最適化が見落とされがちな場所です。H.264 の MP4 はどこでも再生できますが、WebM はあらゆる最新ブラウザがサポートするロイヤリティフリーの代替形式です。このサイトの動画コンバーターは WebM を VP8 でエンコードします。VP8 は H.264 と同じ圧縮クラスに属するため、コンテナを切り替えるだけではファイルは小さくなりません。得られる本当の利点は、完全にロイヤリティフリーなコーデックチェーンと、アルファチャンネルのネイティブサポートです。現実的な進め方は、一度 WebM に変換し、video 要素で優先ソースとして配信し、古いブラウザ向けに MP4 をフォールバックとして残すことです。変換は WebAssembly にコンパイルした FFmpeg によりブラウザ内で実行され、何もアップロードされず、500 MBまでのファイルなら待ち行列なしで変換できます。インラインの背景動画には、エンコード前に無駄な秒を切り落とす動画トリマーも検討しましょう。再生時間こそファイルサイズを最も左右する要因です。

インラインのアセット: base64 と SVG

ごく小さな画像、アイコン、ファビコンを base64 文字列として HTML や CSS に直接埋め込むと、アセットごとに1往復のネットワーク通信を省けます。これはロゴのスプライトや読み込みインジケーターのように、すべてのページに現れる約2KB未満のアセットに向いています。base64 はバイナリより33パーセント大きくエンコードされ、ブラウザはファイル参照はキャッシュしてもインラインデータは独立してキャッシュしないため、より大きなアセットは別ファイルのままにすべきです。SVG 最適化ツールは、書き出された SVG から見た目の出力に触れずにエディター由来の不要な記述を取り除きます。画像から base64 への変換ツールは、貼り付ければすぐ使えるデータ URI をブラウザ内で生成します。

追加のHTTPリクエストが必要な別ファイルのキャッシュと、約33%大きく各ページで再送されるBase64インラインアセットとの間のトレードオフ

適切なサイズで配信し、優先して読み込む

ファイル自体と同じくらい重要な配信の詳細が2つあります。1つ目はレスポンシブサイジングです。幅ディスクリプタのsrcsetリスト(image-400.webp 400w、image-800.webp 800w など)を使うと、ブラウザはCSSの幅にデバイスピクセル比(device pixel ratio)を掛けた値を計算してからリクエストを送り、画面をカバーできる最小のファイルを選択します。レイアウト幅が390pxで3xのスクリーンを持つスマートフォンは、約1170ピクセルが必要なため、1200wのバージョンを取得し、デスクトップ用のオリジナルはスキップします。2つ目は優先度の設定です。ブラウザはプリロードスキャナー(preload scanner)を実行して先読みし、メインパーサーが処理する前から画像のダウンロードを開始します。最も大きなファースト・ビュー(above-the-fold)の画像にfetchpriority="high"を追加すると、ブラウザにその画像を最初に取得するよう指示でき、通常これがLargest Contentful Paintを決定する要因となります。

4000ピクセルのカメラ原寸、レイアウトが使用する1200ピクセルサイズ、480ピクセルのサムネイルを比較する棒グラフ。リサイズが画質設定より容量を削減することを示す

この記事で紹介するツール

よくある質問

画像の圧縮は検索順位に影響しますか?

Google は Core Web Vitals を順位付けのシグナルとして使っており、Largest Contentful Paint はほとんどの場合、画像か動画のポスターです。ヒーロー画像が1秒未満で読み込まれるページは、3秒かかるページより良いスコアになります。圧縮と正しい形式はこの指標に直接影響するので、画像の最適化には測定可能な SEO 効果があります。効果が最も大きいのはモバイルで、回線が遅く、重い画像のペナルティも大きくなります。

ウェブサービスではなくローカルでメディアを処理する理由は?

ほとんどのオンラインメディアツールは、ファイルをリモートサーバーにアップロードする必要があり、時間がかかり、帯域を消費し、自分の管理外のインフラにファイルのコピーが存在することを意味します。このサイトのツールは完全にブラウザ内で動作します。画像も動画も端末上で処理され、出力は直接ダウンロードされます。アカウントもアップロードの待ち時間もなく、ファイルに関するものがサーバーに送られることは一切ありません。