※本記事はプロモーションを含みます
ブログ画像サイズは、記事内なら横幅1,000px前後・容量200KB前後以下を出発点にし、画像の役割と実際の表示幅に合わせて調整するのが現実的です。
Googleが「1,000px・200KB」をSEOの固定基準として定めているわけではありません。重要なのは、スマホでも読める画質を保ちながら、必要以上に大きな画像データを送らないことです。
ブログ運営では、画像だけでなく記事設計やSEOを含めて仕組み化すると、毎回の判断を減らしやすくなります。
👉 ブログ運営の基本をあわせて確認する
↓↓↓
https://utage-system.com/p/dnGib1s5QNx6/1nZcAFenGERf
ブログ画像サイズの目安は何px・何KBにすればいい？
通常の記事内画像なら横幅700〜1,000px程度、迷ったら1,000px前後、容量は200KB前後以下を最初の目安にすると管理しやすいです。
最初に重要な点を明確にしておきます。
Google公式の固定値：なし
Googleは「ブログ画像は横幅1,000px」「200KB以下ならSEOに有利」といった合格基準を公表していません。
Google検索セントラルの「画像のSEOベストプラクティス」で重視されているのは、高品質な画像を提供しつつ、画像最適化やレスポンシブ画像を利用して高速なユーザー体験を実現することです。Googleは画像がページ容量の大きな部分を占めることがあるとも説明しています。Google for Developers+1
したがって、「200KBを1KBでも超えたら失格」と考える必要はありません。
私が実務上の初期設定として考えやすい基準は次のとおりです。
用途 サイズの目安 容量の考え方
通常の本文画像 横700〜1,000px程度 200KB前後以下を目標
大きめの図解 横1,000〜1,200px程度 文字の読みやすさを優先
アイキャッチ 1,200×630px前後も候補 画質と表示速度の両方を見る
16:9の解説画像 1,000×562px前後 横長記事で扱いやすい
4:3の画面画像 1,000×750px前後 管理画面などを見せやすい
3:2の写真 1,000×667px前後 写真の構図を保ちやすい
ここで「目安」と表現しているのがポイントです。
たとえば細かな文字を多く含む操作画面を150KBにするため、強く圧縮して文字が読めなくなれば意味がありません。
一方、単純なフラットイラストなら100KBを大きく下回っても十分きれいに見えることがあります。
画像サイズを決めるときは、数字を先に絶対視するのではなく、次の順番で考えると迷いにくくなります。
1. 実際の本文表示幅を確認する
2. その幅で文字や被写体が十分に見えるサイズにする
3. 不要な余白や巨大な元画像を削る
4. 適切な画像形式を選ぶ
5. 画質を確認しながら容量を下げる
6. PCとスマートフォンの両方で確認する
たとえば本文幅が800px前後しかないサイトで、毎回横4,000pxの写真をそのまま掲載する必要性は通常高くありません。
逆に、横400pxの図解を800pxまで引き伸ばせば、文字や線がぼやける可能性があります。
つまり、「大きければ高画質」「小さければ高速」という二択ではなく、表示する用途に対して過不足のないサイズを選ぶことが基本です。
私は長年、サイト運営やウェブ集客の実務でページ構成や表示速度を確認してきましたが、画像最適化では「正解の1px」を探し続けるより、最初に共通ルールを作ったほうが運用は安定します。
副業ブログなら、まず横1,000px前後を標準にし、細かな図解だけ1,200px程度まで許容する、といった決め方で十分実用的です。
画像の「1000px」と「200KB」は何が違う？
1,000pxは画像の縦横寸法、200KBはデータ容量です。この2つは別々に確認する必要があります。
「画像サイズ」という言葉が分かりにくい理由は、異なる2種類の数値を同じ言葉で呼ぶことにあります。
- ピクセルサイズ：1,000×562pxなど、画像の縦横の大きさ
- ファイルサイズ：80KB、200KB、1MBなど、画像データの容量
同じ1,000×562pxでも、保存形式や圧縮率、画像の内容によって容量は変わります。
たとえば空や壁のように色の変化が少ない写真は圧縮しやすい一方、草木、髪の毛、細かな文字、複雑な模様などが多い画像は容量が増えやすくなります。
そのため「1,000pxなら軽い」とは限りません。
反対に「200KB以下なら最適」とも限りません。
図解を強く圧縮した結果、文字の輪郭が崩れてしまえば、ページは軽くなっても読者にとっての価値は下がります。
Google検索セントラルも、ぼやけた画像より高品質で鮮明な画像がユーザーにとって魅力的である一方、画像はページ容量を大きくしやすいため、品質と速度の双方を最適化するよう説明しています。Google for Developers
したがって、ブログ画像では「画質を確認してから容量を削る」という考え方が重要です。
以前は「ページ全体を○MB以下にする」といった一律の数字が語られることもありましたが、現在のWebページは画像だけで構成されているわけではありません。
HTML、CSS、JavaScript、Webフォント、計測タグ、埋め込みコンテンツなど、さまざまなデータが読み込まれます。
そのため、画像だけを見てページ性能を判断するのではなく、公開後にPageSpeed Insightsなどで実際のページを確認するほうが合理的です。
私なら、ブログ初心者には次のように伝えます。
1,000px・200KBは「守れなければ失敗する基準」ではなく、「まずここから調整してみる基準」です。
この違いを理解しておけば、201KBになった画像を何度も圧縮し直すような無駄を減らせます。
画像を4000pxから1000pxにすると容量はどれくらい変わる？
元画像のピクセル数を必要な範囲まで縮小するだけでも、画像容量は大きく減る可能性があります。
この点は画像形式の説明だけでは分かりにくいため、本稿では再現条件を明示した比較テストを行いました。
検証条件は次のとおりです。
- 使用ソフト：Python Pillow 12.3.0
- 元画像：4,000×2,250px
- 内容：固定シードで生成した色変化のある写真風テスト画像
- 縮小方法：Lanczos
- JPEG品質：85または75
- WebP品質：80または70
- WebPエンコード：method 6
- 比較画像：すべて同じ元画像から生成
- 容量：保存後の実ファイルサイズを測定
結果は次のようになりました。
条件 容量
4,000×2,250px・JPEG品質85 約1,675KB
1,000×562px・JPEG品質85 約254KB
1,000×562px・JPEG品質75 約193KB
1,000×562px・WebP品質80 約218KB
1,000×562px・WebP品質70 約182KB
今回の条件では、4,000px幅のJPEGを1,000px幅へ縮小しただけで、約1,675KBから約254KBまで減りました。
さらに圧縮条件を調整すると、JPEG品質75では約193KB、WebP品質70では約182KBとなっています。
ただし、ここで重要なのは「WebPなら182KBになる」という数字ではありません。
画像容量は元画像の内容、ノイズ、文字量、色数、保存ソフト、品質設定によって大きく変化します。
以前の検証条件では、より単純な画像を使ったため、4,000×2,250pxのJPEGが約560KB、1,000×562pxのJPEGが約47KB、WebPでは約15KBまで縮小できたケースもありました。
この差から分かるのは、同じピクセル数でも画像内容によってKB数は大きく変わるということです。
だからこそ、「ブログ画像は必ず200KB以下」というルールをGoogle公式基準のように扱うのは適切ではありません。
一方、2回の検証に共通する傾向もあります。
それは、4,000px級の画像を必要な表示幅まで縮小すると、容量削減の効果が大きいことです。
画像最適化というと「JPEGとWebPのどちらが軽いか」に意識が向きがちですが、その前に確認したいのが元画像の寸法です。
スマートフォンやデジタルカメラで撮影した画像は、ブログ本文で必要な幅を大きく上回っていることがあります。
横4,000pxの画像をそのまま高度な圧縮ツールへ入れるより、まず1,000〜1,200px程度まで縮め、その後に画質と容量を調整したほうが手順は単純です。
画像最適化のような細かな作業ほど、記事制作全体のルールを先に決めると継続しやすくなります。
👉 副業ブログの運営方法を確認する
↓↓↓
https://utage-system.com/p/dnGib1s5QNx6/1nZcAFenGERf
筆者としては、この「先に寸法、次に圧縮」という順番が、会社員の副業ブログでは特に重要だと考えています。
作業時間が限られている人ほど、高度な設定を増やすより、アップロード前に巨大画像を縮小するという単純なルールのほうが再現しやすいからです。
JPG・PNG・WebPはブログ画像でどう使い分ける？
写真はJPEGまたはWebP、文字や透過を含む図解はPNGまたはWebPを候補にし、実際の画質と容量を比較して選ぶのが基本です。
画像形式にはそれぞれ特徴があります。
JPEGは写真に使いやすい
JPEGは、写真やグラデーションなど色の変化が多い画像に向いています。
比較的小さな容量にしやすい一方、圧縮を強くしすぎると細部がにじんだり、ブロック状の劣化が目立ったりすることがあります。
商品写真、風景、人物を含む一般的な写真では、現在でも使いやすい形式です。
PNGは文字や透過画像で使いやすい
PNGは、文字、図形、単色部分、透過背景を含む画像などで使いやすい形式です。
WordPressの操作説明や図解では、文字の輪郭を維持しやすいケースがあります。
一方、写真をPNGで保存すると容量が大きくなりやすいため、すべてをPNGへ統一する必要はありません。
WebPは有力だが万能ではない
WebPは写真にもイラストにも利用できます。
Google検索セントラルが2026年9月14日時点で案内している対応形式には、BMP、GIF、JPEG、PNG、WebP、SVG、AVIFが含まれています。Google for Developers+1
したがって、「Google検索に載せるためにJPEGでなければならない」ということはありません。
ただし、先ほどの検証でもWebP品質80がJPEG品質75より大きくなったように、WebPへ変換すれば無条件に最小容量になるわけではありません。
圧縮率や画像内容が違えば結果も変わります。
実務では、形式名だけで判断するより、次の順番で処理すると迷いにくくなります。
1. 不要な余白をトリミングする
2. 必要な横幅まで縮小する
3. 写真か図解かで形式候補を決める
4. 圧縮後の文字や輪郭を見る
5. ファイル容量を確認する
6. WordPressへアップロードする
7. スマートフォンで実際に確認する
縦横比についても同じです。
通常の解説画像なら16:9は高さを抑えやすく、1,000×562px前後で使いやすい形です。
しかし、WordPress管理画面のスクリーンショットを無理に16:9へ切り取ると、説明したいメニューやボタンが消えることがあります。
縦方向に情報が多い図解なら4:3や縦長のほうが読みやすい場合もあります。
私は、ブログ全体の見た目をそろえることより、その画像だけを見ても説明内容が理解できることを優先すべきだと考えています。
統一感のために必要情報を切り落とすのは、画像本来の目的から外れるからです。
WordPressではsrcsetと遅延読み込みをどこまで気にすればいい？
初心者はまず元画像を適正化し、そのうえでWordPressがレスポンシブ画像を正しく出力しているか確認すれば十分です。
WordPressは2015年11月10日に公開されたWordPress Coreの開発者向け資料「Responsive Images in WordPress 4.4」で、WordPress 4.4から生成画像のマークアップへ`srcset`と`sizes`を追加するレスポンシブ画像対応を案内しました。Make WordPress
現在のWordPress Developer Resourcesでも、WordPress 4.4以降は`srcset`と`sizes`によるレスポンシブ画像をサポートすると説明されています。WordPress Developer Resources
仕組みは比較的単純です。
たとえば大きな画像をWordPressへアップロードすると、WordPressは複数サイズの画像を生成できます。
`srcset`には利用可能な画像候補が記載され、ブラウザが画面幅などに応じて適した候補を選びます。
WordPress 4.4導入時には、レスポンシブ画像向けの中間サイズとして横768pxの`medium_large`も追加されました。Make WordPress+1
Google検索セントラルも、レスポンシブ画像の指定方法として`srcset`や`picture`要素を案内しています。Google for Developers
つまり、1,500px幅の元画像をアップロードしたからといって、すべてのスマートフォンで必ず同じ1,500px画像が配信されるとは限りません。
テーマや出力HTMLが適切なら、ブラウザはより適した候補を選択できます。
ただし、これを理由に巨大画像を無制限にアップロードしてよいわけでもありません。
元画像そのものを必要な範囲へ整えておけば、メディアライブラリの容量やバックアップ容量も抑えやすくなります。
遅延読み込みは全部の画像へ使えばいいわけではない
WordPressでは、2020年7月14日に公開されたWordPress Coreの開発者向け資料「Lazy-loading images in 5.5」で、WordPress 5.5からHTMLの`loading`属性を利用した画像の遅延読み込みが導入されました。Make WordPress
遅延読み込みは、画面外にある画像を必要になるまで読み込まないことで、初期表示時の通信を減らす考え方です。
しかし、ページ上部の重要画像まで一律に遅延読み込みするのは適切ではありません。
web.devの「Optimize Largest Contentful Paint」では、LCP対象画像に`loading=”lazy”`を設定すると不要な読み込み遅延につながり、LCPへ悪影響を与えるため避けるよう明確に説明しています。web.dev
つまり、
画面上部の主要画像は早めに読み込み、下部の画像は必要に応じて遅延させる
という考え方が基本です。
ブログ初心者がここで陥りやすいのは、画像圧縮、WebP変換、キャッシュ、遅延読み込みを複数のプラグインで一気に設定することです。
機能が重複すると、どの設定が画像を変換しているのか分かりにくくなる場合があります。
まずは、
- アップロード前に巨大画像を縮小する
- 容量を確認する
- スマホで表示を見る
- WordPressの`srcset`が出ているか必要に応じて確認する
という順番で十分です。
高度な高速化設定は、その後に実際の問題を確認してから追加するほうが管理しやすいでしょう。
PageSpeed Insightsを使って画像サイズをどう最終判断する？
PageSpeed Insightsでは点数だけでなく、LCPや画像関連の改善項目を見て、実際に問題が起きているか判断します。
Chrome for Developersの「Lighthouse のパフォーマンス スコアリング」では、Performanceスコアを次のように分類しています。
- 90〜100：良好
- 50〜89：改善が必要
- 0〜49：低い
50〜89は「平均」ではなく、「改善が必要」に相当します。Chrome for Developers+1
ただし、100点を取ること自体がブログ運営の目的ではありません。
Chrome for Developersも、100点は非常に難しく、期待されるものではないと説明しています。Chrome for Developers
ブログ画像との関係で特に確認したいのがLCPです。
web.devの「Web Vitals」では、2026年9月14日時点のCore Web Vitalsについて、良好とされる主な基準を次のように示しています。
- LCP：2.5秒以下
- INP：200ミリ秒以下
- CLS：0.1以下
評価では、モバイルとデスクトップそれぞれについて、ページ読み込みの75パーセンタイルを見る考え方が使われています。web.dev
画像と直接関係しやすいのはLCPです。
記事上部の大きなアイキャッチ画像などがLCP要素になっている場合、重い画像や読み込み開始の遅れが表示速度へ影響することがあります。
PageSpeed Insightsを見るときは、単純に「78点だから失敗」と判断するのではなく、次の点を確認してください。
- 表示サイズに対して極端に大きな画像がないか
- 画像の転送量を減らせる余地があるか
- LCP画像の読み込み開始が遅れていないか
- LCP画像が不要に遅延読み込みされていないか
- 画面外画像を必要に応じて遅延できているか
- 画像の縦横サイズ不足などでレイアウトが動いていないか
ここで重要なのは、画像最適化を「SEO順位を上げる裏技」と考えないことです。
画像を1枚削除してPerformanceスコアを数点上げても、その画像が読者の理解に必要だったなら、記事全体の価値が下がることがあります。
私見では、画像最適化の目的は検索エンジン向けに数字を整えることではなく、読者が必要な情報をストレスなく受け取れる状態を作ることです。
画像の品質とページ速度は対立するものではありません。
不要な巨大データを削りながら、必要な図解や写真はきちんと残す。この線引きをするのが運用者の仕事です。
なお、過去にはGoogleが2016年のモバイルサイト調査をもとに「読み込みに3秒を超えると53％が離脱する」というデータを紹介したことがあります。
これは約10年前の調査であり、2026年現在のすべてのユーザー行動を表す最新基準として扱うべきではありません。
現在のサイト改善では、この古い数字を目標値にするのではなく、Core Web Vitalsや自サイトのPageSpeed Insights、実際のユーザー環境を優先して見るほうが適切です。
ブログ画像サイズは結局どう決めればいい？
迷ったら「横1,000px前後→画質確認→200KB前後を目標に圧縮→スマホ確認」という4段階で決めると実務上迷いにくくなります。
ここまでの内容を、公開前に毎回使える判断手順へ絞ります。
手順1：まず横1,000px前後へ整える
通常の本文画像なら、まず横700〜1,000px程度を候補にします。
迷う場合は1,000px前後から始めれば、本文幅が比較的広いテーマにも対応しやすくなります。
図解の文字が小さい場合だけ、1,200px程度まで広げる方法があります。
手順2：100％表示で文字や画像を確認する
容量を下げる前に、画像として十分読めるか確認します。
特にスクリーンショットでは、操作ボタン、メニュー名、設定値が読めることを優先してください。
手順3：200KB前後以下を目標に圧縮する
通常画像なら200KB前後以下を一つの目標にします。
ただし、230KBから180KBへ減らすために文字が崩れるなら、無理に減らす必要はありません。
逆に、簡単なイラストで60KBまで落としても違いが見えないなら、そのまま使えます。
手順4：公開後にスマホとPageSpeed Insightsを見る
最終判断は編集画面ではなく、公開ページで行います。
スマートフォンで画像が読めるか、極端に読み込みが遅くないかを確認します。
必要であればPageSpeed InsightsでLCPや画像関連の診断を見て、問題が確認できた部分だけ改善します。
この方法なら、「847pxが正解なのか」「200KBを3KB超えたから作り直すべきか」といった細かな迷いを減らせます。
特に副業ブログでは、画像1枚ごとに最適解を探す時間もコストです。
画像品質だけでなく、判断に使う時間まで含めて最適化するという視点を持つと、運営を継続しやすくなります。
これは私がウェブマーケティングやサイト運営を見てきたなかでも重要だと感じる点です。
高度な画像圧縮技術を一度だけ完璧に使える人より、「通常画像は1,000px前後」「図解だけ必要なら大きくする」「公開後はスマホで見る」という簡単なルールを毎回守れる人のほうが、サイト全体の品質を一定に保ちやすいからです。
まとめ
ブログ画像サイズは、本文なら横700〜1,000px程度、迷ったら1,000px前後、容量は200KB前後以下を最初の運用目安にすると分かりやすいです。
ただし、Googleが「1,000px・200KB」をSEOの公式基準として定めているわけではありません。
大切なのは、画像の文字や内容がスマートフォンでも読めること、そのうえで不要な巨大データを送らないことです。
通常画像は1,000px前後から始め、写真ならJPEGやWebP、図解ならPNGやWebPを候補にし、画質と容量を実際に比較してください。
WordPressでは4.4以降のレスポンシブ画像、5.5以降に導入されたネイティブ遅延読み込みなどの仕組みもありますが、初心者が最初に行うべきことは複雑ではありません。Make WordPress+1
巨大な元画像を必要な寸法へ縮める。画質を見る。容量を確認する。スマホで確かめる。
この4点を毎回同じ順番で行うことが、ブログ画像サイズで迷わない最も再現性の高い運用方法だと私は考えています。
よくある質問
ブログ画像は横幅何pxにすればいいですか？
通常の記事内画像なら、横700〜1,000px程度が一つの実務目安です。
迷った場合は1,000px前後から始め、WordPressテーマの本文幅やスマートフォンでの見え方に合わせて調整してください。
ブログ画像が200KBを超えるとSEOに悪いですか？
200KBはGoogleが定めたSEOの合格基準ではないため、超えたことだけでSEOに悪いとは判断できません。
文字が読めなくなるほど圧縮するより、必要な画質を保ちつつ、可能な範囲で容量を減らすほうが合理的です。
ブログ画像は全部WebPにすべきですか？
WebPは有力な選択肢ですが、すべての画像で必ずJPEGやPNGより小さくなるわけではありません。
Google検索はWebPのほかJPEG、PNG、AVIFなど複数形式をサポートしています。実際の画像で画質と容量を比較して決めるのが確実です。Google for Developers
WordPressなら大きな元画像をそのままアップしても大丈夫ですか？
WordPressは`srcset`と`sizes`を使ったレスポンシブ画像をサポートしているため、画面幅に応じて別サイズが選ばれる場合があります。WordPress Developer Resources
ただし、メディアライブラリやバックアップの容量まで考えると、ブログで必要のない4,000px級の画像はアップロード前に縮小しておくほうが管理しやすいでしょう。
PageSpeed Insightsは90点未満なら問題ですか？
Lighthouseでは90〜100が「良好」、50〜89が「改善が必要」、0〜49が「低い」と分類されていますが、点数だけでページ価値が決まるわけではありません。Chrome for Developers
画像が読者の理解に必要なら、単に点数を上げるためだけに削除するのではなく、容量や読み込み方法を改善できないか先に確認することをおすすめします。
確認した主な公式資料
本稿では2026年9月14日時点で、Google検索セントラル「画像のSEOベストプラクティス」、WordPress Core「Responsive Images in WordPress 4.4」（2015年11月10日）、WordPress Core「Lazy-loading images in 5.5」（2020年7月14日）、WordPress Developer Resources「Responsive Images」、web.dev「Web Vitals」「Optimize Largest Contentful Paint」、Chrome for Developers「Lighthouse のパフォーマンス スコアリング」を確認しています。Chrome for Developers+6Google for Developers+6Make WordPress+6
仕様や推奨事項は将来変更される可能性があるため、WordPressやGoogle関連の技術情報を実装するときは、最新の公式資料も確認してください。
ブログ画像だけでなく、SEO・記事設計・サイト運営を体系的に整理したい方はこちらも参考にしてください。
👉 黒木智也のプロフィール・関連情報を見る
↓↓↓
https://utage-system.com/p/dnGib1s5QNx6/1nZcAFenGERf
黒木智也（くろきともや）
ウェブマーケター
コメント