はじめに
画像や動画の形式って、決める瞬間は一瞬なのに、外すと妙に時間を持っていかれます。たとえば、スライド用の図をJPEGで書き出して文字がにじみ、会議直前にPNGへ戻す羽目になったり、透過素材を変換したせいで白フチが出て作り直したりします。動画でも、軽くしたつもりの書き出しが一部環境で再生できず、結局“無難な形式”を作り直すことがあります。
こういう手戻りは、形式の特徴を暗記するよりも「何を置くのか」「どこで見せるのか」を先に決めて逆算するほうが減らせます。この記事では、写真・図・アイコン・映像といった用途を起点に、PNGやJPEG、WebP、AVIF、SVG、MP4、H.264などをどう選ぶかを整理します。いざというときの判断が少しでも楽になるようなガイドになれば幸いです。
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。
また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。
最初に押さえておきたい用語
ここでは、本文で何度も出てくる言葉だけを軽く整理しておきます。すでに知っている方は、この章は飛ばしても大丈夫です！
用語一覧
ラスター画像
写真やスクショのように、ピクセルの集まりでできている画像です。拡大すると粗くなりやすい一方で、写真の表現が得意です。JPEGやPNGやWebPやAVIFがこのタイプです。
ベクタ画像
線や図形の情報でできている画像です。拡大縮小しても輪郭が崩れにくいので、アイコンやロゴで強いです。SVGがこのタイプです。
コンテナ
動画や音声や字幕などをまとめて入れる「ファイルの箱」です。MP4やWebMがコンテナです。
コーデック
映像や音声を圧縮する方式です。H.264やH.265やAV1は映像のコーデックで、AACやOpusは音声のコーデックです。
互換性
いろいろな端末やブラウザで、同じように表示や再生ができるかどうかの話です。不特定多数に配るほど、互換性は大事になります。
透過
画像の背景を透明にできるかどうかです。透過が必要な素材は、形式選びを間違えると白フチなどの見た目崩れにつながります。
フォールバック
新しい形式が表示できない環境に備えて、代替の形式も用意しておく考え方です。Web配信では、AVIFやWebPを使うときにJPEGやPNGを一緒に持つのが典型です。
ファイル形式を間違えたときの実例
細かいルールの話に入る前に、まずは形式選びを外してしまったときに見た目がどう変わるのかを、具体例でざっと確認してみましょう！
そのうえで、あとから用途別の早見や判断軸のパートで、なぜそうなるのかをもう少し丁寧に見ていきます。
図をJPEGにして文字がにじむ
スライドやエディタのスクショなど、文字と細い線が主役の画像を強めにJPEG圧縮すると、輪郭から崩れていきます。
図やスクショを写真と同じ感覚でJPEGにすると、数字や文字の輪郭がモヤっとにじみます。
| PNGで書き出した例 | JPEGで保存した例 |
|---|---|
 |
 |
ぱっと見では左右の違いが分かりにくいのですが、右側のJPEG版をよく見ると、数字のエッジが少し丸くなっていて、行間のグレーもにじんでいます。倍率を上げたり、プロジェクターで投影したりすると、このわずかなにじみが「全体的にボケている」印象として一気に目立ってきます。
図やスクショのように文字と線が主役の画像では、こうした細部の崩れがそのまま可読性の低下につながります。基本はPNGやSVGを起点にして、JPEGは写真向けと割り切るくらいのスタンスで選んでおくと、あとから作り直す回数をかなり減らせます。
アイコンを小さなPNGだけで持って拡大するとギザギザになる
アイコンやロゴのように、シンプルな形と輪郭のシャープさが大事なものは、本来はSVGのようなベクタ画像で持っておくほうが向いています。ここで小さなPNGだけで持ってしまうと、後からサイズを変えたときに一気に質感が落ちます。
ベクタで作ったアイコンを小さいPNGとしてだけ保存してしまうと、2倍・3倍に拡大したときに輪郭がギザギザになります。
| 大きいサイズで書き出した例 | 小さいPNGを拡大した例 |
|---|---|
 |
 |
左は SVG を元に大きめサイズで保存したもの、右は一度32px程度まで小さくしたPNGを、そのまま同じサイズまで拡大したものです。右側では、角丸の部分や小さな四角の輪郭がカクカクしていて、よく見てみると全体が少しぼやけて見えます。
こうしたアイコンは、元データはSVGで持っておき、必要に応じて各サイズのPNGを書き出すという運用にしておくと、解像度が変わっても品質を保ちやすくなります。
H.264とH.265でMP4のファイルサイズがどう変わるか
動画はMP4という同じ拡張子でも、中身のコーデックや書き出し設定次第で、ファイルサイズや扱いやすさが変わります。ここでは同じ元動画から、H.264とH.265で書き出したMP4を用意し、「容量がどの程度変わるか」を中心に確認します。
この記事内では動きが伝わるようにGIFも併記していますが、ここで比較したいのはGIFの重さではなく、元のMP4ファイルとしての重さです。ここで言う「軽い／重い」は、H.264とH.265で書き出したMP4のサイズ差を指します。
- H.264で書き出した例
- H.265で書き出した例
今回の例では、H.264で書き出したMP4（RF22）が約3.41MB、H.265で書き出したMP4（RF28）が約2.78MBでした。見た目の差が大きく出ない場面でも、容量は条件に応じてはっきり変わります。特に画面収録のような素材では、画質の優劣を言い切るよりも「同じ用途でどのくらい軽くできるか」を見るほうが現実的です。
一方で、RF（一定品質）の数字はH.264とH.265で同じ意味にならないので、RFを同じ値に固定して比較するとサイズが逆転することもあります。今回は見た目が大きく変わらない範囲を優先し、そのうえでどれくらいサイズを詰められるかを見るために、H.265側のRFを上げて調整しています。
用途別おすすめ早見
ここでは 「この用途ならまずこれ」 という目安を先に置きます。最初から完璧な一つを探すより、現場では まず無難な形で出して、必要なら代替に落とす ほうが手戻りが少ないです。
ここから下では、写真・図・アイコンなどのケースごとに、選び方の理由と注意点について補足していきます。
画像の早見
画像は最初に、写真か、図やスクショか、アイコンやロゴか、透過が必要かで切り分けるのが早道です。同じ画像でも何が主役かで劣化の見え方が変わるので、ここを曖昧にしたまま形式だけ選ぶと失敗しがちです。
| 用途 | 推奨 | 代替 | 迷ったらここを見る |
|---|---|---|---|
| 写真 | WebP または AVIF | JPEG | 不特定多数に配るなら代替のJPEGがあると安心です。 |
| 図やスクショ | PNG | SVG できるならSVG | 文字と線が主役なら、にじみにくさを優先します。 |
| アイコンやロゴ | SVG | PNG | サイズ違いが増えそうならSVGを軸にすると管理が楽です。 |
| 透過が必要なUI素材 | PNG または WebP | 背景を合成して非透過にする | 背景色が変わる可能性があるなら透過前提が安全です。 |
図やスクショをJPEGで扱うと、文字や細線がにじんで読みにくくなりやすいです。
写真
人物や風景のように階調が多い写真は、できるだけ軽く配れる形式を選ぶのが基本になります。Webに載せる写真でページが重いと、体感として遅さが出やすく、あとからまとめて最適化する羽目になりがちです。
推奨される選び方
写真はWebPかAVIFを第一候補にしつつ、互換性のためにJPEGも用意する考え方が現実的です。新しめの形式で軽量化を狙いながら、表示できない環境が残っていてもJPEGに逃げ道がある、という状態にしておくと安心です。
よくある場面
たとえばLPのヒーロー画像やブログ記事のサムネイルのように、同じ写真をいろんな画面幅で見せる場合は、まずWebPかAVIFで軽くして、必要ならJPEGを併設する方針にすると決めやすいです。一方で、社内資料に貼るだけで容量の影響が小さいなら、無理に頑張らずJPEGで揃える手もあります。
図とスクショ
図やスクショは「文字と線が読めること」が最優先になります。写真と同じノリで非可逆圧縮をかけると、細い線や小さな文字から崩れていくので、見た目の劣化が一気に目立ちます。
推奨される選び方
図やスクショはPNGを中心に考えるのが無難です。もしロゴや単純な図形のようにベクタで表現できるなら、SVGを選ぶと拡大縮小で崩れにくく、複数サイズ展開の手間も減ります。
よくある場面
たとえばREADMEに貼るアーキテクチャ図や、スライドに載せる画面キャプチャはPNGで固定してしまうと、まず事故が起きにくいです。逆に、アイコンに近い図形やロゴをPNGで量産してサイズ違いが増えていく状況なら、SVGに寄せたほうが管理が楽になります。
アイコンとロゴ
アイコンとロゴはサイズが小さいほど粗が目立つ素材です。16pxの表示で輪郭がにじむだけでチープに見えるので、ここはとにかくシャープさを保てる形式を優先します。
推奨される選び方
アイコンとロゴはSVGを第一候補にして、SVGが使えない場面だけPNGに落とすのが分かりやすいです。UIのあちこちで同じ素材を使い回すことを考えると、拡大縮小に強いSVGを軸にしたほうが後から困りにくいです。
よくある場面
たとえば自社サイトと社内プロダクトの両方でロゴを使う場合、片方はSVGが通るのに、もう片方は画像アップロードでPNGしか受け付けないことがあります。そのときに「SVGを原本、PNGは派生」という形にしておくと、差し替えや色違いが出ても管理が崩れにくいです。
透過が必要なUI素材
透過素材は、背景色が変わった瞬間に粗がバレます。最初は白背景で問題なく見えていたのに、ダークモードにした途端に白フチが出て気づく、というパターンはかなりあります。
推奨される選び方
透過が必要ならPNGかWebPを中心に考えるのが安全です。逆に背景が固定されているなら、透過をやめて背景と合成してしまい、写真ならJPEGや非透過のWebPで軽くするほうが綺麗にまとまることもあります。
よくある場面
たとえば人物の切り抜きをカードUIに載せる場合、背景色が変わる可能性があるなら透過PNGで固めておくのが無難です。一方で、常に同じ背景のバナー画像に埋め込むだけなら、合成してしまったほうが容量も扱いやすさも改善することがあります。
動画の早見
動画は「軽くする」より先に「確実に再生される」を満たすほうが、結局スムーズです。軽量化は上手くいけば嬉しいのですが、環境差で再生できないと送り直しになり、トータルでは損になりやすいです。
| 配り先 | 推奨構成 | 追加で用意するなら | 迷ったらここを見る |
|---|---|---|---|
| Webに埋め込む | MP4 + H.264 + AAC | WebM などの軽量版を併設 | まずは互換性を優先して、軽量化は後から足します。 |
| SNSに投稿する | MP4 + H.264 + AAC | 基本は追加不要 | 投稿後に再エンコードされる前提で、無難な出力が崩れにくいです。 |
| 社内共有や研修 | MP4 + H.264 + AAC | 軽量版を別ファイルで用意 | 端末混在を想定して、まず再生失敗を避けます。 |
軽量化を一本化すると再生できない人が出ることがあるので、必要なときは「無難な版を残して軽量版を追加」に寄せると安全です。
Webに埋め込む動画
Webサイトに埋め込むデモ動画や紹介動画は、ブラウザでの再生互換性が最優先になります。読み込みが遅いと離脱にもつながるので、軽さも無視はできませんが、まずは再生できる土台を作るのが安定します。
推奨される選び方
Web埋め込みはMP4のH.264を基準にして、さらに軽くしたいときだけ別ソースとして追加の形式を併設するのが現実的です。最初から軽量な形式一本に寄せるより、H.264を残しておくほうが事故が減ります。
SNSに投稿する動画
SNSは投稿後にプラットフォーム側で再エンコードされる前提なので、極端な最適化を頑張っても結果が変わらないことがあります。むしろ変な設定のほうが相性が悪く、画質が崩れることもあります。
推奨される選び方
SNS投稿はMP4のH.264を基本にして、崩れにくい出力を目指すのが無難です。最終的にプラットフォーム側で加工される前提で、設定を盛りすぎない判断が効いてきます。
社内共有や研修動画
社内共有は端末が混ざりがちで、再生できない事故が起きると一気に面倒になります。視聴者のリテラシーも環境も揃っていないことが多いので、ここは安全側が正解になりやすいです。
推奨される選び方
社内共有や研修動画は、MP4のH.264とAACを基本にしておくと安心です。軽くしたい場合でも、まずはこの構成の動画を残しておき、必要なら軽量版を別で用意するほうがトラブルが少ないです。
迷わないための共通判断軸
形式を決めるときに「結局どれだっけ」と迷うのは、比較表の知識が足りないからというより、確認する順番が毎回バラバラだからです。ここでは、どんな案件でも同じ順番で確認できるように判断軸を固定し、そのまま形式まで落とせるようにフローチャートも続けて置きます。文章で一度腹落ちさせてから図を見る流れにしているので、読み飛ばしても迷子になりにくいはずです。
まず用途を写真と図とアイコンに分ける
最初にやるのは「何が主役の画像か」を決めることです。写真なのか、文字と線が主役の図なのか、形が主役のアイコンなのかで、同じ圧縮でも見た目の崩れ方が全然違います。
たとえば人物写真なら多少圧縮しても違和感が出にくい一方で、スライドの図を同じ感覚で圧縮すると文字の輪郭がにじんで一気に読みにくくなります。逆にロゴやUIのアイコンは輪郭が少しでも甘いとチープに見えるので、この段階で「写真は軽量化寄り、図は可読性寄り、アイコンは拡大縮小耐性寄り」という方向性を固めておくと後がスムーズです。
写真・図・アイコンは「劣化の目立ち方」が違います。ここを先に確定すると、後ろの判断（透過・互換性・容量）が素直に決まります。
透過が必要かを確定する
次に透過の要否を決めます。透過が必要かどうかで、そもそも選べる形式がガラッと変わるので、ここは早めに確定したほうが迷いません。
たとえば人物の切り抜きをカードUIに載せるなら、背景色が将来変わる可能性がある時点で透過前提にしておくのが安全です。逆に背景が固定で、画像はその上にしか置かれないなら、透過を捨てて合成したほうが軽くできる場面もあります。
透過の要否を後回しにすると、白フチや境界のにじみが出て作り直しになりやすいです。背景が変わる可能性があるかどうかで早めに決めます。
互換性の要求レベルを決める
次に「誰が見るか」を確認します。ここが曖昧だと、攻めた形式を選んで表示できない人が出たり、逆に守りすぎて容量が無駄に大きくなったりします。
たとえば自社サービスのWebページで一般公開するなら、古めの端末や社内の制限環境も混ざる前提で代替を用意しておくほうが安心です。一方で、特定のアプリ内だけで使う素材や閲覧環境が決まっている社内ツールなら、対応環境を前提に少し攻める判断もしやすいです。
不特定多数向けは「見えない・再生できない」がそのまま事故になります。攻める形式ほど、代替の用意までセットで考えるのが安全です。
サイズと容量の優先度を決める
最後に「何を優先するか」を決めます。ここで言うサイズはファイルサイズだけでなく、表示サイズや解像度も含みます。
たとえば記事内の写真はスマホ表示が中心なら、元画像が4Kでもそのまま出す意味は薄いので、表示サイズに合わせてリサイズしてから圧縮したほうが結果が安定します。逆に細かい文字が入った図は、軽くしたい一心で圧縮すると読めるかどうかが先に死ぬので、容量より可読性を優先して形式と解像度を守るほうが手戻りが減ります。
「軽くしたい」ときほど、圧縮の前にリサイズの見直しが効きます。図は容量より可読性を優先したほうが結果的に早いです。
JPEGの品質の決め方
形式を決めたあとに地味に迷うのが「で、JPEGの品質はいくつにするのか」です。ここを案件ごとに場当たりで決め始めると、画像が増えたタイミングで「重いから下げたい」「でも見た目が悪いから上げたい」が揉めて、結局どれも中途半端になりがちです。
やりやすいのは、最初にサンプルを用意して基準を固定してしまうやり方です。よく使う写真を10枚くらい選んで、暗い室内や肌のアップみたいに圧縮に弱いものも混ぜておきます。そのうえで品質をいくつか試して、スマホとPCの両方で「これなら問題ない」と言える境界を見つけて、以後はその値を基本にします。
ここで大事なのは、数字そのものよりも「この案件ではこの基準で行く」を早めに合意することです。一度決めてしまえば、画像が増えても品質で毎回立ち止まらずに済みますし、必要が出たときだけ例外として上げ下げすれば整理がつきます。
この話はJPEGを例にしていますが、WebPやAVIFでも同じで、結局はサンプルで見比べて基準を決めておくのが一番早いです。
画像と動画の選定フロー
上の判断軸をそのまま分岐に落としているので、質問に答えていくだけで候補が決まるようにしています。
画像の選定フロー
動画の選定フロー
主要な形式の特徴を一覧で確認
ここまでの早見とフローで大枠は決まる一方で、「JPEGってどこが弱いんだっけ」みたいな確認はたまに発生します。そういうときのために、実務で触る機会が多い形式だけを表に寄せておきます。
画像形式
写真と図とアイコンで迷ったら、まずは「にじみやすいか」「透過が要るか」「拡大縮小が多いか」を見てください。ブラウザで一般的に扱われる画像形式の整理はMDNにもまとまっています。
| 形式 | 種類 | 得意 | 苦手 | 典型の使いどころ |
|---|---|---|---|---|
| JPEG | ラスター | 写真を軽くしやすい | 文字や線がにじみやすい 透過できない | 記事の写真 サムネ |
| PNG | ラスター | 図やスクショが読みやすい 透過ありも扱える | 写真だと重くなりがち | 図 スクショ UI素材 |
| WebP | ラスター | 写真も図もそこそこ軽い 透過も可 | 環境差を気にする場面では保険が要る | Web配信用の汎用枠 |
| AVIF | ラスター | かなり軽くできることがある | 環境差が残るのでフォールバック前提 | 写真中心のWeb配信で攻めたいとき |
| SVG | ベクタ | 拡大縮小しても劣化しにくい | 受け付けないサービスがある場合がある | アイコン ロゴ シンプルな図形 |
| GIF | ラスター | 手軽なアニメ 互換性は高め | 色数が弱い 容量が大きくなりやすい | 短い動きの説明 既存資産の流用 |
| APNG | ラスター | PNGのままアニメ 透過ありも可 | 対応や運用の都合で避けたい場面もある | 透過付きの小さな動き |
| ICO | ラスター | favicon用途 | 通常の画像用途には向かない | ブラウザのfavicon |
動画は入れ物と圧縮方式を分けて見る
MP4やWebMは「入れ物」で、H.264やAV1は「圧縮方式」です。動画が再生できない事故は、この組み合わせが噛み合っていないときに起きがちです。コンテナとコーデックの整理はMDNにまとまっています。
コンテナ
| 形式 | 中身の例 | 得意 | 注意 | 典型の使いどころ |
|---|---|---|---|---|
| MP4 | H.264 + AAC など | とにかく無難で外しにくい | 中身のコーデック次第で再生可否が変わる | Web埋め込み 社内共有 |
| WebM | VP9 または AV1 + Opus など | Web向けで軽量化の候補になりやすい | 環境差が残るので併設が安心 | Webで軽量版を足すとき |
| MOV | H.264 など | 撮影素材でよく出会う | Web配布の最終形としては扱いづらいことがある | 編集前の保管や受け渡し |
動画コーデックと音声コーデック
| 形式 | 種類 | 得意 | 注意 | 典型の使いどころ |
|---|---|---|---|---|
| H.264 | 動画コーデック | 互換性寄りで困りにくい | 最高効率を狙う用途では最適解にならないこともある | まずこれで土台を作る |
| H.265 | 動画コーデック | 画質と容量のバランスが良い場面がある | 対応状況に差が出やすいので環境が揃うとき向け | 限定環境で軽量化したいとき |
| AV1 | 動画コーデック | 圧縮効率が高い | 単独採用より併設が安心 | 帯域を削りたいWeb配信 |
| VP9 | 動画コーデック | WebMでよく使われる | 併設前提にしやすい立ち位置 | WebMの軽量版 |
| AAC | 音声コーデック | 互換性寄りで扱いやすい | これも「無難枠」 | MP4と組み合わせやすい |
| Opus | 音声コーデック | 効率が良い | コンテナや対応状況とセットで考える | WebMと相性が良い |
この表で見当が付いたら、前のフローに戻って最終決定するのが早いです。
迷いやすいポイント解説
ここでは、よく使う形式についてなぜそれを選ぶのかというポイントについて簡潔に解説します。
写真はJPEG寄りで 図はPNG寄りになる理由
JPEGは写真のような階調の多い画像を軽くしやすい一方で、文字や細い線はにじみやすいです。逆にPNGは図やスクショのように輪郭が大事な画像で崩れにくいので、会議資料の図をJPEGにして読みにくくなる事故が減ります。迷ったら「人や風景ならJPEG寄り、文字と線ならPNG寄り」と覚えておくと判断が早いです。
WebPとAVIFはいつ使って いつ保険をかけるか
WebPとAVIFは、同じ見た目ならJPEGやPNGより軽くできることが多いので、Web配信ではまず候補に上がります。ただし環境差がゼロではないので、不特定多数向けならフォールバックを前提にするのが安心です。具体的には、写真ならWebPやAVIFを出しつつJPEGを残し、図ならWebPやAVIFに寄せすぎずPNGを軸にする、と考えるとバランスが取りやすいです。
SVGが刺さる場面と 運用で詰まりやすい点
SVGは拡大縮小で劣化しにくいので、アイコンやロゴで強いです。サイズ違いのPNGを量産しなくて済むので、UIのあちこちに同じ素材を置くときほど効いてきます。一方で、貼り付け先のサービスがSVG非対応だったり、取り扱いの都合で弾かれることもあるので、その場合はPNGに落とす前提で考えると運用が詰まりにくいです。
動画はまずMP4とH.264で固めるのが安全な理由
動画は軽量化を頑張るほど、再生できない環境に当たったときの手戻りが大きくなります。そのため、まずはMP4とH.264を土台にして「再生できる」を確実にし、必要なときだけ軽量版を追加する考え方が現実的です。特に社内共有は端末が混ざりやすいので、最初から無難な構成で揃えておくほうが結果的に楽になります。
よくある事故と回避策
ここでは、実務で「それ今起きるのか…」となりがちな事故だけを拾って、原因と回避策をセットでまとめます。
図がにじんで読めない
スライドの図やREADMEの設計図を貼ったあとに、文字がモヤっとして読めない状態になるやつです。だいたいは、図やスクショをJPEGのような非可逆圧縮で扱ったときに起きます。写真だと気になりにくい圧縮でも、文字と線は崩れが一気に目立ちます。
回避策としては、図とスクショはまずPNGに倒すのが安全です。元データがSVGで作れる図形なら、最初からSVGにしてしまうと拡大縮小でも崩れません。すでににじんでしまった場合は、圧縮率をいじるより「PNGで書き出し直す」「文字サイズを上げる」「細線を太くする」のほうが効きます。
透過素材で白フチが出る
人物の切り抜きやアイコンを載せたときに、輪郭に白い縁取りみたいな線が出る現象です。白背景だと気づかないのに、背景色を変えた瞬間に急に目立つことが多いです。原因はだいたい、透過前提の素材を別形式に変換したときに、境界が背景色と混ざった状態で固まってしまうことです。
回避策は、透過が必要な素材は最初から透過対応の形式で持つことです。具体的にはPNGかWebPを基本にして、途中でJPEGに落とさないのが無難です。もし白フチが出た場合は、元データ側で切り抜きの境界処理を見直すか、背景が固定なら思い切って背景と合成してしまうと綺麗に片付きます。
動画が再生できない
「送ったのに再生できない」と言われる事故です。動画は見た目が同じでも、コンテナやコーデックの組み合わせで再生可否が変わります。軽量化のつもりで書き出し設定を攻めるほど、相手の環境によっては再生できない確率が上がります。
回避策としては、まずMP4のH.264を土台にしておくのが一番手堅いです。社内共有や研修動画なら、音声もAACにしておくとさらに事故が減ります。どうしても軽くしたい場合は、軽量版を一本化するのではなく「無難な版を残したまま、軽量版を追加する」形にすると、再生できなかったときの逃げ道が確保できます。
計測して確かめる
「ページが重い」「動画が遅い」と言われたとき、いきなり形式を変えたり圧縮をやり直したりすると、だいたい遠回りになります。体感として遅い原因が、画像なのか、動画なのか、そもそも別のリソースなのかが分からないまま動くことになるからです。
まずはブラウザの開発者ツールで、重い犯人を先に当てます。Networkでサイズが大きいリソースを見て、どの画像や動画が効いているかを把握します。次にWaterfallを見ると「ダウンロードに時間がかかっているのか」「読み込みが詰まっているのか」が見えます。ここまで分かると、やることが具体的になります。
犯人が写真なら、表示サイズに対して元がデカすぎないかを見直し、必要ならリサイズしてから圧縮します。図なら、JPEGでにじませていないかを確認してPNGに戻します。動画なら、まずMP4のH.264で確実再生の土台があるかを確認し、軽量版を追加するなら併設に寄せます。形式の話に戻る前に「何がボトルネックか」を一度特定するだけで、手戻りがかなり減ります。
まとめ
いかがだったでしょうか。画像や動画の形式選びは、正解を一発で当てるというより「用途に合わせて無理なく外さない」ことのほうが大事だと思っています。この記事が、次に同じ場面に出会ったときに迷う時間を少しでも減らすきっかけになれば幸いです。必要になったら、早見とフローだけでもサッと見返してみてください。
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。
また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。