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

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

この投稿では、Google Web DevRel が 2019 年夏の画像最適化手法に関するアンケートで寄せられた自由形式のフィードバックを紹介します。回答は Web Fundamentals@ChromiumDev を通じて募集しました。この調査は、パフォーマンスの改善が比較的簡単な方法のように見えても、多くのサイトが画像最適化のベスト プラクティスに従っていない理由を探ることを目的としています。アンケート方法に欠陥があるため、回答データはここに記載されていません。

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

コメント

WebP

  • 「WebP は好きですが、まだ準備ができていません。また、WordPress は WebP をサポートしていません。また、最も人気のある写真編集アプリの 1 つである Photoshop も、WebP をサポートしていません。そのため、画像圧縮についてサードパーティ製のアプリやサービスに頼ることはできません。」
  • 「Safari で WebP を使用可能にします。」
  • 「WebP を Photoshop/Figma/Draw からエクスポートでき、サポートされているすべてのブラウザでエクスポートできるのなら、ぜひ使いたいです。」[注: スケッチは WebP に対応しています]
  • 「次世代のフォーマット ソリューションは素晴らしいと思います。」
  • "ブラウザ サポートが不十分な場合は、WebP を一気に push するのをやめ、スクリーンショットには JPEG ではなく PNG を使用する必要があることを検討してください。"
  • 「Google ドキュメントは WebP に対応していません。」
  • 「WebP のみを使用しますが、ブラウザの互換性に懸念があります。」
  • 「まずブラウザの互換性を修正し、従来のブラウザを更新するか、以前の修正を加えると、ユーザーは WebP のような新しい画像形式を採用する可能性が高くなります。」
  • "プラグインやテーマのデベロッパーに対し、WebP やその他の次世代の画像タイプへのサポートの提供を検討することを奨励し、開発者でなくても操作する必要がないようにします。」

SVG 画像とベクター画像

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

その他の画像形式

  • 「GIF の使用をやめるように、より良い教育を行う [必要があります]。」

遅延読み込み

  • 「遅延読み込みなどの機能を検討する際は、ユーザーのことを念頭に置いてください。遅延読み込みは多くのユーザーにとって煩わしいものです。」
  • "遅延読み込み属性を背景画像で機能させてください。"
  • "フレームワークでは、アセットをすぐに処理できる必要があります。"
  • 「私たちはかなり前に、遅延読み込みから変換しました。何百万もの画像やサイトが「読み込まれない」という報告がユーザーから寄せられました。チームが要約したように理解できたからです。技術者以外のユーザーが問題を説明するのは難しいです。」
  • 「従来の手法ではなく、Intersection Observer API を使用して遅延読み込みを行う方法について、詳しく学びたいと思います。」
  • 「これはうまくいっています: pwafire.org/developer/codelabs/progressive-loading

背景画像

  • 「通常は CSS で画像を背景として読み込みます。」
  • <img> タグには問題があり、特にユーザーが送信したコンテンツでは、詳細を制御するのが困難です。当社では <div> と背景画像のスタイル設定をよく使用しています。なぜなら、背景のサイズや背景の位置を指定でき、画像を右クリックして保存されないようにもできるからです。」

透明性

  • 「2019 年です。アルファ透明がない状態のまま JPG になるのはどうしてですか?
  • 「透明な背景が必要な場合にのみ、写真に PNG を使用します。」

低品質画像プレースホルダ(LQIP)

  • 「当社では LQIPS を利用しています。これは、高品質の画像をすばやく読み込むことなく、訪問者のエンゲージメントを維持できる優れた手法です。」

パフォーマンス

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

サイズ設定

  • 「本質的なサイズでごめんなさい。高さと幅を活用する方が良さそうな気がする。」
  • 「サイズを小さくする方法を探しています。現時点では 12 個までです。」
  • 「画像の動的なサイズ変更は、JS なしでは非常に難しく、不可能です。」
  • 「web.dev には responsivebreakpoints.com のようなツールが適しています。」

高画質かつ高解像度の画像

  • 「DPI の画質を損なわずに圧縮画像をダウンロードする方法は?」
  • 「私たちはドキュメント管理会社です。Google のアプリは数百万点の高解像度スキャン画像(通常は TIFF または PDF)を処理しています。」
  • 「面倒だ。印刷フォーマットには高解像度の画像ファイルが必要です。ウェブ用に最適化する必要があります。ウェブ用に画像を縮小するのは面倒な作業ですが、著者が印刷媒体で公開する画像用の軽量ファイルのみを提供している場合は、非常に手間がかかります。アートワーク付き原稿の提出の要件について、さまざまな内容のメッセージが投稿されます。結局、こうした資料を処理するための複雑なワークフローが生まれます。」

ブラウザ機能

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

CDN と画像サービス

  • 「Google は Cloudflare のような無料の CDN を提供すべきです」
  • 「動的スケーリングと、さまざまなプロバイダで CDN を設定するためのツールが増えるのではないでしょうか。」
  • 「オーバー圧縮された 1 枚の画像が、追加の制作費用なしで非常に優れたソリューションです。モバイルでは約 1,000 ピクセル幅の画像(500 ピクセルのレンダリング幅)が必要です。これは、Retina 以外の大型ディスプレイやデスクトップで必要なサイズです。画像サイズ変更 CDN は、私は以前使っていましたが、非常に悪いソリューションだと思います。サイズ変更の処理は CMS 側で行いますが、設定が複雑すぎるため、現時点では 1 つのソリューションで対応することをおすすめします。」
  • 「CloudFlare は、ユーザーのディスプレイに合わせて画像を自動スケーリングします。画像はユーザーのディスプレイを基準にして読み込まれるため、読み込み時間を短縮できます。たとえば、ユーザーがスマートフォンを使用している場合、デスクトップ サイズの背景では読み込まれません。」
  • 「Cloudflare はこの処理をバックグラウンドで行うので、設定パネルのボックスをオンにするだけで済みます。」
  • 「繰り返しになりますが、srcset などをうまく使える唯一の理由は、Cloudinary の使いやすさです。しかし、Cloudinary は高価で、本当に迅速です。これは開発エクスペリエンスにおける大きな穴のように感じます。」
  • 「さまざまな状況でさまざまなアスペクト比で作業できるように、画像をスマートに自動切り抜く方法が必要です。」
  • 「Unsplash など、解像度、画質、圧縮のコントロールが非常に少ない他のプロバイダの画像も使用しています。」

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

  • 「CMS を使ってサイトを構築しているときに、画像の最適な使い方を見つけるのにいまだに苦労しています。作成者は、さまざまなサイズの画像を設定する傾向があり、画像が縮小または拡大しないことを期待しています。画像に max-width や max-height を設定しても問題ないかどうかわかりません」
  • 「過去数件のプロジェクトでギャツビー イメージを使用してきましたが、過去に一度も見直したことがありません。」
  • 「エンドユーザーが CMS に取り込むのは画像で、サイズや形式が自由で、理想的な画像形式や寸法のオリジナル画像がない場合もあります。」
  • 「当社のシステムはセルフサービス方式であるため、画像の管理が困難です。解像度に影響を与えずに自動的に処理が行われない限り、コントロールを追加するのは困難です。当社では、モバイルとパソコンでは画像が正しく表示されません。」
  • 「サイト(WordPress)の最適化のお手伝いをしています。画像に関して遭遇した最大の問題は、WebP を作成するために CDN やプラグインに依存する必要があること、srcset/picture はテーマのデベロッパーによって適切にコーディングする必要があることです。ほとんどの遅延読み込みプラグインは読み込みが遅く、UX に悪影響を及ぼします。背景画像を遅延読み込みするのは難しいです。"

費用/メリット

  • 「新しい手法は効果的ですが、サイトの開発時間が長くなります。」
  • 「srcset や WebP といった新しい標準への準拠の欠如は、多くの Fortune 500 企業による採用が遅れています。これを見て、多くの企業は、現在のウェブサイトの不必要な開発コストとして、変化に抵抗しています。パフォーマンスの向上については、エンドユーザー(UX)から広く議論または報告されていません。そういうと、ウェブから画像を保存するのがやや難しくなります。」
  • 「複数のサイズやバージョンを作成して管理するのに費用がかかる」
  • 「これらはサーバー上で多くのスペースを占めます。」

SEO

  • 「許容可能な画質とファイルサイズのバランスを取るのは困難です。SEO のメリットのために読み込みを高速化したい一方で、低品質の画像は UI/UX の低下につながります。」

ウェブ上の画像の役割

  • 「ウェブ上には膨大な情報があります。書いたコンテンツを充実させない、役に立たない画像の使用はやめてください。」
  • 「ウェブには画像がなく、自撮り写真を ASCII アートとして共有していたときのことを覚えていますか?」

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

  • [1 人の参加者がこのアンケートに対するブログ投稿を書いた]
  • 「要件は常に変化しているようです。そもそも画像を保存するのには時間がかかるため、ウェブ デベロッパーにとって非常にイライラします。可能な限り最適化を行い、サイトを確認してから数か月後、Google は画像の圧縮率をさらに高めるか、別の形式にする必要性があると判断しました。これが原因で、持続性のある最善のソリューションをお客様に提供することができず、むしろクライアントと私たちに多額の費用がかかることになります。小規模ビジネスのクライアントの中には、要件を満たすために画像を修正し、画像を再保存する予算がありません。管理パッケージ内でこの作業を行うための予算がありません。デバイスごとに異なる画像サイズを呼び出すコードを記述するのにも時間がかかります。長期にわたって整合性が保たれる画像を保存するシステムを考え出せば素晴らしいと思いませんか。」
  • 「はい、Lighthouse の「Keep Request Counts Low And File Sizes Small」は間違っていたようです。サイトが HTTP1.x で配信されている場合はもちろん可能ですが、HTTP2 で配信する場合は、同じホスト名から送信されるリクエストの数は重要ではなく、問題にはなりません。私は Lite ウェブサイトを持っていますが、同じホスト名で HTTP2 を介して、合計約 35 リクエストの小さな WebP ファイルを 30 個読み込みます。Lighthouse では、これを「Keep Request Counts Low And File Sizes Small」の問題として報告していますが、これは非常に高速であり、同じホスト名で HTTP2 を使用しているため、リクエスト数は問題ではありません。しかも、ファイルはすでにサイズが小さくなっています(ほとんどの場合、1 KB から 2 KB 以下)。スプライトを読み込むことはできますが、さらに CSS 計算を行う必要があります。そのため、同じホスト名に対する HTTP2 を考慮に入れるよう、Lighthouse の「Keep Request Counts Low And File Sizes Small」レポートを更新してください。
  • 「ユーザーが画像を圧縮するのを覚えるのに苦労しています。」
  • 「ブラウザをまたいだ動作は依然として予測不可能であるため、多くの場合、最もシンプルなソリューションが最も安全です。」