Written by Nemanja Falb — founder and developer of TinySharp, working on WordPress image optimization, browser-based image workflows and practical website performance tooling.
Content teams do not usually fail image optimization because nobody knows how to compress a file. They fail because five people publish images in five different ways.
One editor uploads the photographer’s original. Another exports every graphic as PNG. A contractor renames files after upload. A marketer compresses screenshots until the text becomes soft. A developer later discovers that the CMS generated new thumbnails from already inconsistent sources.
The solution is not “use a better compressor.” It is a small operating system for image publishing.
Define one source of truth
Separate source assets from web delivery assets.
- Source assets are originals used for editing, future crops and re-exporting.
- Delivery assets are the files approved for websites, campaigns, newsletters or other publishing systems.
Do not repeatedly download an already compressed website image, edit it and compress it again. That creates generation loss and makes quality harder to control.
A simple folder structure is enough:
/project
/source
/approved
/archive
The exact storage platform matters less than the rule: nobody should wonder which file is the master.
Create asset classes before creating presets
Do not start with “quality 80 for everything.” First classify recurring assets.
| Asset class | Typical examples | Primary risk |
|---|---|---|
| Editorial photo | Blog headers, news images | Oversized dimensions |
| Product photo | PDP and catalog assets | Loss of buying detail |
| UI screenshot | Documentation and product pages | Soft text and edges |
| Transparent graphic | Logos, cutouts, overlays | Broken alpha edges |
| Social preview | OG and campaign cards | Wrong crop or unreadable text |
Each class can then have a recommended dimension range, format strategy and QA rule.
Use presets as defaults, not as unquestionable rules
A preset should reduce decision fatigue. It should not hide bad outputs.
For example, a team might use:
- editorial photos: resize to the site’s real content width, then compare modern delivery output;
- screenshots: preserve text clarity and review at 100%;
- transparent graphics: preserve alpha, then compare PNG and suitable modern formats;
- social previews: export to the exact campaign aspect ratio and keep text readable.
If a file becomes larger after conversion, keep the smaller acceptable version. “Converted successfully” is not the same as “optimized successfully.”
Standardize filenames before publishing
Renaming after a file has become a public URL creates unnecessary cleanup. Use a naming convention before upload.
A good filename is:
- descriptive enough for humans;
- short enough to remain readable;
- consistent in lowercase and separators;
- free of internal version noise such as
FINAL-final-v7; - not stuffed with repeated keywords.
Keep internal production versioning in your source system, not in every public asset URL.
Process batches by risk, not only by quantity
A batch of 200 near-identical product thumbnails is lower risk than 40 mixed assets containing screenshots, transparency, photography and social graphics.
Group similar assets together. That makes it easier to:
- use a relevant preset;
- spot outliers;
- compare output size consistently;
- sample quality without opening every file.
Use representative QA sampling
Teams rarely have time to inspect every image manually. They still need a quality control system.
For each batch, review:
- the largest file;
- the smallest file;
- one dark image;
- one high-detail image;
- one image with text if present;
- one transparent asset if present;
- any file with unexpectedly low or high savings.
Outliers often reveal a wrong preset faster than random inspection.
Define what counts as a failed optimization
A failed optimization is not only a technical error.
Track separate outcomes:
- Optimized: smaller output with acceptable quality.
- Kept original: converted or compressed output was not a better result.
- Needs review: visual quality is uncertain.
- Failed: processing error or unsupported file.
This prevents the team from reprocessing “kept original” assets every week as if they were unfinished.
Keep a rollback path for high-value publishing systems
When images are replaced in a CMS, record enough information to recover:
- original filename;
- new filename;
- original size;
- optimized size;
- processing date;
- responsible batch or campaign;
- backup location or restore mechanism.
The more automated the replacement process becomes, the more important recovery becomes.
Separate optimization from frontend verification
The batch can be perfect and the website can still serve the wrong asset.
After publication, sample live pages and verify:
- the final file URL;
- the content type delivered by the server;
- the responsive candidate selected by the browser;
- whether offscreen images are loaded too early;
- whether critical above-the-fold images are delayed;
- whether the CDN is serving an old cached asset.
For browser-level inspection, use the workflow in How to Audit Page Images With a Chrome Extension.
Measure the process, not only total megabytes saved
“We saved 2 GB” is useful, but it does not tell you whether the publishing workflow improved.
Track a few operational metrics:
- percentage of uploads above the team’s maximum dimension;
- percentage of files that need manual rework;
- median file size by asset class;
- number of assets kept as original because conversion was not beneficial;
- number of live pages with oversized image delivery;
- time between source delivery and approved web asset.
These metrics reveal whether the team is preventing problems earlier.
A practical content-team SOP
- Intake: receive source files and confirm the final use case.
- Classify: photo, screenshot, transparent graphic, product asset or social preview.
- Resize: prepare dimensions for the real publishing placement.
- Name: apply the public filename convention.
- Batch: group similar assets and process together.
- Compare: keep the output only when it is genuinely better.
- QA: inspect representative files and outliers.
- Publish: upload approved delivery assets.
- Verify: sample the live frontend.
- Archive: preserve sources and the rollback path.
Frequently asked questions
What is the best batch size for image optimization?
The right batch is the largest group your team can process, review and recover safely. Similar asset types matter more than an arbitrary number.
Should every team member choose their own quality settings?
No. Use shared defaults by asset class, then allow exceptions when visual requirements justify them.
How do we stop already optimized files from being processed again?
Track processing state or checksums, and record intentional “kept original” results so those assets are not treated as unfinished.
Should source files be stored in the CMS?
Only when the CMS is intentionally your source archive. Many teams keep editable masters in dedicated storage and upload purpose-built delivery files to the CMS.
How often should a content team audit live pages?
Audit after major template or CDN changes and on a recurring sample of high-traffic pages. The goal is to catch workflow drift before it affects the whole library.
Continue the workflow
Use the TinySharp Bulk Image Converter for repeatable batches, the Image Compressor for one-off review, and the Chrome Extension to verify live delivery.
