Smarter Image Compression for the Modern Web
Choose the displayed size, compare real exports and verify the image that the published page actually downloads.
Content updated:
Start with the space on the page
A useful web image has enough detail for its display slot without carrying unnecessary pixels. Write down the typical and largest displayed widths before exporting. A card image and a full-width hero do not need the same source dimensions.
For an illustrative card displayed at 400 CSS pixels wide, compare 400- and 800-pixel-wide candidates on your target screens. The larger candidate may help a high-density display, but it also has more pixels to encode. Choose by appearance and bytes rather than assuming one size is best everywhere.
Select a format for the content
For an opaque photograph, compare JPG and WebP where the destination supports both. For a transparent graphic or text-heavy screenshot, start with PNG and assess whether a lossy alternative damages the important edges. Converting a file to a newer format does not guarantee that it becomes smaller.
TheImageIs exports let you inspect actual sizes. The compression quality number is an encoder control, not a percentage of original detail retained, and equal numbers in different formats do not imply equivalent quality. Compare the saved outputs at the same dimensions.
Use a small comparison record
Record the source filename, output dimensions, format, chosen quality or target, actual bytes and a visible-detail note for each candidate. For example, note whether a small product label stays readable or a sky develops visible bands. These observations make a decision reproducible.
Calculate savings only after measuring both files: (original bytes − output bytes) ÷ original bytes × 100. If the output is larger, report that honestly. A larger output can still be needed for transparency or a compatibility requirement.
Check the published request
Exporting a smaller file helps only when the page serves it. After upload, inspect the image request in the browser's Network panel or the CMS's image preview. A theme, plugin or CDN may create different sizes or continue to serve an older asset.
Responsive image markup can offer several widths using srcset and describe the display slot with sizes. Include image dimensions so the page can reserve space. These are publishing controls separate from compression; a file export alone does not configure your website's delivery.
Set a sensible stopping rule
Accept the smallest candidate that meets the actual dimensions and preserves the important detail at the intended viewing size. Do not keep lowering quality solely to win a byte comparison. A label nobody can read is not a successful optimization.
Keep the master and export new variants from it. Measure page performance separately if speed is the goal: caching, network conditions, scripts and other resources also affect loading. A smaller image is evidence of fewer image bytes, not a guaranteed page-speed score.
Compare two sizes and two formats
A guided exercise, not a benchmark. Inspect your own output; results depend on the source and settings.
- Choose an image and write down the page slot's intended display width.
- Export two appropriate widths, then compare JPG and WebP for the same width where both are accepted.
- Record actual bytes and a specific detail check for each candidate.
- Upload the chosen copy and verify that the page requests the intended image or an appropriate generated variant.
The chosen file should meet the upload requirements and preserve necessary details; the published page should request the expected asset. Record page-speed results only if separately measured.
Sources & further reading
Try an idea and review your result before saving your edits.
