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

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

アンケート回答者からの各種画像最適化手法についてのコメント

Sam Dutton

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

対象読者

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

WebP

「WebP は気に入っていますが、まだ準備ができていません。さらに、WordPress は WebP をサポートしていません。最も人気のある写真編集アプリの一つである Photoshop も、WebP もサポートしていません。そのため、画像圧縮にサードパーティ製のアプリやサービスに頼ることはできません。」
「Safari で WebP を使用できるようにします。」
「Photoshop/Figma/Sketch から WebP をエクスポートでき、すべてのブラウザで WebP がサポートされていれば、WebP を使用したいと思います。」[注: スケッチは WebP をサポートしています]
「次世代のフォーマットソリューションが良さそうです。」
「ブラウザサポートが十分でないときは、WebP を極力押しやるのをやめて、スクリーンショットには JPEG ではなく PNG を使用する必要があると考えてください。」
「Google ドキュメントは WebP に対応していません。」
「WebP のみを使用しますが、ブラウザの互換性が心配です。」
「まず、ブラウザの互換性を修正し、従来のブラウザを更新するか、以前の修正を追加すれば、ユーザーは WebP などの新しい画像タイプを採用するようになります...」
「プラグインやテーマのデベロッパーに、WebP やその他の次世代イメージタイプのサポートを提供することを検討し、デベロッパーでなくても大丈夫です。」

SVG とベクター画像

「可能であれば、（アニメーション化された）SVG を使っています。gatsby-image でこの問題は解決しました。しかし、彼らの手口を掘り下げてみると、通常のウェブサイトで画像を正しく機能させるために、このようなものを構築しなければならないというのは、まったく非現実的です。ブラウザはこの役割の多くを担うべきです。」
「lottie.js を使って SVG アニメーションを作成する方法を文書化してもらえますか？」
「当社のウェブサイトでは、読み込み時間を避けるために、たいていの場合、小さなサイズの高解像度の JPEG 画像を使用するよう努めています。また、レスポンシブデザインの品質を確保するために、必要に応じて SVG を使用するようにしています。」
「可能な限り、写真以外のすべての画像に最適化されたベクターグラフィックを使用するよう努めています。」

その他の画像形式

「GIF の使用をやめるよう、もっとよく教育する [必要]。」

遅延読み込み

「遅延読み込みなどの機能を検討する際は、ユーザーのことを念頭に置いてください。遅延読み込みなどの機能はユーザーにとって煩わしいものが多いためです。」
"遅延読み込み属性を背景画像で機能させてください。"
「フレームワークでは、導入後すぐにアセットの処理が改善されます。」
「当社はずいぶん前に遅延読み込みから移行しました。何百万もの画像やサイトが「NOT LOADING」とユーザーから報告されています。チームが要約すると、技術者以外のユーザーが問題を説明するのは難しいことです。」
「私は、従来の手法ではなく、Intersection Observer API を使用して遅延読み込みを行う方法について理解を深めたいと考えています。」
「pwafire.org/developer/codelabs/progressive-loading はとても役に立っています。」

背景画像

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

透明性

「2019 年です。JPG にアルファ透明度がないのはどうしてですか？」
「私は透明な背景が必要なときだけ、写真に PNG を使用します。」

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

「当社では LQIPS を使用しています。高品質の画像を早い段階で読み込むことなく、訪問者のエンゲージメントを維持できる優れた技術です。」

パフォーマンス

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

サイズ調整

「ごめんなさい。高さや幅を使ったほうがいいと思います。」
「サイズを減らす方法を探しています。現在は 12 個までです。」
「画像の動的なサイズ変更は、JS がないと非常に難しく、不可能です。」
「web.dev には、responsivebreakpoints.com のようなツールを使うと便利です。」

高画質で高解像度の画像

「DPI の画質を落とさずに画像を圧縮してダウンロードするにはどうすればよいですか？」
「私たちはドキュメント管理の会社です。当社のアプリは、数百万枚の高解像度スキャン画像（通常は TIFF または PDF）を処理しています。」
「手間がかかります。印刷形式では高解像度の img ファイルは必要です。ウェブ用に最適化する必要があります。ウェブ用の画像サイズを縮小するのは面倒ですが、著者が印刷出版物向けの画像用に軽量なファイルしか提供しないと、大きな問題になります。作品を含む原稿の提出要件については、さまざまなメッセージが混在しています。そして、このような資料を処理するための複雑なワークフローができあがります。」

ブラウザ機能

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

CDN と画像サービス

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

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

「CMS を使ってサイトを構築しているとき、画像の最適な使用方法を見つけるのにまだ苦労しています。作成者は画像のサイズが異なる傾向があり、画像の縮小や拡大は期待できません。画像に max-width または max-height を設定しても問題ないかわかりません」
「これまで数件のプロジェクトで gatsby-image を使用していて、それ以来一度も振り返っていません。」
「エンドユーザーによって CMS に組み込まれる画像は、多くの場合、どのようなサイズや形式でも使用でき、場合によっては理想的な画像形式の元の画像がなく、サイズが異なることもあります。」
「Google のシステムではセルフサービスで制御を追加できるため、画像の保守が難しくなります。ただし、解像度に影響を与えることなく自動的に処理が行われる場合を除きます。また、パソコンとモバイルで画像が正しく見えないという問題もあります。」
「サイト（WordPress）の最適化を手伝っています。私が画像について見た最大の問題は、WebP を作成するために CDN またはプラグインに依存する必要があるということです。srcset/picture は、テーマのデベロッパーが適切にコーディングする必要があります。遅延読み込みプラグインのほとんどは読み込みが遅く、UX に悪影響を及ぼします。背景画像は遅延読み込みが難しいです。」

費用/メリット

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

SEO

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

ウェブ上の画像の役割

「ウェブ上の情報が多すぎます。文章の内容を充実させない、役に立たない画像の使用はやめてください。」
「ウェブに画像がなく、自撮り写真を ASCII アートとして共有したときのことを今でも覚えていますか？」

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

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