このページは Cloud Translation API によって翻訳されました。

2019 年夏の画像最適化アンケートに関するフィードバック

さまざまな画像最適化手法に関するアンケート回答者のコメント

Sam Dutton

この投稿では、Google Web DevRel が 2019 年夏に実施した画像最適化手法に関するアンケートで寄せられた自由形式のフィードバックを紹介します。ウェブの基本と @ChromiumDev で回答を募集しました。この調査の目的は、パフォーマンスを向上させる比較的簡単な方法であるにもかかわらず、ほとんどのサイトが画像の最適化のベストプラクティスに従っていない理由を探ることでした。アンケート手法に欠陥があったため、回答データはここに記載されていません。

オーディエンス

ウェブデベロッパーの方は、新しい画像最適化手法の検討や、他のウェブデベロッパーが直面した問題をどのように解決したかの詳細、各手法の費用、メリット、制限事項の確認に、この投稿が役立つかもしれません。
画像サービスまたは画像 CDN プロバイダである場合は、この投稿が新しい市場機会を見つけるのに役立つ可能性があります。
フレームワーク、ビルドツール、CMS のデベロッパーは、この投稿で実装する新しい機能のアイデアを得ることができます。

WebP

「WebP は良いのですが、まだ完全には準備ができていません。また、Google の WordPress は WebP に対応していません。最も人気のある写真編集アプリの 1 つである Photoshop も、WebP をデフォルトでサポートしていません。そのため、サードパーティ製のアプリやサービスを使用して画像を圧縮することはできません。」
「Safari で WebP を使用可能にします。」
「Photoshop/Figma/Sketch から書き出して、すべてのブラウザでサポートされているなら、WebP を使いたい。」[注: Sketch は WebP をサポートしています]
「次世代のフォーマットソリューションが欲しい。」
「ブラウザのサポートが不十分な場合は WebP の使用を控え、スクリーンショットには JPEG ではなく PNG を使用することを検討してください。」
「Google ドキュメントは WebP に対応していません。」
「WebP のみを使用したいのですが、ブラウザの互換性が懸念されます。」
「まずブラウザの互換性を修正し、以前のブラウザを更新するか、以前の修正を追加してください。そうすれば、WebP などの新しい画像形式をユーザーが採用しやすくなります。」
「デベロッパー以外のユーザーが設定を変更しなくても済むように、プラグイン/テーマのデベロッパーに WebP などの次世代画像形式のサポートを提供することをおすすめします。」

SVG とベクター画像

「可能であれば、（アニメーション化された）SVG を使用しています。gatsby-image によってこの問題の多くは修正されました。しかし、彼らが行ったことを詳しく調べてみると、通常のウェブサイトで画像を正しく機能させるために、そのようなものを構築しなければならないというのは、まったく現実的ではありません。ブラウザがこの責任をより多く負うべきです。」
「lottie.js で SVG アニメーションを作成する方法を記載してもらえますか？」
「読み込み時間を短縮するため、ほとんどの場合、ウェブサイトではサイズの小さい高解像度の JPEG 画像を使用しています。また、必要に応じて SVG を使用して、レスポンシブデザインの品質を確保しています。」
「可能な限り、写真以外には最適化されたベクターグラフィックを使用しています。」

その他の画像形式

「GIF の使用を止めるよう、ユーザーに適切に教育する必要があります。」

遅延読み込み

「遅延読み込みなどの機能を検討する際は、多くのユーザーにとって煩わしいものであるため、ユーザーのことを念頭に置いてください。」
「遅延読み込み属性を background-image で動作するようにしてください。」
「フレームワークは、すぐに使える状態でアセット処理を改善する必要があります。」
「弊社は、以前に遅延読み込みから切り替えました。数百万もの画像とサイトが「読み込まれない」という報告がユーザーから寄せられています。これが、Google のチームがまとめた内容です。技術に詳しくないユーザーは問題を説明するのが難しい。」
「従来の手法ではなく、Intersection Observer API を使用して遅延読み込みを行う方法を詳しく理解したい。」
「pwafire.org/developer/codelabs/progressive-loading はうまく機能します。」

背景画像

「通常は CSS で画像を背景として読み込みます。」
「<img> タグは問題があり、特にユーザーが送信したコンテンツでは細かい詳細を制御するのが困難です。<div> と background-image スタイルは、background-size や background-position を使用でき、画像の右クリック保存を防ぐことができるため、より頻繁に使用しています。」

透明性

「2019 年です。JPG にアルファ透明度がないのはなぜですか？」
「写真の PNG は、背景が透明な場合にのみ使用します。」

低画質の画像プレースホルダ（LQIP）

「LQIPS は、高画質の画像を最初から読み込まずに、訪問者の関心を維持するのに最適な手法です。」

パフォーマンス

「最近、画像に関するパフォーマンスの問題が発生しました。ユーザーがサイトを下にスクロールすると、サムネイルを含む次の 60 枚のカードが表示されます。同じドメインでの接続上限が 6 件であるため、サムネイルと、ユーザーが下にスクロールし続けた場合に次の 60 個のカードを取得するための次の AJAX リクエストがブロックされていました。」
「HTTP/2 はぜひ使いたいのですが、ほとんどのお客様が IE11 を使用しています。そのため、ドメインシャーディングや、別のドメインから AJAX JSON データリクエストを読み込む方法を検討しています。」

サイズ

「intrinsicsize については申し訳ございません。height と width を使用することをおすすめします。」
「サイズを減らす方法を探しています。現在は 12 個ほどです。」
「画像の動的サイズ変更は非常に難しく、JS なしでは不可能です。」
「responsivebreakpoints.com などのツールは web.dev に適しています。」

高画質で高解像度の画像

「DPI の画質を損なうことなく画像を圧縮してダウンロードするにはどうすればよいですか？」
「弊社はドキュメント管理会社です。当社のアプリは、数百万もの高解像度スキャン画像（通常は TIFF または PDF）を処理します。」
「面倒です。印刷フォーマットには高解像度の画像ファイルが必要です。ウェブ用に最適化する必要があります。ウェブ用に画像をサイズダウンするのは手間がかかりますが、著者が印刷出版向けの画像に軽量なファイルしか提供していない場合は、公開できません。そのため、アートワークを含む原稿の送信要件について、混乱が生じてしまいます。そのため、素材を処理するための複雑なワークフローが生まれます。」

ブラウザの機能

「すべての画像を 4 つのサイズに切り抜き、すべてのマークアップを記述するのは時間がかかるため、ブラウザからの自動レスポンシブ src 切り抜きを [組み込み] 機能として追加すると非常に便利です。大きな写真を 1 枚アップロードして、シンプルな picture タグを記述すると、ブラウザが複数の src 属性を自動的に作成してくれる機能が便利です。」
「個人的には、レスポンシブ画像の CSS で画像の幅が設定されている場合（max-width: 100%; height auto または height: width: 100%; height auto）、特にアダプティブ画像/picture タグのアートディレクションと組み合わせると、ページの再読み込みを回避するのが難しいです。これを回避する最善の方法は、固定の画像比率に「ネガティブパディングハック」を使用し、この比率のボックス内に画像を配置することです。ブラウザのサポートやレスポンシブ画像の処理が改善されると、非常に助かります。」
「最初のフレームのみ取得して、GIF の自動再生を無効にしてください。」

CDN と画像サービス

「Google は Cloudflare のような無料の CDN を提供すべきだ。」
「動的スケーリングとさまざまなプロバイダの CDN を設定するためのツールを増やしてほしい。」
「サイズが大きく圧縮率が高い単一の画像は、追加の制作費用をかけずに非常に優れたソリューションです。モバイル用には幅 1,000 ピクセル程度の画像（レンダリング幅 500 ピクセル）が必要です。これは、大画面/デスクトップの非レチナディスプレイにも必要なサイズです。画像サイズ変更 CDN は、過去に使用したことがありますが、非常に悪いソリューションだと思います。CMS がサイズ変更を処理する必要がありますが、設定が複雑すぎる場合は、（現時点では）単一のソリューションが妥協案として適しています。」
「CloudFlare は、ユーザーのディスプレイに最適なサイズになるように画像を自動的にスケーリングします。画像はユーザーのディスプレイを基準に読み込まれるため、読み込み時間を短縮できます。たとえば、ユーザーがスマートフォンを使用している場合、デスクトップサイズの背景で読み込まれることはありません。」
「Cloudflare は、設定パネルでチェックボックスをオンにする以外に何もする必要なく、この処理をバックグラウンドで実行します。」
「繰り返しになりますが、srcset などを正常に使用できる唯一の理由は、Cloudinary の使いやすさです。しかし、Cloudinary は非常に急速に費用が増加します。これは、開発エクスペリエンスの大きな欠陥のように感じます。」
「さまざまなコンテキストで異なるアスペクト比で画像を扱えるように、画像をスマートに自動トリミングする方法が必要です。」
「Unsplash などの他の提供元の画像も使用していますが、解像度、品質、圧縮を制御する機能はほとんどありません。」

CMS、プラットフォーム、フレームワーク

「CMS を使用してサイトを構築する際に、画像を使用する最適な方法を見つけるのに苦労しています。作成者は、さまざまなサイズの画像を設定することが多く、画像が縮小または拡大されないことを想定しています。画像に max-width または max-height を設定してもよいかどうかわかりません」
「最近のプロジェクトでは gatsby-image を使っていますが、もう手放せません。」
「画像はエンドユーザーが CMS にアップロードするため、サイズや形式がさまざまです。また、理想的な画像形式やサイズの元の画像が使用されていないこともあります。」
「当社のシステムはセルフサービスであるため、画像の管理は困難です。解決に影響を与えることなく自動的に処理されない限り、制御を追加することは困難です。また、モバイルとパソコンで画像が正しく表示されない」
「私は、サイト（WordPress）の最適化をサポートしています。画像に関する最大の問題は、WebP を作成するために CDN またはプラグインに依存する必要があることです。srcset/picture は、テーマデベロッパーが適切にコーディングする必要があります。遅延読み込みプラグインのほとんどは読み込みが遅く、ユーザーエクスペリエンスが悪くなります。背景画像は遅延読み込みが難しい。」

費用対効果

「新しい手法は効果的ですが、サイトの開発時間が長くなります。」
「srcset や WebP などの新しい標準に準拠していないため、多くの Fortune 500 企業で導入が遅れています。多くの企業は、現在のウェブサイトに不要な開発コストがかかるとして、この変更に抵抗してきました。パフォーマンスの向上は、エンドユーザー（UX）から広く議論されたり報告されたりしていない。むしろ、ウェブから画像を保存するのがやや難しくなります。」
「複数のサイズやバージョンを作成、管理するのはコストがかかる。」
「サーバーの容量を大量に消費します。」

SEO

「許容できる画像品質とファイルサイズのバランスを取るのは難しい。一方で、SEO のメリットのために読み込みを速くしたい一方で、画質の悪い画像は UI/UX を損なうことになります。」

ウェブでの画像の役割

「ウェブ上には数え切れないほどあります。文章のコンテンツを補完しない無駄な画像の使用を止めてください。」
「ウェブに画像がなく、自撮りを ASCII アートとして共有していた時代を覚えていますか？」

ツール、ガイダンス、標準、ベストプラクティス: 不満とリクエスト

[1 人の参加者が、このアンケートに応えてブログ投稿を作成しました]
「要件は絶えず変更されているようです。ウェブデベロッパーとしては、画像を保存するだけで時間がかかるため、非常にイライラします。最適化を最大限に進め、サイトを確認した後、数か月後に Google が画像をさらに圧縮できる、または別の形式に変更する必要があると判断することがあります。これにより、Google はお客様に長期にわたる最適なソリューションを提供できず、お客様と Google の双方に費用のかかる作業が発生します。小規模ビジネスのクライアントの中には、要件を満たすために画像を修正して再保存し続ける予算がない場合があります。管理パッケージ内でこの作業を行う予算はありません。デバイスごとに異なる画像サイズを呼び出すコードを記述するのも時間がかかります。長期にわたって一貫した画像を保存するシステムを構築できればと思います。」
「はい、Lighthouse の [リクエスト数を少なく、ファイルサイズを小さく維持してください] が間違っていると思います。サイトが HTTP1.x で提供されている場合は問題ありませんが、HTTP2 で提供されている場合は、リクエストの数は重要ではなく、同じホスト名から送信された場合でも問題になりません。ライトウェイトのウェブサイトですが、同じホスト名で HTTP2 経由で 30 個の小さな WebP ファイルを読み込み、合計で約 35 件のリクエストが発生しています。Lighthouse では、この問題が「リクエスト数を少なくしてファイルサイズを小さくする」問題として報告されていますが、このページは非常に高速で、同じホスト名の HTTP2 を使用しているため、リクエスト数は問題ではありません。ファイルはすでに小さく（ほとんどが 1 KB ～ 2 KB 以下）、スプライトを読み込むことはできますが、その場合は CSS の計算がさらに必要になります。そのため、Lighthouse の「リクエスト数を少なく、転送サイズを小さく維持してください」レポートを更新して、同じホスト名を介した HTTP2 を検出するようにしてください。」
「画像を圧縮することを忘れてしまうことがよくありました。」
「クロスブラウザの動作は予測できないため、最もシンプルなソリューションが最も安全な場合が多い。」