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

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

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

オーディエンス

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

コメント

WebP

  • 「WebP は気に入っていますが、まだ完全には準備が整っていません。また、WordPress は WebP をサポートしていません。最も人気のある写真編集アプリの一つである 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 で機能させてください。」
  • 「フレームワークは、すぐに使えるアセット処理をより適切に行う必要があります。」
  • 「遅延読み込みから変換したのはずっと前のことです。数百万の画像やサイトが「読み込まれない」というユーザーからの報告。チームは、そのように理解していました。技術的な知識のないユーザーが問題を説明するのは困難です。」
  • 「従来の技術ではなく、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 は申し訳ありません。高さ / 幅を活用する方が良いと思います。」
  • 「生成するサイズを減らす方法を探しています。現在は 12 種類ほどです。」
  • 「画像の動的なサイズ変更は非常に難しく、JS なしでは不可能です。」
  • 「responsivebreakpoints.com のようなツールは web.dev に適しています。」

高画質で高解像度の画像

  • 「DPI 品質を損なわずに圧縮画像をダウンロードする方法」
  • 「当社はドキュメント管理会社です。当社のアプリは、通常は TIFF または PDF 形式の、数百万もの高解像度スキャン画像を処理します。」
  • 「面倒です。印刷形式には高解像度の画像ファイルが必要ですが、ウェブ用に最適化する必要があります。ウェブ用に画像のサイズを小さくするのは面倒ですが、著者が印刷用の画像に軽量なファイルしか提供しない場合は、大きな問題となります。アートワークを含む原稿の提出要件について、一貫性のないメッセージを伝えてしまうことになります。その結果、それらの素材を処理するための複雑なワークフローが必要になります。」

ブラウザの機能

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

CDN と画像サービス

  • 「Google は Cloudflare のような無料の CDN を提供すべきです。」
  • 「動的スケーリングと CDN をさまざまなプロバイダで設定するためのツールがもっとあればよいと思います。」
  • 「1 つの特大の過圧縮画像は、追加の制作コストがかからない非常に優れたソリューションです。モバイル(レンダリング幅 500 ピクセル)には幅 1,000 ピクセル程度の画像が必要で、これは大型 / デスクトップの非 Retina ディスプレイに必要なサイズでもあります。画像のサイズ変更 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 を損ないます。」

ウェブにおける画像の役割

  • 「ウェブ上には多すぎる。テキスト コンテンツを補完しない無駄な画像の使用をやめる。」
  • 「ウェブに画像がなく、自撮り写真をアスキーアートとして共有していた頃を覚えていますか?」

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

  • [ある参加者は、このアンケートに回答するブログ投稿を執筆しました]
  • 「要件は常に変化しているようです。ウェブ デベロッパーとしては、画像を保存するのに時間がかかるため、非常に不満を感じています。できる限り最適化し、サイトをチェックしても、数か月後に Google は画像をさらに圧縮できる、または別の形式にする必要があると判断します。これでは、クライアントに最適なソリューションを継続的に提供できず、クライアントと Google の双方にとってコストのかかる取り組みになってしまいます。小規模ビジネスのお客様の中には、要件に準拠するために画像を修正して再保存し続ける予算がないというお客様もいらっしゃいます。管理パッケージ内でこの作業を行う予算がありません。また、デバイスごとに異なる画像サイズを呼び出すコードを記述するのも時間がかかります。長期間にわたって一貫性を保てるような、画像を保存するシステムを考案できれば素晴らしいと思います。」
  • 「はい、Lighthouse の『リクエスト数を少なく、ファイルサイズを小さく保つ』を完全に誤解していると思います。サイトが HTTP1.x で提供されている場合は、確かにリクエスト数が重要になります。しかし、サイトが HTTP2 で提供されている場合は、リクエスト数はそれほど重要ではなく、同じホスト名から送信されている場合は問題になりません。軽量なウェブサイトを運営していますが、同じホスト名で HTTP2 を介して、合計約 35 件のリクエストのうち 30 件の小さな WebP ファイルを読み込んでいます。Lighthouse は、これを「リクエスト数を少なく、ファイルサイズを小さくする」問題としてフラグを立てていますが、これは非常に高速であり、同じホスト名での HTTP2 のため、リクエスト数は問題になりません。ファイルはすでに小さくなっています(ほとんどが 1 KB ~ 2 KB 以下)。スプライトを読み込むことはできますが、その場合は CSS の計算をさらに行う必要があります。そのため、Lighthouse の「リクエスト数を少なく、ファイルサイズを小さく保つ」レポートを更新して、同じホスト名での HTTP2 を考慮するようにしてください。」
  • 「画像を圧縮することを忘れないようにするのは、人々にとって大変なことでした。」
  • 「クロスブラウザの動作は予測できないため、最もシンプルなソリューションが最も安全な場合が多い。」