Updated: June 20, 2026
To compress blog images before publishing, resize each image to the maximum width your layout displays, choose a format suited to the image type, gradually lower the quality setting while checking the output at your actual display size, and record the final file size before uploading. This pre-publish step gives you full control over what reaches your CMS — format, dimensions, and weight — rather than depending on plugin defaults to fix bloated uploads after the fact.
Key Takeaways
- Resize before you compress. Cutting pixel dimensions to your real display width removes the most weight; compression then refines what remains.
- Format choice matters as much as the quality slider. WebP is a practical default for photographs; SVG for logos; PNG for graphics requiring lossless fidelity; AVIF where maximum compression is needed and a fallback is available.
- Quality settings are a starting point, not a universal scale. A "quality 80" value in one tool is not equivalent to "quality 80" in another. Adjust gradually and compare the output at your actual display size.
- File size targets are an editable budget, not an official standard. Common starting points: under 150 KB for inline images, under 200 KB for a hero. Your real target depends on layout, responsive variants, and performance testing.
- Verify after compressing. Record the output size and spot-check the published LCP element with PageSpeed Insights — the hero is often, but not always, the largest element on the page.
What Should Happen Before an Image Reaches Your CMS?
Many blogs upload full-resolution originals and rely on a CMS plugin or CDN to compress them on delivery. Plugin defaults may not match your specific file-size goals, and the original heavy file remains in your media library. Pre-compressing before upload means the file that arrives in your CMS is already at the format, dimensions, and weight you intend.
Pre-compression and CMS or CDN optimization are not mutually exclusive. Pre-compression handles the source file; CDN and responsive image pipelines handle device-specific delivery. Using both gives you the most control: you set the starting quality, and the delivery layer handles the rest.
The hero image on a blog post is often the Largest Contentful Paint (LCP) element — the time until the largest visible element finishes loading — which Google includes in its page experience assessment (Google Search Central; web.dev LCP). Image bytes are one possible contributor to poor LCP, alongside server response time, resource discovery, and render-blocking resources. Compressing the hero image is a useful early step, but verify the actual LCP element with PageSpeed Insights rather than assuming it is always the image.
How to Compress Blog Images Before Publishing
Step 1: Resize to Your Real Display Width
Before touching a compression setting, resize the image to the maximum width your theme actually renders. Uploading a 5 000 px camera original when your content column renders at 800 px means every visitor downloads pixels their screen will never display. Resizing first removes that weight at the source; compression then works on a smaller canvas.
The table below lists common starting budgets. Treat these as an adjustable benchmark — your actual targets should be driven by your CSS layout, responsive breakpoints, and real performance measurements.
| Image role | Example starting width | Example size budget |
|---|---|---|
| Inline content image | 1 200–1 600 px | under 150 KB |
| Full-width hero | 1 600–2 000 px | under 200 KB |
| Thumbnail or card | 400–600 px | under 50 KB |
| Logo or icon | Exact display size | under 20 KB (or SVG) |
Starting budgets only. Final targets should reflect your layout, responsive strategy, and page performance testing.
If you serve responsive images with srcset, generate the variant widths from the already-resized master — not from the original camera file.
Step 2: Choose the Right Format for the Image Type
Format choice often saves more file weight than adjusting the quality slider. The right format depends on the image content, not a single rule for all images.
Format decision guide:
| Image type | Recommended format | Reason |
|---|---|---|
| Photograph | WebP (lossy) | Smaller than JPEG at similar quality; widely supported |
| Photograph (max compression) | AVIF with WebP fallback | Can be smaller than WebP; check current browser support |
| Screenshot with text or sharp UI | WebP lossless or PNG | Lossy compression can blur text edges; test before deciding |
| Graphic with transparency | PNG or WebP lossless | Preserves hard edges and alpha channel |
| Logo or simple illustration | SVG | Infinitely scalable; smallest file for vector art |
| Icon | SVG or WebP | SVG preferred for vector; WebP for raster variants |
For photographs, WebP is a practical default for blogs that need broad compatibility — it is smaller than JPEG at similar visual quality and is supported across modern browsers (see MDN WebP compatibility for current data). AVIF can produce smaller files than WebP under comparable settings, but encoding time varies by tool and codec, and browser support, while growing, should be confirmed against your target audience before dropping a fallback (Alliance for Open Media AV1 Image File Format).
Keep PNG for graphics where every pixel must be exact — diagrams, UI screenshots with fine text, images that require transparency. For photographic content, PNG files are much larger than lossy formats and rarely necessary.
Step 3: Choose Lossy or Lossless Compression
Lossy compression permanently discards visual data that the eye registers less acutely — fine grain, subtle gradients — in exchange for much smaller files. It is the right choice for most photographs and blog imagery. The quality setting controls how aggressively data is discarded.
How to find the right quality setting:
- Start at a relatively high quality value (e.g., 85 for JPEG, 80 for WebP in your tool of choice).
- Export and compare the output against the source at your actual display size.
- Reduce the quality by 5–10 points and compare again.
- Stop when you see the first perceptible difference in areas that matter: text in the image, faces, sharp gradients.
Note that quality numbers are not equivalent across formats or tools. A "quality 80" in one encoder is not the same as "quality 80" in another. Use the visual comparison — not the number — as your acceptance criterion. Low quality settings tend to introduce banding in gradients, blurring on text edges, and blocking in high-contrast areas; check those regions specifically.
Lossless compression preserves the exact pixel data after decoding. Use it for screenshots with fine text, diagrams, logos, and graphics where any alteration is unacceptable. Lossless compresses by eliminating redundant encoding patterns without changing pixel values.
Step 4: Compare the Output Before Uploading
After compressing, record the output file size and review the image at your actual display size before uploading. A browser-based tool such as LessMB lets you compress images before they reach your CMS, making it straightforward to compare the compressed result against your size budget before you upload anything.
Pre-publish image checklist:
- Pixel width matches your layout (not the camera original)
- Format is appropriate for the image type (see Step 2 table)
- Output file size is within your role-based budget
- Quality setting passes a visual check at actual display size — check gradients, text, and fine detail
- Informational images have descriptive
alttext; decorative images use an emptyalt="" -
widthandheightattributes reflect the correct aspect ratio so the browser reserves space and avoids layout shift (web.dev: Optimize Cumulative Layout Shift) - After publishing, confirm the actual LCP element using PageSpeed Insights and check whether image weight is a contributing factor
How to Set an Image Size Budget
File size budgets are editorial guidelines, not search engine requirements or Core Web Vitals thresholds. Google's Core Web Vitals assess LCP timing, layout shift, and interaction delay — they do not define a maximum image file size. The connection is indirect: smaller image files typically reduce download time, which can lower LCP.
A practical approach to setting your own budget:
- Identify the widest image slot in your layout and the responsive breakpoints where smaller variants are served.
- Use PageSpeed Insights or Chrome DevTools Network panel to measure the current image transfer sizes on a representative post.
- Set a target that gets your LCP into the "Good" range (under 2.5 seconds as assessed by field data or lab testing) on your typical connection type.
- Adjust the budget per image role — hero, inline, thumbnail — based on how each contributes to page weight.
Example: Compressing One Blog Hero Image
The following example shows what a typical compression step looks like. Because file size depends on image content, encoder, and settings, the numbers below are illustrative of the process rather than a guaranteed outcome for your images.
Scenario: A 4 000 × 2 700 px JPEG original, 3.8 MB, intended for a 1 600 px wide hero slot.
| Step | Action | Result |
|---|---|---|
| 1. Resize | Resize to 1 600 × 1 080 px | Approximately 10× fewer pixels |
| 2. Format | Export as WebP (lossy) | — |
| 3. Quality | Start at quality 80; compare against source | Output passes visual check |
| 4. Record | Note file size; compare to budget | Confirm within 200 KB budget |
| 5. Verify | Check alt text, width/height, and LCP element after publish | — |
Run this comparison on your own test image to find the quality setting that meets your visual standard at your target display size. Do not apply the same quality number to every image without checking each one.
When CMS or CDN Optimization Is Still Useful
Pre-compressing before upload and using CMS or CDN image optimization together is a reasonable workflow, not a contradiction. Each layer handles a different concern:
| Layer | What it handles |
|---|---|
| Pre-compression (your step) | Source format, starting dimensions, initial quality |
| CMS plugin | Variant generation on upload, delivery format negotiation |
| CDN | Responsive resizing, next-gen format serving, caching |
If your CMS or CDN automatically generates WebP or AVIF versions and serves the appropriate size per device, you may be able to use a less aggressive pre-compression target. The key benefit of pre-compressing first is that your media library stores a clean, intentionally sized source file rather than an unmodified original.
Common Image Problems and How to Fix Them
| Problem | Likely cause | Fix |
|---|---|---|
| File size is still large after compression | Image was not resized before compressing | Resize to display width first, then compress |
| Text or gradients look blurry or banded | Quality set too low for this image | Raise quality and re-compare; use lossless for text-heavy graphics |
| Transparent background shows unexpected color | Format does not support alpha, or wrong export settings | Use PNG or WebP lossless; verify export settings |
| Page LCP is slow despite small images | LCP element is not the image, or image is not preloaded | Check actual LCP element in PageSpeed Insights; consider <link rel="preload"> for the hero |
| PNG is larger than expected for a photo | PNG is lossless and not suited to photographs | Switch to WebP lossy or JPEG for photographic content |
Practical Next Steps
- Define your image size budgets per role using the Step 1 table as a starting point, then validate against real LCP measurements on your highest-traffic posts.
- Set your default export format to WebP for photographs; adjust quality by comparing the output at display size.
- Add the Step 4 checklist to your editorial workflow so every image is reviewed before upload.
- Prioritize retroactive compression on posts with high traffic, large image payloads, or known LCP issues — use PageSpeed Insights field data to identify which posts have actual Core Web Vitals problems rather than targeting a fixed number of posts.
FAQ
What file size should a blog image be?
There is no universal file size requirement from search engines or browser standards. A common starting budget is under 150 KB for inline images and under 200 KB for a full-width hero. Your actual target should be guided by your layout width, responsive variants, and real performance testing. Measure your LCP on representative posts with PageSpeed Insights to see whether image weight is a contributing factor.
Should I resize an image before or after compressing it?
Resize first. Shrinking the pixel dimensions to the largest size your layout actually displays removes the most file weight. Compressing a full-resolution original without resizing first leaves most potential savings unused.
Does compressing images hurt SEO or quality?
When done carefully, lossy compression at moderate quality settings produces results that are visually close to the original at typical display sizes, while substantially reducing file size. This can improve page load time and Largest Contentful Paint, which is a factor in Google's Core Web Vitals assessment. Always compare the compressed output against the source at your actual display size before publishing.
Is WebP or AVIF better for blog images?
For blogs that need broad browser compatibility, WebP is a practical default: it produces smaller files than JPEG at comparable quality and is widely supported across modern browsers. AVIF can produce even smaller files in many cases, but encoding time varies by tool, and support should be confirmed for your target audience. Check current compatibility data (e.g., MDN) before dropping a WebP or JPEG fallback.
Should I use PNG or WebP for screenshots?
It depends on the content. For screenshots with fine text or sharp UI elements, WebP lossless or PNG both preserve detail well. If lossy WebP compression does not introduce visible artifacts on text edges at your display size, it will usually produce a smaller file. Test both and compare before deciding.
Do I still need to compress images if my CMS or CDN optimizes them?
Pre-compression and CMS or CDN optimization address different concerns and can work together. Pre-compression ensures your media library stores a clean, intentionally sized source file. CMS or CDN tools then handle responsive delivery and format negotiation per device. Relying solely on CMS or CDN defaults means your source files may remain larger than necessary and default settings may not match your size targets.
How can I tell whether an image is causing poor LCP?
Run PageSpeed Insights on the published page. The LCP section identifies the actual LCP element. On article pages the hero image is often, but not always, the LCP element. If the image is the LCP element and the score is poor, check its file size, whether it is preloaded with <link rel="preload">, and whether a render-blocking resource is delaying it.
Sources
- Google Search Central — Core Web Vitals and Google Search
- web.dev — Largest Contentful Paint (LCP)
- web.dev — Optimize Cumulative Layout Shift
- MDN Web Docs — Image file type and format guide
- Alliance for Open Media — AV1 Image File Format (AVIF) specification
- W3C/WAI — Images Tutorial: Decorative Images
- Google — Image SEO best practices