画像
Astroでは、プロジェクト内にローカルに保存された画像、外部URLにリンクされた画像、CMSやCDNで管理されている画像などについて、これらをサイト上で使用するためのいくつかの方法を提供しています。
画像を保存する場所
セクションタイトル: 画像を保存する場所src/
とpublic/
セクションタイトル: src/とpublic/ローカル画像は、Astroが変換、最適化、バンドルできるように、可能な限りsrc/
に保存することをおすすめします。/public
ディレクトリのファイルは、常にそのままビルドフォルダにコピーされ、処理されることはありません。
src/
に保存されているローカル画像は、プロジェクト内のすべてのファイル(.astro
、.md
、.mdx
、.mdoc
、その他のUIフレームワーク)で使用できます。画像は、コンテンツと同じ場所など、任意のフォルダに保存できます。
画像に対する処理を避けたい場合や、画像へのリンクを直接公開したい場合は、画像をpublic/
フォルダに保存します。
リモート画像
セクションタイトル: リモート画像コンテンツ管理システム(CMS)やデジタルアセット管理(DAM)プラットフォームなど、リモートに画像を保存することもできます。
外部ソースを扱う際の保護を強化するために、設定で指定した許可された画像ソースからのリモート画像のみ処理されます。ただし、リモート画像の表示は常に可能です。
Astroは、APIを使用してリモートからデータを取得したり、画像をそのフルURLパスから表示したりできます。一般的なサービスを組み込む例については、CMSガイドを確認してください。
.astro
ファイル内の画像
セクションタイトル: .astroファイル内の画像.astro
ファイルでローカル画像を使用するには、ファイルにインポートする必要があります。リモートとpublic/
の画像はインポートする必要はありません。
astro:assets
からAstro組み込みの<Image />
コンポーネントをインポートして使用すると、画像を最適化できます。また、Astro構文ではHTMLの<img>
タグを直接書くこともできますが、画像処理はスキップされます。
<Image />
(astro:assets
)
セクションタイトル: <Image /> (astro:assets)Astro組み込みの<Image />
コンポーネントを使用して、ローカル画像と設定済みのリモート画像の最適化版を表示できます。
public/
フォルダ内の画像とプロジェクトで明示的に設定されていないリモート画像もImageコンポーネントで使用できますが、最適化処理はおこなわれません。
<Image />
は、ローカルまたは許可されたリモート画像のサイズ、ファイルタイプ、品質を変換して、表示される画像を制御します。生成された<img>
タグには、alt
、loading
、decoding
属性が含まれており、また Cumulative Layout Shift(CLS) を回避するために画像のサイズを推測します。
Cumulative Layout Shift(CLS)は、ローディング中にページのコンテンツがどれだけ移動したかを測定するためのCore Web Vitalのメトリックです。<Image />
コンポーネントは、ローカル画像の正しいwidth
とheight
を自動的に設定することで、CLSへと最適化します。
現在、組み込みのassets機能には<Picture />
コンポーネントは含まれていません。
代わりに、アートディレクションやレスポンシブ画像を作成するために、HTMLの画像属性srcset
とsizes
または<picture>
タグを使用して、getImage()
により画像やカスタムコンポーネントを生成できます。
プロパティ
セクションタイトル: プロパティsrc (必須)
セクションタイトル: src (必須)画像ファイルのsrc
値の形式は、画像ファイルの場所によって異なります。
-
src/
内のローカル画像 - 相対ファイルパスを使用するか、またはインポートエイリアスを設定して**、画像もインポート**する必要があります。インポート名をsrc
値として使用します。 -
public/
フォルダ内の画像 - 画像のpublicフォルダを起点としたファイルパスを使用します。 -
リモート画像 - 画像のフルURLをプロパティ値として使用します。
alt (必須)
セクションタイトル: alt (必須)必須のalt
属性を使用して、画像の説明的な代替テキストの文字列を記述します。
画像が単に装飾用である場合(つまり、ページの理解に貢献していない場合)、スクリーンリーダーやその他の支援技術に画像を無視するよう伝えるために、alt=""
を設定します。
widthとheight (public/
とリモート画像の場合は必須)
セクションタイトル: widthとheight (public/とリモート画像の場合は必須)これらのプロパティは、画像に使用するサイズを定義します。
ローカル画像をオリジナルのアスペクト比で使用する場合、width
とheight
はソースファイルから自動的に推測されるため、必須ではありません。
ただし、リモート画像とpublic/
フォルダに保存されている画像については、Astroはこれらのファイルを解析できないため、両プロパティは必須となります。
format
セクションタイトル: formatオプションで、使用する画像ファイルタイプの出力を指定できます。
デフォルトでは、<Image />
コンポーネントは.webp
ファイルを出力します。
quality
セクションタイトル: qualityquality
はオプションのプロパティで、次のいずれかの値を取ります。
- フォーマット間で自動的に正規化されるプリセット(
low
、mid
、high
、max
)。 - (フォーマット間で異なる解釈となる)
0
から100
までの数値。
その他のプロパティ
セクションタイトル: その他のプロパティ以上のプロパティに加えて、<Image />
コンポーネントは、HTMLの<img>
タグに設定可能なすべてのプロパティを受け付けます。
たとえば、最終的な<img>
要素にclass
を指定できます。
デフォルト値の設定
セクションタイトル: デフォルト値の設定現在、すべての<Image />
コンポーネントに対してデフォルト値を指定する方法はありません。必須属性は個々のコンポーネントに設定する必要があります。
再利用性を高めるための代替案として、<image />
コンポーネントを別のAstroコンポーネントでラップできます。たとえば以下のようにして、ブログ記事の画像用コンポーネントを作成できます。
Astroテンプレートの構文では、最終的な出力を完全に制御可能な<img>
タグを直接書くこともできます。これらの画像は処理されず、最適化もされません。
すべてのHTMLの<img>
タグのプロパティを記述でき、必須のプロパティはsrc
のみです。
src/
内のローカル画像
セクションタイトル: src/内のローカル画像ローカル画像は、.astro
ファイルからの相対パスによりインポートするか、インポートエイリアスを設定して使用する必要があります。これにより、<img>
タグで使用する画像のsrc
やその他のプロパティにアクセスできます。
たとえば、CLSを回避しCore Web Vitalsを改善するために、画像のheight
とwidth
プロパティを使用します。
インポートされた画像アセットは、以下のシグネチャと一致します。
public/
内の画像
セクションタイトル: public/内の画像public/
にある画像の場合は、src
の値に画像のpublicフォルダを起点としたファイルパスを使用します。
リモート画像
セクションタイトル: リモート画像リモート画像の場合は、src
の値に画像のフルURLを使用します。
<Image />
と<img>
の選択
セクションタイトル: <Image />と<img>の選択<Image />
コンポーネントは、画像を最適化し、また(ローカル画像の場合は)オリジナルのアスペクト比に基づいて幅と高さを推測することでCLSを回避します。ただし、特定のフォーマットのみに対応しており、<picture>
要素はなく、srcset
もサポートしていません。
以下のような<Image />
コンポーネントを使用できない場合に、HTMLの<img>
要素を使用してください。
- サポートされていない画像フォーマット
- Astroによる画像の最適化が不要な場合
- クライアントサイドで
src
属性に動的にアクセスして変更する場合
リモート画像の許可
セクションタイトル: リモート画像の許可image.domains
とimage.remotePatterns
を使用して、画像の最適化に使用する、許可された画像ソースのURLドメインとパターンのリストを設定できます。この設定は、外部ソースから画像を表示する際にサイトを保護するために追加の安全性を提供します。
他のソースからのリモート画像は最適化されませんが、これらの画像に<Image />
コンポーネントを使用すると、Cumulative Layout Shift(CLS)を防ぐことができます。
たとえば以下の設定では、astro.build
からのリモート画像のみが最適化されます。
以下の設定では、HTTPSホストからのリモート画像のみが許可されます。
CMSやCDNの画像の使用
セクションタイトル: CMSやCDNの画像の使用画像CDNは、Astroのすべての画像オプションと互換性があります。<Image />
コンポーネント、<img>
タグ、またはMarkdown記法のsrc
属性に、画像のフルURLを指定してください。リモート画像の最適化には、許可されたドメインまたはURLパターンを設定する必要があります。
あるいは、CDNがNode.js SDKを提供している場合は、プロジェクトでそれを使用することも可能です。たとえばCloudinaryのSDKは、適切なsrc
をもつ<img>
タグを生成してくれます。
Markdownファイル内の画像
セクションタイトル: Markdownファイル内の画像.md
ファイルでは、Markdown標準の![alt](src)
構文を使用します。この構文は、Astroの画像サービスAPIと連携して、ローカル画像と許可されたリモート画像を最適化します。
ローカル画像の場合<img>
タグはサポートされておらず、また.md
ファイルでは<Image />
コンポーネントは使用できません。
画像の属性をより細かく制御する必要がある場合は、Markdown構文に加えて、Astroの<Image />
コンポーネントや、JSXの<img />
タグを使用可能な.mdx
ファイル形式を使用することをおすすめします。AstroにMDXサポートを追加するには、MDXインテグレーションを使用します。
MDXファイル内の画像
セクションタイトル: MDXファイル内の画像コンポーネントと画像をインポートすることで、.mdx
ファイル内でAstroの<Image />
コンポーネントとJSXの<img />
タグを使用できます。使い方は.astro
ファイルの場合と同様です。
さらに、インポート不要でMarkdown標準の![alt](src)
構文もサポートされています。
コンテンツコレクションと画像
セクションタイトル: コンテンツコレクションと画像ブログ記事のカバー画像など、コンテンツコレクションのエントリに関連付けられた画像を、現在のフォルダからの相対パスを使ってフロントマターに宣言できます。
コンテンツコレクションスキーマのimage
ヘルパーにより、Zodを使用して画像のメタデータを検証できます。
画像はインポートされ、メタデータへと変換されます。これにより、<Image/>
、<img>
、そしてgetImage()
に、src
として渡すことができます。
以下の例は、上記のスキーマから各ブログ記事のカバー写真とタイトルをレンダリングする、ブログのインデックスページを示しています。
UIフレームワークコンポーネント内の画像
セクションタイトル: UIフレームワークコンポーネント内の画像UIフレームワークコンポーネントに画像を追加する場合は、フレームワーク独自の画像構文を使用して画像をレンダリングします(たとえば、JSXの<img />
、Svelteの<img>
などです)。
ローカル画像は、src
などの画像プロパティにアクセスするために最初にインポートする必要があります。
Imageコンポーネントを渡す
セクションタイトル: Imageコンポーネントを渡す<Image />
コンポーネントは、他のAstroコンポーネントと同様に、UIフレームワークコンポーネントでは使用できません。
しかし、.astro
ファイル内のフレームワークコンポーネントに、<Image />
によって生成された静的コンテンツを子要素として渡すか、または名前付きの<slot/>
を使用して渡すことは可能です。
getImage()
で画像を生成する
セクションタイトル: getImage()で画像を生成するgetImage()
はサーバー専用のAPIに依存しており、クライアントで使用するとビルドが失敗します。
getImage()
関数は、たとえばAPIルートなど、HTML以外の場所で使用する画像を生成することを目的としています。また、これを使って独自のカスタム<Image />
コンポーネントも作成できます。
getImage()
は、(alt
を除く)Imageコンポーネントと同じプロパティをもつオプションオブジェクトを受け取ります。
getImage()
は以下のプロパティをもつオブジェクトを返します。
代替テキスト
セクションタイトル: 代替テキストすべてのユーザーが同じように画像を見れるわけではないため、画像を使用する際のアクセシビリティは特に重要です。画像に対して説明的な代替テキストを提供するために、alt
属性を使用してください。
この属性は<Image />
コンポーネントでは必須です。代替テキストが指定されていない場合、<Image />
はエラーをスローします。
画像が単に装飾用である場合(つまり、ページの理解に貢献していない場合)は、alt=""
を設定して、スクリーンリーダーが画像を無視するようにしてください。
デフォルトの画像サービス
セクションタイトル: デフォルトの画像サービスSharpは、astro:assets
で使用されるデフォルトの画像サービスです。
画像を変換するためにSquooshを使用したい場合は、以下のように設定を更新してください。
pnpm
のような厳格なパッケージマネージャーを使用している場合は、Astroの依存関係であるにもかかわらず、プロジェクトにSharpを手動でインストールする必要があるかもしれません。
コミュニティインテグレーション
セクションタイトル: コミュニティインテグレーションAstroプロジェクトで画像を最適化したり、画像を扱ったりするための、サードパーティのコミュニティインテグレーションがあります。
v2.xからv3.0へのアップグレード
セクションタイトル: v2.xからv3.0へのアップグレードAstro v3.0では、astro:assets
は実験的な機能ではなくなりました。
<Image />
は組み込みのコンポーネントとなり、以前の@astrojs/image
インテグレーションは削除されました。
これらのことと、Astroで画像を使用するためのその他の変更により、以前のバージョンからAstroプロジェクトをアップグレードすると、いくつかの破壊的な変更が発生する可能性があります。
Astro v2.xプロジェクトをv3.0にアップグレードするには、以下の手順に適切に従ってください。
experimental.assets
からのアップグレード
セクションタイトル: experimental.assetsからのアップグレード以前にastro:assets
の実験的なフラグを有効にしていた場合は、Astro v3.0ではデフォルトでアセット機能が含まれているため、プロジェクトを更新する必要があります。
experimental.assets
フラグの削除
セクションタイトル: experimental.assetsフラグの削除実験的なフラグを削除します。
必要に応じて、astro/client-image
への参照をastro/client
に置き換えるために、src/env.d.ts
ファイルも更新します。
~/assets
インポートエイリアスの削除
セクションタイトル: ~/assetsインポートエイリアスの削除このImportエイリアスは、astro:assets
にデフォルトで含まれなくなりました。実験的なアセット機能でこのエイリアスを使用していた場合は、相対ファイルパスに変換するか、自分でImportエイリアスを作成する必要があります。
Cloudflare、Deno、Vercel Edge、Netlify Edge向けのシンプルなアセットサポートを追加する
セクションタイトル: Cloudflare、Deno、Vercel Edge、Netlify Edge向けのシンプルなアセットサポートを追加するAstro v3.0では、Astro組み込みのSquooshとSharpによる画像最適化をサポートしていないCloudflare、Deno、Vercel Edge、Netlify Edgeでも、astro:assets
をエラーなしで動作させることができます。Astroはこれらの環境では画像の変換や処理をおこないませんが、Cumulative Layout Shift(CLS)がなくなること、alt
属性が必須であること、一貫したコードの書き心地など、astro:assets
を使用した場合の他の利点は享受することができます。
こうした制約のために以前astro:assets
の使用を避けていた場合でも、もう問題なく使用できるようになりました。この動作を明示的に有効にするために、no-op画像サービスを設定できます。
画像を保存する場所を決める
セクションタイトル: 画像を保存する場所を決める画像を保存する場所を決めるには、今読んでいるこのガイドを参照してください。astro:assets
がもたらす柔軟性を活用して、画像を保存するための新しいオプションを利用したい場合があるかもしれません。たとえば、プロジェクトのsrc/
からの相対画像は、Markdown、MDX、MarkdocいずれにおいてもMarkdown標準の![alt](src)
構文により参照できるようになりました。
既存の<img>
タグを更新する
セクションタイトル: 既存の<img>タグを更新する以前は画像をインポートすると、画像のパスを含む単純なstring
が返されました。現在は、インポートされた画像アセットは以下のシグネチャをもつオブジェクトとなります。
(UIフレームワークコンポーネント内の画像を含む)既存の<img>
タグのsrc
属性の更新が必要です。また、インポートした画像から利用できるようになった他の属性も更新できます。
Markdown、MDX、Markdocファイルを更新する
セクションタイトル: Markdown、MDX、Markdocファイルを更新するプロジェクトのsrc/
からの相対画像は、Markdown、MDX、MarkdocいずれにおいてもMarkdown標準の![alt](src)
構文により参照できるようになりました。
これにより、画像をpublic/
ディレクトリからプロジェクトのsrc/
に移動し、処理を加えて最適化できます。public/
内の既存の画像とリモート画像は引き続き有効ですが、Astroのビルドプロセスでは最適化されません。
画像の属性をより細かく制御する必要がある場合は、Markdown構文に加えて、Astroの<Image />
コンポーネントやJSXの<img />
タグを使用可能な.mdx
ファイル形式を使用することをおすすめします。AstroにMDXサポートを追加するには、MDXインテグレーションを使用します。
@astrojs/image
を削除する
セクションタイトル: @astrojs/imageを削除するAstro v2.xで画像インテグレーションを使用していた場合は、以下の手順を完了させてください。
-
@astrojs/image
を削除します。インテグレーションを削除するためにアンインストールし、また
astro.config.mjs
ファイルからも削除する必要があります。 -
(必要に応じて)型を更新します。
src/env.d.ts
に@astrojs/image
のための特別な型を設定していた場合、v3へのアップグレードでこのステップが完了していなければ、デフォルトのAstroの型に戻す必要があるかもしれません。同様に、必要に応じて
tsconfig.json
を更新します。 -
既存の
<Image />
コンポーネントを移行します。新しい組み込みの
<Image />
コンポーネントを使用するために、@astrojs/image/components
からのimport
文をすべてastro:assets
に変更します。現在サポートされていない画像アセットのプロパティを削除します。
たとえば、
aspectRatio
はもうサポートされていません。これは、width
とheight
属性から自動的に推測されるためです。 -
既存の
<Picture />
コンポーネントを削除します。現在、組み込みのアセット機能には
<Picture />
コンポーネントは含まれていません。代わりに、HTMLの画像属性
srcset
とsizes
、または<picture>
タグを使用して、アートディレクションやレスポンシブ画像を作成できます。 -
デフォルトの画像サービスを選択します。
Sharpは、
astro:assets
で使用されるデフォルトの画像サービスとなりました。Sharpを使用する場合は、特に設定は必要ありません。画像を変換するためにSquooshを使用したい場合は、以下の
image.service
オプションを使用して設定を更新します。
コンテンツコレクションのスキーマを更新する
セクションタイトル: コンテンツコレクションのスキーマを更新するブログ記事のカバー画像など、コンテンツコレクションのエントリに関連付けられた画像を、現在のフォルダからの相対パスによりフロントマターに宣言できるようになりました。
コンテンツコレクションの新しいimage
ヘルパーにより、Zodを使用して画像のメタデータを検証できるようになりました。コンテンツコレクションで画像を使用する方法について、詳しくはこちらを参照してください。
Astro v3.0での画像インポートの扱い
セクションタイトル: Astro v3.0での画像インポートの扱いAstro v3.0で、以前の画像をインポートした際の挙動を維持しなければならず、画像URLの文字列が必要な場合は、以下のように画像パスの末尾に?url
を追加してください。
この方法により、URLの文字列を取得できます。なお、Astroは開発中にsrc/
パスを使用しますが、ビルド時には/_astro/cat.a6737dd3.png
のようなハッシュ化されたパスを生成することに注意してください。
画像オブジェクト自体を直接扱いたい場合は、.src
プロパティにアクセスできます。この方法は、Core Web Vitalsメトリクスのための画像サイズの調整や、CLSの防止などのタスクに最適です。
新しいインポートの挙動に移行する場合は、?url
と.src
の両方を組み合わせることが、シームレスに画像を扱うための正しい方法かもしれません。