Define which details must survive
Keep the original asset and identify its purpose before producing alternatives. A photograph, a screenshot with small labels and a transparent logo have different visual requirements. List the details that a reader must recognize, such as a product edge, a diagram label or a face, and the display sizes used by the page.
Record the existing file format, pixel dimensions and bytes. Do not confuse reducing pixel dimensions with changing compression: either can affect the result. If several variables change at once, retain enough notes to explain which candidate was chosen and why, rather than describing every smaller file as equivalent quality.
Prepare a small candidate set
Generate candidates from the original rather than repeatedly recompressing an already degraded derivative. Choose dimensions that suit the actual placements and compare appropriate format and quality settings. The official web.dev material distinguishes lossy and lossless compression and emphasizes that there is no universal compression setting for every image.
Keep the comparison manageable: one baseline and a few named candidates with recorded settings. Preserve transparency when the design needs it. Do not promise a fixed percentage saving before examining the output; the content of the image affects both size and visible artifacts.
Inspect the image in its page context
Compare candidates at the intended rendered size and inspect a larger view when detail is important. Look for ringing around text, softened edges, banding in gradients or damaged transparent boundaries. A candidate that looks acceptable as a thumbnail can fail when the same asset is used in a larger component.
For Arabic screenshots, check the small letter shapes and labels directly rather than judging only the surrounding interface. Ask a reviewer familiar with the content to confirm that the information remains readable. Do not use an attractive file-size reduction to override a failed readability check.
Illustrative example: an interface screenshot
Imagine a fictional tutorial screenshot with small Arabic labels. Candidate A is smaller but makes two labels difficult to distinguish; candidate B is slightly larger and preserves them at the article’s display size. The editor rejects A and records B as the preferred candidate, provided its larger placement also passes review.
This decision protects the screenshot’s instructional purpose. It does not establish that B is optimal for every page or that a visitor’s connection became faster. The review sheet stores the candidate name, export settings, bytes, tested placements and reason for selection. No measured customer result is implied by this example.
Verify delivery and retain a rollback asset
After integrating the selected candidate, inspect the actual request made by the browser in each relevant layout. Confirm that the intended file is delivered and that an old cached or oversized variant is not still used. Check the final visual result, including cropping and transparency, on the page itself.
Keep the original and the accepted export settings so a later design change can produce a suitable derivative. Measure any performance claim separately under comparable conditions; a smaller image does not prove a specific timing gain. A website audit can flag large transfers, while visual acceptance determines whether reducing them has preserved the image’s purpose.